On Tue, Jul 25, 2023 at 11:57 AM Sergii Bykov <[email protected]> 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. > Best, > Sergii > > On Thu, Jul 20, 2023 at 7:56 PM Reilly Grant <[email protected]> wrote: > >> Sergii, thank you for adding some discussion of design alternatives in >> WICG/WebApiDevice#20 <https://github.com/WICG/WebApiDevice/pull/20>. >> Please also update the explainer to address the following issues: >> >> - WICG/WebApiDevice#1 <https://github.com/WICG/WebApiDevice/issues/1> >> - WICG/WebApiDevice#2 <https://github.com/WICG/WebApiDevice/issues/2> >> - WICG/WebApiDevice#6 <https://github.com/WICG/WebApiDevice/issues/6> >> - WICG/WebApiDevice#11 >> <https://github.com/WICG/WebApiDevice/issues/11> >> >> WICG/WebApiDevice#11 <https://github.com/WICG/WebApiDevice/issues/11> in >> particular seems to align with Mike's original question. >> Reilly Grant | Software Engineer | [email protected] | Google Chrome >> <https://www.google.com/chrome> >> >> >> On Wed, Jul 5, 2023 at 9:29 AM Mike Taylor <[email protected]> >> wrote: >> >>> On 7/4/23 5:35 AM, 'Sergii Bykov' via blink-dev wrote: >>> >>> Contact emails [email protected] >>> >>> 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 >>> <https://bugs.chromium.org/p/chromium/issues/list?q=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 >>> <https://github.com/mozilla/standards-positions/issues/815#issuecomment-1593801419>, >>> but it's not clear to me if it's being incorporated or not. >>> >>> >>> >>> *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 >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ? 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 >>> <https://chromestatus.com/>. >>> >>> -- >>> >>> Sergii Bykov >>> >>> Software Engineer >>> >>> [email protected] +49 174 2575015 <+49%20174%202575015> >>> >>> 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. >>> -- >>> 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/CAEBayjL7AyE-m7A90NxnKbsXUtqreD7GNH5qWSy4ydSpv3_4AQ%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEBayjL7AyE-m7A90NxnKbsXUtqreD7GNH5qWSy4ydSpv3_4AQ%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/c6761cdc-aadb-ca8a-6dae-95a4f34f0043%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c6761cdc-aadb-ca8a-6dae-95a4f34f0043%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/CAEmk%3DMbfFFzrVhtMd_t20CQfr8s%2BSo-JzLcLn1k_%3DTFoE_pi7g%40mail.gmail.com.
