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

Hi David,

> On 20 Dec 2014, at 7:25 am, David Singer <singer@apple.com> wrote:
> 
> A few comments, all minor:
> 
> 1) "We recognize that HTTPS will not solve all — or even many — security problems”
> 
> I hope it solves *many* problems; maybe it doesn’t solve “most” problems? If it only solves *few* problems, is it worth doing?

See:
  https://github.com/w3ctag/web-https/commit/023afa30

Thanks.


> 2) I really think that this paragraph needs considerable more text:
> 
> "We recognize that as this policy is implemented, it will further reduce the utility of shared HTTP caches -- a trend started by the transition of many popular Web sites to HTTPS (and thus, loss of a high proportion of cache hits). This is an unfortunate outcome, and we should continue to examine how efficiency can be gained without compromising security.”
> 
> As I think many fear that if they go to HTTPS their users’ perceived performance will go to hell.  Since we have a CDN employee on the Tag, I expect that they can say more :-)

Well, to be clear I’m not sure that being an employee of a CDN has much to do with it; it’s more that I’ve been doing HTTP caching for about 20 years, including deployments of large university, ISP and enterprise proxy caches, as well as doing reverse proxies at very high scale (not only CDNs, but also helping folks like Flickr), doing HTTP API caching, being a committer on Squid, being embedded with the Traffic Server team at Y!, writing caching extensions, etc. 

So, I guess I’m saying — I really like HTTP caching.

What I find interesting is that by the numbers I’ve seen and talked to people about in the industry, the vast majority of people *don’t* use a proxy cache; that said, what we all seem to be concerned about are those specific cases where they are used, and they really help. As I said before, I’m keenly interested in addressing those use cases, and the frontrunner seems to be something like SRI + p2p — but the privacy properties of that are really tricky, and therefore the browser folks have so far balked at going there. My understanding is that they want to get experience with the basics of SRI first before they go to more advanced use cases like this, and so in time and with discussion + a bit more mechanism, we may be able to address these cases.

Anyway, I’ll try to add some context roughy along the lines I explored in my previous mail, but without the bulk. I’ve created <https://github.com/w3ctag/web-https/issues/10>.


> 3) We had an interesting offline discussion at the privacy workshop on “imagine if every router on the internet did NAT”.  This means that the ability to trace people by IP address would be curtailed: people often don’t both to reduce fingerprinting because the source IP address has already ‘given the game away'. It’s an interesting thought experiment, but its impact on security might be negative.  (And there are many other problems, notably pper-peer connections for things like telephony.)
> 
> Maybe worth a paragraph?

Once one scratches the surface, you can find a multitude of security and privacy issues on the Web and Internet. While they’re important issues to consider, I’m striving to NOT make this finding the be-all-and-end-all of security and privacy, because it will make it that much difficult to agree upon, read, and understand. Small steps...


> 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 - Domenic opened an issue for this, and I agree it’s important to address. Suggestions for text welcome.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

Received on Saturday, 20 December 2014 04:50:39 UTC