Dan: third thing is about user agent and .. I had a post from chromium about relaunching the plan to deprecate some parts of the user agent string in favour of client hints, and wondering how does this .. what kind of information would you like from the TAG on this? How would you like us to review? How can we be helpful?

Mike: we announced we're ready to re-begin this process to reduce the user agent string, or the amount of information you can fingerprint from the UA string. We want to do this in a safe way, not our intent to break the web, UA strings are very tricky and sensitive to change. We propose an end step process, seven phases. Predicated on our ability to have an origin trial for sites to opt into and tes tproposed changes with a long period of feedback, at least 6 months, so we can discover what we're not thinking of. We've done testing, we think it's safe, but the internet is big and scary, based on this 6 month feedback period if we feel its safe to proceed we do.. first step is removing minor build patch numbers from chromium string and sending 000. It feels like a safe change and if you rely on that information you can get them from clients hints api. Then we aim to change desktop user agent string, then mobile. What you will reliably be able to get without caringa bout client hints is the name of the browser, the platform, major version, and the mobileness. We feel like that covers the majority of use cases for most web apps today. If you need something more nuanced like the device model of your phone for optimization you can request that through client hints. That's a broad overview of the plan. If you find that blog post you can follow a link to th echromium wiki and see all the ua strings at their various phases. What kind of feedback are we looking for? Should we be giving away the platform by default? Prtend everyone is on a windows device becuase its less fingerprinty, but it breaks too much of the web? Real accessibility use cases..

Dan: that information is still accessible via a client hint?

Mike: correct, get it on the next request

Yoav: information exposed by default and considered low entropy are not going to be reduced from the orignal ua string content that relies on the platform, ctrl+c vs cmd+c work even if they don't change their code to rely on the user agent client hints. that and the fact that platform is somehow still already expoed becuase of tcp level fingerprinting that won't go away.

Mike: the legacy part is also important to consider. You could upgrade your site to upgrade that platform information assuming you have a maintained site which is not true for a large part of the web.

Rossen: owe more time on the media feature ones, at least to convince ourselves that some concerns are a non issue. What else?

Dan: we're going to continue to work on this issue, on 604, and get feedback. It's the case that ua string is used for fingerprinting and its well known for years now that privacy focussed browsers are normalising the ua string including the platform. That's what Tor does. Very sympathetic to that. To what extent do small players, some of the use cases around content transcoding in africa for instance where they're using the ua string to identify .. how much are we taking into accoun those use cases? sounds like you are because you're going through this very cautious process and keeping a certain amount of the string, but has that been part of your thinking? how much have you been able to listen to the communityi?

Mike: for background, I spent the last 10 years wokring on web compatibility at mozilla and opera. "All sites must work." Very sensitive to this idea of not breaking the web for users of underdog browsers, or countries that are not 'silicon valley targets'. To the extent that we get feedback from web devs and other interested parties it's in our interest to take that seriously and try to design soultions for that. I expect that during this origin trial feedback period we may learn some uncomfortable facts that cause us to reconsider our plans. Not convinced we know all the answers yet. I'm hopful we can get to a place where passive fingerprinting thorugh the ua string is less fruitful. The client hint reliability effort - how to solve for that on the first request - would solve for use cases where an extra round trip is very expensive. Some evidence that we're trying to make this work for a lot of people.

Hadley: good to hear.

Yoav: also on the feedback front - point of feedback that already changed what's exposed by default is the platform. Mobile vs non mobile.. for the africa use case that was the first case that convinced me that that extra bit of entropy [??] expose by default in order to address the low-bandwidth networks / content adaptation case, I don't now the %, but a large portion, exposing device model by default exposes a ton of entropy. So the calculus there doesn't make sense. But client hints reliability will make it easier for folks to get that on that request. And hosting providers can get that out of the gate without requirng people to create custom server side logic for them

Dan: great to hear. Anything else we can help with right now? What's the time sensitivity of us getting back to you? Other design reviews pending that you're waiting on?

Mike: in the next week or so would help convince some of the blink api owners to be comfortable. Next two weeks is still fantastic..

User Preference Media Features Client Hints Headers - @torgo, @atanassov

Trust Token API - @hober, @torgo, @hadleybeeman, @plinss

Hadley: we left this pending editor update and we have not heard [nudges]

Realms API ECMAScript Proposal - @hober, @kenchris

