4 ms·

Like everything it comes down to trust. I fail to see how shipping Javascript to a browser schould be treated any different than code shipped to a phone or your

Like everything it comes down to trust. I fail to see how shipping Javascript to a browser schould be treated any different than code shipped to a phone or your desktop. Yes the frequency of updates is different, but other than that if you can't trust the entity that sends you the code that you run, you are out of luck.

FabHK 3y ago
And the article says as much: > It is worth noting that this law also applies to non-web applications where the service provider supposedly being secured against is also the client software distributor; thus, the “end-to-end encryption” offered by Whatsapp and Signal, amongst other proprietary services, is equally bogus.
MattPalmer1086 3y ago
It's much easier to update or hack a web site than it is to distribute a new signed version of your code via app stores. On your web site, you could easily serve up different pages to different users. I think you'd have to distribute compromised copies of your app to everyone with an app store? Or is there any evidence that app stores can deliver different versions for specific users?
piaste 3y ago
It's not the frequency of updates, it's the control. I can easily ignore an application update until any arbitrary standards I require are satisfied; whether those standards are "ok, 48 hours have passed with no security alerts" or "my company's professional auditors have reviewed all code changes" is up to me. (Unless there's a breaking change on the server side, but precisely because app updates are not guaranteed, app backends are much more conservative than web backends). Controlling the updates for a web client might not be totally impossible but it's far, far more difficult and clumsy. Best case is it's a full SPA so you can just save the resources locally, but it's using classic server-side rendering with just a single chunk of client-side JS used for encryption... And of course there are no clearly announced and numbered releases, you need to keep refreshing the page to know when an update is deployed.

FabHK 3y ago

And the article says as much: > It is worth noting that this law also applies to non-web applications where the service provider supposedly being secured against is also the client software distributor; thus, the “end-to-end encryption” offered by Whatsapp and Signal, amongst other proprietary services, is equally bogus.

MattPalmer1086 3y ago

It's much easier to update or hack a web site than it is to distribute a new signed version of your code via app stores. On your web site, you could easily serve up different pages to different users. I think you'd have to distribute compromised copies of your app to everyone with an app store? Or is there any evidence that app stores can deliver different versions for specific users?

piaste 3y ago

It's not the frequency of updates, it's the control. I can easily ignore an application update until any arbitrary standards I require are satisfied; whether those standards are "ok, 48 hours have passed with no security alerts" or "my company's professional auditors have reviewed all code changes" is up to me. (Unless there's a breaking change on the server side, but precisely because app updates are not guaranteed, app backends are much more conservative than web backends). Controlling the updates for a web client might not be totally impossible but it's far, far more difficult and clumsy. Best case is it's a full SPA so you can just save the resources locally, but it's using classic server-side rendering with just a single chunk of client-side JS used for encryption... And of course there are no clearly announced and numbered releases, you need to keep refreshing the page to know when an update is deployed.