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,
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
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
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
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
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/
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
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
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
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
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
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
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
13 matches
Mail list logo
