- From: Daniel Huigens <d.huigens@gmail.com>
- Date: Wed, 26 Apr 2017 19:16:29 +0200
- To: Jeffrey Yasskin <jyasskin@google.com>
- Cc: Eduardo Robles Elvira <edulix@nvotes.com>, public-webappsec <public-webappsec@w3.org>, Brad Hill <hillbrad@gmail.com>
Forgot [1]: https://github.com/WhisperSystems/Signal-Desktop/issues/871 2017-04-26 19:12 GMT+02:00 Daniel Huigens <d.huigens@gmail.com>: > 2017-04-26 17:36 GMT+02:00 Jeffrey Yasskin <jyasskin@google.com>: >> Daniel's asking to build HCS into browsers, which means he's asking lots of >> other people to do work for him. We have to decide whether the potential >> benefit is worth that work, and if it's only appropriate for very few use >> cases, it's probably not worth it. > > I agree. I think there is probably not an abundance of web apps that > will use HCS, but I think that the ones that will will be high-value > web apps, such as E2E messaging apps (as Brad brought up), encrypted > storage, Bitcoin clients, things like that. More importantly, HCS will > allow *new* web apps like that to be created, that simply wouldn't be > secure today. Here's a discussion about that regarding Signal Desktop > [1], with metromoxie (ex-Google Chrome Security team) specifically > saying he wants a feature like this. > > The other category of apps that would benefit from HCS are ones that > don't particularly have anything to do with encryption, but also don't > trust the server, for example by being completely client-side. > >> Now, HCS is not the only way to achieve its goals. Brad Hill proposed >> another way, that would likely work for more kinds of sites, > > I disagree. I think for a large web application, requiring Subresource > Integrity for every resource is unmaintainable, and disallowing > eval(), inline event handlers, and more, is restricting. What if you > have a Web Worker, referenced by a script, referenced by an iframe, > etc? Ignoring the fact that Subresource Integrity for Web Workers and > iframes doesn't exist yet. Having an external list of resources and > hashes, be it in the certificate or an external file, is much easier. > >> and even Brad's proposal might not be the best option. > >> We should follow the WHATWG's proposal process, described at >> https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F: >> describe the threat model that we want a defense against, and the kinds of >> infrastructure that should be able to deploy the solution, and then look for >> defenses against those threats that can be deployed by those kinds of >> infrastructure. >> >> The https://github.com/twiss/hcs repository would be a good place to start >> that requirements document if you're interested in pursuing it, or Brad >> might already have a document started somewhere else. > > Sure. I've started with a list of attacks I want a defense against here: > > https://github.com/twiss/hcs/blob/master/threat-model > >> Jeffrey
Received on Wednesday, 26 April 2017 17:17:22 UTC