Can try to fork?, china , russia, and lots of smaller countrys are steadily moving away
and as basic introperability standards for phone and internet will remain, they can do this, and pressure is also mounting to get a linux phone fully functional, that will alao happen.
And in a world where Guggappl is providing genocide and abduction services, Billions would happily choose other alternatives.
China and Russia are likewise involved in their own genocides (Uyghurs and Ukraine respectively), and they are just as interested in developing centralised systems of control. They will not give the world truly free and open platform.
"They will not give the world truly free and open platform", uhuhu!, but we are giving them the pivot point to claim the flag of freedom , rather than just doing that ourselves.
also, one more move from you know who, and a whole lot of countrys will have to very seriously start looking for stable deals that last longer than it takes the ink to dry. China just ghosted nvidia, on the "something 200" ai chip to start shipping in march, tsmc and all there suppliers have stood down on that, and will of course, instantly re focus on the next job, which might be a batch of chips for fairphones....
I love your optimism. What you'll see is return to 2000s where you may have had "Symbian" as the operating system, but the phones weren't compatible between themselves and apps broke and didn't work across manufacturers (or even product lines) because there was noone enforcing compatibility.
I wonder if you forgot that or you're too young to remember what kind of bizarre hell mobile development was at that time.
Heck, even early Android was really hard to develop for because CTS suite didn't cover enough and all of us spent hours upon hours (and many dollars) trying to reproduce and fix Samsung, Huawei, HTC and other bugs.
I never said it's going to be smoother than it is right now, just that Google will lose control.
8 of the top 10 manufacturers are Chinese, the last two are Samsung (which definitely isn't going to side with Google) ... and Google themselves.
If Google doesn't publish AOSP anymore, Pixels will be the only phone with their software on it, Samsung might attempt something alone and the rest will pick up the development from a Chinese government consortium which will be the de-facto default mobile platform instead of the Google one.
I am all for it but it would be hard to enforce. Ads are already hidden everywhere. Someone "review" a product? Most of the time it is a hidden ad even if the reviewer hasn't been paid with money for that. Watches a movie or a video clip? A lots of products are advertised through close ups on the logos, etc.
Youtubers happily do "reviews" in exchange of receiving stuff, regardless if they can keep it or not. They also know that if they are too critical they may not receive anything more and they don't have any material to review. This was already true on paper magazines.
This is a false argument. Regulations are effective. When was the last time you breathed in second hand smoke while eating dinner? Or inhaled lead from a passing car? Or asbestos from your neighbor's new house?
Not sure why you're gettimg downvoted. This is exactly what he did to instant messaging; extremely damaging to everyone and without solid arguments for such design.
Or, he took a barely niché messaging app plugin (OTR), improved it to provide forward secrecy for non-round trips, and deployed the current state-of-the art end-to-end encryption to over 3,000,000,000 users, as Signal isn't the only tool to use double-ratchet E2EE.
>broken SGX metadata protections
Citation needed. Also, SGX is just there to try to verify what the server is doing, including that the server isn't collecting metadata. The real talking is done by the responses to warrants https://signal.org/bigbrother/ where they've been able to hand over only two timestamps of when the user created their account and when they were last seen. If that's not good enough for you, you're better off using Tor-p2p messengers that don't have servers collecting your metadata at all, such as Cwtch or Quiet.
>weak supply chain integrity
You can download the app as an .apk from their website if you don't trust Google Play Store.
>a mandate everyone supply their phone numbers
That's how you combat spam. It sucks but there are very few options outside the corner of Zooko's triangle that has your username look like "4sci35xrhp2d45gbm3qpta7ogfedonuw2mucmc36jxemucd7fmgzj3ad".
>and agree to Apple or Google terms of service to use it?
Yeah that's what happens when you create a phone app for the masses.
Moxie Marlinspike sounds like some 90s intelligence guy’s understanding of what an appealing name to hacker groups would sound like. Put a guy like that as so-called creator of some encryption protocol for messaging and promote the app like it’s for secret conversations and you think people won’t be suspicious? It screams honeypot like nothing else.
He IS a hacker from the 90s. It’s an assumed name. Plenty of hackers from the 90s have pseudonyms.
> so-called creator of some encryption protocol
All evidence points to him being one of the protocol’s designers, along with Trevor Perrin.
I’ve met both of them. The first time I met Moxie and talked about axolotl (as it was called back then) was in 2014. Moxie and Trevor strike me as having more integrity and conviction than most. There is no doubt in my mind that they are real and genuine.
Interestingly enough, some of the work Trevor did related to Signal’s cryptography was later used by Jason Donenfeld in the design of WireGuard.
> It screams honeypot like nothing else.
As you can see there is plenty of evidence suggesting otherwise.
>Moxie Marlinspike sounds like some 90s intelligence guy’s understanding of what an appealing name to hacker groups would sound like. Put a guy like that as so-called creator of some encryption protocol for messaging and promote the app like it’s for secret conversations and you think people won’t be suspicious? It screams honeypot like nothing else.
This criticism has absolutely zero substance and honestly just reads like paranoid rambling. The Signal protocol has been independently formally analyzed [1] and has no known security issues.
The example you linked is about push notifications in general, nothing specific to the Signal app. If the concern is that your OS is compromised or spying on you, that's not something E2E encryption can protect against, whether it's Signal or any other app.
I don't think so, you could use the official Linux build as far as I know. I think it needs a phone number but not necessarily a mobile device. I might be wrong though.
So the argument against Signal is now "the creator's nickname sounds odd"? I mean, OK? Keep using WhatsApp, Telegram or Instagram if you think those are more private than Signal.
It's just people having zero product sense, or an idea of what it means to target more than 0.01% of the market. The last comment said that Signal's problem is that it's mobile-first, which, how does someone even think that a messaging app should be anything other than mobile-first?
There are no fully open/auditable android phones. All of them have privileged binary blobs. An end to end chat service where there are no options permitting full accountability of the client software and operating system is largely security theater.
Even if you do all that, it is not an official option, let alone a recommended one. The recommendation is to accept the google or apple terms of service.
Moxie even went as far as to say he would actively do anything in his power to discourage or stop the use of third party clients.
> You can download the app as an .apk from their website if you don't trust Google Play Store.
I wish apple & google provided a way to verify that an app was actually compiled from some specific git SHA. Right now applications can claim they're opensource, and claim that you can read the source code yourself. But there's no way to check that the authors haven't added any extra nasties into the code before building and submitting the APK / ios application bundle.
It would be pretty easy to do. Just have a build process at apple / google which you can point to a git repo, and let them build the application. Or - even easier - just have a way to see the application's signature in the app store. Then opensource app developers could compile their APK / ios app using github actions. And 3rd parties could check the SHA matches the app binaries in the store.
This is what F-droid does (well, I suspect most apps don't have reproducable builds that would allow 3rd-party verification), but Signal does not want 3rd-party builds of their client anyhow.
>> and agree to Apple or Google terms of service to use it?
> Yeah that's what happens when you create a phone app for the masses.
No, that's what happens when you actively forbid alternative clients and servers, prevent (secure) alternative methods of delivery for your app and force people to rely on the American megacorps known for helping governmental spying on users, https://news.ycombinator.com/item?id=38555810
This is probably impossible and also not needed. Choose security through compartmentalization (instead of security through correctness that never works), if you really care about security.
Do you daily drive Qubes? I'd be curious to hear about your experiences. I've been following the project from the sidelines for years, but haven't taken the leap.
Do you hate GPU acceleration? Do you hate using most hardware? Do you like using Xorg? Then Qubes is for you.
This is in jest, but those are my pain points - the AMD thinkpad I have can't run it, the Intel one melts yubikeys when decoding h264 video. The default lock screen can't read capital letters from the yubikeys static password entry. Qubes has a certain user that it caters to, I really wish they could get enough money to be able to cater to more use cases. It is not difficult to use it if it works for you.
Nobody uses "most hardware". You may be unlucky with your hardware, then it's a problem. Or you can specifically buy hardware working with the OS you want.
Yes, I daily drive Qubes. It's an amazing feeling to feel in full control over your computing and not being afraid to open any links or attachments. Here is my Qubes OS Elevator Pitch: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15
Just FYI, there are some people that vastly exaggerate the security it provides. For the most part, you're just as safe using flatpak versions of applications.
Apart from the fact that this is extremely rare, the first vulnerability is not a complete escape. For example, any offline vault VM storing secrets stayed secure. This is just not happening with any other security approach.
Speculative sidechannel attacks have nothing to do with OS or compartmentalization technology, since they are the problem of CPUs. Nothing can help here, so this is irrelevant to this discussion. Except that Qubes Air will save you in the future: https://www.qubes-os.org/news/2018/01/22/qubes-air/
> Apart from the fact that this is extremely rare,
So are bubblewrap escapes, which is the sandbox flatpak uses.
> the first vulnerability is not a complete escape.
It could potentially lead to one, and being able to obtain information from other VMs defeats much of the point of isolation, and so defeats much of the point of why people use qubes.
> For example, any offline vault VM storing secrets stayed secure. This is just not happening with any other security approach.
That's not true. Strong MAC would suffice, no VT-d needed.
> Speculative sidechannel attacks have nothing to do with OS or compartmentalization technology
Of course they do, in fact they have more to do with it than solutions like flatpak, which is why Qubes releases security advisories and patches to address those vulnerabilities.
>> Apart from the fact that this is extremely rare,
> So are bubblewrap escapes, which is the sandbox flatpak uses.
Not only they are much more frequent, including possibly kernel privilege escalations, not affecting Qubes, - the bubblewrap repository itself says that you have to be really careful to stay secure with it, even in the lack of vulnerabilities. This is not what people should seriously rely on. Again, my secrets in vault VM are safe since the introduction of VT-d in Qubes 4.0 in ~2021. There is no comparably secure OS in the world.
I don't understand your unsubstantiated attack on Qubes.
> and being able to obtain information from other VMs defeats much of the point of isolation
It does not. Even if a VM becomes hostile and starts reading the RAM, it will not get any privileges in any other VM. Also, it can be easily cleaned. Also, you can just stop all VMs when performing a secure operation. Tell me how you protect yourself in such case with Flatpak.
> Not only they are much more frequent, including possibly kernel privilege escalations,
No, that's simply not the case.
> not affecting Qubes,
Maybe, qubese would still be vulnerable to kernel vulnerabilities even if they didn't allow VM escape - anything in the disposable VM would be at risk.
> the bubblewrap repository itself says that you have to be really careful to stay secure with it, even in the lack of vulnerabilities.
Source? I assume they are referring to misconfigurations.
> There is no comparably secure OS in the world.
You've said before you don't have a lot of security knowledge and it continues to show. Qubes is one specific approach to a problem not suitable for all goals, it's useful for hobbyists who use browsers and such. Anything in the disposable VM is still at risk.
SEL4, ASOS and CuBit are all more secure than Qubes. Qubes doesn't offer any more security than having a bunch of different machines to do different tasks on. Not even airgapped. If the machines have a vulnerability, then whatever is on the machine is fair game.
> I don't understand your unsubstantiated attack on Qubes.
There is no attack, I'm just refuting your preposterous zealotry for it. It's fine for what it is, but you make it much more than what it is. The developers of Qubes would absolutely disagree with your claims.
> Even if a VM becomes hostile and starts reading the RAM, it will not get any privileges in any other VM.
You keep repeating this without providing any actual statistics. I provided statistics about Qubes vulnerabilities, https://www.qubes-os.org/security/xsa/. Show me the numbers please.
> anything in the disposable VM would be at risk.
This just shows that you don't understand the security approach of Qubes. You do not store anything important in a disposable. You run it specifically for one task of opening something untrusted and then it's destroyed. It's in the name: Disposable. Moreover, nothing prevents you from running Bubblewrap inside Qubes. Then one single VM will be as secure as your whole setup, and in addition, you get reliable isolation.
> Source? I assume they are referring to misconfigurations
> bubblewrap is not a complete, ready-made sandbox with a specific security policy.
> As a result, the level of protection between the sandboxed processes and the host system is entirely determined by the arguments passed to bubblewrap.
> Everything mounted into the sandbox can potentially be used to escalate privileges.
This is not a robust system designed for security first. You can use this to be (much) more secure than otherwise, but it's not a security-oriented design, unlike Qubes.
> Anything in the disposable VM is still at risk.
Which means nothing. Disposable can't store anything, it's destroyed every time you stop it.
> You've said before you don't have a lot of security knowledge and it continues to show.
I see the same about you. You keep repeating some myths about Qubes OS based on misunderstandings of its security approach. I don't have to be a professional in security to understand simple concepts. Qubes is not an OS made for professionals but for users.
> Qubes doesn't offer any more security than having a bunch of different machines to do different tasks on.
> SEL4, ASOS and CuBit are all more secure than Qubes.
Do I have to trust you on this, or do you have any reasonable reference to security people? You don't even provide your threat model when saying this, which clearly shows how amateur your approach to security is.
> I'm just refuting your preposterous zealotry for it
Relying on professionals in the field is not zealotry. In contrast, you show exactly the latter. I see no references.
> The developers of Qubes would absolutely disagree with your claims.
> You keep repeating this without providing any actual statistics. I provided statistics about Qubes vulnerabilities, https://www.qubes-os.org/security/xsa/. Show me the numbers please.
You can find this yourself. For any software running in the guest OS, you can look up it's security history.
> This just shows that you don't understand the security approach of Qubes. You do not store anything important in a disposable. You run it specifically for one task of opening something untrusted and then it's destroyed. It
I understand it perfectly, but you seem to be missing my point. Yes, the qubes are disposable, but you need to have information in them while you are using them, yes? So, you make a new qubes to do your taxes, your tax information is in the qubes because you need it to do that. While the qube is running, if it is vulnerable, then that information is at risk. I get that it is no longer at risk once the qube is destroyed, but that is irrelevant to my point.
Consider an example, back in 2024 if you were running SSH in a Qubes for some reason, you would likely be vulnerable to the regreSSHion vulnerability. Sure, an attacker could only access what was on the disposable VM, but that could still be a lot.
> This is not a robust system designed for security first. You can use this to be (much) more secure than otherwise, but it's not a security-oriented design, unlike Qubes.
Neither is qubes. It's designed for specific use cases, and doesn't do much to protect the information running within a qube aside from destroying it after disposing of it.
> Which means nothing. Disposable can't store anything, it's destroyed every time you stop it.
It's at risk while the VM is running, which is the point.
No, it doesn't. Those points are rather nonsense. Malware that can bridge airgapped systems? Sure, if you have a compromised USB stick and stupidly run something from it, I guess. The disposable VM would be at risk also.
> Do I have to trust you on this, or do you have any reasonable reference to security people? You don't even provide your threat model when saying this, which clearly shows how amateur your approach to security is.
You have no security knowledge at all, though, you just repeat your chosen solution because it's FLOSS. It makes this discussion very frustrating. Do you understand anything about capabilities, mandatory access controls or formal verification?
> Relying on professionals in the field is not zealotry.
You are exaggerating claims you can't backup in a field you don't understand due to the software meeting your only real criteria, being FLOSS. That is absolutely zealotry.
> This is plain false:
Not only do your links not support your exaggerated claims at all, meaning I am correct the author would absolutely not agree with you, but the FAQ entry dismissing formal verification and safe languages refers to a paper from 2010 - back when Rust didn't even exist. You might not know this, but the tech world moves pretty fast...
Do me a favor, spend some time with your favorite FLOSS AI and ask it why SEL4 would be considered superior to Qubes from a security perspective.
You refuse to provide any references. I don't see a reason to continue the discussion.
You also reply to my references with shallow dismissals with no substance presenting that as facts ("Not only do your links not support your exaggerated claims at all")
You give examples how Qubes can't save you from absolutely everything. It's true. Yet your original claim is that Flatpac is similarly secure and you failed to explain how it would protect from the same problems.
Why is there a need for references? Do you not understand how VMs work? Do you dispute that software running in the VM can be vulnerable?
> You also reply to my references with shallow dismissals with no substance presenting that as facts ("Not only do your links not support your exaggerated claims at all")
Because your 'references' don't support your claims, it's that simple. You can't just copy and paste links and act like you have provided evidence when the links don't match. Your claim doesn't appear on the Bubblewrap github page at all.
> Yet your original claim is that Flatpac is similarly secure and you failed to explain how it would protect from the same problems.
Vulnerable software running in a Bubblewrap sandbox and in a Qubes VM are both similarly vulnerable to software vulnerabilities, and it is unlikely an attacker would be able to escape the sandbox or the VM. I grant that escaping the sandbox is easier and more common, but not by much.
Your first key point was that Bubblewrap vulnerabilities happen all the time, and you've yet to support that. The only 'reference' you provided was to the Bubblewrap github page.
> They do not exist, only open-weight ones do.
And of course you don't trust anything that isn't FLOSS, right?
Qubes doesn't compartmentalize the image decoder in a web browser from the rest of the renderer, and if you're serving tracking pixels and can exploit image decoding, you can make serious mischief.
If you use Qubes correctly, then VM in which you go to untrusted websites is disposable and contains no personal information, so there is no mischief to make.
The web page you are visiting contains personal information, and that is where the mischief can be made. All that is required is for the website to incorrectly trust an image, either by not sanitizing a user-uploaded image or by embedding a third party image. Both trust bugs are rampant on the web, and both have caused problems in the past. Adding an improperly vetted image decoder is a sure-fire way to get exploit authors salivating.
> The web page you are visiting contains personal information, and that is where the mischief can be made.
This is a weird threat model. You trust some website with your personal information but you don't trust that images they embed are trusted and will not attack you. Nothing will save you here except switching off showing pictures, which you can also do on Qubes.
I would say, if they really embed malicious images, then they probably have other problems with security, which nothing you run can help with.
> Nothing will save you here except switching off showing pictures
Or having a trustable image decoder, which is what web browsers actually do. This is a basic requirement that you are proposing to do away with by instead not showing images at all.
For purely data, sure, that works. I have actually done it for multiple projects but for industrial purposes. It is slower than what a phone can achieve with an integrated baseband and SoC but would be good enough
For VoLTE, it is possible to get very basics with external modules but it is also very time and operator dependent. You need to have the profiles of each and every single operator you may support. If the phone would be globally available, this means thousands of profiles. Your module needs to be configurable after deployment. You still carry the risk of operator changing their profile or switching to a different encoding that your module doesn't support.
RCS is completely proprietary to the specific operator. There are currently no external modules that supports it, nor I beleive will be due to the complete proprietary nature. Google and Apple internally handle their pairing with the ones that support it.
On top of these two, you have actually a significantly bigger problem. The reason companies like Qualcomm integrate baseband chips with the main SoC die is the power efficiency. With external modules you will never reach an integrated circuit efficiency. Moreover you are sacrificing valuable battery space to the extenal module.
This is all true, and my phone (from the link) is not very energy efficient and doesn't support all mobile bands. But it exists and is usable.
Calls work for me, too.
> You still carry the risk of operator changing their profile or switching to a different encoding that your module doesn't support.
I am quite sympathetic towards Tuxedo, and am considering to replace my work laptop (a 6yr old MBP) with one of those when it stops working, but those are Apple and gaming laptop prices, not mass market prices.
reply