Hey folks,

I've taken a look at the explainer as part of our security/privacy triage 
process (note: it looks like the link above is broken, it should be 
https://github.com/screen-share/capture-all-screens) and wanted to chime in 
with some security feedback.

Concretely, this API gives any origin that has the ability to call it 
(anything allowlisted in the Enterprise Policy) access to ~all of the 
user's browsing data -- not just what's displayed on the screen. This is 
because the caller can also redirect the user (or open popups, etc.) to 
arbitrary cross-site endpoints which might contain authentication tokens 
(e.g. JSON responses with a JWT or similar secret); these credentials can 
later be used to gain access to accounts to which the user is logged in, 
even if the user hasn't intentionally interacted with the affected websites 
while screen capture was happening.

This makes any allowlisted origin privileged to access almost arbitrary 
cross-origin information; any XSS bug in such an origin will be capable of 
doing the same. This introduces a somewhat unprecedented attack surface 
where finding a common web vulnerability in a single origin/site will give 
attackers the capability to persistently compromise the user's accounts on 
other sites. 

My guess is that the proposal should include a security section to discuss 
this risk and implement restrictions on the API to prevent its abuse. Some 
possibilities include ensuring that JS can't get access to the MediaStream 
(e.g. the MediaStream can be sent to an allowlisted origin but not accessed 
by scripts) and requiring the user to click through a non-dismissible 
All-Screen Capture interstitial before starting capture (to prevent the API 
from being called when the user is away from the device). I'd suggest 
having a fairly in-depth discussion of the options to prevent this API from 
introducing a substantial risk for its users.

Cheers,
-Artur



On Wednesday, June 7, 2023 at 5:57:23 PM UTC+2 Mike Taylor wrote:

> Also, it would be good to file a TAG review sooner than later to prevent 
> any delays at a possible future I2S time.
> On 6/7/23 11:53 AM, Chris Harrelson wrote:
>
> LGTM
>
> On Tue, Jun 6, 2023 at 1:57 PM Simon Hangl <sim...@chromium.org> wrote:
>
>> Contact emails 
>>
>> sim...@google.com
>>
>> Explainer 
>>
>> https://github.com/screen-share/capture-all-screens/blob/main/explainer.md
>>
>> Specification 
>>
>> https://screen-share.github.io/capture-all-screens/
>>
>> Design docs 
>>
>> https://screen-share.github.io/capture-all-screens
>>
>> https://github.com/screen-share/capture-all-screens/blob/main/explainer.md
>>
>>
>> https://docs.google.com/document/d/1p8hhW8cp1PbhEClMTWzYGjfTkBxaNcD34170F60FRpg/edit?resourcekey=0-gLQD4Q6bPVJlZ3gEyZ4_mA#heading=h.qxjlhbc2utcv
>>
>> Summary 
>>
>> Capture all the screens currently connected to the device using 
>> getAllScreensMedia().
>>
>> Calling getDisplayMedia() multiple times requires multiple user gestures, 
>> burdens the user with choosing the next screen each time, and does not 
>> guarantee to the app that all the screens were selected. 
>> getAllScreensMedia() improves on all of these fronts.
>>
>> (As this feature has extreme privacy ramifications, it is only exposed 
>> behind an enterprise policy, and users are warned before recording even 
>> starts, that recording *could* start at some point.)
>>
>>
>> Blink component 
>>
>> Blink>GetDisplayMediaSet 
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EGetDisplayMediaSet>
>>
>> TAG review 
>>
>> None
>>
>> TAG review status 
>>
>> Pending
>>
>> Risks 
>>
>> Interoperability and Compatibility 
>>
>> This API is only available to origins allowlisted by administrators 
>> through a policy. The policy itself is non-standard, limiting even 
>> theoretical interoperability.This API rejects requests from pages that are 
>> not allow-listed through an administrator. The likelihood of this API being 
>> adopted by a browser that does not provide administrators mechanisms to 
>> manage clients is low.
>>
>>
>> Gecko: N/A - given that the API is limited to managed configurations, 
>> it's not clear that requesting a position is needed
>>
>> WebKit: N/A - given that the API is limited to managed configurations, 
>> it's not clear that requesting a position is needed
>>
>> Web developers: Positive (
>> https://github.com/screen-share/capture-all-screens/issues/9)
>>
>> Other signals:
>>
>> Ergonomics 
>>
>> No
>>
>> Security 
>>    
>>    1. 
>>    
>>    Risk of malicious sites exploiting the API and gaining access to 
>>    sensitive information on users' devices. This risk is mitigated by the 
>> API 
>>    only being accessible to origins allowlisted by an enterprise policy.
>>    2. 
>>    
>>    Risk of users loading private information that gets recorded and made 
>>    available to apps affiliated with their device's admin. This risk is 
>>    mitigated by informing users that recording might start at any moment 
>>    before the API becomes accessible. (In CrOS, this warning is delivered in 
>>    the log-in screen, and when users log-in despite the warning, this is 
>>    tantamount to assent.)
>>    3. 
>>    
>>    Risk of users forgetting that their screens are being recorded. This 
>>    risk is mitigated through a persistent notification.
>>    
>>
>>
>> WebView application risks 
>>
>> None
>>
>>
>> Goals for experimentation 
>>
>> Learn about the experience of web developers and how this API fulfills 
>> their needs.
>>
>> Ongoing technical constraints 
>>
>> None
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, Chrome OS, Android, and Android WebView)? 
>>
>> No
>>
>> This API is initially implemented on CrOS, where demand for it is 
>> greatest, and where we have the most flexibility in offering users early 
>> warning that their screens may be recorded if they proceed past the log-in 
>> screen. Lessons learned from shipping this API on CrOS will be used when 
>> deciding how to correctly implement such warnings on other platforms.
>>
>>
>> Is this feature fully tested by web-platform-tests 
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ? 
>>
>> No, as WPTs don’t support setting of managed policies. The API is tested 
>> by a number of unit- and browser- tests (Test files 
>> <https://source.chromium.org/search?q=getallscreensmedia%20f:test.cc%20-f:out%2F&sq=>
>> ).
>>
>> DevTrial instructions 
>>
>> https://github.com/screen-share/capture-all-screens/blob/main/HOWTO.md
>>
>> Flag name 
>>
>> enable-get-all-screens-media
>>
>> Requires code in //chrome? 
>>
>> True. To support this API, embedders need to implement the 
>> ContentBrowserClient::ContentCreateScreenEnumerator 
>> <https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:content/public/browser/content_browser_client.h;l=1377;drc=9c68f2c46912577bf73bcf032c0f8c00379a0bca>
>>  
>> interface.
>>
>> Tracking bug 
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1300883
>>
>> Launch bug 
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1300881
>>
>> Estimated milestones 
>>
>> OriginTrial desktop last
>>
>> 119
>>
>> OriginTrial desktop first
>>
>> 117
>>
>> DevTrial on desktop
>>
>> 116
>>
>>
>> Link to entry on the Chrome Platform Status 
>>
>> https://chromestatus.com/feature/6284029979525120
>>
>> Links to previous Intent discussions 
>>
>> Intent to prototype: 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEdDZo9N354i6eST0x19TXwpeBtgs5_gJUYVF%2BTKLpiJySDADg%40mail.gmail.com
>>
>> Ready for trial:
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/e_cUVJEvzuY?pli=1
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to blink-dev+...@chromium.org.
>> To view this discussion on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEdDZo8ijX%3DMG_bE_U0%2B_HMOd1VSBj8GM5fv13HZ69gtoeHgdw%40mail.gmail.com
>>  
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEdDZo8ijX%3DMG_bE_U0%2B_HMOd1VSBj8GM5fv13HZ69gtoeHgdw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to blink-dev+...@chromium.org.
>
> To view this discussion on the web visit 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8UCe1jw3D%2BKd_%2Be%2BGJSthaMPy6fU3pDf%3DARRk_pYry3w%40mail.gmail.com
>  
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8UCe1jw3D%2BKd_%2Be%2BGJSthaMPy6fU3pDf%3DARRk_pYry3w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4053eb5b-25b4-421c-9f60-b3dc8799bd33n%40chromium.org.

Reply via email to