W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

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

From: Harald Alvestrand <hta@google.com>
Date: Sat, 28 Jun 2014 10:34:49 +0200
Message-ID: <CAOqqYVHyo8KLZV6g08w8UU4NKttCO3_KAS9tCaA5dnd3bE_NHw@mail.gmail.com>
To: PhistucK <phistuck@gmail.com>
Cc: Ryan Sleevi <rsleevi@chromium.org>, Peter Kasting <pkasting@google.com>, blink-dev <blink-dev@chromium.org>, security-dev <security-dev@chromium.org>, dev-security@lists.mozilla.org, "public-webappsec@w3.org" <public-webappsec@w3.org>, Chris Palmer <palmer@google.com>
Just because this echoes the long discussions in WebRTC:
For cameras and microphones, the rule is:

- Permissions are prompted for when required
- Permissions can be stored for secure origins
- Permissions can NOT be stored for non-secure origins

We treat file: as a non-secure origin, because file: is frequently used for
things like HTML from incoming mail messages.
I'd argue that http://localhost should be in the same category as file:,
but would have to work through the cases to have a strong opinion here.

I like the idea of having a Web platform-wide definition of "secure" vs
"insecure" origins, so that we don't have a per-spec definition that is
inconsistent from feature to feature. But there are devils in those details.

On Sat, Jun 28, 2014 at 10:19 AM, PhistucK <phistuck@gmail.com> wrote:

> Regarding audio and video input - I would not dismiss that just yet.
> While we are still in the unfortunate situation of having a prefixed
> implementation (and I think no browser except Presto based Opera has a non
> prefixed implementation), we can take advantage of this and add the secure
> origin restriction when we remove the prefix.
> ☆*PhistucK*
> On Sat, Jun 28, 2014 at 3:35 AM, 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.
>> >
>> > PK
>> 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.
>> 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.
>> Would it make more sense to clarify that its in response to
>> deny-by-default permissions? 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.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to security-dev+unsubscribe@chromium.org.
>  To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscribe@chromium.org.
Received on Saturday, 28 June 2014 08:35:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:39 UTC