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

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

The capturee-facing API is pretty much a manifest, which would be useful to have a 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.

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?

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?


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

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