W3C home > Mailing lists > Public > www-tag@w3.org > December 2014

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

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 12 Dec 2014 11:12:17 +1100
Cc: "www-tag@w3.org List" <www-tag@w3.org>
Message-Id: <7BCAC328-9895-40AA-8817-9A9DD1F19680@mnot.net>
To: Henri Sivonen <hsivonen@hsivonen.fi>
Hi Henri,

> On 11 Dec 2014, at 11:46 pm, Henri Sivonen <hsivonen@hsivonen.fi> wrote:
> On Tue, Dec 9, 2014 at 1:28 AM, Mark Nottingham <mnot@mnot.net> wrote:
>> We've started work on a new Finding, to a) serve as a Web version of the IAB statement, and b) support the work on Secure Origins in WebAppSec.
>> See: <https://w3ctag.github.io/web-https/>
> Thank you for this! It's great to get signaling to this direction from the TAG.
> Can you elaborate on what this means (specifically if it means Web
> content-callable APIs):
>> Finally, imposing policy in endpoints implies creation of a browser API for doing so.
>> The TAG encourages work in this area, provided there is a good chance of
>> implementation and a reasonable outcome.
> ?

We're saying that since we believe policy should be imposed in endpoints, we need better facilities for doing that.

One way is to improve the UX for inserting a new root into the trust store; it's pretty bad now. By "improving", I mean that the security implications of doing so should be more apparent, and there should be better tools for restricting the capabilities of a particular trust root.

Another way is to provide APIs (probably not Web APIs as most people think of them, but rather extension APIs) for software (possibly running elsewhere) to do things like filtering, scanning, etc. -- with limited capability, rather than the all-or-nothing proposition that a proxy makes. 

I'll cheerfully admit that this latter point is speculative, but it's informed by discussions with and among browser network engineers.

>> * The example of a village with poor access (e.g., in Africa) has regularly been
>> brought up in the IETF as an example of a population who want shared
>> caching, rather than encryption. The (very strong) response from folks who
>> have actually worked with and surveyed such people has just as regularly
>> been that many of these people value security and privacy more.
> Thank you for bringing this up.
> It seems to me that there is a pattern that people find the theory of
> forward proxies architecturally appealing and then try to find use
> cases that fit the architecture. The previous hobbyhorse of this kind
> was "transcoding proxies". No one had really seen one (*reverse*
> proxies and origin servers don't count) or had a personal need for one
> but they were believed to exist Over There in Russia and it was
> supposedly important to design protocols and formats to cater to them
> (even though the more reasonable protocol design choice was for
> everyone to use UTF-8 and not transcode anything--and even failing
> that, browsers have built-in support for a whole bunch of Cyrillic
> legacy encodings, so there is no need for intermediaries to transcode
> anyway). People making this argument weren't themselves from Russia,
> of course. Hence, "Over There".
> It seems that Africa has taken Russia's place as Over There where
> theoretical use cases for the pre-supposed proxy architecture might
> lurk.

Well said.


Mark Nottingham   https://www.mnot.net/
Received on Friday, 12 December 2014 00:12:46 UTC

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