Re: [w3ctag/design-reviews] Capture Handle Identity (#645)

> First pass, not an official review. Initial skim nothing serious really sticks out. Some comments:

Early pass much appreciated - thanks!

> The capturee-facing API is pretty much a manifest, which would be natural to have a complementing declarative path. Not only because this lets noscript applications to work, but the imperative-only path exposes the capturee to an unwanted capture timing attack if it happens between page load start and the first setCaptureHandle() call.

Sorry, I did not fully follow. Could you please clarify this for me?

> The asymmetric nature seems strange to me - why shouldn't the capturee know that the capturer has started capturing itself? This would be a rather wild paradigm shift, but could unlock some interesting use cases. (And obviously, abuse patterns.) Has a tradeoff discussion happened in the WG?

It's been discussed in the WG in the sense that some people initially misunderstood my proposal of Capture Handle as proposing the inverse direction, and were alarmed at the abuse potential (which you have acknowledged).

I think it's possible to follow up in the WG with a proposal for a **separate mechanism** to allow a capturer to opt-in to alerting the capturee. Without opt-in, this would not be desirable, as capturees would be able to self-censor themselves when captured, perhaps even throwing up ads for some video-conferencing application of their choosing. This would push users away from the Web platform and towards native apps.

At any rate, it seems to me like an orthogonal API to the currently proposed mechanisms, even if we end up exposing them adjacently. Or wdyt?

> CaptureHandleConfig.permittedOrigins seems rather oversimplistic - an exact mechanism doesn't immediate come to mind, but wouldn't wildcard patterns *.capturer.com be something our users would expect to work?

I am open to extending the spec later if there is consensus. Wdyt?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/645#issuecomment-1064090035
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/645/1064090035@github.com>