Hi, @jan-ivar, and thanks for sending this. @torgo and I have started looking at it at our TAG face-to-face in Wellington.

We've seen that the Security and Privacy section has matured a lot since we last looked at this document. But we got lost a bit in the current wording. Specifically:

1. For sections 8.2.1. and 8.2.2., it's not clear to us what use cases you have in mind. It may be useful to spell them out explicitly.

For 8.2.1., what is active user consent (perhaps it's asking for a permission?), and how is it different to the "novelty" mentioned in 8.2.3?

And for 8.2.2., when do you foresee content crossing origins? With the sharing user, or somehow including the recipient? Also, what elevated permissions are you expecting here? Perhaps those in the OS, or on the specific origin? If it's the origin, then what permissions, and how are they different to what you're thinking of in 8.2.1?

2. On 5.5 device identifiers: we are pleased that you're concerned about enumerated devices revealing too much information. That's great!

But we're a bit confused... how do you think that UAs will solve that problem? Is it necessary to spell that out, or is flexibility useful here?

Specifically, we were wondering if you are expecting them to create temporary device IDs? Do you see any danger of them being preserved, and therefore causing the same problem?

Also, we were happy to see how much throught went into the responses to the privacy & security questionnaire, especially since this API has some tricky privacy considerations. We'd appreciate it if that doc could be brought over into your repo instead of living as a google doc.

Hi, and thanks! I'm happy to elaborate since the privacy issues aren't super evident. (Part 1/2)

For 8.2.1., what is active user consent (perhaps it's asking for a permission?),

In short, yes. It's one of two forms of mandated consent interactions; the one required regardless of source. This spec tries hard to not assume what shape UX might take, hence these abstractions.

Example of Active User Consent: all current implementations implement a screen/window/tab picker, which imply giving permission much like a file upload dialog does.

and how is it different to the "novelty" mentioned in 8.2.3?

It should be less severe/novel than the elevated permission required for scary sources.

Importantly, "elevated permissions are not a substitute for active user consent." In other words: sharing a scary source requires both elevated permission and active user consent.

Example of Elevated Permission: an installation procedure akin to installing an extension, where the user understands they're making a high-trust special exception. At the time of writing years ago, Chrome still required installation of an extension to enable screen sharing, and Firefox required an about:config whitelist of websites (i.e. an extension).

Since then, implementations have lowered the bar:

1. Firefox shows a ⚠️ warning in the preview pane (seen here) of scary sources only.
2. Chrome makes no distinction (in violation of the spec in my opinion).

(Part 2/2)

And for 8.2.2., when do you foresee content crossing origins?

If a web site controls both what is being captured and the resulting stream, then it has a power tool to circumvent the same origin policy. See the blog for an explanation of this exploit.

On 5.5 device identifiers:

Device identifiers are not exposed to JS ("MUST NOT be enumerated by enumeratedevices()").

@hadleybeeman @torgo. I've added the questionnaire in https://github.com/w3c/mediacapture-screen-share/pull/137

Hi - I think we are happy to close this. Thanks for taking our feedback on board.