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

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