- 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>
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. > Thanks. > > 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? -Eric
Received on Friday, 19 December 2014 22:33:10 UTC