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.)
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)
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.
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.)
Risk of users forgetting that their screens are being recorded. This risk is mitigated through a persistent notification.
Learn about the experience of web developers and how this API fulfills their needs.
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.
No, as WPTs don’t support setting of managed policies. The API is tested by a number of unit- and browser- tests (Test files).
True. To support this API, embedders need to implement the ContentBrowserClient::ContentCreateScreenEnumerator interface.
Ready for trial:
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.
Also, it would be good to file a TAG review sooner than later to
prevent any delays at a possible future I2S time.
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.
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.
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.
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.
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.