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

On 1/9/2015 12:51 PM, Mark Nottingham wrote:
> While I agree with you in spirit — we should be building a Web for the
> long term, and we should allow unintended reuse — this seems like an
> argument that “we shouldn’t do X because it might reduce utility in
> undefined, far-future circumstances,” and that’s a VERY high bar to get
> past. It’s also one that AFAICT we haven’t applied to any other
> decision made at the W3C.

I buy your concern up to a point, but I think the case can be made that
caching has shown its utility often and in many distributed systems,
including until fairly recently (some argue still) on the Web.

IMO one of the brilliant things that Tim did in the original design of the
Web was to make artful gambles on architectural choices [1] that would
> tend< to have value over time.

Whichever path we choose is a gamble. Maybe a balanced analysis would
indeed suggest the emerging emphasis on https, but I confess that at times
the discussion has seemed a bit weighted toward presuming that it is.

> We discussed this finding at the TAG F2F this week, and I have some
> editing to do; among that is making it clear that this document is NOT
> about deprecating or disallowing http:// on the Web, but about making
> sure that https:// is as easy as possible to use, and that transitioning
> to it is relatively painless, while assuring that it’s used when
> appropriate (the so-called “powerful features” discussion).

I haven't had a chance to read the minutes. That still sounds just a bit 
strong to me. The painless to use part is fine. The question I have relates 
to nuance regarding the phrase "and that transitioning to it is relatively 
painless". There's a big difference between the following readings:

* Naming a resource with https vs http and serving it with HTTPS vs HTTP 
involves significant and complex tradeoffs (e.g. cacheability vs. 
security). This finding sets out those tradeoffs in a balanced way and 
explains how transition can be made painless when appropriate.

vs.

* The big trend is toward transition and you our readers should probably 
get on the bandwagon. That's why we're emphasizing how painless it is.

I'm happier with the TAG taking the first position than the second. I think 
that in most cases the role of the TAG should be to explain tradeoffs, and 
only where there is clear benefit to one choice (e.g. when in doubt, 
identify things with URIs) the TAG should weigh in with a SHOULD or a MUST. 
I'm not convinced we've reached consensus that most resources SHOULD or 
even "should" transition to https.

Noah

Received on Friday, 9 January 2015 20:53:13 UTC