W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2017

Re: Verified Javascript: Proposal

From: Daniel Huigens <d.huigens@gmail.com>
Date: Wed, 26 Apr 2017 19:12:45 +0200
Message-ID: <CAL14OeHJZ2CsoYgShLwV8xM1wAvognaNGToyC63t6A_B00Ra4A@mail.gmail.com>
To: Jeffrey Yasskin <jyasskin@google.com>
Cc: Eduardo Robles Elvira <edulix@nvotes.com>, public-webappsec <public-webappsec@w3.org>, Brad Hill <hillbrad@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:13:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:22 UTC