Re: [blink-dev] Proposal: Prefer secure origins for powerful new web platform features

On Fri, Jun 27, 2014 at 5:35 PM, Ryan Sleevi <rsleevi@chromium.org> wrote:

> On Jun 27, 2014 5:02 PM, "'Peter Kasting' via Security-dev" <
> security-dev@chromium.org> wrote:
> > On Fri, Jun 27, 2014 at 3:55 PM, 'Chris Palmer' via blink-dev <
> blink-dev@chromium.org> wrote:
> >> "Particularly powerful" would mean ... generally any feature that
> >>
> >> we would provide a user-settable permission or privilege to.
> >
> > I don't really understand this last clause.  Users of browsers can set
> many permissions, e.g. in Chrome the user can grant or deny sites the
> ability to use plugins, open popup windows, run Javascript, etc. I doubt
> you intended to suggest that a new feature with a similar scope to those
> should be restricted.
>
> There is, I think, a balance.
>
> The examples you gave are examples where we default positive (allow), but
> then allow the user to deny. In effect, all origins BUT X have access to a
> permission.
>
I don't know that I'm comfortable with that summary.  We allow users to
globally default-deny these permissions.  In the case of plugins in
particular, we have a click-to-play setting that many people use that
amounts to default-deny.  There are arguments one could make for a browser
shipping that setting by default (although I agree with Chrome's decision
not to do so in this case), but those arguments don't really have much
connection to the security of the feature, they're more about preventing
annoyances that are widespread on the web.  If we end up conflating things
like "feature is scoped to HTTPS" with "feature is occasionally annoying",
I think we've made a mistake.

> However, for permissions where the assumption is default-deny (or prompt),
> those are certainly in scope. That's because if you grant Origin X access,
> and X is an origin delivered over an insecure transport, you've granted it
> to all origins, in effect.
>
Again, I think the reason _why_ such a thing would be default-deny is an
important part of the answer here.  I can imagine features that I think
your argument makes sense for, as well as ones where it doesn't.
 Accordingly, I wouldn't use "default-deny" in my list of descriptions of
the rules governing this, I'd instead focus on the reasons why a particular
capability could e.g. leak private data or something.  Which Chris
basically did.  Which is why the trailing "...or anything else that has
permissions" clause seemed not only confusing but unnecessary.

> geolocation, audio, video all come to mind as modern deny features that
> would, ideally, have been restricted for the reasons listed - though that
> horse has long since left the barn.
>
Clarity: I assume you mean audio/video recording, not playback (which is an
example of a capability we shouldn't restrict).

PK