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. >
Received on Saturday, 28 June 2014 08:20:27 UTC