[Bug 25972] Please require a secure origin

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972

--- Comment #16 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Ehsan Akhgari [:ehsan] from comment #15)
> (In reply to Henri Sivonen from comment #14)
> > From the Gecko Intent to Ship thread:
> > https://groups.google.com/d/msg/mozilla.dev.platform/bwC_Srw12CM/ReD8hQ1EsDsJ
> 
> Ryan, I'm curious to know what your take is on the last paragraph of Henri's
> post?

You're talking about the post with the paragraph "As for making new features
unavailable without TLS in order to promote  the use of TLS", right?

I disagree with Henri's explanations for the motivations, or the analysis of
risk, with providing the API to secure origins only.

There are two dimensions of discussion captured on this bug:
1) What is a secure origin/Can we find a necessary sufficient definition? 
2) Whether there is sufficient risk / sufficient benefit to exposing this API
to unauthenticated origins

For 1, I'm not going to spend much time discussing it here. Boris has already
captured some of the nuance, and I think the conversation is rightfully
continuing on in the context of WebAppSec for discussions of things like Mixed
Content (and how things like Blob URLs behave, service workers, sandboxed
iframes, etc)

For 2, the issue is not and has never been about "promoting TLS" as an
ideological point. It's about a belief, from careful evaluation of the security
properties of this API, that there is no possible net-positive impact of this
API surface without some form of code authentication. That is, we would have
zero interest in implementing this API if it was normatively required to be
available to unauthenticated origins, because this API would provide zero
benefit to the web platform, while introducing significant complexity for
implementors. The only benefits from this API are realized when delivered over
authenticated transports to authenticated origins.

Our principal is we want new APIs to be secure by default. Having the UA
ultimately place that decision in the author's hand by saving "caveat author",
and providing no guidance, continues the trend of insecure by default, where
authors can and will write applications that attempt to use security features
insecurely. It's correct that the web platform is vast and, for many reasons,
there are still lots of ways to shoot yourself in the foot. It's also true that
even with this API, there are ways to shoot yourself in the foot (for example,
unauthenticated encryption). However, for a new API with zero deployment, and
with very real risks, it seems we have a unique opportunity to pursue "secure
by default".

If this analysis is wrong, which we don't believe it is, it's something we can
always revisit. We can expand upon the definition of what is an authenticated
origin if we find we're too restrictive. We can potentially expose operations
that have "no" security surface (as some claim hashing does not, although
that's highly debatable). But if we ship it all by default, that's a decision
that can never be revisited. Based on the many uninformed discussions that have
happened in this WG regarding the security properties of the Web, we believe
the risk is real enough that the value is great enough to promote "secure by
default".

Again, this is nothing to do with "requiring TLS because TLS is great". It's
about taking a measured analysis of the intended use cases for this API, to
take into account public usage of this API, and to make a documented part of
the web platform work 'securely', to the best of our ability, by default.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 22 October 2014 17:59:08 UTC