I'm only an interested bystander, but I couldn't help but notice that many of the sections of your Security & Privacy self-review seemed very incomplete or incorrect, given what I know about the spec. For example, for question 6 ("What information from the underlying platform, e.g. configuration data, is exposed by this specification to an origin?"), you answered "No", but my understanding from the explainer was that one of the major goals of this work was to expose the device serial number and directory ID to web platforms. Is this correct?

Question 8 has similar issues—you said that no information is exposed cross-origin, but that's not what the question is asking. It's asking what information the proposed APIs would expose to any origin at all—i.e., any part of the Web. The response here makes me think that there may have been some miscommunication or confusion about the wording of the security and privacy questionnaire, and the answers may need to be fixed before the TAG could get any useful information out of your self-evaluation.

Additionally, reading through the explainer I had a hard time understanding how the spec proposed to implement the "trusted applications" mechanism. Since this spec clearly introduces the possibility for lot of potential security & privacy issues, I think it's really important to nail down exactly how you expect to authenticate and verify the integrity of "Trusted Applications". For example, one very obvious piece of low-hanging fruit is that this API should only be available in secure contexts, to prevent malicious code insertion by adversaries on the network. The explainer is very handwavy about the authentication mechanism here, and it references several concepts, like "applications", that don't make a ton of sense when applied to the web platform. Looking at the Chromium implementation diagram included in the repo, it seems like this means "access is scoped to installed PWAs with an origin that matches a list of origins defined by Enterprise policy", but since i'm not an expert in Chromium code, I'm still not sure if I interpreted the name "WebApp" correctly.

Finally, I couldn't help but notice that while this API appears to be very general, most of the supportive feedback in the WICG incubator thread comes from a set of cloud-managed kiosk companies with very specific needs. Have you considered narrowing the scope of the proposed API to something that would be much more targeted at this use-case? For example, the current spec exposes 4 different identifiers: the Directory ID, the Serial Number, the Annotated Asset ID, and the Annotated Asset Location. But after reading the desires in that thread from the kiosk companies, why not just expose 1 identifier that can be customized by the device administrator, rather than 4 different identifiers with unclear use-cases?

