W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2018

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 10 Apr 2018 14:16:57 +1000
Message-ID: <CABkgnnV_r4h7UghpBYN6bpFPOvuLpP5M3Htq9a6LdbGZsvmGyw@mail.gmail.com>
To: Isaac Kwan <i@isaac.pw>
Cc: public-webrtc@w3.org
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

On Tue, Apr 10, 2018 at 1:25 PM, Isaac Kwan <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> wrote:
>> On Tue, Apr 10, 2018 at 4:16 AM, westhawk <thp@westhawk.co.uk> wrote:
>>> On 9 Apr 2018, at 19:04, youenn fablet <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.
Received on Tuesday, 10 April 2018 04:17:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:39 UTC