Element Capture #857

Activity

1. jan-ivar commented on Jul 28, 2023

   

   jan-ivar

   on Jul 28, 2023

   MemberAuthor

   More actions

   I sympathize with the first use case, and would be open to explore targeting it more narrowly. E.g. allow webpages to temporarily render (semi-transparently?) atop a captured area without affecting the capture for brief periods of time. I also wonder whether briefly pausing the capture might suffice in many slide-ware use cases?

   Apologies, I didn't fully understand the second use case, which seemed better solved with HTML than video to me.

   Privacy Concerns

   This API appears to let websites capture occluded content, which could be exploited to render and capture covertly.

   A User Agent's rendering is tailored to its user, and may contain private information the site is not privy to (preferences, history, cross-origin user information). Letting sites capture this covertly seems harmful to users.

   In contrast, https://www.w3.org/TR/screen-capture and https://www.w3.org/TR/mediacapture-viewport capture what the user sees. While not impervious to render-and-capture, sites risk being caught doing so. While not impervious to occlusion, end-users are in control of occlusion (switching tabs, moving OS windows).

   Those APIs have a WYSIWYG quality that seems desirable from a privacy viewpoint.

   Confusing terminology and under-specified rendering

   I was happy to see there were some CSS restrictions, but they didn't seem to prevent capture of off-screen content.

   Naively, track.restrictTo(element) sounds like it should capture a subset of what's on screen. But "restrict" is defined to mean "a capture of the DOM sub-tree rooted at the target-element." But does capture of a more descended DOM node always yield a smaller area?

   Is there an implied rendering step here of something other than the viewport? What does it mean to render a DOM sub-tree apart from its container(s)? How is element rendered if it is larger than its container, or off-screen at (-10000,-10000)?

   I'm happy to get clarifications, but I think our position should negative since the privacy concerns are neither addressed nor disclosed.
2. zcorpan

   changed the title [-]Request for position: Element Capture[/-] [+]Element Capture[/+] on Aug 17, 2023
3. eladalon1983 commented on Sep 7, 2023

   

   eladalon1983

   on Sep 7, 2023

   More actions

   Hi @jan-ivar. Sorry for not getting back to you earlier, but as I was not tagged here, I was not aware of this issue before. It's only recently that I have learned of this thread.

   A User Agent's rendering is tailored to its user, and may contain private information the site is not privy to (preferences, history, cross-origin user information). Letting sites capture this covertly seems harmful to users.

   The user must first consent to the capture of the current tab.
   None of the information being captured using Element Capture is new; the capturing site would have had access to it all using pre-existing mechanisms that predate Element Capture.
   The user agent will continue to inform the user that the tab is being captured, so "covertly" does not appear correct to me.

   Those APIs have a WYSIWYG quality that seems desirable from a privacy viewpoint.

   During our discussions of getViewportMedia(), you have done much to educate me on the multitude of ways to exfiltrate information without alerting the user - exposing information at low opacity, or extremely briefly, or piecemeal - up to even one pixel at a time. Because of these many techniques, malicious sites can already abuse self-capture, and Element Capture does not increase their power to do harm.

   I was happy to see there were some CSS restrictions, but they didn't seem to prevent capture of off-screen content.

   ...

   Is there an implied rendering step here of something other than the viewport? What does it mean to render a DOM sub-tree apart from its container(s)? How is element rendered if it is larger than its container, or off-screen at (-10000,-10000)?

   Please see what the spec had to say here:

   3. Let intersection be the intersection of E's bounding box
       and the captured surface's top-level browsing context's viewport.
   4. If intersection is empty, abort without producing a new frame.
   5. A corollary of previous steps is that E forms a stacking context.
       Produce and deliver a frame consisting of an independent rendering
       of that stacking context, clipped to intersection.
   

   Naively, track.restrictTo(element) sounds like it should capture a subset of what's on screen. But "restrict" is defined to mean "a capture of the DOM sub-tree rooted at the target-element." But does capture of a more descended DOM node always yield a smaller area?

   Yes, it's always a smaller area, because of the clipping to the intersection of the target-element and the viewport - see above.

   but I think our position should negative since the privacy concerns are neither addressed nor disclosed

   As mentioned, I have only recently learned of this GitHub issue. I am happy to keep discussing any issues you raise.
   It bears mentioning that I have extended multiple personal invitations for you to attend the Screen Capture CG's meetings. And it should go without saying you remain ever welcome.
4. jan-ivar commented on Nov 20, 2023

   

   jan-ivar

   on Nov 20, 2023

   MemberAuthor

   More actions

   The user must first consent to the capture of the current tab.

   User consent is meaningless if risks aren't understood. Existing wording doesn't cover capture of invisible content.

   None of the information being captured using Element Capture is new; the capturing site would have had access to it all using pre-existing mechanisms that predate Element Capture. The user agent will continue to inform the user that the tab is being captured, so "covertly" does not appear correct to me.

   Capture isn't limited to old information. Self-capture allows websites to render new potentially sensitive information on demand. Rendering it "covertly" (to a known occluded area that always escapes user detection) is new.

   ... exposing information at low opacity, or extremely briefly, or piecemeal - up to even one pixel at a time. Because of these many techniques, malicious sites can already abuse self-capture, and Element Capture does not increase their power to do harm.

   Those techniques minimize risk of visual detection, but does not eliminate it like this API does.

   I think it's a mistake to look only at the most malicious sites. Two threat vectors:

   1. Malicious trap sites largely undeterred by detection. Detect, eject, too late, we have your info
   2. Mainstream tracking libraries doing ongoing data collection for unsuspecting customer websites

   For 2, escaping detection is core to business. Element Capture increases their power to do harm.

   The deterrent of visual evidence showing a site engaging in unseemly data collection should not be underestimated. It may be all that separates what's objectionable from the norm, as we saw in w3c/mediacapture-main#574.
