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. >> 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, but I don't think people from Google were in favor either. > > 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. For instance, Hangouts is now WebRTC in Chrome and will be WebRTC in Firefox soonish, 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. > 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, > but I tested now: We already distinguish between http: and https: so > that our UI don't allow persistent permission grants to http: but > allows them for https: in the gUM case. (Kudos to whoever implemented > this and didn't leave this as a dead letter of WG deliberations!) I think Florian implemented it. Adam Roach deserves the credit for insisting we do it right. > 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. -Ekr -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
