Intent to Prototype: Read Chrome device attributes

183 views
Skip to first unread message

Anqing Zhao

unread,
Nov 18, 2020, 3:24:02 PM11/18/20
to blin...@chromium.org

Contact emails

anq...@chromium.org

Explainer

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

Specification

None

Summary

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


Blink component

Blink

Motivation

It is a common requirement for operating systems to be able to provide applications with the highest degree of trust access to the highly-privileged data/functions. One of the popular requirements in the commercial systems is the ability for a highly-trusted application to access device-identification information(serial number, asset it). Some real use cases are as follows.

  • Virtual Desktop Infrastructure (VDI): an enterprise application launched on the client side needs to pull the device ID / serial number from the local device it is running on. Then the VDI provider can rely on this information to determine which user is using which device at any point in time.
  • Context-based configuration: an enterprise application needs to apply a specific configuration to a local device based on device attributes like location, asset ID. Then different users can have appropriate experience respectively.

Initial public proposal

https://github.com/WICG/proposals/issues/14

TAG review


TAG review status

Pending

Risks

Interoperability and Compatibility

TBD.

Gecko: No signal
WebKit: No signal
Web developers: No signals

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

Tracking bug

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

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5694001745231872

This intent message was generated by Chrome Platform Status.

--
Regards,
Anqing

Tom Jones

unread,
Nov 18, 2020, 4:13:25 PM11/18/20
to Anqing Zhao, blink-dev
This does not look good to me, and I hope the API owners agree.

There is a strong move for byod devices to give employers strong rights on a user's own phone in order to access company email. From what I gather from the explainer, this situation is not addressed. So if the user has given an employer admin rights, will the user be able to disable location data. If not, I believe this feature is in violation of employees' rights. So IHMO this should be rejected or at least the explainer should address the issue.

Peace ..tom


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

Jeffrey Yasskin

unread,
Nov 18, 2020, 5:45:14 PM11/18/20
to Tom Jones, Anqing Zhao, blink-dev
My impression is that this set of APIs will only be available where a device administrator has set up the same sort of device configuration that would allow them to run a native application at startup. Is that right Anqing? If this is enabled one origin at a time, and it's more scary to enable this for an origin than it is to install a native app, the overall idea seems ok to me. It also doesn't look like this gives access to the device's geolocation: the navigator.device.getAnnotatedLocation() function says it returns the "the administrator-annotated location", so probably just a direct copy from a string in the enterprise policy?

Anqing, it might be helpful if https://github.com/Ananubis/WebApiDevice/blob/master/Explainer.md showed rough screenshots of an end-to-end UI flow that a device administrator or owner could use to turn this on for an origin and set the values that it returns. We wouldn't want the eventual spec to _require_ any particular UI flow, but it'd be good to have it show examples of what we think is safe-enough.

It would probably also be good to be more precise than just "Device Web API" for describing this set of APIs. There's already a "Devices and Sensors" working group at the W3C (https://www.w3.org/das/) that covers a broader range of things. Might this be an "Enterprise Policy API"?

Jeffrey

Tom Jones

unread,
Nov 18, 2020, 6:31:58 PM11/18/20
to Jeffrey Yasskin, Anqing Zhao, blink-dev
The major issue I raised is whether this applies to byod. If not that should be made clear. If so, I think there is a problem.
Peace ..tom

Anqing Zhao

unread,
Feb 5, 2021, 5:31:59 PMFeb 5
to Tom Jones, Jeffrey Yasskin, blink-dev
Thanks for the feedback to this proposal!

Re Tom's concern:
  • This API will be available on the managed devices only. It won't take effect on the BYOD. I rephrased the first paragraph (What is this?) in the explainer to make this point clear as you suggested.
Re Jeffrey's comment:
  • Your understanding is correct. The annotated location is different from the device's actual geolocation. It is allowed by the device administrators and configured by device users. The main purpose is to let the web application provide different user experience according to this configuration. Some real user cases are listed in the Device Attribute paragraph of the explainer and the initial proposal thread.
  • We are preparing the UI design. Will add some related screenshots later.
  • There is another similar naming suggestion from another reviewer. Now the title of this proposal was changed to 'Managed Device Web API'. I am hesitating to use the name 'Enterprise Policy API' because it indicates a bigger scope than what I actually want to propose. There are hundreds of 'Enterprise Policies' being defined in the Chrome browser for various purposes, but they are not related to this web API.
--
Regards,
Anqing
Reply all
Reply to author
Forward
0 new messages