Yes. I'm constantly annoyed by the dark patterns Zoom and Slack use to trick you into downloading their desktop apps. The web experience is practically indistinguishable and much more secure.
> The web experience is practically indistinguishable
The web experience is actually better, as eg there I can do web searches when right clicking sth with my default search engine without slack highjacking the options to force me onto google.
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’.
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.
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.
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.
Don't let yourself be fooled into thinking this is enough. Plenty of examples of, especially through wasm, being able to reach far beyond what they're supposed to.
It gets buttoned up fast and is always getting better, but its absolutely not a silver bullet.
If you enable lockdown mode on your iPhone and Mac, WASM is disabled through Safari. If absolutely needed, an alternative browser like Firefox can be used for those sites.
Look at who is on the board of Dropbox and ask yourself what the value of a file syncing service having accessibility (and previously kernel extension) privileges on your machine are.
Not to mention that Dropbox has never been E2E protected and had that Lenovo credential free access bug on web not too long ago.
Dropbox should be considered untrustworthy at this point, especially since iCloud Drive offers E2E encryption and so do other competitors.
Don't most things people use day-to-day for both work and entertainment require use of the actual app these days, or at least make it very difficult to do so?
India's data collection is much worse than China's but we can also look at other metrics like exports. India exports less in total value than a resource-starved, tiny nation like South Korea.
Thus, India could at least add another 100 million manufacturing jobs, along with an additional 100 million service jobs to support manufacturing in logistics, trade, maintenance, customer support, insurance, and food service.
Given the structure of Indian constitution which gives very little power to local governments to raise revenue and build infrastructure, India is structurally limited as of now from ever becoming as developed as China, let alone western countries.
I see India becoming more like Brazil than China. That's not necessarily a bad thing since even Brazil is 4-5x richer in per capita than India.
Large organisation, hmmmkay, but for private persons, I disagree. Windows 11 is annoying as hell and removing the annoyances, while possible, is not easy for anyone not tech savvy.
I have been a software engineer for 8 years and not once I have had a jira ticket handed over to me by a senior engineer.
I have worked in startups before and currently work at bkng, and have friends at uber. Everywhere it is expected that the engineers will create their own tickets and refine them with the team. If you are in a product facing team, your PM could even help you with a PRD but I have not seen one in the last few years.
By contrast I have not worked anywhere that engineers originated tickets. And thankfully, only one place that used Jira (but the engineers didn't interact with it).
Tickets came from the product side, after being evaluated and prioritized. Engineers got involved with estimating effort (in "points") and doing the actual implementation of course.
Do you think it's acceptable to do the work of multiple full time positions? I can't imagine it's very sustainable, nor healthy for you (both body and soul).
My last job was like that, it was miserable having no agency. The whole team was from fang companies and were all ok with the tell me what to do dynamic.
usually in most when engineers tend to create their own tickets - it's for useless shit like improve x, clean up y etc.
very few people have worked in places with high agency - where you work with a higher up & create a feature/product line that has customer impact. startups are one of the few places I can think of with high agency.
