Re: [w3ctag/design-reviews] Managed Device Web API (#606)

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 it may need to be fixed before the TAG could get any useful information out of the 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](https://github.com/WICG/proposals/issues/14) 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?)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/606#issuecomment-774606031