Re: Per-origin versus per-domain restrictions (Re: Restricting gUM to authenticated origins only)

2014-09-13 Thread Anne van Kesteren
On Sat, Sep 13, 2014 at 12:07 AM, Martin Thomson m...@mozilla.com wrote:
 On 12/09/14 13:59, Anne van Kesteren wrote:
 But shouldn't it be aware of this so you can adequately scope the
 permission? E.g. I could granthttps://amazingmaps.example/  when
 embedded throughhttps://okaystore.invalid/  permission to use my
 location. But it would not be given out if it were embedded through
 https://evil.invalid/  later on.

 Or e.g. I could allow YouTube embedded through reddit to go
 fullscreen, but not necessarily YouTube itself or when embedded
 elsewhere.

 In most cases (though here sicking's comment regarding what should happen
 remains especially applicable), the actor is the only thing that matters.

 That is, it's the principal of the JS compartment, which is the origin you
 see in the bar at the top.  The location that script is loaded from doesn't
 matter.

Yes, I know how the web works. I was talking about nested browsing contexts.


  An iframe embed is different, but in that context, the framed site
 retains complete control over its content and is arguably competent to
 ensure that it isn't abused; more importantly, the outer site has no
 visibility other than what the framed site grants it.

I just gave an example where it would matter. I could similarly
imagine that I'd be okay with skype.com to have persistant camera
access when I navigate to it, but not when skype.com is in an iframe
somewhere serving ads.


-- 
http://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Per-origin versus per-domain restrictions (Re: Restricting gUM to authenticated origins only)

2014-09-13 Thread Eric Rescorla
On Sat, Sep 13, 2014 at 12:38 AM, Anne van Kesteren ann...@annevk.nl
wrote:

 On Sat, Sep 13, 2014 at 12:07 AM, Martin Thomson m...@mozilla.com wrote

   An iframe embed is different, but in that context, the framed site
  retains complete control over its content and is arguably competent to
  ensure that it isn't abused; more importantly, the outer site has no
  visibility other than what the framed site grants it.

 I just gave an example where it would matter. I could similarly
 imagine that I'd be okay with skype.com to have persistant camera
 access when I navigate to it, but not when skype.com is in an iframe
 somewhere serving ads.


I just tested this and it appears that at least for gUM, IFRAMEs do *not*
get persistent permissions even if they would have them if they were
in the top level window. Rather, you always get prompted. You can
test this yourself using:

https://mozilla.github.io/webrtc-landing/gum_test.html
and
https://mozilla.github.io/webrtc-landing/gum_iframe.html (note: contains
mixed content for
test purposes) or the HTTP variant.

-Ekr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform