URL-based Screen Share Restriction?

[michhyun1]

I'm trying to implement URL-based allowlisting screen sharing using getDisplayMedia.

I've seen the capture handle api, but that only passes the origin - I'm hoping to do the full URL.

I'm trying to come up with a plan to do this, I could use some guidance.

I saw this text blurb - #52.

"we can use BroadcastChannel, a shared back-end, sometimes a service worker"

How would this work? Would I set up a BroadcastChannel, which I would publish URL changes (from the captured side) and then listen for those changes on the capturing side?

[eladalon1983]

The URL exposes significantly more information than the origin. If there is enough interest in exposing it, we'd need to specify a separate opt-in for it, rather than reuse the current opt-in that exposes the origin. But it's not clear to me that there is much of an appetite for that yet.

In the meantime, you can get the same behavior by having the captured page set its URL in the free-form handle field.

(Note that even for exposing the origin, you need the captured site to opt-in; so presumably it's cooperating with the capturer and is well-positioned to set additional information in the handle field in your use case.)

[michhyun1]

I guess my main concern was that the handle can be spoofed - what's stopping someone from re-setting the capture handle, with some other handle config?

If not, then this would support our use case, although the only downside then would be browser support - as this seems to only be a chrome feature.

We are also considering the stenographic approach - where we ask the captured side to embed a QR code. On the capturing side, we'd process the captured side's mediastream and run it through a video processor in order to decode the QR code. This would give us more browser support - was wondering what your thoughts were on that.

Thanks!

[eladalon1983]

I guess my main concern was that the handle can be spoofed - what's stopping someone from re-setting the capture handle, with some other handle config?

Indeed, you should only trust the handle if you either (1) trust the origin, which is unspoofable, or (2) the handle is unfakeable, e.g. if it's signed somehow.

For (1), it's worth mentioning that only the top-level document may set or edit the handle. So if your concern was that an embedded iframe might have spoofed it - you shouldn't worry about that, at least.

If not, then this would support our use case, although the only downside then would be browser support - as this seems to only be a chrome feature.

Increased Web developer demand might help convince additional browsers to support this. (Full disclosure - I work for Google and I designed and implemented the feature in Chrome.)

We are also considering the stenographic approach - where we ask the captured side to embed a QR code. On the capturing side, we'd process the captured side's mediastream and run it through a video processor in order to decode the QR code. This would give us more browser support - was wondering what your thoughts were on that.

I have also considered this possibility and have pointed it out in the explainer. But Capture Handle has some benefits in that it is:

• Simpler to use
• More reliable (other content would not accidentally draw over the QR code)
• Cannot be spoofed (by cross-origin iframes that might draw QR codes)
• Is more private (only allowlisted readers can observe the handle, unlike with a QR code)

Given that only the captured page's top-level can set the handle, and that you can limit exposure to an allowlist of capturing origins, I think setting the handle to the URL and setting exposeOrigin: true should work for you much better than steganography. Wdyt?

(That said, longer-term, of course a dedicated mechanism for URL-exposure would be better for you.)