1189097 - Make it possible to determine if a track was allowed via user-mediated permission

Status: RESOLVED WONTFIX

(Core :: WebRTC, defect, P2)

Description

[Randell Jesup [:jesup] (needinfo me)]

This is service to bug 1189060, to make it possible to scan the tracks attached to a PeerConnection at createOffer/Answer time and determine if any of them were explicityly allowed by the user (gUM prompt, or saved permissions for the site).  It's not 100% clear yet if we need to distinguish between the two ways permissions could be granted.

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Are the tracks relevant? Isn't the question simply whether this page (or page's origin) has been granted gUM permission, and if it has, then it implicitly also has peerConnection permission?

Is there a case where the user has granted gUM permission but still expects non-gUM tracks to be blocked?

Comment 2

[Nils Ohlmeier [:drno]]

(In reply to Jan-Ivar Bruaroey [:jib] from comment #1)
> Is there a case where the user has granted gUM permission but still expects
> non-gUM tracks to be blocked?

A web page which asks for gUM permission to take a picture of the user to add to his profile, but the webpage/service not offering any P2P communication services?!

Comment 3

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Where's the non-gUM track in that case?

Comment 4

[Nils Ohlmeier [:drno]]

The page calls gUM for getting the users picture, but never attaches that track to any PC. But then creates a PC with a data channel (without ever connecting the gUM track to the PC).
If that web page is not offering PC based communication services I would be surprised to learn that it is using PC's in the background.
I think we need to iterate through the tracks of the PC to find out if any of the tracks got permissions.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

The purpose of this bug is to enable the hooks in bug 1189060 to iterate the tracks and determine if they were approved by the user.  The possible downside would be a "snap your picture" page that sets up a PeerConnection using the getUserMedia-creadte stream.  Truly paranoid can make it ask always.  And this would stop almost all NYTimes-style drive-by issues.

Comment 6

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Since the two main concerns are IP leakage and dialog fatigue, it seems irrelevant to me what the tracks contain.

I see three useful states from the above for a createOffer add-on:

  State                               Sample Action
  ------------------------------------------------------
  No IP leaked yet; No gUM granted    Warn user
  No IP leaked yet; gUM granted       Avoid extra dialog
  IP already leaked                   Too late to warn

Anything finer seems like feature-creep to me.

If others agree, then I don't think we need this bug, because the add-on can use enumerateDevices to learn whether gUM has been granted (== non-empty labels).

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

(In reply to Jan-Ivar Bruaroey [:jib] from comment #6)
> Since the two main concerns are IP leakage and dialog fatigue, it seems
> irrelevant to me what the tracks contain.
> 
> I see three useful states from the above for a createOffer add-on:
> 
>   State                               Sample Action
>   ------------------------------------------------------
>   No IP leaked yet; No gUM granted    Warn user
>   No IP leaked yet; gUM granted       Avoid extra dialog
>   IP already leaked                   Too late to warn
> 
> Anything finer seems like feature-creep to me.
> 
> If others agree, then I don't think we need this bug, because the add-on can
> use enumerateDevices to learn whether gUM has been granted (== non-empty
> labels).

So if we're quite sure that carries over correctly (if you release all getUserMedia streams, and then enumerateDevices, do you get labels?  And if so, is that correct?  And if so, is that the correct action for this use?), then you may be correct.  If so, that'd be cool; we'd just need to ensure the extension can hook createOffer/Answer (and perhaps that's also already there inherently, even better if so).

One other question/issue: how much overhead is enumerateDevices; how long does it take?  Async is ok as createOffer/Answer are async too.  And I don't care that much about efficiency for this sort of hack.

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

Also: just need to verify if an extension 'hooks' createOffer/Answer they still see the right behavior from enumerateDevices - i.e. they don't get 'chrome' privs

Comment 9

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

We could also add a boolean for this. May be a lot simpler.

Comment 10

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

There's a fourth state:

  State                                    Sample Action
  --------------------------------------------------------------
  No IP leaked yet; gUM request pending.   Delay until gUM grant 

The fastest way to connect is to connect and ask for the camera in parallel: http://jsfiddle.net/xdxjvmgp

It would stink if we didn't cover this case. We could add a boolean for this, and either add a way for the add-on to learn when gUM is granted, or add a way for it to give an answer contingent on gUM being granted.

Comment 11

[Randell Jesup [:jesup] (needinfo me)]

The extension could hook both getUserMedia and createOffer/Answer; the logic to get that right would less-than-fun, but likely doable.  Advantage to using enumerateDevices is that we may not have to wait as long, if they're in 40.

Comment 12

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Randell Jesup [:jesup] from comment #7)
> (if you release all getUserMedia streams, and then enumerateDevices, do
> you get labels?

No.

> And if so, is that correct?

It doesn't make a lot of sense, since a site can just store the labels in a cookie, but it's to spec. We might want to mention that on the list, regardless of this issue.

> And if so, is that the correct action for this use?),

A boolean in this new API may be just as simple, or simpler.

Comment 13

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Randell Jesup [:jesup] from comment #8)
> Also: just need to verify if an extension 'hooks' createOffer/Answer they
> still see the right behavior from enumerateDevices - i.e. they don't get
> 'chrome' privs

Good point, they would always see labels. Oh well, next idea.

Comment 14

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

We've reduced the scope of functionality here, as outlined in comment 6, which removes the need for this feature.

We can't use enumerateDevices to check for gUM state as mentioned in comment 13, rather an add-on would have to intercept both gUM requests and createOffer requests and keep track of state and correlate inner windows itself to avoid double-dinging the user with dialogs.