6 milestones is consistent with our OT process' recommendations. Still LGTM. Good luck with the experimentation.
-mike On Wed, Aug 16, 2023 at 4:52 PM 'Simon Hangl' via blink-dev < [email protected]> wrote: > Hi everybody, > > I'd like to update the OT milestones mentioned above to an OT of 6 months > duration [1]: > OriginTrial desktop last: 124 > OriginTrial desktop first: 118 > > [1] https://www.chromium.org/blink/launching-features/#origin-trials > > On Monday, July 10, 2023 at 5:29:35 PM UTC+2 Simon Hangl wrote: > >> | Lastly, this API is currently only shipping for CrOS, where the user is >> already prompted to consent to this capture before they log into the >> system[*]. >> >> One correction - due to technical limitations, the user is NOT warned on >> the login screen that if they proceed they might be recorded. This >> notification is only shown (immediately) after login. As mentioned, it is a >> notification that shows up even before recording starts, letting the user >> know that they *might* be recorded at any moment. >> >> On Thursday, June 15, 2023 at 5:33:21 PM UTC+2 Artur Janc wrote: >> >>> On Thu, Jun 15, 2023 at 3:52 PM Elad Alon <[email protected]> wrote: >>> >>>> Hi Arthur! >>>> >>>> Using the pre-existing getDisplayMedia(), an application can already >>>> gain access to the user's screen and capture content in pop-ups, detect >>>> browsing history, etc. - provided the user chooses to capture their (often >>>> only) screen. All of the concerns above apply for gDM. Further, any website >>>> can call gDM. >>>> >>> >>> The "provided the user chooses to capture their screen" part is what >>> does the heavy lifting here. Each time gDM is called the user has to >>> explicitly consent to sharing their screen and decide what to share; as >>> such, even an XSS in an application which calls gDM generally isn't enough >>> to read the contents of the user's screen because the user has to interact >>> with the UI that will enable screen sharing. >>> >>> This feature doesn't have an equivalent protection and permits the >>> allowlisted origin to call the API at any time without obtaining consent >>> from the user, making it possible to abuse the privileges of the >>> allowlisted origin if an attacker finds an XSS bug in it. >>> >>> >>>> >>>> In contrast, getAllScreensMedia() can only be called by websites >>>> expressly allowlisted by the device's owner. This configuration would >>>> typically be carried out by an admin who is more tech-savvy than the >>>> average user, and it would usually be the admin's job to apply some good >>>> judgement with respect to security risks their organization might face. >>>> >>>> It is expected that a reasonable company would only allowlist: >>>> 1. Its own applications. >>>> 2. Applications from providers who were contracted specifically for >>>> this purpose, and who are trusted by the contracting company to such an >>>> extent, that long-term full-screen recording is permitted. >>>> >>> >>> It's not at all clear that domain admins who want to monitor their >>> users' activity are familiar with the web security posture of all the >>> origins they want to allowlist. Even if the scope of the allowlist is just >>> "the company's own applications", there is a substantial risk that an XSS >>> bug in any of the applications (which could previously only access the >>> user's data in that single application) will now be granted the privileges >>> to access the user's data on all other websites. >>> >>> Lastly, this API is currently only shipping for CrOS, where the user is >>>> already prompted to consent to this capture before they log into the >>>> system[*]. Shipping for non-CrOS platforms will naturally be harder, and >>>> that work is not currently on anyone's OKRs. >>>> >>> >>> In this case the entity calling the API is an attacker with a >>> vulnerability in any of the origins allowlisted in the Enterprise Policy. I >>> don't think the fact that a user has clicked through a dialog when logging >>> into the device serves as any protection for the user in this case because >>> it's the attacker that is abusing the persisted privileges of the >>> allowlisted origins to read the user's data, rather than the application >>> that the domain admin has added to their allowlist. >>> >>> Wdyt? >>>> >>>> --- >>>> [*] As Matthew and Simon tell me. I have not checked. >>>> >>>> On Thursday, June 15, 2023 at 2:36:41 PM UTC+2 Artur Janc wrote: >>>> >>>>> 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 <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Contact emails >>>>>>> >>>>>>> [email protected] >>>>>>> >>>>>>> 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 [email protected]. >>>>>>> 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 [email protected]. >>>>>> >>>>>> 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0e6f204e-dfda-4f98-9df5-2531364f79aen%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0e6f204e-dfda-4f98-9df5-2531364f79aen%40chromium.org?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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DesXY%3DfvPEMZnkG-9kLev4uAi2eEOednggi0eEAzkHOaA%40mail.gmail.com.
