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 th

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 resp

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 web

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 white

Re: Restricting gUM to authenticated origins only

have said that we shouldn't be following Google's example regarding restricting feature access to secure origins though. - Original Message - From: "Ehsan Akhgari" To: "Chris Peterson" , dev-platform@lists.mozilla.org Sent: Friday, September 5, 20

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 t

Re: Restricting gUM to authenticated origins only

Akhgari" Cc: "Chris Peterson" , 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.

Re: Restricting gUM to authenticated origins only

Den 05-09-2014 kl. 12:47 skrev Robert O'Callahan: 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

Re: Restricting gUM to authenticated origins only

On Fri, Sep 5, 2014 at 4:15 PM, Eric Rescorla wrote: > > > > On Fri, Sep 5, 2014 at 3:34 AM, Henri Sivonen wrote: >> >> On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan >> wrote: >> > On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen >> > wrote: >> >> Is current gUM restricted to authenticated or

Re: Restricting gUM to authenticated origins only

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

Re: Restricting gUM to authenticated origins only

On Mon, Sep 8, 2014 at 12:16 PM, 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. > >

Re: Restricting gUM to authenticated origins only

On Sun, Sep 7, 2014 at 11:45 PM, Henri Sivonen wrote: > On Fri, Sep 5, 2014 at 4:15 PM, Eric Rescorla wrote: > > > > > > > > On Fri, Sep 5, 2014 at 3:34 AM, Henri Sivonen > wrote: > >> > >> On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan > > >> wrote: > >> > On Fri, Sep 5, 2014 at 10:19 PM,

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 ava

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

Re: Restricting gUM to authenticated origins only

On Mon, Sep 8, 2014 at 7:00 PM, Martin Thomson 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'

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 in

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-ca

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 kno

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, especiall

Re: Restricting gUM to authenticated origins only

On Mon, Sep 8, 2014 at 6:06 PM, Eric Rescorla wrote: > On Sun, Sep 7, 2014 at 11:45 PM, Henri Sivonen wrote: >> On Fri, Sep 5, 2014 at 4:15 PM, Eric Rescorla wrote: >> > On Fri, Sep 5, 2014 at 3:34 AM, Henri Sivonen >> > wrote: >> >> On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan >> >> >> >

Re: Restricting gUM to authenticated origins only

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 origin

Re: Restricting gUM to authenticated origins only

On Mon, Sep 8, 2014 at 7:10 PM, Martin Thomson 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.ht

Re: Restricting gUM to authenticated origins only

On Tue, Sep 9, 2014 at 1:26 PM, Mounir Lamouri 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

Re: Restricting gUM to authenticated origins only

On Tue, Sep 9, 2014 at 1:32 AM, Henri Sivonen wrote: > On Mon, Sep 8, 2014 at 6:06 PM, Eric Rescorla wrote: > > On Sun, Sep 7, 2014 at 11:45 PM, Henri Sivonen > wrote: > >> On Fri, Sep 5, 2014 at 4:15 PM, Eric Rescorla wrote: > >> > On Fri, Sep 5, 2014 at 3:34 AM, Henri Sivonen > >> > wrote:

Re: Restricting gUM to authenticated origins only

On Tue, Sep 9, 2014 at 8:13 PM, Eric Rescorla wrote: > On Tue, Sep 9, 2014 at 1:32 AM, Henri Sivonen wrote: >> On Mon, Sep 8, 2014 at 6:06 PM, Eric Rescorla wrote: >> > On Sun, Sep 7, 2014 at 11:45 PM, Henri Sivonen >> > wrote: >> >> On Fri, Sep 5, 2014 at 4:15 PM, Eric Rescorla wrote: >> >> >

Re: Restricting gUM to authenticated origins only

On Wed, Sep 10, 2014 at 2:09 AM, Henri Sivonen wrote: > On Tue, Sep 9, 2014 at 8:13 PM, Eric Rescorla 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

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 thi

