Of course, but that's not the threat model we're protecting against. Note that we link to that article (and agree with it!) in the discussion. This isn't just for browser based products. The reference implementation is in JS and intended for packaged HTML5 mobile apps, and we'll follow with implementations in C, Python, Java, etc.
In the browser app scenario, we also declare on that very same page that the threat model is explicitly this: you're an application provider who doesn't want the liability of having a database of plaintext user supplied content. (I.e. protecting a business from its customers' activities.) Not the other way around.
Nonetheless you do have at least some liability because if your server is compromised for long enough for one or more users to sign in, their details could be captured using modified Javascript and used to decrypt their private data. It does provide protection against hackers stealing the whole database in one shot though.
Comments
Of course, but that's not the threat model we're protecting against. Note that we link to that article (and agree with it!) in the discussion. This isn't just for browser based products. The reference implementation is in JS and intended for packaged HTML5 mobile apps, and we'll follow with implementations in C, Python, Java, etc.
You say it's appropriate for browser apps on the the landing page.
In the browser app scenario, we also declare on that very same page that the threat model is explicitly this: you're an application provider who doesn't want the liability of having a database of plaintext user supplied content. (I.e. protecting a business from its customers' activities.) Not the other way around.
Nonetheless you do have at least some liability because if your server is compromised for long enough for one or more users to sign in, their details could be captured using modified Javascript and used to decrypt their private data. It does provide protection against hackers stealing the whole database in one shot though.