Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

Setting up cross-network communication backs us into the "URI that can 
be used to connect webrtc" topic.

We had strong warnings against minting those tokens in the security docs 
for general A/V media session usage; it seems to make much more sense 
(or rather: forbidding it seems to make much less sense) when we're 
dealing with process-to-process comms in a distributed application.

But I think it is a different application space than where 
Capture-Handle is trying to go.


On 6/16/21 12:30 PM, T H Panton wrote:
> Ha, I see the problem now, I’ve got comfortable in a flat-unique 
> token-namespace and forgotten how ugly the outside world is!
>
> I’m afraid this tells me that the idea of just having a token doesn’t 
> work - we need to define a namespace to assign meaning to it.
> I have a couple of possibles in mind. The simplest being MDNS - you 
> look up the token in MDNS and retrieve an SRV which tells you how to 
> connect.
>
> Adding an origin only helps if you have a very specific solution in 
> mind. i.e. server mediated remote control of a well known web app from 
> the same vendor that happens to be on different origins.
> Which does not allow you to control a local native app (e.g. keynote) 
> which seems to me very necessary. It also doesn’t allow a native 
> capture app to control a web page (e.g. slideshare), which is also 
> desirable.
> Adding an origin also provides a hook for uncompetitive practice.
>
> If we are going to limit communication to ’same browser instance’ then 
> we would be better off with a port we can invoke postMessage() on.
>
> Generally I’m in favour of “as simple as possible” - however Einstein 
> did add “but no simpler.”
> It seems to me the token/origin solution is too simple - it solves 
> small part of the problem and leaves a slightly smaller new problem.
>
> Tim.
>
>
>> On 15 Jun 2021, at 22:23, Elad Alon <eladalon@google.com 
>> <mailto:eladalon@google.com>> wrote:
>>
>> Consider the alternative.
>>
>> Different apps have different ID spaces. 0x1234567890abcdef might be 
>> a valid ID on multiple services. Sometimes even for the same 
>> overarching company. When a captured app claims to be 
>> 0x1234567890abcdef, is that a Vimeo video, a Google Doc, a Google 
>> Slides deck, a Microsoft Word session, a CodePen...? And the list 
>> goes on.
>>
>> What's left for the app to do? I see two mutually-_non_-exclusive 
>> options:
>> 1. Prefix the session ID with an identifier. E.g. 
>> MsWord:0x1234567890abcdef. This is vulnerable to either spoofing or 
>> unintended clashes, though. "Works sometimes." Better marry that with #2.
>> 2. Verify 0x1234567890abcdef on some shared cloud infrastructure. 
>> "0x1234567890abcdef, you say? Let's have some remote challenge to see 
>> if you're who you really claim you are." This will take at least an 
>> RTT, though...
>>
>> You escape this conundrum if you allow UA-mediated origin-exposure. 
>> (_Optional_ origin exposure, btw, which means that you can send out 
>> an opaque token if you need to.)
>>
>> On Tue, Jun 15, 2021 at 9:49 PM Tim Panton <tim@pi.pe 
>> <mailto:tim@pi.pe>> wrote:
>>
>>
>>
>>     > On 15 Jun 2021, at 20:37, Harald Alvestrand
>>     <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>>     >
>>     > The point of the origin is that the UA vouches for it's
>>     authenticity.
>>     >
>>     > The token is just a string. As long as you can pass a string,
>>     the app can choose to pass anything: numbers, tokens, or
>>     jsonified objects. App's business, not UA business.
>>
>>
>>     I still don’t understand why the origin is relevant - apart from
>>     enabling a page to engage in uncompetitive behaviour.
>>
>>     The token is only exchanged when a user has authorised a capture
>>     and both sides agree that the captured page is suitable for
>>     remote control.
>>     So why would either side care what the origin is?
>>
>>     T.
>>
>