Intent to Experiment: Read Chrome device attributes

[Anqing Zhao]

Contact emails

anq...@chromium.org

Explainer

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

Specification

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

API spec

Yes

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

TAG review status

Pending

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: No signals

Goals for experimentation

Reason this experiment is being extended

Ongoing technical constraints

Debuggability

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

enable-restricted-web-apis

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

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

[Matt Menke]

Are wildcards supported in the list of origins this is enabled for?

[Anqing Zhao]

No. We want to support wildcards if the policy is a blocklist, but fully formed origins should be specified if the policy is an allowlist.

In this case, we are using an allowlist policy 'DeviceAttributesAllowedForOrigins', so wildcards won't be supported.

[Chris Harrelson]

Hi, one comment below.

Could you fill in the goals for experimentation?

 

Reason this experiment is being extended

Ongoing technical constraints

Debuggability

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

enable-restricted-web-apis

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

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

--
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/CAPmUGQQon78ML%3DMMoiQF0Kp5TJ2YORc5w1FB_AG3-KdswhFocA%40mail.gmail.com.

[Manuel Rego]

On Friday, 16 July 2021 at 15:39:36 UTC+2 Anqing Zhao wrote:

TAG review

https://github.com/w3ctag/design-reviews/issues/606

TAG review status

Pending

The TAG seems to be waiting for your answers on that issue. It'd be nice to provide some feedback about the status of things.

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: No signals

BTW, if we're planning to ship soon, it doesn't harm to fill requests for signals. See https://bit.ly/blink-signals & https://goo.gle/developer-signals.

Cheers,

  Rego

[Anqing Zhao]

Thanks Chris & Manuel. I have replied to the TAG, and filled in 'goals for experiments'. Let me copy-paste the goals here as well. Any suggestion or question is welcome :)

Experiment GoalsWe want to collect feedback for the new device attributes web APIs via this experiment. One main goal is to make sure the current API design and functionalities can fulfill web developers’ actual requirements, especially those enterprise developers who expressed interest in the ‘initial proposal’ thread (https://github.com/WICG/proposals/issues/14). In particular, we want to double check whether the current permission model / flow can meet enterprise security and privacy requirements, and integrate well with their products before shipping.

TBH, whether we are able to ship this API *soon* really depends on what (how many) feedbacks will be received during the origin-trial period. Yeah, many thanks for the links. Let me try to fill them both according to the guides :)

[Alex Russell]

That's a good justification. LGTM.

[Anqing Zhao]

Hello Phil,

This API is controlled by a permission policy 'DeviceAttributesAllowedForOrigins'. Finally it will be configured by Google Admin Console, but now it hasn't been ready. So you need to create a local policy file to overwrite it, then continue the testing. (See the detailed guide here.) In general, you need to create a /etc/opt/chrome/policies/managed/test_policy.json file in those dev-mode devices, and add allowed origins in it.

At the origin-trial stage, we don't encourage you to use this web API in your real production devices. And yes, you have to access the devices and manually configure the policy for the moment. When we finish the Google Admin Console changes, and don't receive any critical concerns from developers in next months, we will announce GA shipment for this API. Then, you will be able to configure the policy for all managed devices more easily.

The current plan is running the original trial until Feb 23, 2022.

On Sat, Sep 11, 2021 at 6:45 PM Phil Hodey <ph...@hodey.com> wrote:

Hi, We are about to start testing the API for a suite of kiosks being deployed to a chain of restaurants in the UK.

I am currently working remotely so do not have physical access to the Chrome OS devices we are testing on. I have registered the domain on Chrome Origin Trials but when I try to use the API on the test machines I get the following error...

The current origin cannot use this web API because it is not allowed by the DeviceAttributesAllowedForOrigins policy."

Do I need physical access to the devices to configure support for the new API?

[Phil Hodey]

Hi, We are about to start testing the API for a suite of kiosks being deployed to a chain of restaurants in the UK.

I am currently working remotely so do not have physical access to the Chrome OS devices we are testing on. I have registered the domain on Chrome Origin Trials but when I try to use the API on the test machines I get the following error...

The current origin cannot use this web API because it is not allowed by the DeviceAttributesAllowedForOrigins policy."

Do I need physical access to the devices to configure support for the new API?

On Thursday, 22 July 2021 at 23:36:12 UTC+1 sligh...@chromium.org wrote:

[Phil Hodey]

Thanks for this. I was not intending to use in a production environment at this stage but it is good to hear that this should be available next year.

I have registered on Chrome Origin Trials (https://developer.chrome.com/origintrials/#/view_trial/-7898187846501007359) as I thought this was the equivalent of setting the policy locally in the test_policy.json file but it seems like this is not the case. 

It may be some time before I can access the physical chrome devices to make the changes so sadly it looks like I will not be able to experiment with the new API.

[Anqing Zhao]

Hi Phil,

There is a small misunderstanding. Registering your origins in the OT Console has the same effect as enabling --enable-experimental-web-platform-features flag, but the permission policy 'DeviceAttributesAllowedForOrigins' is another requirement. So yes, you need to access your own physical devices at this moment to try this API until the policy is exposed on Google Admin Console.

I replied to a similar question with more explanation in this github issue page recently.