W3C home > Mailing lists > Public > www-tag@w3.org > January 2015

Re: Draft finding - "Transitioning the Web to HTTPS"

From: Rob Meijer <rmeijer@xs4all.nl>
Date: Sat, 10 Jan 2015 10:04:16 +0100
Message-ID: <e640d00da8b1b123dc4d2d1bada26ae6.squirrel@webmail.xs4all.nl>
To: "Henri Sivonen" <hsivonen@hsivonen.fi>
Cc: "Marc Fawzi" <marc.fawzi@gmail.com>, "Eric J. Bowman" <eric@bisonsystems.net>, "Domenic Denicola" <d@domenic.me>, "Tim Berners-Lee" <timbl@w3.org>, "Chris Palmer" <palmer@google.com>, "Melvin Carvalho" <melvincarvalho@gmail.com>, "Mark Nottingham" <mnot@mnot.net>, "Public TAG List" <www-tag@w3.org>
On Fri, January 9, 2015 17:52, Henri Sivonen wrote:

> However, this thread makes me regret my position. Clearly, the issue
> is not just whether in technical actuality Web Crypto enables
> something that pure-JS crypto doesn't but about what sort of
> misconceptions Web developers' minds make up about the difference in
> capability. The notion that Web Crypto can give you meaningful new
> security/privacy properties when the JS code on the page calling Web
> Crypto arrived (from outside localhost) over http transport is false
> and harmful if relied upon as if it was true.

The same could be said for https that uses an infrastructure of something
like 600+ CA+sub-CA's. Web crypto over HTTPS at least could give security
people the ability to build plug-ins that use an alternative and less
flawed PKI or something like webkeys over http+webcrypto from the ground
up using nothing but HTTP and JS code. Something that seems like a nice
idea, for if new security research for the web is going to rely on browser
vendors, its definitely not going to happen.
Received on Saturday, 10 January 2015 09:04:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:09 UTC