W3C home > Mailing lists > Public > public-privacy@w3.org > October to December 2014

Re: Fwd (TAG): Draft finding - "Transitioning the Web to HTTPS"

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Fri, 19 Dec 2014 15:32:28 -0700
To: Nicholas Doty <npdoty@berkeley.edu>
Cc: David Singer <singer@apple.com>, TAG List <www-tag@w3.org>, "public-privacy (W3C mailing list)" <public-privacy@w3.org>
Message-Id: <20141219153228.1677821d4fecf5dab533a7fd@bisonsystems.net>
Nicholas Doty wrote:
> Eric J. Bowman wrote:
> > 
> > David Singer wrote:
> > 
> >> 4) A discussion of the point from web-sites “look, all my content
> >> is public, I have nothing to hide and hence nothing to secure”
> >> maybe needs addressing?  (“You may not, but you are exposing your
> >> customers/visitors by insisting on plain HTTP.”)
> > 
> > Yes. I don't use cookies, so I don't understand what I'm exposing
> > visitors to by stubbornly insisting on HTTP. My site visitors seem
> > to be at greater risk by using their CC's at Sony or Target or...
> It does seem like it would be useful for the TAG finding to
> explicitly address this point.


> To summarize, sites are still exposing information about their users
> when they force visitors to use HTTP, even if there are no
> authentication cookies. In particular, the user’s reading habits are
> exposed (which page on your site are they reading? does that page
> contain words of political interest?). Non-authentication cookies are
> used to surveil users or identify them for more invasive attack [0].

Sorry, but is this problem actually solved by HTTPS in an era of super-
cookies? HTTPS doesn't hide the visited site IP from network admins. So
I still believe (until convinced otherwise, but I'm a hard audience) w3c
should come up with something better instead of copping out to using 
ubiquitous HTTPS despite its known problems.

> Also, without integrity guarantees, HTTP sites expose their users to
> the risk of running any script the attacker wishes to introduce,
> including potentially asking for access to sensitive device APIs.
> Network attackers can also introduce identifiers or modify content
> for HTTP browsing. That is, integrity also helps with confidentiality
> and other privacy concerns [1].

But still, why HTTPS? When I can solve those problems using HTTP Digest
and auth-int? To solve a problem nobody I know has ever come across in
the first place? So many of the reasons to not use HTTP come across as
FUD when I delve deeper -- theoretical problems pale in comparison to
actual problems, there are enough of those to go around without
resorting to scare tactics.

My opinion is Digest is more-easily-fixable than HTTPS, thus making for
a better starting point. When the main argument against Digest has for
years, been the inability to style the password box -- but is this any
worse of a problem than the unstyle-able invalid certificate box which
drives naive users away thinking my site has security issues, when it's
really a third-party gewgaw responsible?

Received on Friday, 19 December 2014 22:33:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:49:28 UTC