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

On Fri, 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.
>
> 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


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.

-Ekr

>
>