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
