Closed Bug 1189097 Opened 5 years ago Closed 5 years ago

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

Categories

(Core :: WebRTC, defect, P2)

defect

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox42 --- affected
Blocking Flags:

People

(Reporter: jesup, Unassigned)

References

(Blocks 1 open bug)

Details

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.
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?
backlog: --- → webRTC+
Rank: 23
Priority: -- → P2
Blocks: 1189167
(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?!
Where's the non-gUM track in that case?
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.
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.
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).
(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.
Flags: needinfo?(jib)
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
We could also add a boolean for this. May be a lot simpler.
Flags: needinfo?(jib)
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.
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.
(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.
(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.
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.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.