[jpgoldberg]

It is important to separate three security concerns:

1. Crypto delivered to the browser over HTTPS depends on the integrity of HTTPS.

2. A browser is a very hostile environment (injected JS, other browser extensions, etc.)

3. JavaScript may not be the best language for coding certain things (e.g., it is hard to remove strings from memory)

Depending on your use, some of these might be larger concerns than others. For us, 1Password.com, (1) is the biggest concern for those using the web-app. Our approach is to be very strict about TLS (TLS 1.2 only, HSTS, etc) and to encourage use of the native clients over the web-app.

[thinkloop]

The browser is not secure, but it's secure enough for banking and passwords - why is this that different?

[notyourwork]

The place that stores and manages your passwords for things like financial institutions has the right to decide if they would prefer a higher level of security.

Banking industry doesn't have much of a choice, they have to provide an online portal to service their customers. Customer's don't want or need a banking application to check their balance or do a bill pay.

[k__]

When will we have end-to-end encryption in the browser, is it even possible?

Can this be achieved with extensions?

What makes this unsafer than, lets say SSH?

I mean, it is a software I download from somewhere, just like a browser, so if I trust SSH to encrypt stuff I want, why can't I trust the browser to do the same?

[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).

[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.

[Buge]

What do you mean by end-to-end encryption?

If one end is the browser, and the other end is the server, then we already have end-to-end encryption: https (as long as you don't use a TLS terminating CDN).

[k__]

ah...

For example a social network, where I create messages and encrypt them and only my friends can read them, not the server.