Intent to Ship: Read Chrome device attributes

[Sergii Bykov]

Contact emails

sby...@google.com

Explainer

https://github.com/Ananubis/WebApiDevice/blob/master/Explainer.md

Specification

https://wicg.github.io/WebApiDevice/device_attributes

Summary

Device Attributes Web API is a subset of Managed Device Web API, that provides web applications the capability to query device information (device ID, serial number, location, etc).

Blink component

Blink

TAG review

https://github.com/w3ctag/design-reviews/issues/606 There was no indication of implementation support from browsers other than Chrome. And reviewers were concerned by the risk of pervasive monitoring of employees. Privacy concerns were addressed in 'Permission control' and 'privacy consideration' paragraphs of the spec. But TAG reviewers didn't endorse adding this as a general mechanism to the Web platform.

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

navigator.managed object includes managed configuration and this device attributes API. These APIs only work in managed applications and return an error in other contexts. Thus navigator.managed exposure may be reduced in the future to managed environments only. This will be done as a separate chrome feature and after an investigation with usage counters.

Gecko: Neutral (https://github.com/mozilla/standards-positions/issues/815) Mozilla decided not to take a position. Also suggested to limit the exposure (see proposal in Interoperability and Compatibility).

WebKit: Neutral (https://github.com/WebKit/standards-positions/issues/198) Mixed signals from WebKit. Offering to leave it as an extension API or do not expose it everywhere. Exposure addressed in Interoperability and Compatibility

Web developers: Positive (https://github.com/WICG/proposals/issues/14) Web developers request this API as they migrate from deprecated ChromeApps to PWAs

Other signals:

Ergonomics

Frequently used with managed configuration. No performance risks.

Activation

No activation challenges for developers. API is straighforward to use. ChromeOS Admins will need to set up the force-installed or kiosk app and the allowlist policy correctly.

Security

Please see 'Permission control' and 'privacy consideration' paragraphs in the API spec.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

This feature does not deprecate or change behavior of existing APIs.

Debuggability

Verified that all five new methods show up in the DevTools Console autocomplete functionality.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No

Is this feature fully tested by web-platform-tests?

No

DevTrial instructions

https://github.com/WICG/WebApiDevice/blob/main/README.md

Flag name on chrome://flags

enable-restricted-web-apis

Finch feature name

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1132865

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1217848

Availability expectation

Feature is available only in ChromeOS (Ash and Lacros) browsers for the foreseeable future.

Adoption expectation

Feature will be used by Web App developers for Kiosk and other managed apps on ChromeOS as a part of migration from ChromeApps to PWAs within 12 months of launch in Chrome.

Adoption plan

A new setting in dpanel kiosk settings will allow admins of managed chrome to configure 'trusted' apps access to API usage via existing policy 'DeviceAttributesAllowedForOrigins'. This setting will be enabled for trusted testers end of Q2 2023.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

Yes. Policy for managed devices is used to control apps that can access this API. For example, after the launch navigator.managed.getAnnotatedAssetId will be defined for 'trusted' origins (kiosk or force-installed web app), but it will return an error if origin is not allowlisted in 'DeviceAttributesAllowedForOrigins' policy.

Sample links

https://github.com/WICG/WebApiDevice/blob/master/README.md

Estimated milestones

Shipping on desktop	117
OriginTrial desktop last	98
OriginTrial desktop first	93

OriginTrial Android last

98

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

Spec changes are not expected in the near future. Current spec is consistent with a similar extension API.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5694001745231872

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/oYRwgx8SwTA/m/OTfKKCMZBQAJ Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/dJQgwZ_1jk0/m/eo5aXO8eAgAJ

This intent message was generated by Chrome Platform Status.

--

Sergii Bykov

Software Engineer

sby...@google.com
+49 174 2575015

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. 

     

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Mike Taylor]

On 7/4/23 5:35 AM, 'Sergii Bykov' via blink-dev wrote:

Contact emails

sby...@google.com

Explainer

https://github.com/Ananubis/WebApiDevice/blob/master/Explainer.md

I see that getAnnotatedAssetId(), getAnnotatedLocation(), getDirectoryId(), and getSerialNumber() are all defined as uniquely identifying a device. Forgive my ignorance, but can you expand on the use cases for each of these unique IDs in the explainer (and why there are so many of them)?

Specification

https://wicg.github.io/WebApiDevice/device_attributes

Summary

Device Attributes Web API is a subset of Managed Device Web API, that provides web applications the capability to query device information (device ID, serial number, location, etc).

Blink component

Blink

TAG review

https://github.com/w3ctag/design-reviews/issues/606 There was no indication of implementation support from browsers other than Chrome. And reviewers were concerned by the risk of pervasive monitoring of employees. Privacy concerns were addressed in 'Permission control' and 'privacy consideration' paragraphs of the spec. But TAG reviewers didn't endorse adding this as a general mechanism to the Web platform.

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

navigator.managed object includes managed configuration and this device attributes API. These APIs only work in managed applications and return an error in other contexts. Thus navigator.managed exposure may be reduced in the future to managed environments only. This will be done as a separate chrome feature and after an investigation with usage counters.

Can you clarify what you intend to ship vs "exposure may be reduced in the future"? Mozilla had a good suggestion, but it's not clear to me if it's being incorporated or not.

--
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/CAEBayjL7AyE-m7A90NxnKbsXUtqreD7GNH5qWSy4ydSpv3_4AQ%40mail.gmail.com.

[Reilly Grant]

Sergii, thank you for adding some discussion of design alternatives in WICG/WebApiDevice#20. Please also update the explainer to address the following issues:

• WICG/WebApiDevice#1
• WICG/WebApiDevice#2
  
• WICG/WebApiDevice#6
  
• WICG/WebApiDevice#11
  

WICG/WebApiDevice#11 in particular seems to align with Mike's original question.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c6761cdc-aadb-ca8a-6dae-95a4f34f0043%40chromium.org.

[Sergii Bykov]

Hello Reilly, colleagues,

I replied to #11 in the thread and made a small pull request to the explainer (directory id promise can also resolve as undefined).

For #6 I will replace 'trusted' applications with 'managed' applications tomorrow.

But I'm trying to figure out what to do with the others.

#1 was addressed previously. There is a section "What are trusted applications" that explains it.

Is there something else I should specify?

For Jeffrey's question in #2:

"I think ChromeOS has decided to give the user notice when these APIs are enabled. Can you add example screenshots to the explainer, and possibly the specification, to illustrate that privacy solution?"

I checked the implementation in the chromium code and I don't see any triggers for a notification.
Current decision with the privacy team is that device attributes will only return valid results if called in a force installed app (including kiosk) and the origin is listed in DeviceAttributesAllowedForOrigins policy.

These are implementation details. Should I still add them to the explainer? As an impl example section?

Best,

Sergii

[Sergii Bykov]

Colleagues, I've addressed #6 earlier today too. 

Can you please recommend how to proceed with #2 (see prev email)?

Sergii

[Sangwhan Moon]

It would definitely help disambiguate the context a bit if that information is provided, but I also sense with policy-based installation and API access gating it does seem to beg the question of whether this can be considered a web platform feature.

I am guessing there isn't much appetite from other implementors either, since management isn't really a thing (maybe sans Edge).

Sangwhan

On Jul 27, 2023, at 21:23, 'Sergii Bykov' via blink-dev <blin...@chromium.org> wrote:



To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEBayj%2B%2BYTkmO5Jfqur_GHiXQTmRw3sKfStiQ4A1YWPLn1pCqw%40mail.gmail.com.

[Reilly Grant]

On Tue, Jul 25, 2023 at 11:57 AM Sergii Bykov <sby...@google.com> wrote:

Hello Reilly, colleagues,

I replied to #11 in the thread and made a small pull request to the explainer (directory id promise can also resolve as undefined).

There is still the unresolved question of whether these particular properties are too tightly coupled with the particular inventory management system Google has implemented for ChromeOS devices. Personally I think the descriptions of the 5 properties specified here are pretty generic but it would be good to see some indication of research to back that up and show that this could be implemented by multiple engines, or even in Chrome running on other desktop platforms.  

 

For #6 I will replace 'trusted' applications with 'managed' applications tomorrow.

But I'm trying to figure out what to do with the others.

#1 was addressed previously. There is a section "What are trusted applications" that explains it.

Is there something else I should specify?

I think the update to replace the ambiguous "trusted" with "managed" is sufficient here.

 

For Jeffrey's question in #2:

"I think ChromeOS has decided to give the user notice when these APIs are enabled. Can you add example screenshots to the explainer, and possibly the specification, to illustrate that privacy solution?"

I checked the implementation in the chromium code and I don't see any triggers for a notification.
Current decision with the privacy team is that device attributes will only return valid results if called in a force installed app (including kiosk) and the origin is listed in DeviceAttributesAllowedForOrigins policy.

These are implementation details. Should I still add them to the explainer? As an impl example section?

For an explainer this kind of non-normative example is useful to provide context, as in this case readers may not be familiar with what kinds of signals various platforms use to disclose that a device is managed. I thought that there would be a message like "This app is configured by your organization" in the three-dots menu on force-installed web apps.

[Sergii Bykov]

Hello colleagues,

As discussed, I added images to the explainer with examples from ChromeOS of how a managed app and a managed setting look like.

Sergii

[Chris Harrelson]

LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEBayj%2BzuTzfe%2B6ecn8hAWP%3D6jY0-b9-wdeATKneDit4SCQFUg%40mail.gmail.com.

[Daniel Bratell]

LGTM2

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_SCBxADg9SKC1BejVJdkinDcyTADh4yhF7ezC%2BkOdTKw%40mail.gmail.com.

[Yoav Weiss]

LGTM3

Please follow up on moving the entire namespace to be behind a managed permission (as Mozilla folks requested)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f42de963-0fbc-8480-186c-36f9347985ce%40gmail.com.