Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

That's server mediated communication. Doesn't solve the problem if identification, but it is certainly one of the things that can be used as a next step.

Den 19. juni 2021 01:23:03 CEST, skrev Silvia Pfeiffer <silviapfeiffer1@gmail.com>:
>Thinking a bit outside the box: there's an existing weary to
>communicate
>"state" to a web page and that's through URL fragments and URL query
>parameters. Could we just support those instead of something as
>specific as
>slide numbers?
>
>Cheers,
>Silvia.
>
>
>On Thu, Jun 17, 2021, 12:27 PM Jan-Ivar Bruaroey <jib@mozilla.com>
>wrote:
>
>> > Embedding the specific UA controls in the browser (proposal A and
>B) is
>> a layering violation.
>>
>> @Harald (I think you mean B?) In any case, the explainer
>>
><https://github.com/w3c/mediacapture-screen-share/blob/gh-pages/explainer.md#what-is-it-whats-it-for>
>> seems quite clear that the primary use case of getDisplayMedia is
>> presentations in video conferences. That's why browsers push captured
>> windows to the front
>> <https://github.com/w3c/mediacapture-screen-share/issues/138>, among
>> other things. I'm not taking a position on Youenn's proposal, only
>noting
>> that having user agents involved at a high level here does not seem
>out of
>> bounds: Two sites are involved, and user agents stepping in to
>mediate to
>> protect users seems fine and appropriate to me, if they wish to do
>that.
>>
>> > Considering both exist in the same browser instance, that is a
>> mind-bogglingly unnecessary detour.
>>
>> @Lennart Point taken. Most users run just one browser (we're all the
>> anomaly). So it's useful to scope the problem down to capturer and
>capturee
>> in the *same user agent*.
>>
>> This may not matter in the id-solution, but back to Sergio's concern:
>>
>> > My concern is that it will provide no value to Jitsi but will help
>> create monopolies to VC+content providers.
>>
>> @Elad An id-only solution is no good, for this reason. At the same,
>an
>> id-solution is probably inevitable: even a {slideNumber} constraint
>could
>> be used to communicate a handshake.
>>
>> Thus, the solution needs to mandate a baseline set of presentation
>> controls that work without any id, and expose the id as part of
>registering
>> for that. That's what I'd like to propose:
>>
>>    1. Target calls a method, providing how many slides it has, and
>>    whether to UA-guard against capture past (cross-origin) navigation
>>    2. Capturer gets {min, max} = track.getCapabilities().slideNumber;
>and
>>    can track.applyConstraints({slideNumber: min});
>>    3. Capturer can also get a track.getSettings().presentationId.
>>    4. Some event if the target navigates or calls the method again.
>>
>> I agree we cannot force apps to work together, but if we make it
>> embarrassingly easy, then hopefully twitter shaming can do the rest.
>>
>> But seriously, I think vc apps see the market benefit of letting
>> presenters present with whatever tools they have, just like they
>recognize
>> the benefit of participants joining from browsers on whatever device
>> they're on (or dialing in from phones! sheesh)
>>
>> I think presentation apps see the market benefit of working in
>whatever
>> meeting their user is in.
>>
>> IOW you can't capture an audience that is already captured in a
>meeting
>> they didn't start.
>>
>> If it turns out I was being naive here, it'll be on the internet
>forever.
>> No biggie. ;)
>>
>> Disclaimer: this all still needs to be under site-isolation and
>capture
>> opt-in.
>>
>> On Wed, Jun 16, 2021 at 3:42 PM Harald Alvestrand
><harald@alvestrand.no>
>> wrote:
>>
>>> 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> 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> wrote:
>>>
>>>>
>>>>
>>>> > On 15 Jun 2021, at 20:37, Harald Alvestrand
><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.
>>>
>>>
>>>
>>
>> --
>> .: Jan-Ivar :.
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.