The Thinkpad T14s 2-in-1 with Intel Core Ultra 5 has great battery life: 10+ hours with moderate usage. I also have the Snapdragon T14s which gets about 14 hours, but I'm still waiting to get full Linux support for this two year old laptop.
Note however, since I've been using my Thinkpad 2-in-1 on battery almost everyday for a year, it is somewhat degraded. upower shows
I'd love to give someone at Verda a demo of https://github.com/purpleidea/mgmt/ to show them how they could actually do fast provisioning and automation. Seeing Ansible+Kubernetes+K* stuff in their jobs offering does not inspire confidence that they're innovating in building their core infra. You can't out-compete AWS or even the smaller clouds there.
My personal bet is there's an 80% chance this is caused by some internal bootstrapping problem that they've messed up. AIUI all the main cloud vendors are in trouble here. The automation project I work on is expressly designed to help folks solve this DR/bootstrapping problem. Soo many people get this wrong. Of course missiles don't help things, but I'd bet AWS is primarily to blame here. I'd love an actual technical report of why they can't recover things.
I work on the same kind of thing, and while we think hard about bootstrap problems, we always find new surprising ones. The problem is you never know until you do it, and creating a faithful test of restarting giant systems is economically impossible. Because if you say to the boss, "look, I need 1 million now to test against a maybe 100 million loss, maybe in 10 years" they don't give you the money (and rightly so).
Even if you did the $1MM test there is very low likelihood that the $100MM event would be fully mitigated 10 years down the line (after who knows how many changes - physical, logical, and even in the org chart).
The only way to approach readiness here is repeated investment - like one team doing the deep dive and another pulling cables and then constantly doing pre- and post-mortems.
Signal needs to release all the infra automation code behind their backend. How they setup and manage it all should not be secret. It also makes it easy to rebuild if for some reason they are compromised. They've ghosted multiple people about this question. There's no reason a 501(c)(3) shouldn't release it.
Signal is there for power and control, not for its users, otherwise they would welcome the usage of third party clients, and generally, encourage decentralisation measures like self hosting, federation and account portability. Yep, they have nice engineering blog posts, they are also US-incorporated, extensively centralised in AWS and subject to the cloud act, which together negates, or largely diminishes claims about being privacy conscious.
That's a defeatist take that's been vastly debunked, someone linked the Matrix version and here is the XMPP one: https://gultsch.de/posts/objection/
In short, yes, building a standard takes some effort, but that serves your users and to future-proof your solution. Moxie's post boils down to "1- I know better than my users and I don't need input to protocol-design, 2- I'm not willing to put in the effort to standardize and document, 3- I reserve the right to change the deal for whatever reason if I ever feel the need" which is not a good look
Matrix is a vastly different protocol with vastly different privacy implications. Things like leaking reaction metadata outside of the encrypted envelope (though there finally is an MSC to fix that) should make that obvious. Matrix is cool tech and I use it every day, but comparing Matrix to Signal doesn't make much sense. You can't do what Signal does with Matrix or XMPP, simply because the lack of federation affords privacy and security advantages that federated protocols cannot support.
As for Moxie's post: all three points feel completely valid for a service they're offering for free. Moxie does know better than most users (most users don't know the first thing about software, programming, protocol design, or UX design) and it's a companies choices that drive users to their platform in the first place. Users who don't like it can choose from the dozens of other chat apps instead.
As for the second point, Matrix's ever-moving target of a protocol makes selecting a client or server that covers all of your needs a massive pain. Currently, Matrix's primary server software, Synapse (which is also at the base of the matrix.org server many people default to when joining the network), is violating the Matrix protocol, making it impossible to invite users to chat if they are on compliant Matrix servers. On the XMPP side, there are two different methods of achieving E2EE communication, with seemingly no standard mechanism to support the use case "I want to log in to my chat on my laptop and be able to decrypt the messages in the group chat". I can't blame Signal for not wanting to deal with issues like that. One piece of server software, one set of client versions, with fixes ready to deploy when they're called for: Signal's current design saves a lot of time and effort.
As for the third point, that's part of the reason I use Signal in the first place. I like federated networks as much as the next nerd and I like open standards even more, but the decisiveness behind the company, even when I disagree with their decisions sometimes, is what makes it clear what you can and cannot expect.
On the XMPP defence: yes, I believe what they are saying, XMPP could in theory be a good product, just like Matrix could be, and like Signal is. However, currently, it isn't. XMPP is currently losing in terms of public marketshare to Matrix, which I also wouldn't exactly call a great success.
> As for the second point, Matrix's ever-moving target of a protocol makes selecting a client or server that covers all of your needs a massive pain. Currently, Matrix's primary server software, Synapse (which is also at the base of the matrix.org server many people default to when joining the network), is violating the Matrix protocol, making it impossible to invite users to chat if they are on compliant Matrix servers.
This will be referring to enforcing MSC4311 (https://github.com/matrix-org/matrix-spec-proposals/pull/431...) stripped state validation. Synapse announced a 1 year compatibility window to avoid ecosystem fragemtnation: https://github.com/element-hq/synapse/issues/19943. However, due to MSC4311 not better outlining how to handle compatibility, another server implementation chose to enforce the MSC more rapidly, breaking compatibility with everyone who hadn't yet implemented the MSC - including Synapse, which hadn't actually implemented it yet. Speaking as the lead of the Matrix Spec Core Team, we should have handled this better. https://github.com/element-hq/synapse/pull/19723 is the Synapse implementation which is now in the process of landing.
As a former XMPP believer, I will say that the extremely fragmented capability state of the XMPP ecosystem, whatever people may claim, is the exact proof that vindicates Signal's position.
As a XMPP user in the modern times, XMPP ecosystem and its alleged fragmentation affects me and my users about… never. Every major platform has at least one decent client that support all essential features (reactions, message corrections, A/V calls, easy onboarding, modern encryption, …) and every one of them receives a healthy flow of contributions. Client developers talk to one another, coordinate protocol discussion and features roll-out (reactions for instance didn't happen "overnight", but pretty close).
I'm certainly not willing trade a theoretical minor annoyance in exchange for my (literally) vital messaging needs to be subject to enshittification, or abuse by a single actor (which controls whether I can access the network, when, whom I can speak with, what features I am allowed to use, and whether it's time to rope me into buying some cryptoshitcoin).
what does debunked here mean? like I can right now go on websites with firefox or safari and they will not be displayed properly. I do personally think federation is worthwhile, but I think it's a bit much to say Signal only cares about power and that all their reasoning for what they did are debunked or w/e.
I've attended the eponymous CCC talk and I've never seen any other talk there where the Q&A section has just immediately turned into nearly everyone almost dunking on the presented ideas. It's a rather poor take (or at least "controversial" if you will).
Realistically nothing is ever perfect, but XMPP comes very close. You've got Signal-introduced double-ratchet encryption if forward secrecy is your jam (so it's as "E2E-secure" in practical terms) and you've got a healthy ecosystem of independent client and server implementers, and service providers to choose from.
> Does the perfect messaging tool exist (100% e2ee encrypted and decentralized and open)?
(Note that I don't care about cryptocurrencies except for the cryptography behind it)
There are fully anonymous cryptocurrencies using ZKP where it's not possible to tell if a transaction sent is a transfer of the cryptocurrency itself or a message. It's decentralized and it's also impossible to tell who the transaction is made for (anyone with a copy of the chain can potentially be the recipient of either the money transfer or the encrypted message).
If people were really serious about privacy and secure messaging they'd look into this instead of constantly attacking the concept.
But then of course there are entire armies of shills who have a vested interest in pushing a narrative explaining that services, at best, collecting metadata and, at worst, being backdoored are offering "secure messaging".
I'm only using Telegram and I don't believe for a second it's secure and private (it's got, supposedly, "one on one" E2EE but not for groups). But at least they're not posturing as the most secure and private messenger on earth.
Is there a messenger that allows anonymous group chats, i.e. for union organizing in a company?
As far as I can see, you can invote people to a group chat using QR flyers, but your Signal profile is visible to everyone in a chat, so everyone knows what Tina in marketing thinks about it.
Because nobody is going to have a burner phone with a data plan for a separate Signal identitiy.
Why not? Plenty people already use a dedicated '2FA' phone for Work under BYOD policies when they don't want to install any 'work' software on their 'personal' phone.
Depending on your needs, XMPP or Matrix are probably your best bet. Both have different clients of varying usability and quality on different platforms, so you have to pick your poison. If E2EE is important, you also need to determine how encrypted you want your messages to be (as both XMPP and Matrix carry quite a bit of identifying metadata in its unencrypted headers).
For most people and use cases, either will probably do, but if you're a human rights activist or journalist in an oppressive country, I'd stick to Signal.
> if you're a human rights activist or journalist in an oppressive country, I'd stick to Signal
So that the state actor can listen on the edge of the network and infer with whom you are taking and when? Or maximize their chances of finding a 0-day in the client considering that it's the same client that everyone else's using? Or throwing it all away anyways when it's using Apple/Play services for notifications delivery?
I mean, as opposed to using something like XMPP which you can completely use over Tor and never even reveal which server you use/that you use XMPP, from a client running a secure and minimalistic OS and no service-in-the-middle ?
Some would label Signal as a honeypot and it would be difficult to falsify that.
Apple, at least, maintained a historical database of your phone's notifications, that it did not clean up after they expired. That includes all notifications from Signal telling you that person XXX has sent you a message that starts YYYY <facepalm>
Forgot about that and that def was bad, though imo not really on Signal and would have just as much affected any XMPP app, no? To me this definitely didn't "[throw] it all away" as in your messages were still only on your phone and never decrypted on any server or w/e.
Well that's the thing, you just don't know what happens once you let Signal send notifications via Apple/Google - clearly they get them plaintext, and who knows if they're retained and subpoena-able directly from Apple/Google. The leak via notifications DB not being cleaned up is just the shot across the bow. You pay a price for convenience.
Anyway, I'm not OP, and they have a mad setup (XMPP via Tor) which is a flaky solution most people wouldn't go for. In general, if you're not going to such extreme measures of hiding among the crowd of Tor users to mask your metadata, you're better off directly connecting and hiding among the crowd of Signal users, rather than hosting your own instance.
to be clear though notifications do the decryption on device themselves. signal uses apple/play services only to notify the device that there has been a message, none of the contents are delivered over these services. if you cant trust the device to do that then no messaging app could ever be secure enough
De-jure it's against the ToS, but it's not being enforced besides "don't be an asshole, don't abuse the network and be careful with Signal branding". Technically, you can use Whisperfish on SailfishOS, Flare on mobile-linux-of-the-day or even signal-cli as a primary device.
"...otherwise they would welcome third party clients..."
Signal app can update itself at any time
The app is constantly phoning home to Signal servers checking for updates even when it has not been launched and is not being used
That means the client could change at any time, for any reason, unbeknownst to the user
If the advanced user is free to write, edit and compile source code for a Signal client, software developers might call this a "third party client" because there is allegedly some "business transaction" between Signal Corporation and the user where Signal Corporation and the user are first or second parties (although, curiously, the Signal app and service are free)
But it's arguable the more important use of the term "third party" in this context, i.e., "secure" communications, is to indicate a party that is not a first or second party to the communication, a potential eavesdropper
Signal Corporation is a third party to the communication
Because it forces users to use its closed source client software that can be updated at all times for any reasons when it's installed on a user's computer, there exists the potential for remote code execution and, for example, eavesdropping
For example, a US corporation subject to US law could be legally forced to eavesdrop on a particular user. This could be done with an "update"
Are you a LLM? In this context, a third party client clearly refers to "a Signal app/client software that's not distributed by Signal",
The point I was making is that this goes against Signal's terms of service, and can get your user account terminated. That's a very oppressive clause in practice, you may want to use a non-signal client for all kinds of legitimate reasons (porting to a non supported platform, to adapt for accessibility needs, for privacy, for compliance, to remove nagging and dark patterns, etc). Signal don't want that, they want to control your user experience, even if this makes it worse for their user.
Signal ghosts people or gets very evasive on other questions to. They've also refused to update their privacy police since they started permanently keeping sensitive user data in the cloud. They can only scream "Don't trust us" so loud.
Non profit doesn't necessitate open sourcing their whole product. If you don't like that, don't donate. As long as they are transparent about their decisions that is the only obligation they have.
Perhaps it shouldn't necessitate it, but I can't think of a good reason why not.
If it were expensive to release it, that would be a reason. But it costs roughly zero dollars to create a public repo on GitHub and a cron job to push to it once a day.
Making the system public potentially increases the likelihood of a hack, which would be bad for Signal users. But relying on this argument to keep the source secret is, I think, a confession that your security is below par. Or to put it the other way round: A secure software system remains secure even if its source code is public, so making your source public is a strong signal that you are confident in your security measures. Security isn't something I expect all non-profits to focus on, but I think it would be telling for Signal to hide behind this reason.
1. A for-profit company rationally doesn't want competitors launching products using their code. Why would a non-profit care at all?
2. An app like Signal depends completely on network effects, so there's even less motivation for a community-fragmenting fork than in most OSS cases, where you'll notice that forks are already rare. There would have to be something very weird or contentious happening with the original codebase for people to want to fork it -- otherwise it's in no one's interests.
> Non profit doesn't necessitate open sourcing their whole product. If you don't like that, don't donate. As long as they are transparent about their decisions that is the only obligation they have.
Actually you're mistaken. Under the 501(c)(3) tax code rules, they are required to act in the public good. Nobody has sued them to enforce this though, but I'd at least like them to acknowledge the game they're playing by ghosting us all on this.
American 501c3 law is extremely lax compared to analogous structures in the EU. A number of 501c3s are run as sinecures where a board (self-selecting, so no input from the membership) just hires its friends for well-paid positions that involve little work. Because the law is so lax and permissive, making a case that a given org is not acting in the public good is extremely rare and uphill.
OpenAI is a 501c4 not a 501c3. Also the structure is much more complicated for OpenAI.
Nevertheless the point stands - I don’t see what relationship company organizational mission has with their technical responsibilities. Indeed, if the open sourced everything, standing up a clone would be easier which creates funding risk due to a race to the bottom of people who didn’t invest into the R&D investing very little additional to compete.
'Apple' was a metaphor to Newton. 'Open'AI was meant as a promise; one that they've since broke both to some of their founders as well to the general populace. Reminding people of that broken promise doesn't seem that wild.
> According to Wozniak, Jobs proposed the name “Apple Computer” when he had just come back from Robert Friedland's All-One Farm in Oregon. Jobs told Walter Isaacson that he was "on one of my fruitarian diets," when he conceived of the name and thought "it sounded fun, spirited and not intimidating ... plus, it would get us ahead of Atari in the phone book."
Not only that. I also question how they pick new features to implement. For example usernames - I am not going to trust another "private" IM app username feature same as what Telegram and WhatsApp questionably chose. Compromise on this? Well, then even WhatsApp and Telegram are good enough with compromises.
Separate usernames completely from phone numbers. Period.
There's a reason Signal is still "US based". No, I am not talking about some CIA/NSA/DoD/tom/jerry funding conspiracy, just good old human obstinacy and hubris. They don't give a f about who uses it, it's about who makes and maintains it all.
I'm being cheeky and implying that the reason signal's active backend is not disclosed as hoped for in a prior poster's comment is because the CIA (or other intelligence) is involved in it.
When news leaked that federal agents and contractors had access to WhatsApp "end-to-end encrypted" messages using the "Signal Protocol", WhatsApp users sued Meta
Faced with mounting statutory damages per violation for wiretapping claims under CIPA and Pennsylvania's wiretap act, Meta forced arbitration
"48. After Meta acquired WhatsApp in 2014, WhatsApp partnered with Open Whisper Systems to integrate the Signal Protocol, which is an end-to-end encryption cryptographic protocol, into the WhatsApp platform.26 The integration of the Signal Protocol onto the WhatsApp platform was completed by April 5, 2016.27
58. Recent reporting has confirmed that WhatsApps numerous promises that no one other than intended recipients has access to users communications is false. Indeed, contrary to WhatsApps repeated assurances otherwise, Meta, WhatsApp, their employees, contractors, and/or third-parties personnel have access to users WhatsApp messages.32
59. According to whistleblower accounts reported to federal investigators, employees of Meta and WhatsApp and third-party contractors employed by Accenture are able to access the contents of users messages, contrary to the privacy representations made by the company.33
60. Former Meta contractors reported to special agents with the U.S. Department of Commerces Bureau of Industry and Security that they and some of their colleagues had broad access to the substance of WhatsApp messages that were supposed to be encrypted and inaccessible.34 The two sources confirmed that they had employees within their physical work locations who had unfettered access to WhatsApp, and one stated that she spoke with a Facebook team employee and confirmed that they could go back always into WhatsApp (encrypted) messages.35
61. Moreover, these whistleblowers have outlined much broader access by Meta employees and third-party contractors than the limited access described in WhatsApps Privacy
Policy and website.36
(I will try this as soon as there is a package in Fedora... That's my personal subjective bar to choosing a new EDITOR. But I definitely hope this succeeds, I'm a fan so far.)
I've been using Arch Linux and macOS for the longest time, so I never saw the appeal with flatpak. It could be a good option until Rune is popular enough. fwiw I'm also working on a cask for homebrew.
Flatpak is the best of all bad options for multi-distro Linux packaging. Adapting to the sandbox if you aren't already using portals will probably be a pita though.
My personal website: https://purpleidea.com/ has been DMCA'ed by some scammer and I still haven't gotten it back out. Google ignores the counter notices, and who knows where else the scammer (masquerading as a legitimate takedown company) has sent notices. Bing and DDG (same basically) have all delisted it.
Don't fall for this trap! GrapheneOS leadership is very against Copyleft, probably to cater to it's corporate sponsors, and copyright is really the only thing that protects Free Software at all. Proprietary software can be kept secret, and only shared as a binary, but the only thing that protects Free Software (open source) is copyright law.
It's not perfect, and the terms are far too long, but we do want to keep it. Reduce it to 20 years and we'd be golden.
We use GPLv2 licensing for substantial portions of our code beyond our Linux kernel changes. Vanadium is licensed as GPLv2. As long as copyright exists then there's a place for copyleft to counter it.
> probably to cater to it's corporate sponsors
That's a strange thing to claim about Proton and Cape. Those are the only companies we're aware of sending us any substantial monetary donations in the past couple years. It has several $10k donations from Proton and maybe around 10x that for Cape which sells phones with GrapheneOS for a $50 fee.
We have a list of formal sponsors at https://grapheneos.org/sponsors which are 4 server companies sponsoring dedicated servers, a GeoIP database company giving us sponsored access to the downloadable database and a VPN company sponsoring 2 DataPacket servers. We could list Cape too but they started donating to us on their own.
> copyright is really the only thing that protects Free Software at all
What does it protect it from? GPL is widely violated with minimal consequences. The main impact is that a lot of Android OEMs and similar companies release Linux kernel drivers as open source while the firmware and userspace drivers are closed source.
> Proprietary software can be kept secret
The source code can be kept secret but not the code running on the device. That can be reverse engineered and forked. If copyright was abolished, it would be legal to fork closed source software. That's becoming far easier to do from a technical perspective.
> We have a list of formal sponsors at https://grapheneos.org/sponsors which are 4 server companies sponsoring dedicated servers, a GeoIP database company giving us sponsored access to the downloadable database and a VPN company sponsoring 2 DataPacket servers. We could list Cape too but they started donating to us on their own.
Where are the details about any arrangements with the Motorola partnership?
Motorola Mobility (Lenovo) isn't providing us with funding. They're improving the updates and security features for their devices, providing what we need to support them with proper updates and helping with the GrapheneOS port.
> Motorola Mobility (Lenovo) isn't providing us with funding.
If you made a strong public commitment to making sure everything in GrapheneOS was strong copyleft, would they still partner with you?
(FWIW, I think it's great what you're doing with the project, but I want to see the work made indelible, and I personally believe copyleft would help with that, otherwise some big vendor can have their proprietary fork and us users lose out.)
They want to sell more devices by improving security and having official support for GrapheneOS. The main work that's being done is official GrapheneOS support. They're also going to integrate improvements from it into their own OS but that's not the main focus. They may not want to do as much integration into their own OS if it was all GPL but it's a side benefit for them rather than the main purpose.
> but the only thing that protects Free Software (open source) is copyright law.
Can you elaborate on that? I have done a lot of open source (professionally and in my free time), and I don't see it.
I have exactly one example where I see that copyleft is useful, and that's Linux: it is nice to be able to get the downstream kernel. I genuinely don't have another example.
For smaller projects (even not that small actually), my feeling is that a Copyleft licence is just an opportunity for a competing project to come with a permissive licence. It happened to me in a library I built: people complained about my choice of MPLv2, eventually someone started a competing library with a permissive licence and everybody jumped on it.
An example of a not-so-small project I have is Ardupilot: as a user I love that GPLv3 should make it possible for me to access (and reflash!) it, but it seems to me that the GPLv3 was clearly an opportunity for PX4 to gain traction (Ardupilot even got evicted from Dronecode).
So yeah, I totally understand the appeal of copyleft in theory, but in practice I'm a bit more skeptical. And I say that as someone who actually licences my projects as copyleft.
> people complained about my choice of MPLv2, eventually someone started a competing library with a permissive licence and everybody jumped on it
Just because you choose copyleft (even weak copyleft like MPLv2) doesn't mean your project will succeed or be more popular. A lot of people (and especially a lot of companies) do prefer permissive over copyleft, and that's because they can built something proprietary on top, without being forced to give back. That's why they're ultra billionaire rich, and in comparison you're poor.
Software often wins because it's better. Copyleft favours the collective good, permissive favours the individual greed. In any case, all of these things require copyright law.
I like how you so easily dismiss my opinion by saying "it's probably because you suck" :-).
For my library, people explicitly complained about copyleft, saying "it comes with strings attached". They were pushing for permissive because it meant they could fork it for their proprietary startups.
For the other example that you conveniently ignored (Ardupilot vs PX4), it's also very clear that many companies choose PX4 because of the licence. I have heard a lot of "if you go for Ardupilot it's risky because GPLv3", and believe it or not, it has an impact on people's decision long before they can say whether PX4 or Ardupilot is better (spoiler: they are roughly equivalent).
What’s the issue? They didn’t like your licence terms, and rewrote the library under a permissive licence? You don’t have a right to users or an audience.
I agree with that, I never said that was the issue. If you read my message, I answered to:
> but the only thing that protects Free Software (open source) is copyright law
I was merely asking them to elaborate on that, because IMHO, copyright law doesn't protect copyleft licences much (I mentioned people going for or rewriting permissive alternatives, which is now a whole lot easier with LLMs), and copyright is not protecting permissive licences at all.
I have been in companies that distributed hundreds of copyleft and permissive binaries without mentioning them. Copyright says that "in theory, it was illegal". In practice, nobody cares.
I see value in open source, but I don't think that copyright is the only thing protecting it.
I don't agree. Free software would still be free even if copyright were to be abolished, if anything it would flourish further. That is because even proprietary software could be better integrated.
You're conflating what "Free Software" means and what Copyleft means. In any case, they both need protection from people like you who want to take it and benefit for free, without having to give anything back. Copyleft was designed specifically to prevent against people with your mindset. Permissively licensed software needs copyright to protect authorship rules, although the requirements are lessened.
> Software doesn't need any protection. People want protection.
Correct, people want protection for the hard labour they put into doing something good (writing software) for the world, and to not have it co-opted for individual profit over communal profit.
> GrapheneOS is permissively licensed and is usable for building devices with an immutable root of trust. GPLv3 is deliberately incompatible with these kinds of locked down devices, unlike GPLv2 code such as the Linux kernel. This means GrapheneOS can't include GPLv3 code without forbidding use cases we want to support. GPLv3 is no problem for our own usage, but we don't want to forbid using GrapheneOS as a replacement for the Android Open Source Project in locked down devices.
They're not against GPLv3 and, but they explain why it's not suited for a project like GrapheneOS.
In Canada, we wear steel-toe, steel-shank safety boots, and we're kind of required to keep them on. We surely give them a good clunk to get rid of mud or snow, particularly in the winter, and we try to wipe our feet as much as possible when it's not a dire emergency, but you called 911, so... your floor is going to get dirty. Might already have blood on it anyways.
Same, even in countries I live/lived where not taking off shoes indoors is borderline a social crime, paramedics, emergency services and even craftspeople/tradespeople would typically not take off their shoes when entering your home.
Personally I got so tired of it we got those "one-use blue shoe covers" that we tell them to wear before going in, but of course I don't think either of us would think about that if we called for emergency services.
Nobody wants a proprietary TUI. We still use claude because the model pricing is way better, but that will eventually change. Bob has a hard lesson ahead of it.
reply