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

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

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.