Is it important for capture control to keep captured tab from knowing it is captured?

w3c / mediacapture-surface-control

Web API allowing capturing applications limited control over captured surfaces.

https://w3c.github.io/mediacapture-surface-control/

Other

9 stars 1 forks source link

Is it important for capture control to keep captured tab from knowing it is captured? #42

Open youennf opened 2 weeks ago

youennf commented 2 weeks ago

getDisplayMedia is trying to ensure that a captured surface does not know it is captured, at least for tab capture. The question is whether this API should keep this contract or whether we do not care about this constraint.

youennf commented 2 weeks ago

FWIW, if a captured tab visibility is hidden and it receives user gesture, then it would know that it is being captured. But that the same time, it is unclear whether a captured tab visibility should hidden or visible. This makes me wonder whether mediacapture-screenshare should say a word about this.

eladalon1983 commented 2 weeks ago

That's a great question. At the moment, Meet is using Captured Surface Control via origin trial in Chrome, and so far, I have not heard of either (1) sites that fail to work correctly, nor (2) sites that abuse the knowledge that they are captured. So I think we could keep this as a non-blocking issue open and allow ourselves to make a more informed decision based on data that will flow in after the API gains adoption. Wdyt?

jan-ivar commented 2 weeks ago

Yes, I think it's important to keep the captured tab unaware. This keeps users in charge.

eladalon1983 commented 2 weeks ago

Without real-world experience, it's hard to weigh the benefits and disadvantages.

On the one hand, we have theoretical, potential abuse by apps that discover that they are captured.
- First, this is completely theoretical at this stage.
- Second, this risk is completely mitigated if the user never scrolls or zooms the captured tab.
On the other hand, we have the risk that apps would function incorrectly if they think they are foregrounded when they are not.
- But then again, it's not clear if this too might be purely academic.

I see no great urgency to specify this behavior one way or the other. We can let user agents experiment here and report back their findings.

youennf commented 2 weeks ago

I had a quick try and AIUI, Chrome is making sure that a tab thinks it is visible (which is sort of true) when captured. This would also be consistent with unsuspending/ not-throttling the captured tab. And this also helps ensuring that the surface control API is not leaking that a tab is being captured.

This might be good input for the screen share main spec.

eladalon1983 commented 2 weeks ago

We appear to have consensus about what is likely preferable. Can we also have consensus that the spec should not yet actively mandate this behavior at this point, given our relative ignorance on real-world conditions?

jan-ivar commented 2 weeks ago

This might be good input for the screen share main spec.

Thanks for testing! I like Chrome's behavior, and agree it seems worth capturing. Opened https://github.com/w3c/mediacapture-screen-share/issues/307.

As to this issue, unless the proposal leaks today, I see no reason to keep it open.

If you're asking would I oppose a proposal that leaked this information? Probably, unless it's a really good one.

But right now I don't see anything here requiring consensus.

eladalon1983 commented 1 week ago

@youennf, are you also in favor of closing this issue?

eladalon1983 commented 1 day ago

Issue transferred; heads up to those discussion participants who might otherwise be looking for it elsewhere: @jan-ivar, @youennf