I was confused also, I use my Yubikey a passkey, so I did not get the rant.
Yubikeys can be used as a device-bound passkey, that the FIDO2 thing.
Now software managed passkeys are also a thing and can be stored in a (good?) old password manager, of course this is less secure and could be disallowed in the future.
Thus the rant is about people without dedicated hardware keys that would have to use things like device-bound passkeys their OS instead of their password manager.
Yes it's very common on sites, and even somewhat forced to have these digital passkeys. It's almost automatic setup and there's a lot of skepticism about them.
> so a Yubikey passkey is very quickly a single-point-of-failure
It is a single point of failure when there is one. As soon as you use two, then it's not a single point a failure anymore, is it?
The counter argument I usually read is: "Yeah but it is not practical, because you need 3 yubikeys: the first 2 with you, that you enroll everywhere, and one in a safe. And every time you add a new passkey, you need to go get the one in the safe, replace it by another one, and enroll the one of the safe. You can't spend your life driving between your desk and your safe".
But I have been using multiple Yubikeys for... 8 years now I think? I don't remember the last time I enrolled and important key. Sure, once in a while I add a website, and it is a bit annoying to have to enroll the other Yubikeys at a different time. But it really doesn't happen that often, and anyway most of those websites allow me to recover my account with my email. So it is actually practical to have a "convenience yubikey" for websites that don't matter so much, and in case this Yubikey dies... well those websites were not so important, and anyway I can recover from my email.
The difference for the important websites (and really, I don't think I have really important websites in my life that don't allow me to recover by going in person with my ID, but for the sake of the argument) is that I actually do have multiple Yubikeys, one of which is stored away.
Whereas the master password of my Bitwarden account is a single point of failure, and the security of my online Bitwarden account is as well.
That's a clever setup that I hadn't seen before. Some extra downsides:
- Relying on emails for account recovery prevents creation of anonymous accounts.
- Have you ever lost your "convenience yubikey"? People underestimate how painful mass account recovery can be.
- The cost of 3 yubikeys can be substantial for some demographics.
- Important accounts are not properly backed up until you drive to your safe. That can be many days for a bank deposit box, or even longer if you're traveling.
Overall that's a lot of compromises for what should have been just "put this recovery key/password in a safe and forget about it until needed", if the protocol was better. And definitely not something that can be widely recommended.
> ... just "put this recovery key/password in a safe and forget about it until needed"...
Surely that is also impacted by:
> Important accounts are not properly backed up until you drive to your safe. That can be many days for a bank deposit box, or even longer if you're traveling.
Nope! You could have one "master recovery key", the public part loaded on your device (to be registered during account creation) and the private part sitting in your safe. Or even a number of pre-generated recovery keys. You could also give those keys a higher "priority", since they're offline, so that they can revoke lesser keys in case of account compromise.
The problem is that the passkey protocol prevents you from adding a (additional) key you don't currently control. This is what crote was referencing here:
> Passkeys have to be online to enroll additional keys, so any kind of software or smartphone solution is going to depend completely on cloud sync.
> I have been using multiple Yubikeys for... 8 years now I think? I don't remember the last time I enrolled and important key.
This probably makes your use case somewhat unusual...
> I actually do have multiple Yubikeys, one of which is stored away.
...and this probably puts you in the 0.0001th or so percentile of users. It's really a great security strategy if you can pull it off, but practically almost nobody can.
Not sure what you mean. "Normal people" have to enroll important keys much more often, and cannot use multiple Yubikeys?
My feeling would be that "normal people" can always recover their accounts from their main email, which makes the main email the only "important" account. So having a Yubikey always plugged in is a "nice convenience".
Now to be honest, I would expect that "normal people" are absolutely fine with passkeys on their smartphone, and don't consider it a "trap".
I would just expect that people who consider it a trap are able to use a Yubikey the way I do.
Let's make a thought experiment: let's think about designing a new Linux distro from scratch. Obviously starting with Linux-the-kernel, and then thinking about what we need to be a modern smartphone OS.
- We'll probably want the security model, with the nice sandboxing and I would argue the verified boot.
- We'll want the battery optimisation.
- We'll want access to the firmwares of the components running in the phone.
- ...
From the very first step "start from Linux-the-kernel", every single question I ask myself goes towards the Android design and away from the classical Linux distro design.
In other words, the open source Linux distribution that is the closest to a modern mobile system is... Android :-).
The best battery life I ever got on a smartphone was on a HTC One X back in 2013 or so. It had a custom ROM (Paranoid Android IIRC) where I stripped out all the google services, blocked all wakelocks and so on. It had an nvidia Tegra3 CPU, which had 4 normal ARM cores and a 5th tiny core that ran at 100Mhz or so max (with powersave governor). On that setup, when I was not using it, it drained like 2% battery a day (50 day runtime).
Since then we went from 40nm to 3nm, 2000mAh to 5000mAh, I'm doing the same things on my phone and yet, due to bloat and spyware the battery life is worse and worse. I went through HTC One m8, HTC 10, OnePlus 7Pro, and a Samsung Fold7 and each had worse efficiency than that 2011 CPU on the OneX (And a Nexus7-2012 until it died due to low quality NAND)
I mean, it was still connected to a cell network, so it was fully usable except maybe notifications. (Obviously the battery drained faster during active use)
Even more so, it is the closest to Inferno's design, which was the evolution the UNIX founders went through.
Like they created UNIX, they declared it done, created Plan 9, followed by Inferno, most as a reaction to JavaOS, but still, the creators of UNIX moved on.
Whereas the FOSS community seems to be stuck in recreating Bell Labs in the 1970's.
Most of the FOSS community is hostile to even creating basic sandboxing. The Flatpak project gets panned all the time. Not for having a weak sandbox (which would be a fair criticism), but for having a sandbox at all and not using 90s-style package management.
A lot of people from the FOSS community seem to believe that (at least from recurring discussions) that Linux is secure because the software is open source and you can trust the maintainers. The idea that even trusted software can have vulnerabilities and that the 80s/90s security model of the standard Linux desktop means that you are only one Mastodon/e-mail/RSS/whatever client vulnerability away from exfiltration of your whole home directory does not even occur to them. All the while all these applications use (XML/image/...) parsers from the 90/00s written in C.
The only reason we don't see mass-exfiltration of data is because the Linux desktop marketshare is effectively meaningless. Though we see some results of the desktop security disaster (also to some extend of macOS) through leaked credentials obtained by compromised NPM, PyPI, etc. packages.
> Most of the FOSS community is hostile to even creating basic sandboxing.
> 90s-style package management
> 80s/90s security model
> parsers from the 90/00s
Perhaps the crux of the issue, and the reason these new systems get pushback, is because people, myself included, don't like being told that they have to stop using the tools that served them well for arbitrary reasons (usually age). Similarly, you can't expect everyone to trade user control, convenience, usability, and more for security, or sometimes perceived security.
We can debate about the 90s style package management, but old C-based file parsers and DAC access control were certainly not designed for modern attack vectors. Defending a device now requires layered security using a combination of among other things:
- Memory-safe languages where possible.
- Sandboxing of applications, parsers, etc., along with a strong permission model.
- Mitigation like secure app spawning, zeroing out pages, etc.
- Modern mitigation hardware-assisted mitigation like MTE and PAC.
- Storing secrets in a separate secure enclave (not ~/.config or ~/.ssh).
- Read-only and fully verified system partitions (anti-persistence).
from Apple's MIE docs [1] shows where modern systems like iOS and Android are. An attacker often needs a long exploit chain to compromise a device and it becomes increasingly difficult with various mitigation techniques. On the standard Linux desktop it's often as easy as exploiting an image parser in a client. Old parsers in C have a history of bad vulnerabilities, exploiting one often gives you privileges of the process calling the function, since Linux applications mostly don't separate/sandbox parsers and from there you have direct access to all data of the user, since Linux applications are typically not sandboxed.
Lets not forget that the motivations for Alef, and Limbo, from the C authors themselves, were also to improve language safety.
In Inferno, only the kernel, DisVM (+ JIT), and a few drivers are still C, everything else in userspace is Limbo.
> Limbo is the application programming language for the Inferno operating system. Although Limbo looks syntactically like C, it has a number of features that make it easier to use, safer, and more suited to the heterogeneous, networked Inferno environment: a rich set of basic types, strong typing, garbage collection, concurrency, communications, and modules. Limbo may be interpreted or compiled ‘just in time’ for efficient, portable execution.
Another angle on this is general reliability and what that does to the experience. I'm reminded of Linus having a moan about poor availability of ECC in consumer RAM and how many errors that get blamed on software are actually down to something happening to hardware but it isn't specifically identified. Plus when you're talking billions of devices even small proportions are significant. Firefox built a memory tester into their bug reporter tool as that 'noise' became a large enough problem for them.
Which is of course after having met those requirements IOS is basically android with a different name and closed source and we only need one player that isn't even properly foss.
Or why ChomeOS invalidates the need to keep working on kde/gnome/etc
Or that isn't the case and this is all just a silly comparison.
He’s saying the examples given were so generic that every OS that cares about battery life and security would just be Android. Battery life optimizations and sandboxing don’t make Android inevitable or the only option.
WebOS was a 3rd option until HP sold it off. Microsoft also had a go at it. They were both very different than Android, but would have those features (if not then, they’d have them by now if the projects were still going).
Well then he is missing my point. Which may mean I was unclear, or course.
My point was that "Linux on Mobile" seems to be mentioned a lot when talking about an alternative to evil BigTech. The thing is, if you want to fork something and make it a modern mobile OS, you may as well just fork Android and go from there. Because Android is open source and already has billions of apps.
Microsoft didn't make an open source system, I think? I had never heard of WebOS, so I'd be open to it, but the fact is that the "Linux on Mobile" crowd is more into Alpine or Debian running on a mobile. Which is far from a modern mobile OS.
I totally respect the Linux on Mobile projects, they do a lot of cool stuff. But I don't see that being a serious alternative to modern mobile OSes anytime soon.
I didn't go into that in this article, but given the number of comments here and on Reddit, I think I should write a second article that explains my thoughts on why I think Linux phones are better strategically than AOSP phones. I'm not opposed to AOSP phones--I use my two AOSP phones more than my two Linux phones. Most people aren't going to use the current Linux phones. Even I as someone who has using Linux since 1999 find that the functionality of the current Linux phones doesn't match AOSP phones. However, I think using AOSP helps lock us into the Android ecosystem, whereas using Linux helps build an alternative ecosystem which is what we need for long-term independence and freedom.
This is what their Unity Desktop was for as well. A desktop environment that had a consistent design language from desktop to mobile.
The remnants of all of this are still kicking around, I think the community still maintains the phone OS, but without the weight of Canonical really pushing it, and a phone shipping with the OS pre-installed, it won’t get as far.
Android's security model isn't the only inevitable option. It was an absolute mess when it launched, to the point where I didn't feel comfortable using any apps from the Play Store and gave up even trying the use the platform. They've since copied a lot of the security controls from Apple, from what I understand, but last I looked, I still like how Apple handles things better.
So even in the world we live, there are 2 platforms that handle security in 2 different ways. Those ways have evolved over time. Ubuntu Touch was made 13 years ago. What did security look like on Android 13 years ago? It's a bit unfair to judge it by today's standards. We can only assume an actively developed OS, being used by normal people (not just hobbyists), would evolve and grow to meet the needs of the platform in the market.
I also assume one of the reasons people want a Linux phone is to have more control, having root without needing to jump through hoops, side loading apps, building from source, etc. They don't want to be locked in a sandbox. I think there is also an assumption that people will play better in a classic Linux environment where there aren't so many financial incentives, and anyone who tries to implement the kind of data collection we see on most modern platforms would be booted from the ecosystem until they can play nice. It would be nice if the current duopoly would do some of this, but most people don't care, and pulling apps from the app stores for breaking the rules is incredibly unpopular.
Some don't work at all, bc they must be GSF-only I guess (installed via Aurora store).
Others like Whatsapp or Signal sort of work but sometimes the app seems to not be running (even though I set up the no battery optimization). And I get multiple unread messages at once when manually starting the app.
If you aren't using sandboxed Google Play then you're not going to have push notifications in apps solely implementing those via FCM. That's your decision and not an issue with push notifications on GrapheneOS. You're using the fallback push notification systems in WhatsApp and Signal rather than FCM. Neither app cares much about those fallbacks. If you want reliable push notifications without FCM for Signal then you need the Molly fork of Signal with a UnifiedPush provider. There are hosted UnifiedPush and MollySocket services so you don't need to host it up yourself.
Thanks for the tips.
To be clear I absolutely wasn't criticizing GrapheneOS in any way. I know things are this way (and my choice) and I'm perfectly fine with it.
In any case, many thanks for your work. GrapheneOS is a breath of fresh air in the consumer electronics nightmare.
I use sandboxed Google Play Services, Signal has been fine... I cannot say it's always immediate (I'm not always on my phone :-) ), but I have never been frustrated for "missing" a notification. Like when I check my phone, the Signal messages are there, they don't appear 3 days later.
Oh, they certainly don't appear days later. But sometimes they do between ~1-30 minutes. This is a well-known issue, you can find many topic about it. When you open the app, everything comes in all at onec.
It is sometimes annoying to me. I cycle a lot and sometimes my wife or somebody else sends a message when I'm on the go (like picking up some extra groceries) and then I miss it.
There is a longer discussion with various people here:
I wonder if they installed something like "adblockers" in their devices on networks that constantly kills keep-alive connection to Google servers which actually delivers the message.
Or somehow broke the device-side wakeup for that keepalive.
Depending on the phone they'd struggle to go in a low power state when the screen is off or can't access other power saving features because the manufacturers keep everything under wraps.
What a weird take. I see it the other way round: if you can run GrapheneOS, run GrapheneOS, period. If you can't, then there is a really cool project called LineageOS that you probably can run, and you should look into it :-).
Yes this is probably a good summary. If you have a fairly recent Pixel, there is probably no reason to pick Lineage over Graphene. But Lineage covers far more devices and device types, including ancient ones.
It's not quite that simple. I don't use GOS because GOS and I have mutually incompatible views of user control. I prefer that I control my phone, they say I can't be trusted with that.
That's an inaccurate portrayal of our approach and especially how it compares to LineageOS. LineageOS does not provide app or user accessible root accessible either. As a counterexample to your narrative, GrapheneOS provides full manual and automatic call recording functionality internationally while LineageOS restricts it based on region.
It's really not; you've argued extensively with me that the moment a user can run an app with root the whole system is insecure. LOS sadly doesn't ship anything but `adb root` by default (although... they do that, so yes they do ship "user accessible root"), but they're still less hostile about it.
Anyways, since you're here perhaps you can answer my question from the other subthread: If I flash GOS and then flash Magisk on it, how hard is it to stay unbricked? Is it as easy as declining to relock the bootloader once, or is the system going to actively fight me on every boot?
I suppose it depends how hard it tries to relock the bootloader; if I can tell it once to not do that then perhaps it's fine, but I don't want to risk a misclick soft bricking the device.
Although as an extension of that - I'm hesitant to use software written by people with such a philosophical difference. It might work today, but I wouldn't trust it to work tomorrow.
Except when you want actual end-to-end encryption, in which case web versions fundamentally cannot guarantee it today (and there are no plans to get there).
People using Telegram don't care so much about end-to-end encryption, so there maybe it makes sense to use the web version indeed.
Not OP, but: You can definitely do encryption in the browser, no problem.
What you can’t do is make sure the server giving you the code that does the encryption doesn’t change it out with code that also sends your secret messages to Siberia. Unless you control the server giving you the web page. And you trust DNS.
At that point your trust model is simpler with an auditable local application. It could even be an Electron app - so almost exactly doing E2EE in the ‘browser’.
You can't meaningfully audit a local application any more than you could audit the code of a web app. Developers frequently send updates which you have no way of verifying any more than you can verify web app updates. Your only choices are to accept the updates or refuse them, and the latter is a bad choice when the updates are security fixes, as they often are.
In practice the only E2EE app that would meet your bar is Signal, with reproducible builds that users can verify from source code, and then in theory they could audit the source code too. But making and verifying a reproducible build requires a ton of tools and hardly anyone does it, so in practice even Signal users don't meet your bar. Furthermore, there's nothing stopping anyone from using tools to verify a web build too. There's nothing fundamentally better about native apps for this purpose.
> Furthermore, there's nothing stopping anyone from using tools to verify a web build too.
Feels like you haven't really thought that through. It's one thing to say it, it's another to actually try. It's not that the laws of the universe make it theoretically impossible for a browser to allow that. It's just that browsers do not allow anything remotely practical in that sense, because they are just not made for that.
> There's nothing fundamentally better about native apps for this purpose.
What's fundamentally better about apps is that it is actually practical. It is possible right now, and I do it.
Which E2EE messaging apps other than Signal provide auditable source and reproducible builds? Without those auditing the security of anything distributed by an app store is hopeless.
> Without those auditing the security of anything distributed by an app store is hopeless.
It's not. People have to realise that security is a gradient. Not everyone's enemy is the NSA. Some examples:
* With apps, you can verify that you are running the same build as random people on the Internet. In the browser you can't.
* With apps, you can verify that you are running a build signed by the same entity as random people on the Internet. In the browser you can't, and WhatsApp even has a browser extension just to allow you to check that Cloudflare didn't tamper with the code served by Meta (because obviously you trust Meta but not Cloudflare :-) ).
* You can compile an app from sources. You cannot do that in the browser.
* You can get an open source app that was compiled by someone you trust. You cannot do that in the browser.
> With apps, you can verify that you are running the same build as random people on the Internet
Not on iOS. You can't verify an iOS app at all. You technically could on Android but only by using developer tools and a separate PC.
> With apps, you can verify that you are running a build signed by the same entity as random people on the Internet
On the web every resource is signed with the certificate of the publisher. For all iOS apps and most Android apps you are required to trust the app store in addition to the publisher, which would be analogous to Cloudflare on the web, with the major difference being Cloudflare is optional and app stores are not!
> * You can compile an app from sources. You cannot do that in the browser.
Bullshit. You can absolutely have a reproducible web build that allows auditing that the assets you receive have not been tampered with.
> You can get an open source app that was compiled by someone you trust
Not on iOS, you have to trust Apple didn't modify it. On the web you can verify the certificate of someone you trust and know that what you're downloading is signed by them.
> E2EE is not limited to messaging apps.
So you concede that Signal, and only on Android, is the only messaging app that meets the bar of being auditable. Both web and native are auditable in theory. In reality the "E2EE" native apps people actually use are not any more auditable than browser apps.
> You can absolutely have a reproducible web build that allows auditing that the assets you receive have not been tampered with
What does that even mean? Show me how I can run ProtonMail on my browser today and verify that what my browser is running is the code they have open sourced? Or find me any example where they actually open source the code (not sure Proton does?).
> Not on iOS
So your argument against "web is fundamentally not built to allow that" is "but some app systems are closed"? Are you really trying to argue that "because some app systems are closed, all app systems are closed" or something?
> So you concede that...
Can you please not invent stuff?
> Both web and native are auditable in theory
So we agree somewhere: there are no laws of physics that say web cannot do it. Web is just not built for that, so in practice it's not there.
> In reality the "E2EE" native apps people actually use are not any more auditable than browser apps.
I don't know if you are consciously manipulative or if you don't realise it. My point is that if someone cares about E2EE, they can actually get some level of guarantee with apps. They can't realistically hope to get that with web.
I am not saying "all apps are 100% perfect, secure, auditable, E2EE" or whatever you may want to consider I conceded.
I find this unconvincing. Isn't this the exact same security posture as a native app with automatic updates turned on?
If your thought is just "disable automatic updates", there's no reason you couldn't do the same by declining new versions of a web app. Unless you built it yourself (as a web app or native app), you need to include the servers and DNS in your trust model.
To me, it seems entirely isomorphic. The only material difference I see is whether automatic updates are on by default (an OS/browser vendor issue, not anything inherent to the tech).
> Isn't this the exact same security posture as a native app with automatic updates turned on?
It's not, I don't think so. For instance, if you install Signal on your Android, the apk was signed by Signal, sent to Google and distributed by Google. Google cannot modify it, because Signal has to sign it. So in order to make you install a "malevolent" version of Signal, Google has to collude with Signal.
Of course you can download and install the apk from Signal's website, in which case Signal may give you personally a malevolent version. But you can easily compare that file to someone else's. On Android there are verifier apps that allow you to check that.
Finally if E2EE does matter a lot to you, you can compile Signal yourself from the sources, and even go as far as auditing those sources yourself.
You don't get to do any of that on the web. When you load ProtonMail in your browser, you don't have any practical way to verify that the code your browser is running is the same as everybody else who is running it around that time. You have to trust Proton that they give you code that prevents them from reading your emails. It is better than nothing or course, but it still means that you have to trust Proton.
> if you install Signal on your Android, the apk was signed by Signal, sent to Google and distributed by Google. Google cannot modify it, because Signal has to sign
I'd stress that for specifically Signal this seems to indeed still be true, but almost apps on Google Play are now signed by Google (with keys either generated by them or provided to them), and even customized by Google for your specific system.
Google requires it for all apps created after August 2021. *
---
> On Android there are verifier apps that allow you to check that.
If you mean Accrescent, it only checks the app's signature, not the hash of the individual versions.
I only know APK redistributors such as apkmirror that might let you check the individual app version, but they don't have API access and only host some apps.
And again, now almost apps on Google Play are signed by Google and customized on the fly for your device, so you typically can't really confront them.
---
* Except that apparently, since a couple months ago Google allows you to use their HSMs?
Even this magnanimous concession though is “strictly for enterprise organizations with mandatory compliance, regulatory, or policy requirements to retain key custody in an external Google Cloud KMS instance” (https://developers.google.com/android-publisher/api-ref/rest...).
There's some chance that they can't access these keys; but the app needs to be compiled on their servers, so yeah, plenty of ways for them to meddle with it, and probably even to issue signing requests.
This seems to have been introduced in July, it's the first time I hear of it
> but almost apps on Google Play are now signed by Google (with keys either generated by them or provided to them),
Yes! Google's goddamn "bundles" seem to be enforced to everybody. I guess part of Google "not being evil" and all. Another reason why initiatives like EU's Digital Markets Act are needed, I guess.
And yet another reason to use GrapheneOS, of course.
> If you mean Accrescent, it only checks the app's signature, not the hash of the individual versions.
No, there is an app called "AppVerifier" actually. That's the one I meant.
> I find this unconvincing. Isn't this the exact same security posture as a native app with automatic updates turned on?
Mostly. But the alternative shouldn't be a native app that updates itself, but rather a native app that is updated by a package manager. The big difference is traceability and auditability: With a trusted package manager (and even in good app stores) the company can only decide to push an update to everyone or to no-one. There is no way to push an update just to the pesky journalist or whistle blower. A covert attack is really hard to accomplish this way.
* The cryptography must be sound. That's the obvious one, if it's not encrypted then it's not "end-to-end" encrypted.
* There must be a practical way for the user to "verify" (with some definition of verifying) the client they are running.
A web browser doesn't provide that at all. It does not mean that everything else provides it: there are many ways to provide a Desktop app that break E2EE, but that is a different discussion. My point is that fundamentally, the web browser does not provide that. It's not that the laws of physics prevent it, it's just that the web browser never chose to provide that.
> it's just that the web browser never chose to provide that.
Yes, this exactly. If we wanted ‘verifiable’ app distribution via browser, then we’d need browsers to implement some way to cross check the code downloaded vs a publicly published list somewhere - similar to certificate transparency or what WhatsApp is trying to do with an extension [1]. Without that, web apps are left working with a weaker threat model.
> or what WhatsApp is trying to do with an extension
I remember looking into it, and while it is interesting, I think what it allows to verify is that the intermediary (Cloudflare, I believe) didn't tamper with the code being served. Which in the end allows the user to verify that the code they run comes... from the server they trust.
It would, but at this point, do you need a browser really? Like the big advantage of the web is that users load the latest version of whatever you serve, and they don't have to care about updates. In many cases that's desirable. But it fundamentally doesn't work for E2EE.
I am not trying to say "browsers should not exist, everything should be a desktop app". I guess I am more defending "some use-cases work better in a browser, others work better as desktop apps". And I have the strong feeling that over the last years (decades?) there has been a very strong push by web people to say "everything should run in the browser".
I wouldn't really say that the advantage of the web is that users load the latest version, there's plenty other real advantages of the web.
A browser allows you to run an app on any device (to a degree), so it definetely seems useful to me.
I'm actually not a fan of web apps, JavaScript and anything that came after XHTML, but it sure is/would be convenient to be able to run the same software on every device, without even having to recompile it.
The single reason I dislike browser "apps" is what we've been discussing here, that you can't check what you're running (well, also that it's hard to control their internet access).
Same here, I personally like to load "websites" in my browser, and to download "apps"... like as "desktop apps".
> but it sure is/would be convenient to be able to run the same software on every device
Oh yeah that's for sure. I can't help but to think that with a fraction of the resources that went into supporting webapps in browsers, it could have improved native systems a lot.
But even then, Kotlin MultiPlatform (KMP) is making me optimistic. With Compose MultiPlatform (CMP) I am hoping that it will make its way to desktop apps, too.
> without even having to recompile it.
If recompiling is the price to pay to have diversity, I'm fine with it. If 100% of the computers ran the exact same OS, it would simplify many things, but that one OS would certainly not be what I want to run.
> The single reason I dislike browser "apps" is what we've been discussing here, that you can't check what you're running (well, also that it's hard to control their internet access).
I dislike the fact that they force me to have a modern browser at all. I like having control over my OS, it's not for being forced to run everything in Google Chrome.
> I dislike the fact that they force me to have a modern browser at all
Yeah that's true
> But even then, Kotlin MultiPlatform (KMP) is making me optimistic. With Compose MultiPlatform (CMP) I am hoping that it will make its way to desktop apps, too
I personally hate Kotlin, but yeah it's one more option ;)
It depends on how the automatic updates are handled.
App updates can be cryptographically signed with a key that’s kept offline and only held by a few people. Your trust in the app can be equal to your trust in those people, multiplied by your trust in the technology that keeps those offline keys safe from compromise.
Your trust in a web app will be equal to your trust in the people running the server multiplied by your trust that the server isn’t compromised. Since the server is necessarily always online, that trust will be much lower.
Theoretically you can download a single HTML file and open it in the browser. However many web features require HTTPS (including JS Modules, yes) so this would be poor developer experience. I want to write simple apps and prototypes in local HTML files but W3C does not let me.
E2EE fundamentally exists for situations where we don't want to trust the server. That's the whole idea of E2EE, right?
Of course it's not black or white, security is a gradient. But if you want to check today that you are running the legit client of ProtonMail in your browser, you do not have a practical way to do it. It is theoretically feasible, I guess (?), but far from practical. But I can walk you through the steps needed to do it today with Signal, for instance.
I think I put my limit there: it's not enough to run cryptography. Verifying the client has to be practical for the user. The way ProtonMail works in the browser is a nice way for Proton to minimise the data they collect, but it's not E2EE, because even as an advanced user I cannot practically verify the client they serve me. In other words, E2EE means (to me) that there can be some kind of guarantee if you put a reasonable amount of effort into verifying it. The browser doesn't provide that at all.
Interestingly, shipping a webapp in ElectronJS (which is terrible in terms of software, IMO) is different: you can have E2EE in an ElectronJS app.
And I'm assuming that's why Signal has a Desktop app (which I believe is ElectronJS) and not a web (as in, "loads in the browser") version.
IMHO, the web should be to load websites (obviously) and small webapps that don't require E2EE or any kind of auditing. As soon as those are desirable, it shouldn't be a webapp anymore.
I find it nice to be able to load websites in my browser, instead of installing one program per website.
Because when you load a page in your browser, you fundamentally trust that the server is giving you what you expect. And the whole point of end-to-end encryption is that you don't trust the server.
If you download an install a program on your OS, you can e.g. check the hash of that downloaded archive and compare it to others, ideally making sure that you are running an audited version of the program. You don't have that guarantee when loading code in a browser: the server could totally serve you a modified version of the code, and you don't have a practical way to check that. Not that the laws of physics prevent it; it's just not how a browser works.
Whether E2EE is implementable or operational has nothing to do with whether you trust the code to actually facilitate it. E2EE can also be trivially circumvented by someone looking over your shoulder. This is not a coherent segmentation for whether E2EE is possible and engaged.
I am not sure what you are trying to say. Let me try an example.
Say you have a device that projects the screen on a skyscraper in Manhattan, visible by tens of thousands of people in real time. You can do all the cryptography you want, I would argue that you fundamentally cannot achieve "privacy" on that device, because "thousands of random people seeing it" means it is not private, by definition. Sure, you can run Signal on that device, and it does actually run sound E2EE maths. But it is not an "end-to-end encrypted deployment", it is a public deployment that happens to be running E2EE cryptography.
What I say is that running E2EE in a browser has that kind of nuance (as far as the comparison goes, obviously). In that the browser is indeed running E2EE cryptography, but it is not an "end-to-end encrypted deployment", because the user has to trust the server.
> This is not a coherent segmentation for whether E2EE is possible and engaged.
I would argue that it is. Just like E2EE is not "possible and engaged" on the skyscraped in Manhattan, I argue that it cannot be in a browser. The browser is running sound cryptographic code, but what the user gets is not an end-to-end encrypted experience.
That "trusting the code that runs in your browser when you load the website of a messaging webapp to actually facilitate E2EE" is out of scope for the question "is E2EE in a browser possible".
> I would argue that it is.
This is what I very directly disagree with. In both your Manhattan example, your browser example, or in my very own shoulder surfing example, it's not that E2EE isn't in place, it's that it is rendered useless by the circumstances. That is a distinct matter. The same applies to your heavily audited, reproducibly built, hash and signature checked, native, installed application. Worth jack if your phone itself, or the virtual keyboard you're typing on, etc, is compromised.
If this is how you segment things, E2EE cannot exist, hence why this is an incoherent segmentation; it selects for nothing that can actually exist, the label never truly applies. It's a category mistake.
But I feel like you are just nitpicking on the wording. When I say "you cannot have E2EE in the browser", I mean "you don't get what you expect if you expect that you don't have to trust the server". And the reason I say it is that many products advertise themselves as "E2EE", and many users believe that what they get from it is that they don't have to trust the server.
So I feel like the message I am trying to convey is "be careful people, you get less security than you think".
Similarly, I feel like the message you are trying to convey is "your wording is subpar". Sure, I'm not good with words, and I'm usually not taken seriously because of that. I am sorry about it. Story of my life, I'm used to it :-). I just wish eloquent people used their skill to help me convey my point (if they agree with me, obviously) rather than to make it sound like my point is worthless.
In a sense I am. We kind of both are, I'd say, for reasons we each think are important.
For example:
- you may wish to protect the trust in / reputation of E2EE, and so you might gonna have an axe to grind with in-browser implementations, and thus you may feel compelled to segment this subject accordingly
- I kind of have an axe to grind with E2EE exactly because of how little it can actually guarantee to begin with, so rather than protecting the trust and reputation of E2EE, I feel drawn to correct the popular record, and spread the word about the very serious limitations of this thing, making me segment accordingly (although I do think that even beyond this, I am right to bikeshed this)
I'm speculating on your part obviously, though not on mine. I think of E2EE as a bare minimum, not something to be particularly proud of and market, and the more I learn about how we secure our devices over the years and decades, the more distraught I feel about these technological measures. It's a lot more smoke than fire.
At the same time, I could also apologize for the bikeshedding, but then I'd hope it's clear that it's not like I did it to annoy you or anything, I just have a different perspective, and find different things salient. What's a perfectly acceptable and even a justified high level categorization to you, is a bending-of-reality category error for me, and vice versa. Happens when people from arbitrarily different walks of lives from arbitrarily different points in their life cross paths. No way around it as far I'm aware, and it's not like I don't see your point either. Like yes, loading up a random website is obviously way more of a gamble than pulling up an app you may very well even manually update biweekly, no doubt about it. It's just a difference in the overarching narrative suggested that I'm hung up on.
> I kind of have an axe to grind with E2EE exactly because of how little it can actually guarantee to begin with
Well then I think this is just wrong. If you do E2EE right, then you have the guarantee that no one in the middle (including the server) can read the data. It does have value, and saying "anyway cryptography is worthless because everything can be hacked" is not a productive argument IMO. Some people do rely on it, and it is important that those people understand when they can and when they cannot.
I don't really care so much about nomenclature and categorisation. I care about the fact that people who need it must understand when they can rely on it. And nitpicking on the wording is not making it clearer for them.
See, perspectives. ¯\_(ツ)_/¯ Ensuring that people have the right idea is why I do care about correct categorization, attribution, and phrasing. People readily twist way clearer things than what you wrote.
E2EE can technically exist on a web app, but it would be stupid to rely on it, so, yeah, I'd just be careful when using the term for web apps, since you get something way less secure than what the term evokes.
Everything that you understand, everything that you learn, everything that you experience gives you more value.
I studied CS, I have been a software engineer for 15 years. The one thing AI cannot take from me is my understanding, my experience, my intuition. An AI will gladly do whatever you tell it to do, and it is getting really good at it. But I regularly have to steer the AI to the right direction. Not because its default wouldn't have worked at all, but because I knew better.
If I task an AI to build something I don't understand myself, I can get further than without an AI, but I am limited. But when I use an AI to build something I am an expert at... I see that it is better than what non-experts get AIs to do.
You lose when you stop learning. You are a PhD student, you have learned to learn. Keep that. Keep learning actively. It was never about the PhD anyway: when you go to the industry, nobody cares about your PhD. What you have is what you know.
> Europe continues to push policies like Chat Control and attempt to backdoor/ban E2E encryption
Some politicians in Europe push for that, until now it has been refused by the others. Unlike in the US, there are many different parties in European countries. And Europe is made of politicians from many parties from many countries.
> The worst parts of Patriot Act were undone in 2015
So the NSA doesn't do any kind of domestic surveillance anymore, is that what you believe?
> the "F" in FISA stands for "Foreign". [...] Europe continues to push policies [...] for domestic surveillance.
So if it's surveilling allies, it's all good in your opinion?
> The present day and trajectory in Europe is far far more grim than in the US.
"Far far"? Do you even realise that Europe is not one single country? The US elected Trump, twice.
>> Some politicians in Europe push for that, until now it has been refused by the others. Unlike in the US, there are many different parties in European countries. And Europe is made of politicians from many parties from many countries.
> And yet neither party in the US is pushing for it...
This is a bad retort. The U.S. has 2 relevant parties. Most countries in the EU have at least twice as many relevant parties and there are over 25 countries in Europe, so you’re looking at close to 100 relevant parties.
Yes, I am an American living in Europe. I have pretty good insight into all of this.
> Some politicians in Europe push for that, until now it has been refused by the others. Unlike in the US, there are many different parties in European countries. And Europe is made of politicians from many parties from many countries.
And yet neither party in the US is pushing for it...
> So the NSA doesn't do any kind of domestic surveillance anymore, is that what you believe?
Do you have any evidence to the contrary? Or if you believe this without evidence, do you have any evidence this is not occurring in Europe?
> So if it's surveilling allies, it's all good in your opinion?
Lol, lmao even. Yes, of course it is. Allies spy on each other. The Europeans do it to each other massively and have done since the dawn of Europe. Good lord, go read some history.
> "Far far"? Do you even realise that Europe is not one single country? The US elected Trump, twice.
Again, I live in Europe. I am well aware, but thanks for the classic European condescension. I don't like Trump. But how has he weakened privacy rights? And yes, beacause I don't want to write dozens of caveats for each teeny tiny member state, I consider Europe to be dominated by happenings in DE + FR + UK. I don't care what Latvia does.
This is such a strange statement about a massively culturally diverse part of the world.
Many European countries speak such poor English that it'd be a miracle if they developed some sort of unified condescension.
I'd argue a big part of Europe not performing as well as other parts of the world economically is the LACK of any defined culture, it's really more like a hodgepodge of countries that have a thin layer of cooperation
I have no clue what English comprehension, monolith culture, and condescension have to do with one another? Or even the presumption that I only speak English?
It's not a strange statement in the slightest if you live here or spend any appreciable time here. I take it you do not.
I think you misunderstand their point. I think their point is that it's difficult to talk about a "typical European condescension" given that "Europe" is not one culture. It's made of many very different countries.
If you randomly take two Europeans, they probably speak a different language and have completely different opinions, but chances are that they can't even understand each other. If you randomly take two US citizen, they most certainly have a shared identity.
Oh given current affairs I don't even think two US neighbors have shared identity. Plus the whole thing about intersectionalism.. basically cut everyone into a million little groups and identifiers, nobody is left the same as anyone else.
I didn't say "they are the same". I said they share some part of their identity. It starts by saying "I am an American". Or thinking that 9/11 was an attack on their country. Or having the same government. Or having the same army. Or the same schooling system.
If you take two random Europeans, they most likely don't have the same school system. The bank of the first probably does not exist in the country of the second. One may be in the EU, the other may not. They have a different army, they possibly have a long history of being at war against each other in the past. They don't have the same architecture. They have a vastly different public transport system.
Sure, there is an identity at every level. Europeans do recognise themselves as Europeans, like South Americans do recognise themselves as South Americans. But the shared identity between a Chilean and a Brazilian is much smaller than the shared identity between two Brazilians.
I think that is not nearly as certain as you say. Some identities are very very outside the norms of local culture. (For example, I identify non-human, which is quite rare in any part of the world)
Well no two identities are exactly the same. But there is a shared part. It's an intersection.
When the USA hockey team played against Canada after Trump threatened to annex Canada, the Canadians booed the US team. Not because they hated the players, but because they wanted to show that they were pissed. As a response, the US supporters booed the Canadian players. Why? Because they felt attacked "as Americans", not because they supported Trump's idea of militarily invading Canada.
That is a shared identity. And surely in this crowd, not everybody identified as a white heterosexual male.
I believe that there is a bit of an asymmetry between US people and... well the rest of the world, in that the WHOLE world has some level of insights into the US. Whether they want it or not, for many different reasons.
However, the US don't typically have a good insights into... the rest of the world. Which does make sense: the rest of the world is pretty big.
Of course the US is more complicated than "they elected Trump". Sure, there are 50 states. But everybody knows that (be it just because your president repeatedly threatens to annex Canada as the 51st state ;-) ). People in the rest of the world do not need to "live in the US" to have that level of insights, because the US makes sure they do, by force if necessary.
The mere fact that you don't seem to be aware of this asymmetry at all suggests that you over-estimate your "pretty good insight into all of Europe".
As counterpoint, though, I've heard some absolutely bonkers impressions of the US made by some Europeans. And that's not isolated; there seem to be lots of Europeans who have some very strange ideas about what it's like in the US.
I do agree with your general point, though: I would expect your average European to have a better understanding of the politics of the US than your average American would have of even a prominent European country like Germany.
Totally, it happens everywhere. And there are stereotypical traits in every country. It's just that everybody tends to recognise the US ones, but nobody knows them for all the other countries. A random European cannot say "this is soooo typical of Latvia".
But a random European can easily say that the parent is sooo stereotypical of the USA :-).
Note that I believe there is some level of European identity. But "European condescension" is not really part of it, I would say. What the OP may have felt was maybe some "non-US condescension"? I think it could be a thing. The OP said "believe me I know Europe better than you, because I live in Europe AND I am an American" (which somehow implies that being an American made them more knowledgeable? Not sure). The answer was something like "dude, it's so American to believe and proudly say that you must know better because you are American", I felt. Sure, it's condescending. But I don't think that whatever the European shared identity is contains a "they are condescending against anyone non-European".
This comment could not have been more stereotypically American. I stress "stereotypical", I'm obviously not saying Americans in general are like this.
> I don't like Trump. But how has he weakened privacy rights?
Attacks on rule of law and civil liberties have increased, and the right to privacy is one of those liberties. It's of course not limited to Trump, he wasn't in office when Snowden showed the world the scale of American mass surveillance on domestic and foreign citizens.
> Do you have any evidence to the contrary?
I'm totally unsure what you are attempting to imply. That mass surveillance by the American state stopped at some point in the last 10 years?
> Allies spy on each other. The Europeans do it to each other massively and have done since the dawn of Europe. Good lord, go read some history.
What does that even mean "read history" ahaha. Espionage != mass surveillance. You do understand the difference, do you not?
> thanks for the classic European condescension
> I consider Europe to be dominated by happenings in DE + FR + UK. I don't care what Latvia does.
> This comment could not have been more stereotypically American.
Of course. As I noted before, dripping in European condescension. Nothing you can actually point to, just condescension from a region that has been left behind over the past century.
> Attacks on rule of law and civil liberties have increased, and the right to privacy is one of those liberties. It's of course not limited to Trump, he wasn't in office when Snowden showed the world the scale of American mass surveillance on domestic and foreign citizens.
Which right or in what way has the right to privacy been attacked? Fully agree with you on attacks on rule of law. And I find Trump incredibly dangerous. But I do not think privacy in the US today has suffered. Please educate me.
> I'm totally unsure what you are attempting to imply. That mass surveillance by the American state stopped at some point in the last 10 years?
I am not implying anything. The Freedom Act curtailed a bunch of activities. You are implying nothing has changed. All of the Snowden revelations implicated many European countries: intelligence agencies spying on each others populations. I am asking you if you believe nothing has changed in the US do you 1) have any evidence of this and/or 2) believe that anything has changed in Europe? You've answered neither.
> What does that even mean "read history" ahaha. Espionage != mass surveillance. You do understand the difference, do you not?
Do you understand that the mass surveillance of European people was done at the behest of the intelligence agencies of those countries? And ditto for the NSA. The agreement was "you spy on mine and I'll spy on yours and we'll swap the intel". I am not talking about espionage. Foreign intelligence agencies spying on foreigners...what did you think they did?
> l m a o. Oh say can you see...
God, it's so painful. Yes in the same way that you talk about the US as a monolith and not 50 individual states. You don't care what Rhode Island does any more than I care what Latvia does.
Christ you guys are insufferable. It's no wonder everyone is leaving in droves.
> Of course. As I noted before, dripping in European condescension. Nothing you can actually point to, just condescension from a region that has been left behind over the past century.
Let's see about that; Just me, some small guy with no knowledge on the topic.
> Which right or in what way has the right to privacy been attacked?
The US scans your device if you enter their land, e.g.
Oh; I heard ICE uses cameras to spy on their own citizen?
What about the raising Flock Cameras?
> But I do not think privacy in the US today has suffered. Please educate me.
A giant corporation just attacked another one. There were no repercussions.
If you think that isn't privacy: How about leaking civilian data to outsiders of the government? DOGE, anybody?
> I am not implying anything. The Freedom Act curtailed a bunch of activities. You are implying nothing has changed. All of the Snowden revelations implicated many European countries: intelligence agencies spying on each others populations. I am asking you if you believe nothing has changed in the US do you 1) have any evidence of this and/or 2) believe that anything has changed in Europe? You've answered neither.
Why does he has to provide evidence but you don't?
Also, I have never heard that an European Country spied on civilians from another country. That's an US and Chinese business model.
Things changed in the US. It is now a lawless country. A war mongering state which dumps its allies for their own benefit. They are actively hostile.
Your second question is so unspecific I have to require elaboration: "believe that anything has changed in Europe?" - I assume you are referring to Privacy Laws? We had plenty of new laws _protecting_ consumers in this regards. Handling data responsible.
Wait; What are you guys doing over there? Ah, right: You are pushing Age Verification and demand information on our criminal record systems. You are pushing biometric tracking. You are telling buys of your weapons that you have the right to disable them. Honestly: The US sucks right now. You guys have elected the stupidest idiot, twice. And now without any regulation you are actively supporting a technology which will undermine _all_ citizen in the world.
> Do you understand that the mass surveillance of European people was done at the behest of the intelligence agencies of those countries? And ditto for the NSA. The agreement was "you spy on mine and I'll spy on yours and we'll swap the intel". I am not talking about espionage. Foreign intelligence agencies spying on foreigners...what did you think they did?
Again: You are accusing all twenty five member states in one statement. To me you are just yelling polemic nonsense. EUROPOL is _cooperating_ with the US. They are hunting people breaking our laws. If any individual is lawless within our boundaries of justice, European states have the rights to try to prosecute them.
> God, it's so painful. Yes in the same way that you talk about the US as a monolith and not 50 individual states. You don't care what Rhode Island does any more than I care what Latvia does.
You are implying your behaviour. The US has _one_ president in order to bundle the power. Your states have their national rights. If you compare the US to the EU you are not informed.
> Christ you guys are insufferable. It's no wonder everyone is leaving in droves.
By appearing with such statements on the Internet as an European Civilian you are undermining our values. Maybe if you can not align with them you should proceed your journey.
You don’t care about Latvia and I don’t care about some dickhead who "lives in Europe" and knows it all. And I’m not even from Latvia, you’re just pathetic.
Does it not count as "passkey" then?
reply