(How far does this set of 4 identifiers even map to non-Chrome systems anyway? They seem very specific to Chrome's existing enterprise interface. Are they even possible to generalize to other browsers? Are there any other browsers who currently have similar concepts, like Safari? Is there any other prior art you investigated that influenced your API design, beyond the existing Chrome API?)

Hi @nightpool,

Thanks for the exhaustive feedback!

We have updated our Security & Privacy self-review to more correctly indicate our proposal.

More specifically, on the questions #6 and #8 the answer is identical -- we are exposing managed configuration which is configured per app and global device-specfic attributes. On all the "untrusted" origins, the API calls will fail and will not expose anything.

The exact mechanism of determining which applications are "trustworthy" is based on the origin of the page. If the current origin belongs to the list of the trusted origins(for Chromium, this means that there is a force-installed Web App in that origin), the access to the trusted APIs shall be given.

Regarding the "authentication" mechanism: since we are scoping all applications by "origin", I do think that relying on HTTPS should be enough to reliably authenticate an app. If the force-installed app is hosted under another less secure protocol, this might be an issue. I think, we shouldn't enforce HTTPS, since some users may have applications hosted in the local network without a proper domai. We should allow such cases, but should alert the device administrator about that potential issue when they would try adding a non-https Web App.

Hello TAG reviewers!

The specification for the first part of the API(Managed Configuration) is out for review: https://github.com/WICG/WebApiDevice/pull/9 . The S&P questionnaire has been updated accordingly.

We are planning to send out the Intent to Ship very soon, please review Managed Configuration part of the API.

For us, the first part of this API(Managed Configuration) has a high priority and we would like to get feedback on it as soon as possible.

Thank you

Apologies this took so long, it was a pretty contentious issue so it took some time for us to figure out what we want to say. We feel this is a risky feature - the use cases we see in the explainer seem like this mainly is to uniquely identify devices. Couldn't this be enabled by pre-installing unique client certificates on the device?

There is the side note of certificates being possible to copy - so it's not as strong of a guarantee as a serial number.

What are the potential unethical use-cases that might come from this feature?

Hi @Ananubis just following up @cynthia's comment: I think we'd really like to see a lot more detail on the use cases / full use scenarios that this spec is intended to support. As you note in the explainer, this has been something that has previously been possible using a Chrome-specific API. However now you're proposing to bake this more fully into the web platform, which is raising some concerns both about how this could be misused in the wild by bad actors and how it could be harmful if used as intended. In particular, I'm concerned about how this could be used to make surveillance of employees easier to accomplish. That (possibly unintended) outcome would strongly echo the concerns laid about about pervasive monitoring in RFC7285: Pervasive Monitoring Is an Attack:

In particular, the term "attack", used technically, implies nothing about the motivation of the actor mounting the attack. The motivation for PM can range from non-targeted nation-state surveillance, to legal but privacy-unfriendly purposes by commercial enterprises, to illegal actions by criminals. The same techniques to achieve PM can be used regardless of motivation. Thus, we cannot defend against the most nefarious actors while allowing monitoring by other actors no matter how benevolent some might consider them to be, since the actions required of the attacker are indistinguishable from other attacks. The motivation for PM is, therefore, not relevant for how PM is mitigated in IETF protocols.

Hi @Ananubis. We haven't heard back from you so at this point we are planning to close this with an unsatisfied status if we don't hear anything by next week. In particular, we haven't seen anything that addresses the ethical issues we've raised.

Hi @cynthia, @torgo . Thank for your time to review this request and provide comments. Sorry for the late reply because we have a similar internal discussion with some privacy and secuirty experts.

Please note the precondition of using this API is managed device and trusted applications. It means that the device admins should understand these applications before they are allowed to be used by end users. In addition, we think that the management platform (like 'Google Admin Console' to Chrome OS devices) should provide a proper permission mechanism for admins to turn off these functionalities if they want.

Regarding 'Pervasive Monitoring': As mentioned above, the use of these APIs has several restrictions and the scope is always limited to a specific organization. This API cannot get the privacy-unfriendly data from unmanaged devices or regular device users.

Regarding use cases: Some examples are listed in the explainer and the initial proposal. Please feel free to let us know if you want more details.

Thanks for the update. Can you get back to us when you have concluded your internal discussions? And hopefully then share what you have concluded?

Hello @kenchris , we improved the draft specification with more description. Please check 'Permission control' & 'privacy consideration' paragraphs.

Basically, I fully understand that we should protect end users' privacy and avoid collecting device identifiers immorally when they are using web applications. But please note, in this case, the devices are NOT owned (managed) by end users, but device administrators. That's why these new web APIs are named as 'managed device web API' and have many restrictions to avoid they are abused.

I guess this is something new to the web world that 'device owners and end users are different groups'. I noticed that @jyasskin has already created two seperated issues for further discussion.

@torgo, thank you for drawing this to PING's attention by adding a privacy-tracker label.

As a reminder for the WG, when you're ready for a PING review, please follow the instructions at https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review

Thanks for the update. We discussed this again in our meetings this week.

NOTE: [RFC7258] treats pervasive monitoring as an attack, but it doesn’t apply to managed devices.

We don't think this is adequate. Given the power dynamics at play in an employer-employee relationship, the UA should still be working in the best interests of the end-user (the employee) even if the device being used is managed by an administrator. That is to say, pervasive monitoring is never a feature. Especially given this in the spec:

[device administrators] may not necessarily have the device user’s best interests

Further, we haven't seen an indication of implementation support from browsers other than Chrome.

As all of the attributes besides serial number are set by the administrator or some internal company system, we have yet to be convinced that the use cases can't be met by the device administrator keeping their own database of these attributes. They already know the serial numbers of the devices they issue to uniquely identify them. Also, the administrator explicitly decides which sites have access to the data. So why is the UA on the managed devices needed to communicate this data to sites? The administrator can do this directly.

We can't endorse adding this as a general mechanism to the Web platform.