Sangwhan: contentious.. get serial number... for corporate things.. when it's not your computer. you list origins where this API is enabled and it's propagated down to the browser. Your enterprise administrator allows that.

Ken: internal sites. Can they go and do that for like youtube? why would they?

Sangwhan: nothing that blocks you, that's an implementation detail

Lea: what are the use cases?

Ken: IT managed laptops. We have specific sites that can do something. is it about limiting or enabling what sites are allowed to do?

Sangwhan: I've seen one case which has the software license portal and it gives the serial numbers that you're supposed to use for your installations. If you don't have access based on the serial number of your device it won't let you download it.

Hadley: would that have to happen in the browser?

Dan: they're moving all of their intranet applications to the browser

Sangwhan: alternative is as a native app

Hadley: that might be safer

Sangwhan: this is uncomfortable in many ways. Undefined aspect is centralized management - probably an implementation detail.

Dan: the people in adtech space are agitating for unique IDs for everyone.. what's to stop them taking advantage of this so that ...

Ken: knowing enterprise it would be opposite, they're never going to do that

Hadley: there are some abuse cases

Ken: I'm sure there are abuse cases

Sangwhan: another use case is the device is preauthenticated to automatically log into certain tools, no ID or password. Knows serial number or host name

Dan: feels like we should say this is not really the web... this is the enterprise software stack. Enterprise specific features for enterprise customers with special APIs can be shipped in Chrome, it's not the web

Hadley: I hear what you're saying.. a lot of it I'm not sure I'm okay with it. If they are fundamentally making changes to the UA and how other parts of the web are working w'eve got to have an opinion.

Amy: last time we talked about this we talked about if only Chrome ships it then it constrains what browser people in corporate settings can use

Sangwhan: either everyone implements this exact API that Chrome ships or we let it become a standard

Lea: interest from other browsers?

Sangwhan: pretty sure Mozilla would not

Ken: pretty sure Edge would

Hadley: MS target market..

Ken: if I want to do something at work I use my IT laptop and it says 'managed by your organisation' and there are a lot of settings you can't even change

Hadley: I wonder if we're in a minority, rebelling against enterprise control...

Sangwhan: should it be a standard?

Ken: is MS interested in this API? Same across edge and chrome makes sense. or do they have any concerns.

Dan: are there certain elements we would like to question? What is really necessary? A more webby approach?

Lea: I was missing a list of use cases for the particular bits of information. What use cases are enabled by returning the serial number? there is nothing in the explainer.

Sangwhan: there are ways to do similar things to the use cases they need for enterprise but I think it's for convenience

Lea: we need to know what problems they're solving

Hadley: it lists two but implies others, buried in detailed description [reads] .. what worries me about these is that they deliberately break the sandboxy nature of the user agent.

Sangwhan: not sure I buy the configuration, that's more convenience.. you could preinstall a client cert on the root of every device which would allow you to uniquely identify each device. There are different ways to do this. It's just more work.

Hadley: worth saying. Good alternate solution.

Sangwhan: same applies for personalisation..

[discussion of certs at OS / browser level]

Hadley: why does this need to go through the web?

Lea: what's the alternative? Don't we want web to compete with native?

Sangwhan: visualbasic.NET?

Amy: we don't want the web to compete on the field of creepy corporate spy-ware. That's not the future we want.

Dan: +1

Sangwhan: instead a fetch on localhost...

Ken: everyone does that at some point

Hadley: feels this really belongs in the OS and at the network level, and push it to IETF

Sangwhan: I don't have a solution

Lea: mixed feelings as well

Dan: resonate with not wanting web to compete on field of spyware.. when you're an employee and your machine is provisioned by taht company, and you oepn your web browser, you still have ane xpectation of privacy - visit your bank website, check on your dentist appointment, perform functions related to your daily life, use your computer during your offtime even if you're in a job where your time is managed.. you still have an expectation of privacy when it comes to use of the web. We need to be aware of that.

Ken: even today people install extensions on my IT laptop, on edge and firefox, that will monitor whatever site I visit, whatever I do, because there are web extensions APIs and I cannot remove them or turn them off. It's the same at other companies.

Dan: I would not be okay with that.

Ken: its unfortunately very common.

[dystopia discussion]

Dan: it might be the right thing to say why do you want to do that with the web

Sangwhan: I could ask.. the main thing seems to be to uniquely identify the device, solvable with client cert. Ask the reason they chose this design?

Hadley: sounds good. Add that it brings up some concerns if you want.

[discuss more at plenary

Dan: we asked for additional use cases, referenced pervasive monitoring is an attack rfc. Was an input for a joint TAG/IETF workshop from 2014 where amongs other things we had the call for moving more of the web to https. It's clear we can't give this a pass, we can't say it's fine to add to the web platform.

Amy: +1

Dan: and they haven't replied.

Sangwhan: the catch is it'll be implemented regardless

Dan: we can say they can code whatever but not into the web platform as a standard

Amy: anything they can say to make us say it's okay? Don't think so

Dan: if they're not going to engage for a whole month..

Ken: leave a comment asking for engagement?

Yves: do we want to make a statement? a longer thing? I think we all agree that the use case itself is dangerous

Sangwhan: has anyone seen intent to implement?

Ken: implemented.. flag you can turn on. In WICG repo. Chrome flag definitely implemented. Requires Chrome 90+

Dan: I could [write something, saying we'll close unsatisfied](https://github.com/w3ctag/design-reviews/issues/606#issuecomment-851925571

Amy: they've not responded to torgo's last comment, or addressed all of nightpool's points (but did address some, updated security and privacy)

Sangwhan: part of me thinks should not be on the web, part of me thinks it should...?

Amy: introducing friction to surveillence is not necessarily a bad thing (imo) .. I'd like to go through this in detail again and leave a nudge comment

Sangwhan: we should have group consensus about whether it should be part of the web or not, potentially close it off. It's contentious.

Amy: worth opening a specific issue in their repo about asking for documenting abuse cases?

Sangwhan: yep

Ken: they are discussing internally about security.... [writes comment to ask them to get back to us about that]

Amy: their response justifies it with a very narrow scope, but that scope seems to me to not have a place on the web platfor

Dan: leave amy's proposed feedback and close with an unsatisfied...

Hadley: good comment.

[general agreement]

Amy: [closes]

Amy: as i see it there's no reason for a web API here. Nothing that can't be done with existing device administrator tools. The user agent doesn't need to get involved.

Dan: we can be stronger than saying we can't endorse it being added to the web. We could say standardising this could be harmful to web users. We should definitely say it doesn't belong in the web platform or in standardisation. Fine if they want to build it into Chrome as a special thing.

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.

Dan: +1 the comment

Tess: works for me

Peter: +1

Rossen: fine to change Is to Wes

Dan: proposed closed for plenary?