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

On 2014-12 -10, at 19:55, Mark Nottingham <mnot@mnot.net> wrote:

> 
>> On 11 Dec 2014, at 5:28 am, Sam Ruby <rubys@intertwingly.net> wrote:
>> 
>> On 12/10/2014 12:31 PM, Domenic Denicola wrote:
>>> From: Melvin Carvalho [mailto:melvincarvalho@gmail.com]
>>> 
>>>> Firstly, HTTP isnt always insecure, it can be, but is not always
>>> 
>>> HTTP is always insecure by definition. The insecure transport is not
>>> always being *attacked*, but you have literally no way of knowing
>>> whether you're being attacked or not, so for all practical purposes
>>> you must always assume an attack.
>> 
>> I'll make an assertion, an observation, and a recommendation.
>> 
>> I'll assert that 'http://localhost:8088/' is secure.  More precisely, if that can't be secured, then one needs to give up all hope.  I'd suggest that a web server on a camera connected via USB to a desktop is another such scenario.
> 
> I don't think anyone disputes that; it's been long established (both in the Chrome document and the subsequent POWER document) that this is the case. 
> 
> 
>> I'll observe that the current draft finding, as currently written, seems to be provoking peoples desire to present the "other side".
> 
> If you can find a way to have a standards discussion without that happening, I for one would be keenly interested.
> 
> 
>> I'll recommend that future TAG drafts attempt to preemptively document the other side; i.e., attempt to capture and exhaustively enumerate the the precious few times when http is secure enough.
> 
> That's what the POWER document will do. This document is NOT intended to contain the details (despite many attempts to get them in), as it's a "high-level" policy document. The original version of this document <https://gist.github.com/mnot/38df717849b775eec3a4/68afec63b782f34d822afc553b904ce86f2ef69c> contained that information, but after discussion, we decided that level of detail was more appropriate in a REC-track document.

I think this finding should not be "high level" in that it should omit the arguments.
I don't feel a TAG finding is something which should do that.  
The world is big, there are many cases out there, like data mashups, where a blanket move to HTTPS just breaks things.
It should say that clearly.

> 
> The language in the draft finding is attempting to balance between being correct (using phrases like "secure origins") and being comprehensible to the majority of people who read it (i.e., those who don't want to know the details, for whom 99% of the answer is "HTTPS").
> 
> We've already taken a few pull requests; more are welcome.
> 
> Cheers,
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 
>