Right, I can see the threat model being similar, but technically we're marrying two separate things under the same UI and more importantly the same permission name. This will instantly cause trouble once one of the two features changes its requirements or behavior in a way that's incompatible with the other, which I think is not unimaginable here.
Hence my recommendation to avoid using the same permission name right now and using a separate UI as soon as that can be prioritized. On Wed, Oct 16, 2019, 19:43 Daniel Veditz <dved...@mozilla.com> wrote: > On Wed, Oct 16, 2019 at 4:40 AM Johann Hofmann <jhofm...@mozilla.com> > wrote: > >> as far as I can see the presented origin does not in fact get access to >> the user's microphone > > > The site doesn't get raw audio, but does get text representing what the > browser thinks it heard. It's the same kind of privacy risk as raw audio > for most people (though less opportunity for creative abuses like trying to > track what TV show you're watching). > > -Dan Veditz > > > > >> and it's a bit >> unclear what "Remember this decision" actually does. It makes no sense to >> set the "microphone" permission on that site, in the same way that it >> makes >> no sense to derive from a permanent "microphone" permission for some site >> that the user intends to submit their voice data to a third party. I feel >> like this feature needs to store a separate permanent permission. >> >> A perfect permissions UX may not be achievable or intended for an MVP of >> this feature, so I would recommend at least hiding the checkbox (to avoid >> setting the "microphone" permission) and prompting every time until a >> better solution can be found. >> >> Let me know if you need any help with that :) >> >> Johann >> >> On Tue, Oct 15, 2019 at 12:27 PM Henri Sivonen <hsivo...@mozilla.com> >> wrote: >> >> > On Tue, Oct 15, 2019 at 2:56 AM Andre Natal <ana...@mozilla.com> wrote: >> > > Regarding the UI, yes, the experience will be exactly the same in our >> > case: the user will get a prompt asking for permission to open the >> > microphone (I've attached a screenshot below ) >> > ... >> > >  >> > >> https://www.dropbox.com/s/fkyymiyryjjbix5/Screenshot%202019-10-14%2016.13.49.png?dl=0 >> > >> > Since the UI is the same as for getUserMedia(), is the permission bit >> > that gets stored the same as for getUserMedia()? I.e. if a site >> > obtains the permission for one, can it also use the other without >> > another prompt? >> > >> > If a user understands how WebRTC works and what this piece of UI meant >> > for WebRTC, this UI now represents a different trust decision on the >> > level of principle. How intentional or incidental is it that this >> > looks like a getUserMedia() use (audio goes to where the site named in >> > the dialog decides to route it) instead of surfacing to the user that >> > this is different (audio goes to where the browser vendor decides to >> > route it)? >> > >> > -- >> > Henri Sivonen >> > hsivo...@mozilla.com >> > _______________________________________________ >> > dev-platform mailing list >> > email@example.com >> > https://lists.mozilla.org/listinfo/dev-platform >> > >> _______________________________________________ >> dev-platform mailing list >> firstname.lastname@example.org >> https://lists.mozilla.org/listinfo/dev-platform >> > _______________________________________________ dev-platform mailing list email@example.com https://lists.mozilla.org/listinfo/dev-platform