Re: Per-origin versus per-domain restrictions (Re: Restricting gUM to authenticated origins only)
On 2014-09-14, 3:54 AM, Anne van Kesteren wrote: On Sat, Sep 13, 2014 at 5:42 PM, Eric Rescorla e...@rtfm.com wrote: 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. That sounds good. However, given that apparently that's not something the permission manager takes care of, it might be nice to cover it there, so this becomes easier for all kinds of APIs that require permission. We could obviously do what you suggest, but it's not really obvious to me whether the same behavior makes sense everywhere. I think what I would expect as a user would be very different depending on the context. For example, for the youtube use case that you mentioned, I don't see why we might want to treat embedded youtube differently rather than youtube.com in the top level browsing context. For a maps widget that communicates my current location to the parent browsing context though, my expectations are different because in that case, we'd be effectively giving the permission to the wrong website as far as the user is concerned. Also, at least in the case of IndexedDB, we have gone with the more restrictive, and initially disabled access to the database from nested browsing contexts, but there seems to be legit use cases that would benefit from that (such as MakeDrive http://blog.humphd.org/introducing-makedrive/) and now people are working on making it less restrictive (see bug 912202). I think it would be very hard to come up with a one-size-fits-all answer here, but perhaps we can. ___ 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)
On Mon, Sep 15, 2014 at 11:15 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-09-14, 3:54 AM, Anne van Kesteren wrote: On Sat, Sep 13, 2014 at 5:42 PM, Eric Rescorla e...@rtfm.com wrote: 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. That sounds good. However, given that apparently that's not something the permission manager takes care of, it might be nice to cover it there, so this becomes easier for all kinds of APIs that require permission. We could obviously do what you suggest, but it's not really obvious to me whether the same behavior makes sense everywhere. The argument that I'm making, and I think Anne is too, is that we should have the ability to store policies like this in the nsIPermissionManager. That way we *can* use it in places where it makes sense, or we can choose to simply store policies like allow youtube.com to use flash independent of parent frames where that makes sense. / Jonas ___ 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)
On 2014-09-15, 4:40 PM, Jonas Sicking wrote: On Mon, Sep 15, 2014 at 11:15 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-09-14, 3:54 AM, Anne van Kesteren wrote: On Sat, Sep 13, 2014 at 5:42 PM, Eric Rescorla e...@rtfm.com wrote: 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. That sounds good. However, given that apparently that's not something the permission manager takes care of, it might be nice to cover it there, so this becomes easier for all kinds of APIs that require permission. We could obviously do what you suggest, but it's not really obvious to me whether the same behavior makes sense everywhere. The argument that I'm making, and I think Anne is too, is that we should have the ability to store policies like this in the nsIPermissionManager. That way we *can* use it in places where it makes sense, or we can choose to simply store policies like allow youtube.com to use flash independent of parent frames where that makes sense. Yes, of course, I agree that we should do that. ___ 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)
On Mon, Sep 15, 2014 at 10:40 PM, Jonas Sicking jo...@sicking.cc wrote: The argument that I'm making, and I think Anne is too, is that we should have the ability to store policies like this in the nsIPermissionManager. That way we *can* use it in places where it makes sense, or we can choose to simply store policies like allow youtube.com to use flash independent of parent frames where that makes sense. Agreed. And it puts all our permission policies within the permission manager, rather than being local hacks that might accidentally vary from feature to feature. -- https://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)
On Sat, Sep 13, 2014 at 5:42 PM, Eric Rescorla e...@rtfm.com wrote: 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. That sounds good. However, given that apparently that's not something the permission manager takes care of, it might be nice to cover it there, so this becomes easier for all kinds of APIs that require permission. -- 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)
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)
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
Re: Per-origin versus per-domain restrictions (Re: Restricting gUM to authenticated origins only)
On Fri, Sep 12, 2014 at 11:56 AM, Frederik Braun fbr...@mozilla.com wrote: Yes and no. I identified this while working on a thesis on the Same Origin Policy in 2012 and filed this only for Geolocation in bug https://bugzilla.mozilla.org/show_bug.cgi?id=812147. But the general solution might be a permission manager rewrite, I suppose? That seems like a good idea. TLS permissions leaking to non-TLS seems really bad. Cross-port also does not seem ideal. I hope it's not as bad as cookies in that it also depends on Public Suffix? If we rewrite I think it would be good to take top-level browsing context partitioning under consideration. That is, if I navigate to https://example/ and grant it the ability to do X. And then navigate to https://elsewhere.invalid/ which happens to embed https://example/, the embedded https://example/ does not have the ability to do X. -- 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)
On 12.09.2014 12:22, Anne van Kesteren wrote: On Fri, Sep 12, 2014 at 11:56 AM, Frederik Braun fbr...@mozilla.com wrote: Yes and no. I identified this while working on a thesis on the Same Origin Policy in 2012 and filed this only for Geolocation in bug https://bugzilla.mozilla.org/show_bug.cgi?id=812147. But the general solution might be a permission manager rewrite, I suppose? That seems like a good idea. TLS permissions leaking to non-TLS seems really bad. Cross-port also does not seem ideal. I hope it's not as bad as cookies in that it also depends on Public Suffix? If we rewrite I think it would be good to take top-level browsing context partitioning under consideration. That is, if I navigate to https://example/ and grant it the ability to do X. And then navigate to https://elsewhere.invalid/ which happens to embed https://example/, the embedded https://example/ does not have the ability to do X. I filed bug https://bugzilla.mozilla.org/show_bug.cgi?id=1066517 for this. ___ 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)
On 2014-09-12, 6:22 AM, Anne van Kesteren wrote: On Fri, Sep 12, 2014 at 11:56 AM, Frederik Braun fbr...@mozilla.com wrote: Yes and no. I identified this while working on a thesis on the Same Origin Policy in 2012 and filed this only for Geolocation in bug https://bugzilla.mozilla.org/show_bug.cgi?id=812147. But the general solution might be a permission manager rewrite, I suppose? That seems like a good idea. TLS permissions leaking to non-TLS seems really bad. Cross-port also does not seem ideal. I hope it's not as bad as cookies in that it also depends on Public Suffix? The permission manager was originally used to store the permission of websites who are allowed to set third-party cookies if you turn on that pref, and it's not used for storing the cookies themselves. As such, it is fortunately oblivious to the Public Suffix List. If we rewrite I think it would be good to take top-level browsing context partitioning under consideration. That is, if I navigate to https://example/ and grant it the ability to do X. And then navigate to https://elsewhere.invalid/ which happens to embed https://example/, the embedded https://example/ does not have the ability to do X. The permission manager itself is unaware of browsing contexts, it is the consumer which decides how to query it. ___ 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)
On Fri, Sep 12, 2014 at 11:44 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: If we rewrite I think it would be good to take top-level browsing context partitioning under consideration. That is, if I navigate to https://example/ and grant it the ability to do X. And then navigate to https://elsewhere.invalid/ which happens to embed https://example/, the embedded https://example/ does not have the ability to do X. The permission manager itself is unaware of browsing contexts, it is the consumer which decides how to query it. This is one of the bad things with the permission manager. It leads to that we end up with different policies for different permissions. It's actually even worse than that. Because it is the *reader* that sets the policy, it means that a cookie policy written to the permission manager could be interpreted in different ways depending on which exact code is checking the permission manager. What we really should do is to enable writing into the permission manager set this cookie policy for domain and subdomains or set this cookie policy for this domain or set this cookie policy for this origin. And then make the reading side simply ask can this principal send cookies. Rather than the current can this principal send cookies assuming that the stored data should use policy X. We can probably expand this pattern to also handle 3rd party iframes. Note that there are use cases for both narrow and broad policies. At the very least it seems useful to be able to say both deny all of *.adnetwork.com from using cookies as well as allow https://google.com/ to use camera. / Jonas ___ 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)
On Fri, Sep 12, 2014 at 8:44 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: The permission manager itself is unaware of browsing contexts, it is the consumer which decides how to query it. But shouldn't it be aware of this so you can adequately scope the permission? E.g. I could grant https://amazingmaps.example/ when embedded through https://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. -- 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)
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. 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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
