Re: Comments/Questions on Media Capture Streams – Privacy and Security Considerations

On Oct 23, 2015, at 4:18 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 23 October 2015 at 16:02, Nick Doty <npdoty@w3.org> wrote:
>> We have discussed in other groups, for example at Geolocation last TPAC,
>> other "opt-in" style permissions. As part of the basic principle of data
>> minimization, we consider it good API design for site developers to be able
>> to specify the minimum data that they need, not just to make the request
>> more palatable to the end user, but also to limit their own risk. I think
>> persisted permission is a special case of this in the security space, and
>> something we've become more aware of with evidence of pervasive monitoring.
> 
> This isn't entirely about minimization.  I know that we've discussed
> this before and the view here at least was that persisting permissions
> is useful in reducing user training.  That being the phenomenon where
> users get so accustomed to seeing a dialog that muscle memory takes
> over whenever they see it.
> 
> We need to be sensitive to the potential for this sort of training as
> it can significantly reduce the level of assurance we get that the
> consent is real.  And it's already the case that consent is marginal
> as it is.
> 
> This is - I think - the principle that drives the Chrome policy of
> persisting these sorts of choices.  Firefox offers users a choice, and
> defaults to non-persistent permissions for gUM.  Defaults are very
> important here.

This is a good point, thanks. I didn't mean my suggestion to be taken as cheerleading for more frequent permission prompts.

My concern is the level of risk that a site takes on by ever making this permission prompt if it might commonly be persisted. The current advice in the specification is for site developers that use the API not to have security vulnerabilities anywhere on their sites. That doesn't seem like advice that can or will be followed.

> I think that both are valid choices, but if you were to suggest that a
> site could override UX choices for browsers, even toward an arguably
> "safer" posture you might get some resistance on those grounds.  More
> so when you consider that even if users are not trained, they can
> still be trained to the default, so changing defaults can be
> surprising in other ways.
> 
> Finally, I would like to point out that browser vendors are quite
> covetous of their small areas of differentiation.  How we talk to
> users is one of the few ways in which we can distinguish ourselves
> from the competition.

Yeah, totally. Does an opt-out or a non-binding hint parameter decrease this concern for the browser vendor? What if I need gUM just once to take a picture for the user's profile image and I called getUserMedia(oneTimeOnly=true)? Browsers could decide for themselves whether they wanted to still provide persistence by default or as an option (they could do so if it was called more than once by a site, for example), but they could take into account an indicator from the site. Site developers couldn't *rely* on all browsers refusing to persist permissions (the same way that I don't want my browser to be forced not to remember a login password) but maybe the developer can decrease the risk of this otherwise small use of the API.

On Oct 23, 2015, at 4:29 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> In fact the RTCWEB Security Architecture documents used to require that
> the site opt-in to persistent permissions and there was strong consensus
> to remove that requirement precisely because browsers weren't interested
> in implementing it.

Good to know. I'm glad it was discussed and I'll try to read up on that discussion, particularly if someone can provide a link.

Thanks,
Nick