Re: Verified Javascript: Proposal

Source-code authenticity and integrity is standard in many areas.  We 
are already able to identify a web site and protect script against 
attacks (xss ..) . However - if an attacker is able to change code on 
the servers hard disk, it will be served and executed on the victims 
computer. Source codes certificates would prevent that as long as the 
signing process has not been compromised. This becomes even more of an 
issue because of installable "web-apps" with special permissions, 
complex script code and webassembly. So - I do support all efforts 
providing some sort of content signing.

m.


On 04/26/2017 10:36 AM, Jeffrey Yasskin wrote:
> On Tue, Apr 25, 2017 at 2:19 AM, Eduardo Robles Elvira 
> <edulix@nvotes.com <mailto:edulix@nvotes.com>> wrote:
>
>     Hello:
>
>     Thanks for the work and the proposal Daniel, I think "HTTPS
>     Content Signing" (HCS) could be very useful in some websites that
>     value highly transparency and trust..
>
>     > I wonder how the logged certificates would be used. I would expect web apps to update several times a day,
>     or even per hour. How would a user tell the difference between a
>     bug fix / feature release on the one hand, and something malicious
>     (from their PoV) on the other hand?
>
>     This can happen already today if you try to download frequently a
>     page source code and diff for changes. It is just not verifiable
>     publicly and perhaps more cumbersome.
>
>     In any case, even if HCS was to be made into a standard, it won't
>     fit all use-cases. If you don't see any advantage to this
>     technology, you could just not use it right? I certainly wouldn't
>     find reasonable to force the usage of HCS of all web pages and all
>     web sites.
>
>
> Daniel's asking to build HCS into browsers, which means he's asking 
> lots of other people to do work for him 
> <https://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94>. 
> 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.
>
> 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, 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.
>
> Jeffrey