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.
Received on Tuesday, 15 June 2021 21:24:37 UTC