5. martinthomson

   added

   position: negative

   on Nov 20, 2023
6. martinthomson commented on Nov 20, 2023

   

   martinthomson

   on Nov 20, 2023

   Member

   More actions

   We walk a fairly fine line with screen capture, with the self-capture version of that carrying a significantly higher risk. We accept that risk for several reasons. Primarily, the absence of self capture as an option would be difficult to explain against whole-of-screen capture, which will often include self capture. The risk of abuse remains there. While it's important to acknowledge that our mitigations are weak at best, recognizing that the entire package has value that outweighs that risk is key.

   For applications like the one described in the explainer, where the risks are heightened without good (or any) mitigations, I agree with @jan-ivar's analysis. This does not strike the correct balance.

   I believe that it is possible, even trivial, with Google Docs to show the document content to all participants using other mechanisms. Maybe the exact sub-pixel rendering of fonts will not be propagated faithfully or other such quirks, but then you probably don't want that and video codecs are terrible at preserving that sort of detail anyway.

   Which leaves the conclusion that this comes with risks that are real, but hard to understand. The benefits are marginal. And we're already right on the edge of what is acceptable anyway. So I have to agree with @jan-ivar's conclusion that this is negative.

   (I'll note that mediacapture-region has absolutely no acknowledgment of associated risks, as does this explainer. Given the nature of those risks, that's concerning.)
7. martinthomson

   closed this as completedon Nov 20, 2023
8. eladalon1983 commented on Sep 22, 2024

   

   eladalon1983

   on Sep 22, 2024

   More actions

   (Responding to @jan-ivar's message.)

   [jan-ivar] [...]

   [eladalon1983] The user must first consent to the capture of the current tab. None of the information being captured using Element Capture is new [...]

   [jan-ivar] User consent is meaningless if risks aren't understood.

   Indeed, informed consent requires comprehension - we agree here. But that does not appear to me relevant. Quotes should be regarded in their full context. In this case, I was addressing your concerns over "preferences, history, cross-origin user information". You only responded to the introductory sentence of my paragraph there. Please note the rest of that message, where my argument was - Element Capture does not change the equation on leaking preferences, history and cross-origin user information.

   Rendering it "covertly" (to a known occluded area that always escapes user detection) is new.
   [Emphasis mine - Elad.]

   In May I emailed you a question about a potential way to address this concern. Allow me to repeat my question:

   You have previously opposed preferCurrentTab on privacy/security grounds; you proposed getViewportMedia as the safe alternative. Would it therefore be possible to mitigate the concerns you have for Element Capture by restricting Element Capture to only work on tracks obtained using getViewportMedia?

   (FTR - I am not yet sure I consider this a necessary mitigation. I am still trying to understand if you would consider it sufficient, in order to understand whether we could reach consensus or at least a compromise.)

   1. Malicious trap sites largely undeterred by detection. Detect, eject, too late, we have your info

   Agreed once more! Then we agreed that in this case (1/2), even if Element Capture did increase a malicious site's ability to go undetected, it would not matter, right?

   2. Mainstream tracking libraries doing ongoing data collection for unsuspecting customer websites

   This case (2/2) is not realistic. Tracking libraries do not call APIs that prompt the user; especially not APIs that would show such a complicated dialog as getDisplayMedia() does; even more so because that would only work if the user navigated through that complex dialog and chose the only option that would enable the attack - the current tab.
9. eladalon1983 commented on Sep 22, 2024

   

   eladalon1983

   on Sep 22, 2024

   Last edited by eladalon1983

   More actions

   (Responding to @martinthomson's message.)

   Martin, could it be that you are confusing Region Capture and Element Capture? You appear to be looking at the RC explainer and its associated use cases.

   I believe that it is possible, even trivial, with Google Docs to show the document content to all participants using other mechanisms.

   The use case of iframing an application developed by the same company is too narrow. Let's examine one illustrative concrete case - Google Meet in September 2024. We see that they have just released an SDK that allows arbitrary Web applications to opt into being iframed in Meet as a "Google Meet Add-on" (link).

   Using Element Capture, one Meet user can present such an opted-in third-party application to other Meet users who either don't have the necessary permissions to log into that application, or users who don't have access to specific user-generated content within that application.

   That is, if I have a Figma license and have produced a private Figma project, I can iframe and present that project to you even if (i) you don't have the license to load Figma yourself, or if (ii) you don't have read-permissions for the specific private projects I intend to present.

   Achieving the same thing with anything other than Region/Element Capture would require bespoke integrations between {Figma, Miro, Polly, ...} x {Meet, Teams, Zoom, ...}. Such a high barrier to entry would be especially damaging for smaller players, as the other side would not be interested in investing the engineering resources to support such an integration with a smaller player. So please consider how benefical Element Capture is for the open Web.

   I'll note that mediacapture-region has absolutely no acknowledgment of associated risks, as does this explainer. Given the nature of those risks, that's concerning.

   Thanks for alerting me to this. But please note that the current request for a standards position is for Element Capture, not for Region Capture. Element Capture already has a lengthy privacy and security section in its spec (here), as well as a security and privacy questionnaire. (If it helps Mozilla, I can copy the same content into the explainer too, although imho that'd duplication would be counterproductive.)
10. eladalon1983 commented on Oct 10, 2024

    

    eladalon1983

    on Oct 10, 2024

    More actions

    Does the recent change of Element Capture, to only work on "restrictable" tracks provided by getViewportMedia(), change Mozilla's position on this API?

    👍React with 👍1Reacted by Stephen Haney