[sly010]

You typically download SSH once, while you download js potentially on every page load.

It is also much harder to monkey-patch a native binary than to inject js into a browser tab.

Browsers by default trust any of hundreds of CA's, while SSH trusts none by default.

[Klathmon]

With service worker, you can have a similar setup to a traditional application (install once, and have the first installed version verify all other versions are signed by a correct key).

It's abstracted away from you, but with some work I feel a browser UI could be made to help with this process if people wanted it.

[Piskvorrr]

Again, the problem lies in the initial setup. How do you authenticate the very first load, in-browser? You can verify the loaded script, but how can you verify the first page? (Spoiler: You can't, unlike installing a binary through a modern install system)

[Klathmon]

You are relying on HTTPS for the initial "install", but with subresource integrity you could check that the hash of the initial script matches a known hash that you verify out-of-band (and then of course the browser verifies that the SRI hash matches what is executed)

It does take some knowhow, and it's not a good ux, but it's possible.

That's where my point of browsers making this easier comes into play. It's possible, and could actually have a pretty good UX, but they would need to build it into the platform.

[Piskvorrr]

I have specifically mentioned SRI - but matching the initial script out-of-band borders on the impossible (or at best "highly improbable"): you need two things, one is easy and one is hard. The easy part is verifying the hash of the initial page - a browser extension could do this (running JS again, oops); and the hard part is a trusted way of obtaining the hash OOB. "Takes some knowhow" doesn't even begin to describe the issues. Where are you obtaining this hash from, and how are you verifying that it's actually a legit and not a malicious one? (It's signed by the author's pubkey...which is verified how?) That doesn't "take some knowhow" - that takes a whole framework, half of which is currently imaginary.

You're handwaving that away as "oh, it's a simple matter of building it into the platform," where "it" is amongst other things a public key infrastructure and a secure software distribution system built with it. Easy peasy, right? (Spoiler: no) Contrast to a binary that's distributed through the platform's install/update system - all this is already built, and there's pretty good assurance that you're not getting a malicious result (signed packages).

[Klathmon]

You are preaching to the choir on that second part.

It's actually why I like services like keybase so much, they are actually trying to tackle that problem (with their own set of issues, but at least trying).

I was more trying to point out that we can get to where we are now in the browser.

Solving the problem of key distribution and management is way outside the scope of what I was talking about, and it's far from solved by platform install tools.

[detaro]

As far as I know, a Service Worker can't protect itself from being replaced by a "newer" one?

[k__]

I know that website JS isn't a solution.

But can't the browsers provide APIs for this?

I mean they force me to directly use user-events to switch to full-screen, why can't the do such things for crypto APIs, so that no one could mess with this?

[StavrosK]

Because you're downloading the program at every launch. A malicious program doesn't have to attack the APIs, it can just send the data to the bad guy's server after it's been legitimately decrypted.