Consider limiting element types

[jan-ivar]

§ 6.3 Limiting element types says: "We do NOT limit the type of Element for which either setZoomLevel() or captureWheel() work. Such a limitation would accomplish nothing, because malicious applications could always overlay transparent permitted Element types on top of visible non-permitted Elements, thereby bypassing this restriction.

We deem the limitation of interaction types to be sufficient. This is accomplished by captureWheel() through its shape, and by setZoomLevel() through its gating on event types."

I'm not sure who "we" is here, or which decision this references (there are 8 hits in this doc compared to zero in https://w3c.github.io/mediacapture-screen-share/). I recommend rephrasing to limit "we" to examples.

I also think it would be prudent to limit to specific events elements for now, as suggested in #14 #14 (comment). I like the text that points out ways in which malicious sites might try to exploit this feature, but to encourage and allow UAs to mitigate these attacks, and discourage giving up trying.

For example, UAs can use heuristics here to turn off the feature if it detects transparency.

[jan-ivar]

I also think it would be prudent to limit to specific events for now, as suggested in #14. I like the text that points out ways in

Sorry, in my rush to file this issue in time for today's meeting, I butchered this part. Here I meant to say specific elements. which is what § 6.3 Limiting element types is about. Sorry for the confusion this caused. (I've now edited the OP to fix this)

[jan-ivar]

I was referring to #14 (comment):

If we step up a level, yes. It sounds like we want zoom controls to work through intentional and primary user interactions with <button> (click), <input type="number"> (input, change), and maybe <input type="range"> (input, change)?

Might it work for existing use cases to normatively limit this browser functionality to events natively coming from those three elements specifically? — This might help interop, and let us extend this list as we get comfortable with more elements.

[eladalon1983]

I'm not sure who "we" is here
...
there are 8 hits in this doc compared to zero in https://w3c.github.io/mediacapture-screen-share/)
...
I recommend rephrasing to limit "we" to examples.

"We" as used in Media Capture and Streams, where there are 7 occurrences of that word.
I have now dropped the number of "we" from 8 to 3, retaining it only for definitions. (#29)

I also think it would be prudent to limit to specific events elements for now, as suggested in #14 #14 (comment). I like the text that points out ways in which malicious sites might try to exploit this feature, but to encourage and allow UAs to mitigate these attacks, and discourage giving up trying.
...
Might it work for existing use cases to normatively limit this browser functionality to events natively coming from those three elements specifically? — This might help interop, and let us extend this list as we get comfortable with more elements.

1. With respect to "click":
   • If you can point out a vector of abuse that this limitation would stop, then yes, let's add this limitation.
   • But if the limitation will only make life harder for honest players, while leaving the capabilities of malicious actors undiminished, I'd rather not do that.
2. With respect to "input":
   • Could you point out an element type that supports this event, which you could argue should be excluded?
3. With respect to event types we will end up allowlisting in the future:
   • I will gladly limit the combination of {event-type, element-type} for undesirable combinations when/if we add event types in the future. I hope that would work for you...?

[jan-ivar]

... But if the limitation will only make life harder for honest players ...

What is made harder by limiting this to <button>, <input type="number">, and <input type="range">?

This seems to be the subset of interest.

I'm not a DOM expert, but given that, even if the subset is zero today, when designing for privacy and security, it seems safer to limit this functionality to the known set required to implement today's use cases, rather than assume all same-typed events from future elements will have the same interaction-level properties.

We can always come back and add new elements once we deem them safe.

[eladalon1983]

add new elements once we deem them safe.

Reiterating my previous message:

1. Which elements are presently unsafe?
2. How does this mitigation help block this attack vector?

[eladalon1983]

No activity in roughly a month; closing the issue. Feel free to re-open.