Re: Restricting gUM to authenticated origins only

On 2014-09-10, at 16:38, Justin Dolske 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 man

Re: Restricting gUM to authenticated origins only

On Thu, Sep 11, 2014 at 1:50 AM, Martin Thomson 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 > prope

Re: Restricting gUM to authenticated origins only

On 2014-09-11, at 00:56, Anne van Kesteren wrote: > Are we actually partitioning permissions per top-level browsing > context or could they already accomplish this through an ? As far as I understand it, permissions are based on domain name only, they don’t include scheme or port from the origi

Re: Restricting gUM to authenticated origins only

On Thu, Sep 11, 2014 at 6:58 PM, Martin Thomson wrote: > On 2014-09-11, at 00:56, Anne van Kesteren wrote: >> Are we actually partitioning permissions per top-level browsing >> context or could they already accomplish this through an ? > > As far as I understand it, permissions are based on domai

Re: Restricting gUM to authenticated origins only

On 2014-09-11, at 10:04, Anne van Kesteren 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 b

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 wrote: >> On 2014-09-11, at 00:56, Anne van Kesteren wrote: >>> Are we actually partitioning permissions per top-level browsing >>> context or could they already accomplish this through an ? >> >> As f

Re: Restricting gUM to authenticated origins only

On Fri, Sep 12, 2014 at 12:39 PM, Frederik Braun wrote: > On 11.09.2014 19:04, Anne van Kesteren wrote: >> On Thu, Sep 11, 2014 at 6:58 PM, Martin Thomson wrote: >>> On 2014-09-11, at 00:56, Anne van Kesteren wrote: Are we actually partitioning permissions per top-level browsing contex

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 wrote: >> On 11.09.2014 19:04, Anne van Kesteren wrote: >>> On Thu, Sep 11, 2014 at 6:58 PM, Martin Thomson wrote: On 2014-09-11, at 00:56, Anne van Kesteren wrote: > Are we actually partitionin

Restricting gUM to authenticated origins only (was: Re: Intent to implement and ship: ImageCapture)

On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan wrote: > On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen 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

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 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 > . > > But the general solution might be a permissi

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 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 >>

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 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 . B

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 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

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 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/

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 embedd

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 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 t

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 wrote: > On Sat, Sep 13, 2014 at 12:07 AM, Martin Thomson 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

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 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: >

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 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 p

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 wrote: > On 2014-09-14, 3:54 AM, Anne van Kesteren wrote: >> >> On Sat, Sep 13, 2014 at 5:42 PM, Eric Rescorla wrote: >>> >>> I just tested this and it appears that at least for gUM, IFRAMEs do *not* >>> get persistent permissions even if they would

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 wrote: On 2014-09-14, 3:54 AM, Anne van Kesteren wrote: On Sat, Sep 13, 2014 at 5:42 PM, Eric Rescorla wrote: I just tested this and it appears that at least for gUM, IFRAMEs do *not* get persisten

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 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 stor

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 wrote: > On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan > wrote: > > On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen > wrote: > >> Is current gUM restricted to authenticated origins? If it isn't, is it > >> realistic to restrict it to authenticat

Re: Restricting gUM to authenticated origins only (was: Re: Intent to implement and ship: ImageCapture)

On Fri, Sep 5, 2014 at 1:47 PM, Robert O'Callahan wrote: > On Fri, Sep 5, 2014 at 10:34 PM, Henri Sivonen wrote: >> >> On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan >> wrote: >> > On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen >> > wrote: >> >> Is current gUM restricted to authenticated ori

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 wrote: > On Fri, Sep 5, 2014 at 1:25 PM, Robert O'Callahan > wrote: > > On Fri, Sep 5, 2014 at 10:19 PM, Henri Sivonen > wrote: > >> Is current gUM restricted to authenticated origins? If it isn't, is it > >> realistic to restrict it to authenticate