Peter: tess and ken, but neither are here. [deferred]. The question is the boundary between realms. Dominic has been pushing to make it a callable boundary, that blocked a whole lot of use cases but it looks like that is moving forwad. There's a way, a shim library, which lets you fake sharing objects between realms by wrapping everything in callables. Looks like that's the approach going forward. Not sure that hard decisions were made.

Rossen: what was blocked?

Peter: if you want to ahve an object that is shared between parent and realm; have an object returend by a server along with some js that can manipulate that object but nothing else. Can change internal sate of that object but not access to the dom or navigator state. That's not easily done directly with a callable boundary. This other library they've developed lets you syntehsize something that has callable boundaries that can be passed back and forth between realms. Think we're okay, just a performance question at that point. I think dominic has concerns that without that restriction you don't get some of the security guarantees that people think realms gives you.

Digital Goods API - @hober, @hadleybeeman

Hadley: also waiting for a response [nudged]

Screen Fold API - @torgo, @plinss, @atanassov

Dan: Screen fold renamed device posture. Hasn't been that many updates. Maybe we want to ping the editors and see if there are additional updates since the issue was raised.

Rossen: i pinged them just now

WebID - @hober, @rhiaro, @hadleybeeman, @atanassov

Amy: there was a workshop that Tess attended

Hadley: we got stalled because I asked Sam for use cases. The explainer was talking about improving privacy and security and creating federated ID but not explaining what he wanted to solve. I asked and he came back with the same general words, some examples that explains ome of the problems with the ID ecosystem which are raelly interesting - too many ways of logging into something, the ossification problem that the web hasn't evolved its ID technologoies. I don't see any problems with what he's erecommending, but I'm still not clear what happens if what we're trying to do here is to make it possible to operate with 3p cookies, what happens after you log in and how that's different

Amy: Sounds like a good summary. The core is that they're not coming up with soultions yet - just exploring the problem. They are creating a CG. Maybe there is not much more we can do. Good for us to keep an eye on it. If there's a CG with broader participation that is good.

Hadley: Agreed.

Yves: can investigate the webID CG

Hadley: not really something to review... I think we can give Sam the feedback that what they are exploring makes sense and we support a CG... we'd like to see designs as group comes up with them...

Amy: I'd be "happy" to join the CG.

Dan: I have questions related to the use cases - my question in the session that we held was what cases are you really going after. THey talk a lot about federated identity, but you can still do it... they need to be specific. They know that but have a lot of discussion about cases around federated identity but they're not addressing "and these are the things that cannot be done without 3p cookies"

Amy: other things as well to get ahead of further changes after 3p cookies go away - documented in our minutes from our special session.

Dan: +

Dan: Multi-browser?

Tess: webkit did an experiment - have they addressed the issues?

Tess: one of the enginess proposing to standardize something that is happening - what the standardization change?

Dan: UA string not specified anywhere to begin with

Tess: maybe Fetch should specify it?

Dan: Mozilla position "not harmful."

Dan: they've listed some feedback from Safari's UA string freeze.

Rossen: not ready to close on this, I think we have other open discussions..

Peter: we don't have Tess or Dan, we have feedback

Dan: some resent comments from mike tayor addressing our questions...

Dan: cross-browser discussions important... should we try to help make them happen?

Tess: I think they are happening -- i feel there are good discussions on the open issues... good engagement... one remaining open issue from webkit folks: https://github.com/WICG/ua-client-hints/issues/151

Dan: which leads to - considering we've already fed back positivel on CH - maybe we should close this with a positive review and encourage them to documet all their findings as they progressively freeze out parts of the UA...

Tess: I'd like to say something about the remaining open issue... it would be nice if they resolved it.

Draft closing comment:

'We're largely positive on the approach that is outlined here. We've already positively reviewed client hints. We appreciate the time and effort being spent on trying to ensure a cross-browser solution and also on mitigating against ecosystem issues (breaking existing web content). The privacy benefits of this approach seem clear. We hope that you resolve issue 151 in a way that improves the multi-vendor consensus around this feature. We'd also encourage you to engage with the Privacy Interest Group to get their views. However we are happy to close this review as satisfactory.'

