RE: Request for feedback: Media Capture and Streams Last Call

> -----Original Message-----
> From: Jan-Ivar Bruaroey [mailto:jib@mozilla.com]
> Sent: Tuesday, July 07, 2015 3:33 PM
> To: Mathieu Hofman; Harald Alvestrand; public-media-capture@w3.org
> Subject: Re: Request for feedback: Media Capture and Streams Last Call
> 
> On 7/7/15 3:15 PM, Mathieu Hofman wrote:
> > I like the idea of only persisting deviceIds after a site was granted
> permissions to use the track but I'm a little confused about the implication of
> the "ask" permission.
> >
> > Consider the following flow:
> > enumerateDevices() => { device: id = 12345 type = videoinput }
> > getUserMedia({video: { deviceId: { exact: 12345 } }, user allows but
> > doesn't want choice remembered => success, app stores deviceId to
> > localStorage
> 
> By "doesn't want choice remembered" I assume you mean the user didn't
> opt for persisting permission? That's fine. We'd persist deviceId on gUM
> success OR persistent permission, not AND. It just takes one or the other.
> The id will be persisted here (if it wasn't already).

Ok, I hadn't realized it was an OR. Makes sense.

> 
> > Browser gets closed, in a new session, user visits site again, deviceId is
> saved in localStorage:
> > getUserMedia({video: { deviceId: { exact: 12345 } } => ?
> 
> User gets asked again for the same camera (aka 12345), just like before.
> 
> > enumerateDevices() => { device: id = ????? type = videoinput }
> >
> > What is the behavior here?
> 
> It'll be { device: id = 12345 type = videoinput }. Persisted.
> 
> 
> > To make sure the app can function properly, we need to persist deviceId if
> the site was ever granted permissions in the past, even if the user chose not
> to remember their choice. This seems detached from the current
> permissions possibilities of "ask / always / never", and wouldn't be surfaced
> in the UI. The user might not have a way to reset this either.
> >
> > Or did I miss something?
> 
> This should fall out naturally from the fact that once a deviceId is persisted,
> the only action that clears it is the clearing of cookies (unless we do
> something special for "Always Deny").
> 
> Hope that matches your thinking,

If clearing persistence is tied to clearing cookie, I think all should work fine.

Just to sum up the logic:

enumerateDevices()
If deviceId stored (persistent or in-session), reuse
If deviceId not stored, generate new one.
  If permanent permissions were already granted, store deviceId in a sort of "hidden" persistent cookie.
  If permanent permissions are not granted, store deviceId in "hidden" session cookie

gUM()
If deviceId stored (persistent or in-session), reuse
If deviceId not stored, generate new one, store in session cookie
 If user grants permission (temporary or permanent), store deviceId in "hidden" persistent cookie.

Clear cookies: Remove session & persistent deviceId.

I think we should not remove stored deviceId if user changes persistent permission type, as that introduce a weird dependency.
It can also create a confusing case for the site:
enumerateDevices() => { device: id = 12345 type = videoinput }
getUserMedia({video: { deviceId: { exact: 12345 } }, user allows and persist permission ("always") => success, app stores deviceId to localStorage
User revokes persistent permissions, which would remove stored deviceId
User visits site again, which has deviceId still saved in localStorage:
getUserMedia({video: { deviceId: { exact: 12345 } } => no we have a problem since device 12345 no longer exists.

So to revisit your questions:
> Q: I change site X's persistent permission from "Always Allow" back to 
> the default ("Always ask").
> A: deviceId persists.
> 
> Q: I change site X's persistent permission from "Always Allow" to 
> "Always Deny".
> A: Should we clear deviceId in this case, or is it unrelated at this point?
A: It's unrelated. deviceId persists. The site might have stored it (or other "unique" info) in cookie/localStorage.

Mathieu

> 
> .: Jan-Ivar :.

Received on Tuesday, 7 July 2015 23:13:08 UTC