LGTM1 On Fri, Aug 11, 2023 at 12:03 PM 'Sergii Bykov' via blink-dev < blink-dev@chromium.org> wrote:
> 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 > > > On Sat, Jul 29, 2023 at 1:39 AM Reilly Grant <reil...@chromium.org> wrote: > >> 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. >> >> >>> Best, >>> Sergii >>> >>> On Thu, Jul 20, 2023 at 7:56 PM Reilly Grant <reil...@chromium.org> >>> 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 | reil...@chromium.org | Google Chrome >>>> <https://www.google.com/chrome> >>>> >>>> >>>> On Wed, Jul 5, 2023 at 9:29 AM Mike Taylor <miketa...@chromium.org> >>>> wrote: >>>> >>>>> 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 >>>>> <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 >>>>> >>>>> sby...@google.com +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 blink-dev+unsubscr...@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 >>>>> <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 blink-dev+unsubscr...@chromium.org. >>>>> 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 blink-dev+unsubscr...@chromium.org. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEBayj%2BzuTzfe%2B6ecn8hAWP%3D6jY0-b9-wdeATKneDit4SCQFUg%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 blink-dev+unsubscr...@chromium.org. 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.
