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

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

From: Henri Sivonen <hsivonen@hsivonen.fi>
Date: Thu, 11 Dec 2014 14:46:48 +0200
Message-ID: <CAJQvAudpakfn4E+Qxd=JKehyQMdwwVfi_OyJuR4G7sD1AiwBNw@mail.gmail.com>
To: "www-tag@w3.org List" <www-tag@w3.org>
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.

> * 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

On Tue, Dec 9, 2014 at 2:57 AM, Noah Mendelsohn <nrm@arcanedomain.com> wrote:
> I also have the vague impression that there is a loss of privacy that
> indirectly results from the reduced practicality of proxies, but I'm not
> sure that intuition is correct.

There seem to be two supposed privacy-favorable effects from proxies:
 1) The proxy hides the IP address of the browser from the origin server.
 2) If the request is responded to from proxy cache, the origin server
doesn't see the request at all.

#1 doesn't work in practice due to X-Forwarded-For and similar
attempts by proxy operators to deliberately avoid acting as
anonymizers. So you end up exposing behavioral data to both the proxy
and the origin server.

#2 doesn't work when only relatively few requests are actually
responded to from cache (as shown by Henry Thompson's data) and
doesn't work when e.g. the request for HTML goes to the origin server
even though images/script/stylesheets come from the proxy cache.

Henri Sivonen
Received on Thursday, 11 December 2014 12:47:17 UTC

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