[NB based on further discussion in plenary we decided not to post this.

Dan: Mike Taylor responded 11 days ago to the feedback.. we've had discussions.. I don't see how Mike is addressing the issues raised by Henri. A key issue is about the severity of the issue they're trying to solve.. Henri is saying have you structured.. Mike is saying the UA has been misparsed or all mobile browsers have similar UA strings.. there are a lot of ways that websites misinterpret and send the wrong content because they misinterpret the users intent. The UA string plays a role in many but not all of those. I just saw a tweet from Terence Eden talking about how his portrait orientation monitor means that on some websites he gets a big notice on this monitor saying we don't have a mobile version of this site becuase they assume that if the viewport is portrait it must be mobile. I'ts an example of misunderstanding.

Peter: parsing UA strings has always been hot flaming garbage.[+1 dka] Mainly because all of them lie. Every UA is claiming to be Mozilla. As soon as sites it get it wrong the clients lie about who they are. Standardising what the UA is and doin git in a structured way that parsers are not going to misinterpret is good.

Dan: if we could get consensus on that point it'd be useful to feedback into this arguement. The rest of Henri's argument is this thing you want to make a client hint for isn't very useful and will decrease user privacy. That's an argument that needs to happen at some level, but not sure we need to get into the weeds on which thing eeds to be in the client hints vs not. Feeding that back that it would be a good thing to have more structure, and this is a good proposal for that structure, would be a positive. But I don't know. Good to talk about at plenary?

Peter: I have concerns that.. I accept that client hints break out the aspects, instead of sniffing and deciding i must be mobile because you're in portrait mode I can see you're mobile becuase you're mobile and not make these assumptions. How long is it going to be before someone is incented to lie about this too? Then this will degrade the same way as the UA string. To the extent that this is welld esigned and the dimension sthat you care about are isolated there may not be a need to lie, I hope.

Dan: another point we could ask Mike - why does Mike think that restructuring the UA in this way will incentivise people to lie less? Structurally, is it less incentive for them to lie?

Peter: there's maybe not a good reason to lie about are you mobile or not. They're still giving away I'm version x of safari and if someone makes a presumption based on that because they're doing a bug fix and they didn't check the version, and safari fixed the bug but sites are still working around it, then devices are incentivised to lie about itself. Browsers lie becuase websites make assumptions. Almost every engine claims to be almost every other engine somewhere in its UA string and is doing it to fool a website that has tailored code against their engine that they're trying to avoid.

Dan: asking that in the comment

Dan: good discussion here.. I asked about UAs telling the truth more often.. [reads response]

Rossen: is your point that you want to reduce the amount of UA impersonation?

Dan: mike talks about a "hot mess" - what's that about? isn't it the lying? There's so much nonsense in the UA string

Tess: still going to be lying in the new stuff

Rossen: a lot of times we had to impersonate other UAs just so you can get the content. Sometimes you have to pretend you're a different version of yourself because there's content targeted to a version. Content matching is defintely something needed going forward

Dan: I'm wondering if the lying that happens now, the targeting towards specific user agents or versions, is encouraged by the current UA system we have and if there is this additional roundtrip required with client hints would it intrinsically discourage that approach? Would it make i tmore likely we'd see more adoption of feature detection and other things against this trend of ua sniffing?

Ken: some is for analytics

Rossen: if you took your example to the extreme and there are no ua strings at all, everything is done through client hints and feature discoverability, that is the utopia? That way you have various user agents with variosu capabilities and they get the content based on these capabilities. Today for better or worse a lot of these capabilities are discovered through the UA string. That is just yet another capability descriptor, on a macro level. From that point of view I don't think that ua hints add or remove any of the complexity about discoverability, referred to here as 'lying'. The question you probably want to asnwer is if we wanted to have this what is the path forward, is client hints the path forward, to ultimately drop ua string?

Dan: even the proposal on the table doesn't drop the ua string entirely, it simplifies ua string and puts stuff in client hints. To engage with the feedback, part of it was that there are things that are being put into t he clien thints which are additional entropy which are not really needed from a fingerprinting perspective add problems. that's a different issue. That's what's being discussed between henri and mike. I think mike has addressed the issue that I raised.

Rossen: good conversation after it

Dan: trying to figure out how best we can engage

Rossen: conversation is still alive. Maybe best path is to let it play out for longer?

Peter: was there a client hint about what level of js is supported?

Rossen: there could still be new client hints..

Peter: one of the primary use cases for client sniffing is js detection [leaves comment]

Dan: good point about that being one of the core reasons for ua sniffing. Also interesting from an analytics perspective. Important for a minority browser. If every browser masquerades it really doesn't help browser diversity

Tess: in the case of Tor it's a minority browser that really does want to look like every other.

Dan: when you're an effort working in a company and you need to justify the existance of that thing, it's important. Different from Tor. [leaves comment]

Dan: note still in progress - i took an action to get a meeting with mike taylor and henri.

Mike: update on what's happened since we last chatted - we have yesterday published an update on the user agent reduction timeline. Before it was an abstract plan, now there are milestones associated with the changes (Chromium milestones). We still plan to give the ecosystem plenty of time to test. An origin trial starts next week and runs for 6 months. Sites can opt in to our vision and give us feedback and let us know - hey this breaks the web, we're doing it wrong, we'll evauate that feedback. That's the UA reduction bit, I think that's less controversial, I understand mozilla is positive onthat set of changes, but can't speak for them. In terms of user agent client hints, we've ladned a few changes since some of the feedback we recieved. Henri in particular had feedback it would be impossible to represent the real gecko version in addition to if they had to spoof as some other browser. We landed a new hint last week called the full version list hint. This is in response to feedback we received from edge team, as chromium embedders that the original design was too tightly bound to Chrome thinking.

Dan: one of the things I'm keen to hear about is the feedback on the use of client hints separate from the feedback on client hints themselves. I'm curious to know what if any is the feedback on this proposal stemming from a general antipathy towards client hints, or is there a middle ground of the use of client hints for some metadata that we could stake out a consensus view on. I may be jumping ahead of the discussion but that's a thought I had. Get under the skin of the feedback and whether or not we can drive some good discussion for consensus.

Mike: Full version list client hint allows a browser to send multiple version, eg. gecko could send a gecko version adn a chromium version if it was compatible with that set of features. Embedder like Edge which operates on different versioning schemes could do so.

Henri: the main issues are is this shuffling stuff around, can we not do the reduction in the old place and then how wasteful is this in terms of adding headers even though header comprehension exists.. added stuff to everything.. what if this catches on just enough that some sites use it but most don't, okay it didn't work out but some sites got stuck with it. How difficult is it to take a step back? One of the concerns that we had that seems now resolved that makes the objection less strong than it was is the thought that this would expose stuff that wasn't currently exposed or was otherwise going away. So that if actually it is so that this doesn't expose things that weren't previously like the specific patch level of the engine or the OS or the model of the mobile device, if that's the case, then obviously that objection isn't strong and is a misunderstanding.

Mike: Martin Thomson filed a really nice issue on github - I'll try to address that in the next week or two - to clarify we do not intend user agent client hints to be a honeypot for additional entropy or information that's not currently available. Privacy is the primary goal here. For user agents that do not currently expose some information, firefox historically has not epoxed device model, the spec will not require that they start doing that. I'll go in and try to make that extra clear. I'm happy to hear that we're aligned on that.

Henri: the issue of to what extent less structure is a bug. Clearly it is a bug in the sense that there is a long history of user agent detection going wrong because of the non structured ness of this data. But then to what extent it's a feature, all the browsers that have claimed that put the name of the previous market leader at the time of their launch in their UA string, IE did this, safari did this, chrome did this.. so clearly there is this use case of making things sniff both ways at the same time, so IE sniffs as mozilla, webkit sniffs as gecko, chrome sniffs as safari, especially the ua full version didn't have this kind of having it both ways and opened the question of if the ua full version is going to happen does it mean that it's just a complicated calendar that's based on chrome's release cycle, instead of saying a year and a month you map it to chrome's release calendar and go from there?

Mike: yeah we built a really complicated calendar, unintentially. We took that feedback about UA full version and recognised that this is not great. We updated the spec with the idea of a version list. We could represent your full version which should be different from chrome's but you could also send a chrome version for a certain site that was doing bad things the idea that you mentioned about the lack of structure being a feature not a bug we've tried to design with that princople in mind. We have this notino of a brands list, you don' thave to say hey I'm chrome. Currently al ot of browsers have user agent spoofing mechanisms, for certain sites they'll say I'm the more tested browser so the idea of this brands list and the version list is you can say I'm chrome and also firefox .. I support the same things that this other mor ewell tested browser supports so you shouldn't block me from your website.

Dan: from a perspective of the Samsung minority browser, we run into the issue of where ua sniffing locks us out because somebody goes to a website using samsung internet, it works completely fine, but they see samsung and they say you must use chrome. How does this proposal address that case?

Mike: this concept of a brands list, where you have a brand which is defined as your marketing version name - samsung, chrome. You also have these equivalency classes. You can stick as much or as little in yoru blrands list as youw ant. You might want to say I'm samsung and I'm chromium. that's true. We want to encourage sites to feature detect and care about capabilities and not strings, but in the case where they make some misguided decision where they say we require these apis that are only spuported in chromium, if samsung is presentin gits brands list as samsung and chromium and the site is looking for chromium that sholud be a better outcome. Developers are clever so they may do different weird things. But that's the intent. There's this notion of ?? in the brands list, sticking this nonsense string in there to prevent sites from hardcoding a serialised list. If you do that yo'ull fail, it changes from version to version. TO encourage people to make smart choices and not do the old style exact match ua sniffing.

Peter: from the positon of why do people sniff ua strings and one of the more common use cases is detecting what level of js so we know what version of compiled script files to send. Struck me as odd that wasn't called out in the client hints. If we're reducing ua strings the fact you can no longer get that behaviour, seems like a common use case we want to support

Yoav: I think people will still be able.. because th elevel of js support is something tha tis dependant in the broader brand and singficant version that is somethig npeople will be able to do. Ideally we would provide an alternative mechanism for them to do that. There has been a long discussion on the html issue regarding what such a mechanism may look like. there is not a lot of consensus around what we can expose and how we can claim that js support. Theoretically we could say ES18 is suported and that means something. But it's hard to get everyone to agreeon what that something would be. So i'm hopeful we'll be able to do that but this is not part of user agent client hints right now. Or in general we also talked about declarative mechanisms to do teh same thing as an attribute on script tag which would have been useful but thep roblem is defining what the thing is rather than the deliver mechanism. Once we have defined a way to do that negotiation it can be either on the client side or on the server side using client hints

Peter: wanted to make sure it's part of the pipeline. Detecting brand or engine is fragile. What happens with a new brand comes out?

Yoav: agree

Henri: one point: the documents didn't motivate - multiple headers on http caching... some edge caching concerns... to what extent is it considered - instead of browsers adding new headers - add response headers - caches adding new features to be able to vary on contents of ua string ... mobile header is a boolean - looking for mobi substring - browsers wouldn't have to send that on every request if there was a cache feature - this cache entry is for ui hearder that doesn't contain mobi, this one is...

Yoav: multiple proposals in http working group for creating a better vary - key header was a proposal and died. Now variations proposal. Generally modify how caches work is hard - and caches don't update as often. I understand it - there could be potential for better variance mechanisms - but likelylook for deployment is not high...

Henri: "lets add this stuff ot every request in browsers because this other software over here won't update" isn't that great

Yoav: not the only motivation, but.. I think we can talk about the actual cost. It's a non zero cost is true even with h2 and h3 header compression but becuase they are static request headers the cost for the first request is the full length of the header but for follow up requests, long lived collections, the cost per request is in theorder of a few bytes. Would you agree?

Henri: I havent measured it. That seems plausible in the presnce of cross request header compression.

Yoav: from that angle the extra cost doesnt' really .. assuming the headers are used the extra cost is not high. Even when they are not used they are not likely to be the extra bytes that throw the request above the threshold of an mtu and move it to the next ?? beyond the current conditon window. I suspect that event hough you're right an dthe cost is nonzero it is very close to zero in real life at least for h2 compression scenarious

Henri: since there is now a proposal for requesting these opting in on the tls layer what are the implications ... that on its own feels very complicated, should we back down if it gets this complicated? but if that complication is going to be there do these headers still need to be sent by default as opposed to the default set being empty and having to opt into each and everyone on on the tls layer

Mike: the complication is real. There's two modes to do this, we call this client hints reliability. oneis not complicated, there's a http header call critical ch - pass client hints tokens as you would accept-ch. Doesn't require any special backend knowledge, just http. If you can use client hints you can use critical-ch today. The accept_ch tls frame bits is more complex but it's no more complex than deploying h2 if you're already sending ?? strings we're effectively doing the ame thing there. Kind of a choose your own adventure - opt into a as much complexity as you need depending on your use case. Not a requried path for average web developer or ecommerce site or whatheveyou. Second part about the headers default headers?

Henri: shold the default set be empty so anyone who wants to have them in the as soon as they appear in the current default scenario that anyoen who needs them on the first request would negotiate them on the tls handshake?

Yoav: the decision from my perspective to make those headers on my default rather than off by default like all the other client hints was that they covered a good chunk of todya's use cases and therefor it seemed reasonable to continue to expose them byd efautl without requiring folks to go to the length of making sure they're tls stack supports the accept_ch frame. Also in terms of order accept_ch was added later. It's still not necessarily as easy to deploy as we would like. It's a new feature taht requires support from the tls stack. It's a new frame for h2 and h3 but it requires some tls support for th eunderlying mechanism to deliver those frames. At least for the basic case of people using passive entropy that we send by efault ain the ua string it seemed reasonable to cover most of those cases mainly bug workarounds that are based on browser version, mobile adaptation based on the mobileness bit or mobi string so people can serve a desktop site and a mobile site even though that's also not a practice i'm a fan of but this is how the web works today. The recent addition for platform which mike can speak more on the motiation behind that, but the justification for why it's okay to expose it is it's already sniffable. The entropy is already exposed through the tcp stack in many cases. there were use cases for that as well.

Henri: the reason for not to do that was considering entropy rather than considering do we want to send these bytes along

Mike: it's a privacy plus compatibility motivation. We're ranking those ahead of network cost. not saying one is not important but that's the primary thinking.

Dan: something yoav said about the mobi-ness bit - if responsive design is something we want to push people towards becuase its more inclusive and can make a better web for everybody should we b adding features to the platform that help people reinforce this bad practice of having a mobile site insteda of using the tools of responsive design? Trying to think, there are a lot of other reviews we've done of new tech wehre the somebody says we're just trying to replicate something that's happening on native and that feels almost similar. Wait a second, we're supposed to be having a higher quality bar for new things coming onto the web. i take your point about not breaking things that are working a certain way but is there a way to design this feature that could encourage, to make it more dificult.. wouldn't it be better ot add an extra step forr people who want to kno wwhether it's mobile or not vs just using the tools of responsive design to begin with?

Mike: good question. My natural thinking here is.. I don't have a great answer. One of the arguements we're making with this api is an improvement over ua parsing which is fragile. if we apply structure to whatever signal the ua string is providng that feels like an ergonmics win for developers. But I hear you is that a carrot we should be providing? If it didn't exist would people stick to the old methods that are hostile to new mobile browsers, etc? Even though in a perfect world we all just do responsive design

Henri: this goes to the core of client hints in general. If we consider a client hint for the viewport width vs media queries. In netscape 4, maybe earlier, pre gecko, there was a time when if you resized the window in netscape under certain conditions would cause a reload. With media queries all th einformation is on the clientside so if you hav ea mobile device and you rotate it the width media query matches and after you rotate it it adapts on th device instead of reloading. If you hav eaclient hint on the http layer that declares viewport width is this, then you rotate the device, do you go back to the pre gecko days of that causing a reload? or you have the request what they were before you rotated it and now you do whatever the css says within the constraints of what the requests were. If you want th efull adaptation you need to reload. The act of resizing or rotating a mobile device causing a reload is very clearly a step back. That's my general concern with client hints the original set and I think this quesiton that Dan asked is pretty much on the same theme in terms of okay there are people who ant to do this adaptation on the server but we have this stuf fin css and so forth that does it on th eclien tand it's better. But they still want to do this other thing, so do we do more specific and granualr tools to do the sort of thing, or do we tell them no you're doing it wrong and use this thing that's conceptually on the other side

Dan: my initial uesion was not about shoul dthe information be available at all, but rather should it be available by default? by making there be an extra step in order to understand that bit of information might that nudge more content to be built along responsive design means?

Yoav: Changing the way that the web is built today is not trivial. Client hints gives us a way to do that in steps in a way. Yes we can expose the mobile bit today but a few years down the road make it an opt in rather than being exposed by default, or add some cost to it. I don't know. at the same time there are also.. initially we weren't planning on exposing it by default and there were a lot of use cases and people crying otu saying that this is how they serve their site and otherwise they will just have serve bloated sites to people in developing countries and that would result in an adverse effect. there's a complex tradeoff here

Dan: there's reality vs theoretical purity..

Dan: it was good to hear Henri some of the objections seem to have been addressed or .. I'm tryign to think about this from the perspective of our review. One thing we try to focus on that we have a strong TAGvalue statement about multiple implementations. When we're reviewing something and we all are nodding our heads there oculd be a group think going on and if we then see a negative review coming from an implementer or we see signals that one implementer is interested but others aren't interested or actively think it's harmful then that's a signal that plays into our review. It's important that we're not fragmenting the web by making more code paths necessary becuase certan thing work with certain browsers, there's already too much of that. I'm interested to know is there a core of this proposal that mozilla would consider implementing?

Henri: I can't make a statement of that kind

Mike: go back and chat with your standards leaders. Marcos had a suggestion in the thread - based on the current reading it's confusing that it's harmful... path forward.. acrobatics.. an http ua ch and a js ua ch... mozilla has interestin the js side of things

Henri: considering that the navigator objects fields are already more structured than the ua string itself what do you see as the main benefit of a new js api compared to the current level of structuredness of navigator.oscpu or navigator. anything else?

Mike: really not that much structure.. user agent echoing http.. oscup which is gecko only.. navigator platform.. some notion of architecture.. appinfo.. you have if you squint structure. You still have to parse these strings and subset them and try to do clever things due to that. So structure is one of the most important arguments there. Right now the firefox people are doing experiments what happens when we hit version 100. We're starting to think about this as well. one of the bugs filed was osmeone was doing an index of and math to know which version and which codepath to take. that stuff goes away if you have clean interfaces to get at platform os etc. The other argument which i know mozilla was in favour of.. martin talked about, the standards position talked about, when you've go tthese active interfaces on the clientside the os can audit them. You can see the callers knwo the origins, something could hook nicely into enhanced trakcing protection. Strict mode doesn't get any ofthis stuff, standard mode gets low entryopy stuff. hard to do when navigator.useragent has a big old string.. you odn't know what folks are asking for and what they're trying to do. in terms of user control you can do interesting product things through this type of api

Henri: navigator.stuff is not strucutred in the right way?

Mike: you could say that.. it's a "hot mess" is how you'd say that in Texas. One of the nice things about the api that sits on top of navigator, you have this get high entroy pmethod.. we split up between low entropy and high entropy, we claim mobileness platform signficant version is low entropy, other stuff like cpu or device model .. if you're trying to provide an optimised download experience or work around a bug, you need to request that, it's an async interface, th eua can make different decisions, browsers can have differne tpolicies, you can reject it based on user choice or ua policy

Henri: is it web compatible every to reject tha tpromise as opposed to always accept it and make the apis return lies?

Mike: I'm bad at predicting the future. i would hope it's web compatible. Ithink if you have the most tested browser ships one behaviour and its the only browser that ships it for 10 years it's sailed.. if we have multiple implementations with differnet opinions developers need to make better choices. If a browser like safari has something like itp has something liek a browse rlike firefox which has something like etp or chrome which has privacy budget.. there is a possible future where developers ar etrained to get this right. Realistically though like you're saying history has not always been kind ot us and browsers have to lie.

Dan: what do we expect very privacy focussed browsers to do with this technology? is the expectation that they would 'lie'? If you're Tor you want to advertise that everybody using yoru browser is using window,s firefox, that they have this completely generic advertisement of what they are so it makes it more difficult ofr peopel tp rofile and fingerprint the users. Is that something that's allowed for?

Mike: yeah. It's allowed, you should be able to do that. the Spec explicitly carves out.. I'l try to make this more clear, but today it talks about the empty string is always a valid answer and you're allowed to return other values. Some browsers would want to lie, hide in the crowd, give as little entropy as you can. Firefox has a resist fingerprinting mode that does somethign similar. there's nothing in the spec that requires you if you wanted to pass all the tests to give away something you don't believe should be given away.

Dan: this has been a good discussion, teased out helpful stuff.. I'd love to hear more about if and how anything today changes the official mozilla standards position on this? that would deifnitely be useful to know for the purposes of resolving our review. What would you like to see TAG do next? Our default would be to continue to monitor this issue and see if consensus starts to emerge we can say it looks like things are moving and close it.. but if there continue to be major disagreements there's a role for TAG to play in trying to mediate that discussion.

Mike: sounds good. We have some feedback from mozilla that I need to address in the spec, especially around privacy and entropy. Once I do that maybe I might open a new standards position issue and say we think this should be considered?

Henri: probably better to open a new one and refer to the old one, so that whenever there's a change there is an issue for that, but point people subscribed to the old one to the new one.

Mike: I'll ask mozilla.. and we'll take it from there. I'd love to know Apple's opinions. (And then I'll ping the TAG thread with the new issue, so everyone can be aware.)

Dan: we won't take any action at this point but it's clearer where we're at.

Dan: Some updates from September.. no update recently. Looks like there's work ongoing.

Rossen: we discussed UA client hints..

Dan: mozilla said it was harmful, authored by henri, so we got them on a call, sounded like some softening of mozilla's position but I haven't seen.. but good discussion between them. I don't know what has happened since then.

Ken: do they want to ship this in the next version?

Dan: mozilla has changed their position to be non-harmful

Ken: in the next version of chrome they have something.. a subset that is going to ship?

Dan: I'll write a comment asking for more info.

Peter: concerns about proliferation of headers, and js versioning. Looks like they're working on it.

Dan: we were on the verge of closing it.. then we got some comments. Mozilla's position shifted, and it will be shipping. Response that they took feedback into account. Does not require browser to expose more entropy. Then a long comment from Jo Rabin of 51degrees, kind of rehashing a lot of the issues raised on the initial thread on 'the previous issue](https://github.com/w3ctag/design-reviews/issues/467) about the first announcement of this.. These have been addressed as far as I'm concerned. But Jo is pointing out this is not really being standardised at ietf or w3c, just sitting in wicg. Recent comment about "market is not ready", "wholesale disruption", "significant disfunction". I think Mike Taylor thinks they have addressed these concerns.

Yves: we just have to figure out if it's a sound proposal or not

Dan: There may be a reasonable request here, but not sure if it's for the TAG. I want to ask Mike to address the issues Jo has raised.

Tess: that sounds good. We should do a bit more than pass the buck to Mike. Things already addressed - maybe we could add a comment that calls out some of those things and point to PRs/etc? And ask Mike to answer others.

Dan: where did Mike point us to when they were talking about response to community feedback? We got Mike on a call and he presented this... Not the things in response to the Mozilla comments, but in response to previous 51degrees feedback. Around the how partial is partial issue. How much of the UA string would remain.

Tess: conversation on #467..

Dan: the call where Mike talked to us about this..

Hi Jo - Regarding some of the issues you raised I believe Mike and Yoav believe that these have been addressed - see the
[minutes of our call on 14-Jun from last year](https://github.com/w3ctag/meetings/blob/gh-pages/2021/telcons/06-14-minutes.md#ua-cleint-hints).  
@Yoav can you provide any further detail or comment here?

Dan: we'll keep it in play for this week

Hadley: we have enough evidence in EWP - Priority of consti.. etc... to defend [closing].

Dan: 51degrees think this is a major change that hasn't been thought out enough. One is compatibility with existing content and software layers. In June with Mike Taylor and Henri and Yoav we queried this, they said they've beenr esponsive to community feedback on this point, and the current proposal was to leave enough of the UA intact that it wuld not have this kind of impact, especially on software layers. Talking about in some countries, especially African countries as an example, are making a lot of use of transcoding platforms that make use of UA string information. Mike and Yoav think they have addressed this issue. Jo also brought up where is this being standardised? The UA client hints spec itself is in wicg. There hasn't really been any official trajectory beyond wicg. They think it's going to go somewhere in w3c. I think that's a completely valid concern. It's pretty major and it's just being incubated in wicg. Slightly mitigated by the fact we did have these discussions with the mozilla folks, they do seem to be moving on their position. From a multistakeholder perspective, I think it's a little bit better. However it still really should be moving to a proper standards group. I don't think they have a good answer to that yet. On the issue of compatibility... Mike Taylor left a response and noted.. second part of the issue, that the underlying client hints spec, is in ietf, but marked as experimental. After checking, I don't think that's an issue. Consensus around the underlying client hints mechanism itself. Cnsensus is not around where it should be applied. We've been vocal in the past about hwere it should not be applied. My proposal is to close with satisfied with concerns:

• we want the proposers to make sure they're taking into account the wealth of existing content out there and be receptive to the community feedback about content breaking;
• they should be moving the client hints UA spec, actively, into a w3c WG.

Yves: by freezing the UA string it removes concern about cacheability and certain content negotiation based on the UA string. I'm pretty sure they'll keep it for a while for compatiility purposes. I odn't think 3 is really an issue. Issue is nly implementation is chrome. Needs to be accepted as a standard somewhere and implemented before being widely used. Also a way to do some discovery mechanism, the UA string, need to ensure all the discoverability capabilities exist. If the other UAs are not implementing that, what are they implementing for discoverability of capabilities?

Peter: the client hints are supposed to expose what is in the UA. It's been around for a while but it's a mess, lots of things have been built on it that shouldn't. Some extent of sniffing still needs to be around. Needed more in old days becuase of the lack of interop. Situation is a lot better these days. Do share your concern Dan about where this is going to go. Wondering where all the other client hint specs are winding up, there's a bunch.

Dan: writes comment

Yves: this rfc is in the http-bis working group. Some are experimental and not in a wg but this is okay.

Peter: concerns that nobody else seems to be taking client hints up. And not this, but other client hints being abused, user preferences stuff. I'm not all in on client hints in general. But fine wiht the UA string being frozen and stripped down over time. Firefox and Safari have already been deploying this and are not providing a way to recover the information. I don't have a problem with a mechanism to get the useful information in a reliable way, but concerns some of the approaches they are talking about are just as bad as what was done with the UA string, that browsers will lie about what they are. But in general, the direction is right. Just needs to be handled more carefully.