Re: Proposal: Prefer secure origins for powerful new web platform features

On Fri, Aug 22, 2014 at 6:51 AM, Austin William Wright <aaa@bzfx.net> wrote:

> On Thu, Aug 21, 2014 at 10:13 PM, Ian Melven <ian.melven@gmail.com> wrote:
>
>>
>> I'm not seeing any arguments against requiring secure origins for certain
>> functionality beyond the same old arguments against using SSL :
>>
>> * it costs some almost negligible amount of money
>> * it requires some non-zero amount of work on the part of the website
>> operator
>>
>> am i missing something ?
>>
>> cheers,
>> ian
>>
>>
>
> The first point introduced, as I understand it, is that it's simply not
> appropriate for a TR to mandate use of an unrelated technology (even if
> otherwise a good practice), unless it's actually addressing a security
> concern (and even then, the e.g. "secure" flag on Cookies, HSTS doesn't
> normatively reference a particular technology).
>
This is the right root cause of the disagreement. And to be honest, I don't
see why the same rationale won't apply in the future for CSP, and HSTS, and
any other opt-in security feature.

Using the "particularly powerful" web features as a carrot to promote an
unrelated technology seems wrong. Specially when "particularly powerful"
has such a broad definition..

> "Particularly powerful" would mean things like: features that handle
> personally-identifiable information,
<input type=text name=address>?

> features that handle high-value
> information like credentials or payment instruments,
<input type=password>?

> features that
> provide the origin with control over the UA's trustworthy/native UI,
requestFullscreen?

> access to sensors on the user's device,
giroscope events? This won't work anymore then: http://www.google.com/teapot

> or generally any feature that
> we would provide a user-settable permission or privilege to.
IndexedDB? requestFileSystem?

Even a "particularly powerful" API (like access to a camera) still exists
> several abstraction layers above network transport. If at all: Use of such
> an API in a daemon (as opposed to a user agent) wouldn't even have a
> concept of a webpage, let alone the transport stream that delivered the
> resource. A concept of a "secure" webpage would be a foreign idea.
>
> And as also discussed, it would likely also mean prohibiting all
> unencrypted network traffic, including in XMLHttpRequest, WebSockets, Raw
> Sockets, script elements appended at runtime, etc. And especially in the
> case of Raw Sockets, it's not clear how the user agent would determine if
> the connection is sufficiently "secure" or not. In general, we can't say
> that in all cases, losing non-secure networking is a "feature". Suppose I
> refer to a resource via a peer-to-peer method like PPSP, with privacy
> concerns, but otherwise encrypted: Is that "secure" and allowed?
>
> A better solution is to make TLS cheap to setup. Really, really cheap -
> because it's not. There's lots of people - largely the offenders being
> targeted by this proposal - who would like TLS, but don't have it, don't
> know where to get started, or can't afford it. Opportunistic HTTP
> encryption would be a start (ensure everyone supports TLS), followed by
> DNSSEC-stapled certificates/DANE, so domain name owners can sign their own
> TLS certificates. (They, out of anyone, should be a trusted party, more so
> than an arbitrary Certificate Authority! And if DNSSEC must be configured
> anyways, surely adding a TLSA record isn't much extra effort, likely less
> effort than submitting a key-signing request to a CA.)
>
> Austin Wright.
>