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: Restricting gUM to authenticated origins only
On 11.09.2014 19:04, Anne van Kesteren wrote: On Thu, Sep 11, 2014 at 6:58 PM, Martin Thomson m...@mozilla.com wrote: On 2014-09-11, at 00:56, Anne van Kesteren ann...@annevk.nl wrote: Are we actually partitioning permissions per top-level browsing context or could they already accomplish this through an iframe? As far as I understand it, permissions are based on domain name only, they don’t include scheme or port from the origin. So it’s probably less granular than that. That seems somewhat bad. Yes. AFAIU (I might be terribly wrong), this is because all of those permissions (gUM, Geolocation, Offilne Storage, Fullscreen) are using the Permission manager we still have from the Popup Blocker/Cookie Manager. This is domain based. Not origin :( You can see this in about:permissions. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On Fri, Sep 12, 2014 at 12:39 PM, Frederik Braun fbr...@mozilla.com wrote: On 11.09.2014 19:04, Anne van Kesteren wrote: On Thu, Sep 11, 2014 at 6:58 PM, Martin Thomson m...@mozilla.com wrote: On 2014-09-11, at 00:56, Anne van Kesteren ann...@annevk.nl wrote: Are we actually partitioning permissions per top-level browsing context or could they already accomplish this through an iframe? As far as I understand it, permissions are based on domain name only, they don’t include scheme or port from the origin. So it’s probably less granular than that. That seems somewhat bad. Yes. AFAIU (I might be terribly wrong), this is because all of those permissions (gUM, Geolocation, Offilne Storage, Fullscreen) are using the Permission manager we still have from the Popup Blocker/Cookie Manager. This is domain based. Not origin :( You can see this in about:permissions. This is shocking. Making the fundamental design bug of cookies affect everything else is *really* bad. Is there a bug on file for fixing this? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Per-origin versus per-domain restrictions (Re: Restricting gUM to authenticated origins only)
On 12.09.2014 11:51, Henri Sivonen wrote: On Fri, Sep 12, 2014 at 12:39 PM, Frederik Braun fbr...@mozilla.com wrote: On 11.09.2014 19:04, Anne van Kesteren wrote: On Thu, Sep 11, 2014 at 6:58 PM, Martin Thomson m...@mozilla.com wrote: On 2014-09-11, at 00:56, Anne van Kesteren ann...@annevk.nl wrote: Are we actually partitioning permissions per top-level browsing context or could they already accomplish this through an iframe? As far as I understand it, permissions are based on domain name only, they don’t include scheme or port from the origin. So it’s probably less granular than that. That seems somewhat bad. Yes. AFAIU (I might be terribly wrong), this is because all of those permissions (gUM, Geolocation, Offilne Storage, Fullscreen) are using the Permission manager we still have from the Popup Blocker/Cookie Manager. This is domain based. Not origin :( You can see this in about:permissions. This is shocking. Making the fundamental design bug of cookies affect everything else is *really* bad. Is there a bug on file for fixing this? 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? ___ 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
Re: Restricting gUM to authenticated origins only
On Thu, Sep 11, 2014 at 1:50 AM, Martin Thomson m...@mozilla.com wrote: That is devious. I suspect that there is a banal reason relating to the use of the Google Front End that motivates the change, but the side effect of having all Google properties have access to user permissions from all other properties is no doubt appealing to some product managers over there. Are we actually partitioning permissions per top-level browsing context or could they already accomplish this through an iframe? -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On 2014-09-11, at 00:56, Anne van Kesteren ann...@annevk.nl wrote: Are we actually partitioning permissions per top-level browsing context or could they already accomplish this through an iframe? As far as I understand it, permissions are based on domain name only, they don’t include scheme or port from the origin. So it’s probably less granular than that. In the Google case, I doubt that there is anything meaningful we can do to scope permissions in a way that would both prevent Google from sharing a persistent grant. Not without breaking a great number of sites. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On Thu, Sep 11, 2014 at 6:58 PM, Martin Thomson m...@mozilla.com wrote: On 2014-09-11, at 00:56, Anne van Kesteren ann...@annevk.nl wrote: Are we actually partitioning permissions per top-level browsing context or could they already accomplish this through an iframe? As far as I understand it, permissions are based on domain name only, they don’t include scheme or port from the origin. So it’s probably less granular than that. That seems somewhat bad. In the Google case, I doubt that there is anything meaningful we can do to scope permissions in a way that would both prevent Google from sharing a persistent grant. Not without breaking a great number of sites. Well, if there's https://maps.example/ that I share my location with, we could make it so that it if https://maps.example/ is embedded from https://mercent.example/, it no longer has the permission. That's what I meant with partitioning by top-level browsing context. -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On 2014-09-11, at 10:04, Anne van Kesteren ann...@annevk.nl wrote: Well, if there's https://maps.example/ that I share my location with, we could make it so that it if https://maps.example/ is embedded from https://mercent.example/, it no longer has the permission. That's what I meant with partitioning by top-level browsing context. Oh, I don’t think that there are any iframes involved in the normal maps embedding process. So each mashup will have to acquire their own consent. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On Tue, Sep 9, 2014 at 8:13 PM, Eric Rescorla e...@rtfm.com wrote: On Tue, Sep 9, 2014 at 1:32 AM, Henri Sivonen hsivo...@hsivonen.fi wrote: On Mon, Sep 8, 2014 at 6:06 PM, Eric Rescorla e...@rtfm.com wrote: On Sun, Sep 7, 2014 at 11:45 PM, Henri Sivonen hsivo...@hsivonen.fi wrote: On Fri, Sep 5, 2014 at 4:15 PM, Eric Rescorla e...@rtfm.com wrote: On Fri, Sep 5, 2014 at 3:34 AM, Henri Sivonen hsivo...@hsivonen.fi wrote: On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen hsivo...@hsivonen.fi wrote: Is current gUM restricted to authenticated origins? If it isn't, is it realistic to restrict it to authenticated origins? That's a good idea but it's a separate issue. Is it already being pursued or should I file a bug? It's not being pursued. It was considered in the WG and rejected. Do *you* think the WG's stance on this was and continues to be the right call for our users Eh.. Not sure. AFAIK, there's not much of a reason why arbitary sites shouldn't be able to access your camera and microphone, provided that you're not placing trust in the site to do anything in particular with your data. I can see that being a valid abstract argument. I wonder, though, if there are non-demo use cases where it's appropriate to ask the user to assume lack of trust. Considering that camera and microphone are particularly privacy-sensitive, I'm worried about not erring on the side of privacy in the absence of non-test, non-demo use cases for allowing gUM on http: origins. Sure, I think there are some reasonable cases. Say that a site asks to take your picture for the purpose of displaying an avatar. So you give it temporary access, it takes the picture, and then it relinquishes access. Because there are UI indicators that show when the camera is being accessed, and I control what's in front of the camera, and the site is planning to publish the picture I don't really need to trust the site much. Oh. I had thought that that use case was outside the scope of gUM and in scope for http://www.w3.org/TR/html-media-capture/ (possibly to be implemented on top of gUM + https://w3c.github.io/mediacapture-image/ by the Firefox OS browser chrome.) (Of course, avatars imply login and login *should* imply https...) Do you have a pointer to the WG's rationale for the rejection? I tried to search for it, but I failed to find either a decision or rationale. The closest I could find was https://www.w3.org/Bugs/Public/show_bug.cgi?id=22214#c3 , which treats https origins as special and says that stored permissions should only be available for them. It was less a rationale than a lack of people being convinced. I raised it once or twice and there were a lot of people strongly opposed, and since the default is that things work on HTTP, that's where it stayed. Do you recall when this happened and if Chrome representatives were against restricting gUM to authenticated origins? IIRC the main person speaking out against this was from MSFT, Hmm. IIRC, Microsoft wanted a non-TLS variant of HTTP/2. but I don't think people from Google were in favor either. I guess the Chrome folks aren't coordinated on this kind of thing, then. Don't look at me. My assessment is that this isn't superb, but it's not a hill worth dying on. Is gUM already in a hill worth dying on stage? With Presto out of the picture, the implementations are just Gecko and Blink, right? And both Gecko and Blink still have gUM vendor prefixed. (Which, if you believe how prefixing is supposed to work, which I don't believe but am willing to pretend in this case, should mean that we can still change stuff.) And at least now if not at the time of first shipping gUM, there's will among Chrome folks to restrict stuff to authenticated origins. I'm not sure I understand the question. There certainly is fairly wide gUM usage. I mean: Does gUM have high non-demo, non-test usage on http origins? For instance, Hangouts is now WebRTC in Chrome and will be WebRTC in Firefox soonish, hopefully. As a Google service, Hangouts are going to be https, hopefully. That obviously doesn't mean things can't be changed, but I think you'd need WG consensus to do so, and I don't have the sense we're going to get that. Per the reply Anne got, http://lists.w3.org/Archives/Public/public-media-capture/2014Sep/0030.html , it looks like the WG is deferring the decision to implementors as a MAY, so it seems to be more an issue of Gecko+Blink consensus than WG consensus. I think Florian implemented it. Adam Roach deserves the credit for insisting we do it right. Thanks to both! seems that Chrome doesn't offer have persistent grants in either case. https://hsivonen.fi/gum-test/ http://hsivonen.com/test/moz/gum-test.html Chrome auto-decides whether the grant is persistent
Re: Restricting gUM to authenticated origins only
On Wed, Sep 10, 2014 at 2:09 AM, Henri Sivonen hsivo...@hsivonen.fi wrote: On Tue, Sep 9, 2014 at 8:13 PM, Eric Rescorla e...@rtfm.com wrote: Sure, I think there are some reasonable cases. Say that a site asks to take your picture for the purpose of displaying an avatar. So you give it temporary access, it takes the picture, and then it relinquishes access. Because there are UI indicators that show when the camera is being accessed, and I control what's in front of the camera, and the site is planning to publish the picture I don't really need to trust the site much. Oh. I had thought that that use case was outside the scope of gUM and in scope for http://www.w3.org/TR/html-media-capture/ (possibly to be implemented on top of gUM + https://w3c.github.io/mediacapture-image/ by the Firefox OS browser chrome.) My understanding is that html-media-capture is basically being abandoned in favor of gUM. (Of course, avatars imply login and login *should* imply https...) I don't disagree with this in principle, but I think we have to admit that a huge number of sites which do some form of persistent identity/login and don't use HTTPS. In any case, there are plenty of other legit applications such as photobooths, voice control APIs, etc. Don't look at me. My assessment is that this isn't superb, but it's not a hill worth dying on. Is gUM already in a hill worth dying on stage? With Presto out of the picture, the implementations are just Gecko and Blink, right? And both Gecko and Blink still have gUM vendor prefixed. (Which, if you believe how prefixing is supposed to work, which I don't believe but am willing to pretend in this case, should mean that we can still change stuff.) And at least now if not at the time of first shipping gUM, there's will among Chrome folks to restrict stuff to authenticated origins. I'm not sure I understand the question. There certainly is fairly wide gUM usage. I mean: Does gUM have high non-demo, non-test usage on http origins? I don't know. To some extent people are being driven to use HTTPS because they want persistent permissions. That obviously doesn't mean things can't be changed, but I think you'd need WG consensus to do so, and I don't have the sense we're going to get that. Per the reply Anne got, http://lists.w3.org/Archives/Public/public-media-capture/2014Sep/0030.html , it looks like the WG is deferring the decision to implementors as a MAY, so it seems to be more an issue of Gecko+Blink consensus than WG consensus. Sure. However, my sense is that the Chrome people aren't in favor of this change. seems that Chrome doesn't offer have persistent grants in either case. https://hsivonen.fi/gum-test/ http://hsivonen.com/test/moz/gum-test.html Chrome auto-decides whether the grant is persistent based on whether the URL is http or https. Whoa. That's non-obvious and creepy. As a user, I find it creepy for an UI that looks like a one-time grant to actually do a persistent grant. (Consider the non-http use case about taking a picture for a random site you gave above, that use case happening on an https origin and ending up leaving the origin with a persistent permission to turn the camera on later.) As a site operator, I find that this makes me appear creepier than I want to appear if I host (I currently don't but I want to eventually) SimpleWebRTC app on my site for ad hoc video conferencing without having to trust a third party to do the call setup in a way that doesn't involve extra parties and I don't want to ask the other party of the conversation to have to trust my site not to turn on the camera later after the conversation. I sympathise with this position, which is why Firefox doesn't do it this way. -Ekr ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On 9/10/14 2:09 AM, Henri Sivonen wrote: Chrome auto-decides whether the grant is persistent based on whether the URL is http or https. Whoa. That's non-obvious and creepy. As a user, I find it creepy for an UI that looks like a one-time grant to actually do a persistent grant. Indeed. I think it's fine for the protocol to influence if persistence _can_ be set (i.e., only allowing persistence on secure connections), but making it automatic is conflating permission (user choice) and security. It's particularly egregious on Google Maps... The maps.google.com site redirects to https://google.com/maps, which means using geolocation on Google Maps in Chrome will automatically allow geolocation for all of google.com. I wonder how many Maps users understand or expect that. Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On 2014-09-10, at 16:38, Justin Dolske dol...@mozilla.com wrote: It's particularly egregious on Google Maps... The maps.google.com site redirects tohttps://google.com/maps, which means using geolocation on Google Maps in Chrome will automatically allow geolocation for all of google.com. I wonder how many Maps users understand or expect that. That is devious. I suspect that there is a banal reason relating to the use of the Google Front End that motivates the change, but the side effect of having all Google properties have access to user permissions from all other properties is no doubt appealing to some product managers over there. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On Mon, Sep 8, 2014 at 6:06 PM, Eric Rescorla e...@rtfm.com wrote: On Sun, Sep 7, 2014 at 11:45 PM, Henri Sivonen hsivo...@hsivonen.fi wrote: On Fri, Sep 5, 2014 at 4:15 PM, Eric Rescorla e...@rtfm.com wrote: On Fri, Sep 5, 2014 at 3:34 AM, Henri Sivonen hsivo...@hsivonen.fi wrote: On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen hsivo...@hsivonen.fi wrote: Is current gUM restricted to authenticated origins? If it isn't, is it realistic to restrict it to authenticated origins? That's a good idea but it's a separate issue. Is it already being pursued or should I file a bug? It's not being pursued. It was considered in the WG and rejected. Do *you* think the WG's stance on this was and continues to be the right call for our users Eh.. Not sure. AFAIK, there's not much of a reason why arbitary sites shouldn't be able to access your camera and microphone, provided that you're not placing trust in the site to do anything in particular with your data. I can see that being a valid abstract argument. I wonder, though, if there are non-demo use cases where it's appropriate to ask the user to assume lack of trust. Considering that camera and microphone are particularly privacy-sensitive, I'm worried about not erring on the side of privacy in the absence of non-test, non-demo use cases for allowing gUM on http: origins. With that said, I wouldn't be upset if HTTPS was required here, and at one point I argued for that for PeerConnection on the grounds that the apparent security properties weren't the real ones. OK. Do you have a pointer to the WG's rationale for the rejection? I tried to search for it, but I failed to find either a decision or rationale. The closest I could find was https://www.w3.org/Bugs/Public/show_bug.cgi?id=22214#c3 , which treats https origins as special and says that stored permissions should only be available for them. It was less a rationale than a lack of people being convinced. I raised it once or twice and there were a lot of people strongly opposed, and since the default is that things work on HTTP, that's where it stayed. Do you recall when this happened and if Chrome representatives were against restricting gUM to authenticated origins? Except as a path dependency thing where you assume you never change things you've already shipped, Chrome's situation of restricting Web Crypto to authenticated origins but not restricting gUM to authenticated origins seems to be the wrong way around and, therefore, quite bizarre. On Mon, Sep 8, 2014 at 8:10 PM, Martin Thomson m...@mozilla.com wrote: On 08/09/14 10:08, Anne van Kesteren wrote: That's been the question people have asked, and I think that the answer was that we don't want to break test pages and that sort of thing unnecessarily. Whoa, that definitely seems like the wrong way to prioritize things. Tests or demos should not influence design choices. Don't look at me. My assessment is that this isn't superb, but it's not a hill worth dying on. Is gUM already in a hill worth dying on stage? With Presto out of the picture, the implementations are just Gecko and Blink, right? And both Gecko and Blink still have gUM vendor prefixed. (Which, if you believe how prefixing is supposed to work, which I don't believe but am willing to pretend in this case, should mean that we can still change stuff.) And at least now if not at the time of first shipping gUM, there's will among Chrome folks to restrict stuff to authenticated origins. Also, DV certs are cheap enough that demo sites should be able to afford one. You are welcome to disagree, of course: public-media-capt...@w3.org Hmm. The W3C list search (which sometimes fails) indicates that neither Ryan Sleevi nor Chris Palmer has ever posted to the list. I wonder if there's a disconnect between the Googlers arguing for restricting APIs to authenticated origins and the Googlers working on media capture. On Tue, Sep 9, 2014 at 3:10 AM, Daniel Veditz dved...@mozilla.com wrote: On 9/8/2014 2:16 AM, Mounir Lamouri wrote: On Sun, 7 Sep 2014, at 04:56, Martin Thomson wrote: It's more the case that a persistent positive grant from permission manager would be ignored for non-secure origins and non-secure origins would not show any option to persist. I don't know the specifics about the UI, but you don't want to have a prompt showing up every time a call to an API is being made. It would be terribly frustrating for users and developers. It wouldn't be every API call, it'd be the first API call. Would it help to have an option to remember for the session (rather than per-document)? We have no guarantee that the foo.com you connect to tomorrow is the same foo.com you trusted today, especially if you're connecting to a new network (e.g. coffee shop, airport, hotel). I should have tested this *before* starting this thread, of course,
Re: Restricting gUM to authenticated origins only
On Mon, Sep 8, 2014 at 7:10 PM, Martin Thomson m...@mozilla.com wrote: Don't look at me. My assessment is that this isn't superb, but it's not a hill worth dying on. You are welcome to disagree, of course: public-media-capt...@w3.org http://lists.w3.org/Archives/Public/public-media-capture/2014Sep/0013.html -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On Tue, Sep 9, 2014 at 1:26 PM, Mounir Lamouri mou...@lamouri.fr wrote: On Tue, 9 Sep 2014, at 10:10, Daniel Veditz wrote: On 9/8/2014 2:16 AM, Mounir Lamouri wrote: On Sun, 7 Sep 2014, at 04:56, Martin Thomson wrote: It's more the case that a persistent positive grant from permission manager would be ignored for non-secure origins and non-secure origins would not show any option to persist. I don't know the specifics about the UI, but you don't want to have a prompt showing up every time a call to an API is being made. It would be terribly frustrating for users and developers. It wouldn't be every API call, it'd be the first API call. Would it help to have an option to remember for the session (rather than per-document)? We have no guarantee that the foo.com you connect to tomorrow is the same foo.com you trusted today, especially if you're connecting to a new network (e.g. coffee shop, airport, hotel). That's why I suggested a combination of time-based permission and session-based. Why would complexity like that be preferable over the simplicity of requiring an authenticated origin? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On Fri, Sep 5, 2014 at 4:15 PM, Eric Rescorla e...@rtfm.com wrote: On Fri, Sep 5, 2014 at 3:34 AM, Henri Sivonen hsivo...@hsivonen.fi wrote: On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen hsivo...@hsivonen.fi wrote: Is current gUM restricted to authenticated origins? If it isn't, is it realistic to restrict it to authenticated origins? That's a good idea but it's a separate issue. Is it already being pursued or should I file a bug? It's not being pursued. It was considered in the WG and rejected. Do *you* think the WG's stance on this was and continues to be the right call for our users? Do you have a pointer to the WG's rationale for the rejection? I tried to search for it, but I failed to find either a decision or rationale. The closest I could find was https://www.w3.org/Bugs/Public/show_bug.cgi?id=22214#c3 , which treats https origins as special and says that stored permissions should only be available for them. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On Mon, Sep 8, 2014 at 12:16 PM, Mounir Lamouri mou...@lamouri.fr wrote: On Sun, 7 Sep 2014, at 04:56, Martin Thomson wrote: It's more the case that a persistent positive grant from permission manager would be ignored for non-secure origins and non-secure origins would not show any option to persist. I don't know the specifics about the UI, but you don't want to have a prompt showing up every time a call to an API is being made. It would be terribly frustrating for users and developers. Considering that the remedy would be migrating the app to an authenticated origin, how useful is it to have gUM available (without persistent permissions) for unauthenticated origins? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On 07/09/14 07:09, Jesper Kristensen wrote: Cookies are segregated by http vs https, right? No, unfortunately they are not. Numerous attempts at fixing it has been rejected by browser vendors. For example http://tools.ietf.org/html/draft-abarth-cake-01 They are, somewhat. All cookies are available to an https origin, but some are restricted so that http origins can't see them. https://tools.ietf.org/html/rfc6265#section-5.4 * If the cookie's secure-only-flag is true, then the request- uri's scheme must denote a secure protocol (as defined by the user agent). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On 08/09/14 04:05, Henri Sivonen wrote: Considering that the remedy would be migrating the app to an authenticated origin, how useful is it to have gUM available (without persistent permissions) for unauthenticated origins? That's been the question people have asked, and I think that the answer was that we don't want to break test pages and that sort of thing unnecessarily. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On Mon, Sep 8, 2014 at 7:00 PM, Martin Thomson m...@mozilla.com wrote: On 08/09/14 04:05, Henri Sivonen wrote: Considering that the remedy would be migrating the app to an authenticated origin, how useful is it to have gUM available (without persistent permissions) for unauthenticated origins? That's been the question people have asked, and I think that the answer was that we don't want to break test pages and that sort of thing unnecessarily. Whoa, that definitely seems like the wrong way to prioritize things. Tests or demos should not influence design choices. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On 08/09/14 10:08, Anne van Kesteren wrote: That's been the question people have asked, and I think that the answer was that we don't want to break test pages and that sort of thing unnecessarily. Whoa, that definitely seems like the wrong way to prioritize things. Tests or demos should not influence design choices. Don't look at me. My assessment is that this isn't superb, but it's not a hill worth dying on. You are welcome to disagree, of course: public-media-capt...@w3.org ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
Den 08-09-2014 kl. 18:58 skrev Martin Thomson: On 07/09/14 07:09, Jesper Kristensen wrote: Cookies are segregated by http vs https, right? No, unfortunately they are not. Numerous attempts at fixing it has been rejected by browser vendors. For example http://tools.ietf.org/html/draft-abarth-cake-01 They are, somewhat. All cookies are available to an https origin, but some are restricted so that http origins can't see them. https://tools.ietf.org/html/rfc6265#section-5.4 * If the cookie's secure-only-flag is true, then the request- uri's scheme must denote a secure protocol (as defined by the user agent). Yes, the abstract in the linked spec draft clearly states this: You can establish cookie confidentiality using the Secure flag, but it is not possible today to establish cookie integrity. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On 9/8/2014 2:16 AM, Mounir Lamouri wrote: On Sun, 7 Sep 2014, at 04:56, Martin Thomson wrote: It's more the case that a persistent positive grant from permission manager would be ignored for non-secure origins and non-secure origins would not show any option to persist. I don't know the specifics about the UI, but you don't want to have a prompt showing up every time a call to an API is being made. It would be terribly frustrating for users and developers. It wouldn't be every API call, it'd be the first API call. Would it help to have an option to remember for the session (rather than per-document)? We have no guarantee that the foo.com you connect to tomorrow is the same foo.com you trusted today, especially if you're connecting to a new network (e.g. coffee shop, airport, hotel). -Dan Veditz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On 08/09/14 17:10, Daniel Veditz wrote: It wouldn't be every API call, it'd be the first API call. Would it help to have an option to remember for the session (rather than per-document)? We have no guarantee that the foo.com you connect to tomorrow is the same foo.com you trusted today, especially if you're connecting to a new network (e.g. coffee shop, airport, hotel). We do have a little leeway with how long a non-persistent grant lives, but I'm not sure that there are many cases where you wouldn't want to ask again. For something like gUM, it's generally only the case that you want one anyway. So persisting grant until navigate doesn't help much, and there are definitely cases where it's harmful. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On Sat, 6 Sep 2014, at 14:49, Martin Thomson wrote: One idea that has been floated (https://bugzilla.mozilla.org/show_bug.cgi?id=1002676) is to restrict persistent permissions to secure origins. The reasoning there being that a persistent grant can be trivially intercepted if you work in the clear. That's a real security concern. One that gUM requires. That sounds interesting. I guess in this case you would want to mark the permission as session-specific with an expire time of a few hours? If there is a way to know whether a nsIPrincipal is associated with an authenticated origin, it should be fairly simple to implement inside nsPermissionManager. Though, it might require some UI, wouldn't it? -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
It's more the case that a persistent positive grant from permission manager would be ignored for non-secure origins and non-secure origins would not show any option to persist. - Original Message - From: Mounir Lamouri mou...@lamouri.fr To: Martin Thomson m...@mozilla.com, Ehsan Akhgari ehsan.akhg...@gmail.com Cc: Chris Peterson cpeter...@mozilla.com, dev-platform@lists.mozilla.org Sent: Saturday, September 6, 2014 6:28:05 AM Subject: Re: Restricting gUM to authenticated origins only On Sat, 6 Sep 2014, at 14:49, Martin Thomson wrote: One idea that has been floated (https://bugzilla.mozilla.org/show_bug.cgi?id=1002676) is to restrict persistent permissions to secure origins. The reasoning there being that a persistent grant can be trivially intercepted if you work in the clear. That's a real security concern. One that gUM requires. That sounds interesting. I guess in this case you would want to mark the permission as session-specific with an expire time of a few hours? If there is a way to know whether a nsIPrincipal is associated with an authenticated origin, it should be fairly simple to implement inside nsPermissionManager. Though, it might require some UI, wouldn't it? -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only (was: Re: Intent to implement and ship: ImageCapture)
On Fri, Sep 5, 2014 at 10:34 PM, Henri Sivonen hsivo...@hsivonen.fi wrote: On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen hsivo...@hsivonen.fi wrote: Is current gUM restricted to authenticated origins? If it isn't, is it realistic to restrict it to authenticated origins? That's a good idea but it's a separate issue. Is it already being pursued or should I file a bug? I don't know. How about other site-specific sticky state? about:permissions suggests the full list is * Passwords * Geolocation * gUM * Cookies * Popup windows * Offline storage * Fullscreen Cookies are segregated by http vs https, right? I hope other kinds of offline storage, and passwords, are as well. Popup windows are just a nuisance so not important here. That leaves gUM, geolocation and fullscreen. Can we make them all require TLS? Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only (was: Re: Intent to implement and ship: ImageCapture)
On Fri, Sep 5, 2014 at 3:34 AM, Henri Sivonen hsivo...@hsivonen.fi wrote: On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen hsivo...@hsivonen.fi wrote: Is current gUM restricted to authenticated origins? If it isn't, is it realistic to restrict it to authenticated origins? That's a good idea but it's a separate issue. Is it already being pursued or should I file a bug? It's not being pursued. It was considered in the WG and rejected. -Ekr ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On 9/5/14 4:39 AM, Henri Sivonen wrote: * Geolocation In principle, I think geolocation should be restricted to authenticated origins. Unfortunately, it might be too late compatibility-wise to do that at this point. Also, since the geolocation responses are easily proxied over postMessage, I think the potential for wind is less than with gUM, whose response is a special kind of object that doesn't travel (I hope!) over postMessage. Google Maps and Yahoo Maps use HTTPS, but MapQuest and Bing Maps use HTTP. Before we could restrict geolocation to authenticated origins, we would need to convince Microsoft and MapQuest to use HTTPS (or whitelist their sites). chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On 2014-09-05, 4:37 PM, Chris Peterson wrote: On 9/5/14 4:39 AM, Henri Sivonen wrote: * Geolocation In principle, I think geolocation should be restricted to authenticated origins. Unfortunately, it might be too late compatibility-wise to do that at this point. Also, since the geolocation responses are easily proxied over postMessage, I think the potential for wind is less than with gUM, whose response is a special kind of object that doesn't travel (I hope!) over postMessage. Google Maps and Yahoo Maps use HTTPS, but MapQuest and Bing Maps use HTTP. Before we could restrict geolocation to authenticated origins, we would need to convince Microsoft and MapQuest to use HTTPS (or whitelist their sites). Those are not the only websites using the API. There are many more. I think we have probably lost our chance to make any changes here. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On 9/5/14 2:38 PM, Ehsan Akhgari wrote: Google Maps and Yahoo Maps use HTTPS, but MapQuest and Bing Maps use HTTP. Before we could restrict geolocation to authenticated origins, we would need to convince Microsoft and MapQuest to use HTTPS (or whitelist their sites). Those are not the only websites using the API. There are many more. I think we have probably lost our chance to make any changes here. Yes. Sorry, I didn't make myself clear. I meant that, if major map websites like Bing and MapQuest are using geolocation without HTTPS, then the longtail of HTTP sites is probably too long to ever fix. :\ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
On 2014-09-05, 5:46 PM, Chris Peterson wrote: On 9/5/14 2:38 PM, Ehsan Akhgari wrote: Google Maps and Yahoo Maps use HTTPS, but MapQuest and Bing Maps use HTTP. Before we could restrict geolocation to authenticated origins, we would need to convince Microsoft and MapQuest to use HTTPS (or whitelist their sites). Those are not the only websites using the API. There are many more. I think we have probably lost our chance to make any changes here. Yes. Sorry, I didn't make myself clear. I meant that, if major map websites like Bing and MapQuest are using geolocation without HTTPS, then the longtail of HTTP sites is probably too long to ever fix. :\ Yep, unfortunately, agreed! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Restricting gUM to authenticated origins only
One idea that has been floated (https://bugzilla.mozilla.org/show_bug.cgi?id=1002676) is to restrict persistent permissions to secure origins. The reasoning there being that a persistent grant can be trivially intercepted if you work in the clear. That's a real security concern. One that gUM requires. We might like to consider extending that to geolocation too. But it's not clear that the security benefits are outweighed by the inconvenience. The real solution is for those sites to get their act together, but that's a tall order. I agree with Henri and others who have said that we shouldn't be following Google's example regarding restricting feature access to secure origins though. - Original Message - From: Ehsan Akhgari ehsan.akhg...@gmail.com To: Chris Peterson cpeter...@mozilla.com, dev-platform@lists.mozilla.org Sent: Friday, September 5, 2014 2:53:21 PM Subject: Re: Restricting gUM to authenticated origins only On 2014-09-05, 5:46 PM, Chris Peterson wrote: On 9/5/14 2:38 PM, Ehsan Akhgari wrote: Google Maps and Yahoo Maps use HTTPS, but MapQuest and Bing Maps use HTTP. Before we could restrict geolocation to authenticated origins, we would need to convince Microsoft and MapQuest to use HTTPS (or whitelist their sites). Those are not the only websites using the API. There are many more. I think we have probably lost our chance to make any changes here. Yes. Sorry, I didn't make myself clear. I meant that, if major map websites like Bing and MapQuest are using geolocation without HTTPS, then the longtail of HTTP sites is probably too long to ever fix. :\ Yep, unfortunately, agreed! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
