Re: WebRTC in {Web,Shared,Service} Workers

Agreed on navigator.mediaDevices.
Stream handling might not be top priority but future APIs might allow generating/processing such data.
OffscreenCanvas+CaptureCanvas comes to mind for instance.

As of UI interaction requirements for DataChannel, this might be related to private IP address filtering.
I kind of agree that if one service worker client has access to private IP addresses, its worker or related service workers could have access as well.
Revocation of this privilege is important though as we would like to keep the ‘reload the page to clear priviledges’ principle.
In that same field, there is https://bugs.webkit.org/show_bug.cgi?id=174500 <https://bugs.webkit.org/show_bug.cgi?id=174500>.

> On Apr 9, 2018, at 9:16 PM, Martin Thomson <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
> 
> FWIW, the concerns about IDP aren't real, as far as I can see.  You
> might need a frame to complete the flow, but those can be created from
> workers.
> 
> On Tue, Apr 10, 2018 at 1:25 PM, Isaac Kwan <i@isaac.pw <mailto:i@isaac.pw>> wrote:
>> As a web developer (so take what I said with a grain of salt), it
>> seems to me that the easier way to implement this is to allow
>> creations of a restricted subset of PeerConnections in workers.
>> 
>> In particular,
>> - Said PeerConnections are only started and available to the worker
>> - IdP-related functions (which are not implemented in Chrome anyway)
>> are not available
>> - addStream() can optionally be available, but navigator.mediaDevices
>> would not be exposed to workers
>> 
>> I am not aware of any UI interaction requirements for
>> DataChannel/PeerConnection for now... but in case there are any, they
>> can be share the same permission set as their origin.
>> In particular: if a permission is granted to web pages of the same
>> origin, grant it automatically to its workers too; otherwise, reject
>> the request gracefully. (Smart developers would then request relevant
>> permissions before having the worker to do anything sensitive.)
>> 
>> The advantages are:
>> - No need to handle atomic transfer of DC/PC ownership, cross-scope
>> bookkeeping (upstream PC closes -> DC in workers get terminated) etc.
>> - Greater flexibility - If downstream applications requires
>> transferring a PeerConnection / DataChannel to a worker (e.g. IdP
>> constraints), downstream application can do their own signaling
>> 
>> On 10 April 2018 at 05:57, Martin Thomson <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
>>> On Tue, Apr 10, 2018 at 4:16 AM, westhawk <thp@westhawk.co.uk <mailto:thp@westhawk.co.uk>> wrote:
>>>> On 9 Apr 2018, at 19:04, youenn fablet <yfablet@apple.com <mailto:yfablet@apple.com>> wrote:
>>>> 
>>>> I would favor enabling instantiations of PeerConnection in workers.
>>>> It seems particularly useful in ServiceWorker contexts where the link with a
>>>> particular Document may be broken at any point.
>>>> If we have that, there might be little incentive in transferring data
>>>> channels.
>>>> 
>>>> 
>>>> That would be nice, but there are a bunch of user interaction requirements
>>>> that may make that tricky,
>>>> - Getting local IP addresses requires a user to grant media permissions.
>>>> - Authenticating an ID requires a user interface
>>>> - starting a media stream requires a user click
>>>> 
>>>> That’s just off the top of my head. I suspect more would be found if one
>>>> looked hard.
>>>> 
>>>> I have the feeling that transferring a connected DataChannel over a
>>>> postMessage may be
>>>> more of a quick win.
>>> 
>>> For me, the lifecycle of a ServiceWorker is the biggest hurdle.
>>> 
>> 
>