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

On 12/10/2014 07:55 PM, Mark Nottingham 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 was responding to Dominic's statement (quoted above).

>> 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.

Proper positioning can help channel input to the right locations.

>> 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.
>
> 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").

Then why didn't you say so? :-)

> We've already taken a few pull requests; more are welcome.

Done: https://github.com/w3ctag/web-https/pull/6

Consider adding text suggesting where feedback should be sent, e.g. 
"high-level goes here; details go there".

> Cheers,
>
> -- Mark Nottingham   https://www.mnot.net/

- Sam Ruby

Received on Thursday, 11 December 2014 01:57:06 UTC