Brian Kardell: Okay. So, I'm Brian Kardell. I'm a developer advocate at Igalia.
Eric Meyer: And I'm Eric Meyer, also a developer advocate at Igalia.
Brian Kardell: And on today's chat, we're going to talk about a string, literally one string, the UA string. And we probably won't have enough time to talk about all the things that we want to talk about, which is weird to think about. So, we've invited on a fellow Igalian who has some relevant experience in this area, and who I've had some interesting conversations with in the past, and that we thought it would be good. So, Alex, do you want to introduce yourself?
Alexander Dunaev: Yeah. Hi, I'm Alex and I have been working in this field, on browsers, and on Chromium, since 2013. So yeah. I witnessed some issues related to the topic, to the UA strings. And yeah, it'll be interesting to discuss them and probably to maybe speculate about the future of all the stuff around.
Brian Kardell: All right. So, I'm going to, I just want to introduce this in a kind of a strange way. I don't know if you both are familiar with this, but maybe a decade ago, Tony Hoare gave a talk called Null Pointers, My Billion Dollar Mistake. And it's just about all of the work and problems and everything created by this one decision. Very particular way he handled the problem that was created by null pointers. And all of the things that were caused by that. And I kind of feel like there's something here, I'm like, I'm not saying it was a mistake, necessarily, but really it's shocking how much time and effort and money has been spent discussing the UA string, and actions. So, I thought it would be cool if we had maybe a little history.
Eric Meyer: Yeah.
Brian Kardell: Eric, do you want to give us a little history?
Eric Meyer: I mean, I can give a very brief sketch. Like you said, a full discussion would take much longer than we have. But the UA string or the User-Agent string, User-Agent being W3C speak for web browser, basically, although it can mean a lot more than that. But again, another thing that we don't have enough time to really dive into. But the string is the thing that the browser sends, that the user agent sends. But the browser sends to the server to say, this is who I am. Right? And going all the way back to the first HTTP specifications. It said, in effect it said, browsers can identify themselves for purposes of tracking, not tracking in the sense of following people, but tracking what browsers are being used, right?Or what user agents are being used, so that a server administrator could possibly look in their server logs and say, 'Oh, this is a new user agent. I should go see what that's about.' And they started out really simple, right? And then basically saying, 'I am this browser in this, with this version number.' And then over time, they started to evolve a little bit into, 'I am this browser with this version number on this operating system.' Sometimes they would say. Although many of the first web browsers were one platform only. So, in a lot of cases, they didn't bother to identify the platform because there was never any ambiguity about that. If you saw a cello show up in your user agent logs, that meant that it was a windows machine, because cello was only available on windows.
Brian Kardell: As we'll see, a lot of the things that happen here are about reasoning at a point in time. Right?
Eric Meyer: Right. Yeah.
Brian Kardell: For a lot of years, people would've been like, well, the Microsoft browser only runs on windows. Until suddenly that's no longer true.
Eric Meyer: Right. Until Internet Explorer for the Macintosh.
Brian Kardell: Exactly. Right. And now you can get Edge for every platform, more or less. So-
Eric Meyer: Right. So, eventually, browsers did start to say, at least some of them in the User-Agent string started to say, 'This is who I am. And also this is the operating system I'm on.' But then it got weird. They started saying, 'Oh, I'm going to look at the User-Agent string, and if you're on this browser, then I will give you this page. And if you're on this other browser, I will give you something different.'
Brian Kardell: The HTP spec, the first one says that it could be used for tailoring the HTP response, to get around limitations, because that was foreseen. Right? Because browsers were getting much better, but we still had a Line Mode Browser. If you have something that is super capable, maybe the Line Mode Browser isn't, but you should still serve them, right?
Eric Meyer: Yeah.
Alexander Dunaev: Honestly, I learned a few points from the discussion. And I didn't know the full history of the UA string in details. But what looks kind of a summary to me is that on one hand, the UA string is used more or less for the purposes which were designed initially, because it was invented to allow the servers to decide what to send to the client, so the client would identify itself using the UA string, and the server would decide how to serve this particular client based on that. But the original intent, the initial intent, probably did some turns which were not anticipated. And the entire thing evolved into something much more complicated, and that maybe even to some extent, harmful or dangerous. Because it turned into something which started to limit some clients from getting the content which they deserve to get. That's the idea.
Eric Meyer: I don't know who the first, I don't know which browser was the first to start lying. I remember clearly Opera doing it.
Eric Meyer: Or your browser does not support this, go download the browser that supports this page.
Brian Kardell: Yeah. So, the interesting thing though, is that Microsoft found that they were in dilemma because that's really when they entered the game, and they started really pouring some money into development. They got people from Mosaic, like Chris Wilson, with the intent of being really competitive. And Microsoft's next browser was frames capable. But now even if they push the browser onto people's operating systems, that requires people to use the browser, and for them to have a good experience and then switch. Right?
Eric Meyer: Right.
Brian Kardell: The trouble is that no website would send it. The good website, they would all send it the stripped down website. And so, that's like a catch 22. And so-
Eric Meyer: So, browser started lying about who they were, basically, in order to not have that happen to them as they advanced in capability. Right? Because if a later version of Internet Explorer supports that stuff, but the sites aren't being updated. Right? Because either somebody put them up and just left them there, or they don't realize that Internet Explorer has shipped a more capable new version, or whatever, doesn't matter. Sites aren't being updated, and so, yeah, like you were saying, Brian, the browser basically had to say, 'Well, I'm Internet Explorer, but I'm also going to tell you that I'm Mozilla.'
Brian Kardell: Yeah. That's the really interesting thing. And the way that they did that is by looking at the spec and how people were parsing the string based on the spec. So, the first one is supposed to be the product token, the first part. And up until that point, everybody was just honest. They would say, 'We're Mozilla, we're Mosaic, we're the Line Mode Browser, we're... But in IE2, when Microsoft realized this, they cheated. They claimed that they were Mozilla. So that people would send them the good content. But then in the second portion, which has all the clarifying information about your OS and stuff, they said, 'Well, we're compatible actually.' In parentheses. And then that they were Microsoft IE2. So, you have to lie to get the content, but you also still have to identify yourself because we need... The purpose of the string is in part for statistics, right?
Eric Meyer: Yep.
Brian Kardell: So, that's important. Right?
Eric Meyer: Right. Yeah. Because Internet Explorer doesn't want to just say, 'Oh, we're Mozilla.' Because then it looks like Mozilla has a hundred percent market share, instead of at the time, 95% or whatever. Right. But whatever it is, if you just lie and don't actually say who are, then nobody can tell that your browser's being used.
Brian Kardell: Yeah. You want to change that. Right? You want to change that narrative, and you get a little bit of the tail wags the dog. So, you have to identify yourself. So, they just kind of found a clever way to slip through the regex crack.
Eric Meyer: Right. Yeah. By saying, 'Hey, we're Mozilla and then... oh, by the way, we're actually Internet Explorer.'
Brian Kardell: And the sort of 'nice knock on of this,' if you are a Microsoft Internet Explorer is that, if you do change the narrative and you can turn the tables, right? As you said, we like this new feature in IE. And so, we will send the good stuff to IE and something less to everyone else. If you can manage to get the good new features, and beat to market and change the narrative, then you can also create a runaway scenario. And so, that is also indeed what happened. Microsoft did become a really good browser. They did kind of win. And so, this is really, just wash, rinse and repeat, right? This is just, it just keeps happening where people make websites and they find that they want to use some feature. They're trying to kind of do the right thing in a way, a lot of times, like they still want to send content.But even if they do, that decision is sort of locked in time and then a new browser comes along that they hadn't considered, or a new OS is available for their browser, and you had reason that it was only available on one OS. What ends up happening is, every time there's a new browser, we have to concoct a new way to find the holes in the current predominant regex parse. And by the time you get to Chrome version one in 2008, it looks something like this, Mozilla/5.0(windows;u;windowsnt51;enus) space, AppleWebKit, which then in parentheses, khtml like Gecko, space, Chrome version, space, Safari. And it's like, 'Okay, what is that? What Frankenstein monster is that?'
Eric Meyer: Right. It was every engine and every browser that had been prominent in people's regular expression, checking of user agent strengths, basically, that had accreted over the years.
Brian Kardell: Yeah, exactly.
Eric Meyer: Yeah. Pretty much. And yeah, it went back and forth because at a certain point, like you said, the Internet Explorer became dominant. And then people started parsing User-Agent strings looking to send the best stuff to Internet Explorer. And so, Netscape had to munge up its User-Agent string in order to get the good stuff. And yeah, that's how you end up with that enormous list of... It's almost, it's fascinating how the User-Agent string now is, it's almost a historical document, right? You can sort of look at it the way archeologists look at compressed layers of sediment in a cutaway.
Brian Kardell: A few years ago, I was in California at an event. I think it was a [Blink On 00:14:59] or Chrome Dev Summit with a bunch of Igalians. And I was there after hours in the cafeteria, having pizza with Alex and Yvonne, who used to be here, now works at Brave. And somehow the topic turned to some things about UA string, and work that had to be done, and sort of pains that were caused by things. And I was totally unaware of this aspect of UA strings. And so, I was wondering maybe I can throw it to Alex to describe it.
Alexander Dunaev: Yeah. The situation with the US string and the issues around it, it is complicated. But I think the Chromium browser and it's family of browsers derived from it, like the Google Chrome first, then some major force, for example, the Samsung Internet or for example, Yandex Browser. Yeah. Or some other forked like Brave or like Opera now. And actually there are many, many brothers based on Chromium. And what issue they all face. That, for example, there are some resources, some websites which expect you to come there with Chrome and other brothers forked from Chromium. They want to distinguish themselves from the family. So, they would have their separate line in the stats or something like this. But then they get discriminated by the system because it expects Chrome or Chromium, but not Samsung Internet, and not Opera, and not Yandex Browser, and not whatever else. There are literally dozens browsers based on Chromium. And that's the issue. The UA string in this regard turned into the instrument of limiting the system and limiting the users. So you come to some website using the browser based on Chromium, which is totally capable of everything which is required, but you are rejected because it doesn't expect the fork. It expects the Chromium or Chrome. Now, that the issue. The solution is kind of obvious. Every major browser which wants to have its separate line in the stats sooner or later they come to this, that on certain resources, on certain websites, they have to say that they are Chrome. Probably they just have a fixed set of some domains or maybe URLs where they send the fake UA string. This is called the user agent spoofing. And I cannot tell for sure, but I'm pretty sure that every browser has it kind of implemented more or less the same way.
Brian Kardell: Yeah. So, that was the bit of the conversation that I was previously unaware of. So, to be really clear, if you create a new browser today, you aren't going to get a lot of content on important websites, things will not work unless you tell an elaborate UA string lie, right? Not a lie, a series of lies, like Eric said. It's like layers, archeological layers of lies that you have to tell. But what I was previously unaware of before that point is that's only sort of the first layer of lies. There are more lies in which a, you can't fall through all of the cracks. There are websites, important like Alexa websites or something, Alexa top websites, that are critical to people's lives but that the WebKit team has no power to make them change and send them the good content or let them through the door. But any other lie that they tell will mess up other sites. And so, in those cases, straight up spoofing, right? Like safari will just be like, 'I'm Chrome.'
Alexander Dunaev: It would be interesting to measure somehow the amount, the share of websites which want only some certain browsers to come. The summary of the idea is that only a small, maybe even teeny segment of internet is that sensitive for the version for the user agent. So, maybe the problem is not that huge. It only affects some certain points in the huge graph of the internet. I don't know. So, it will be interesting to measure it somehow. I don't know how.
Brian Kardell: I also think that, which is why started diving into some of this. So, there's another layer to this, which is that, you're right, the ones that any browser has to lie to is a relatively small list. There are a list of domains or sub domains where you just straight up lie. But there's another layer to this where you have to tell a smaller lie. Where you send the right UA string that's packed, just jam packed with lies, but still properly identifies you. But then again, for some important Alexa site where some in-time reasoning happened, it won't work unless you do something that was true at that time. And so, there are also things where, say this particular domain, you have to force in the quirks mode or you have to cause this really particular behavior that was a side effect that somebody was using to determine something in their code path that would cause it to blow up otherwise. It now, again, though, it is not, as Alex said, it's not this astronomical list of a million domains. It's a relatively small number that there are workarounds in there for. And there are workarounds really, I think mainly because they are top sites, they're ones that a lot, a really lot of people use those and you will have a bad impression of this browser if it just doesn't work with those websites. Lots of people will notice those. But smaller than that, there's things like your website or my website, or maybe a company that we work with that has an internet, that smaller scale kinds of things. And it's interesting question of, how does it affect those? One of the interesting things is that people don't not care about this, they do. We have questions about how we want to tailor something in response to maybe all kinds of things. Sometimes there are workarounds, loading polyfills is a big one. How do you know which polyfills to load? If you know which browser, you can kind of build an index of those and send down the right ones. I think the polyfill as a service kind of does this. But even CMSs have these things that simplify it. They don't make you look at the UA string, but they let you say, if it's an iPad, you show it like this, or you give it this style sheet, or you give it this HTML. And if it's a second generation iPad, then you do it like this or something, right? The way that it's achieving those is really through the UA string. And this, as you can imagine, it's the UA string has gotten a lot more information and more complicated. There are whole industries built around this, there's this, what's my browser.com that claims to have over 150 million unique UA strings in the wild that has this database that breaks it down and says, this one indicates a second generation iPad with this kind of chip set. It's really this huge database of meta information that these other products use to make it palatable for you to do useful things. They are absolutely useful things. But as you get more vectors of information, you also create this privacy problem. Because that's getting to be pretty specific at that point. Right?
Eric Meyer: Yeah. Yeah.
Brian Kardell: So, yeah, this is a problem. And it's a problem on many, many levels. So, Safari who has been leading on privacy a lot for a long time, they're the first ones that just got rid of third party cookies. And they also began treating the UA string as kind of a vector for just wanting too much information sharing. And they began limiting the string. They had some problems, they made some adjustments. I think Mozilla also followed. And now Chrome has efforts around this too. And how we maybe take this out of a string so it doesn't need to be full of lies. How we freeze it. There's also conversations, there's couple of blog posts from both Mozilla and Chrome that are about what happens when we reach version 100. There's a little bit of a worry that there might be a parser Y2K bug, sort of, where-
Eric Meyer: Yeah. In part, because that happened when browsers went to version 10.
Brian Kardell: Right, right. I mean, so-
Eric Meyer: It's already happened once.
Brian Kardell: Back in the days when we were talking about, it needs to look good in the 4.0 browsers they're like, reaching version 100 seemed like a thing that would not happen in our lifetimes.
Eric Meyer: Yeah. Back in the day, there was this whole evergreen release a new version every six weeks cycle, is a relatively new invention. I mean, it's been around for quite a few years now, but it's relatively new and yeah. But it used to be that you could literally go a couple years between a version release, and I don't, and we're not talking about a major version release, like between 5.0 and 5.1. It could be 18 months. It could be two years. And of course then there was also the time that Internet Explorer just went away for five years.
Brian Kardell: Exactly. Right. Yeah. Some of the outfall of that is, even as they want to make these changes, there are groups in the industry that stand up and say, 'Yeah, wait a minute. We have an entire business model based on this. And we think it can be used for all sorts of useful things. Look, it's been in the HTP spec since the very beginning, to do useful things.' And what is not useful about that? Those are useful things. And I mean, they're not wrong. You can do useful things. Right? But you kind of also make decisions that make a lot of sense in the moment, but then perpetuate this kind of problem. Just make it harder and kick it further down the road, but also begin to create some real privacy tracking issues. So, it's an interesting set of problems and it's, I think Alex you're right that would be interesting to know how many sites are affected by something about the UA string. And I would say, more than you think, I bet. Somehow, because it is used for loading polyfills, it is used for directing, is used for, I mean, it's used for everything, and it's used for everything on both ends. Like we said, for planning. How important that market share is, because all of these products have a problem with funding as we've talked about a number of times. Which is, they're largely funded privately by one or two companies with, completely independently for different reasons. And they have to make the case for budget, and they have to convince users to use their product. And knowing the stats definitely plays into both the ends of that. If you're Samsung Internet and, you're going to have a really hard time getting budget. But if you show that you were at 1%, a few years ago and then you got to 3% and now you're at 6%, that looks like success you can build on and you'll get more budget. Right? The fact that then that breaks into news stories and there's more and more people who can share with you. Like, 'Oh, I use Samsung Internet, it's really good. It's good for privacy.'You get a lot of people out there evangelizing it. That's then also good for feeding that cycle and getting more users. We know that we build trust through relationships. If Eric recommends a browser to me, I'm like, maybe I'll try that browser. Right? Even if I've never heard of it, I'm going to go look into it and maybe try it. Samsung was being miscounted, once we fixed all things that counted them, and we don't even know if they're all fixed yet. But it's the third most used browser in mobile in the world by a wide margin. If you're building a website and you're treating it like, that you're making some discretion there for even something as simple as sending polyfills, you'll be wrong if you think that Samsung Internet is Chrome, right? They're not the same. They have different features. They have different holes that you need to fill, or landmines that you need to avoid.
Alexander Dunaev: This looks a bit like a paradox.
Brian Kardell: It does feel incredibly hard to unwind.
Alexander Dunaev: On one hand we are interested. So, competition is good for everyone. But on the other hand, when so many, many, many, many, many clones of and forks and versions are out there, it is again, not really good, and very hard to handle. So, the webmaster has to be aware of dozens of versions and brands, and their possible in incompatibilities or some minor issues like this browser supports this feature a bit incorrect way or something like this. So, it's kind of the backside of the competition. Too many competitors and it becomes a very complicated thing.
Brian Kardell: So yeah, a way that this ties directly to something that we've been working on, and we've been involved with, is these things have affected, like Epiphany. There's a bunch of stuff in there about Epiphany and WPE. Like what do you send? And do you get the right content? And if you send a string and you don't get the good content, the right content, good and right, even is an interesting thing. What does that mean in some cases? People will blame your browser and they will say like, 'This browser is not good. I don't want to use it.' Even though maybe the browser is good and it's not, it's the website's fault. So, a really direct recent thing is Igalia took over the project that was formally known as Firefox Reality, and we've now creating a browser out of the same guts of that, called Wolvic. And that's for AOSP based standalone XR devices and harmony OS tethered systems. So, that's like Meta Quest, now, I guess it's called Two. And like Huawei VR glasses and things like that. We've been doing testing. We have a bunch of websites that have XR stuff. They're linked to, in a lot of places, we go, we look at them. And there are not a small number of them that... They present this enter VR button, or they shove you into a mobile mode or a desktop mode based on something in the UA string. And so, when Wolvic comes long, they shove us into the wrong mode or they don't present the, enter VR. We can't make all those sites change. And even if we could somehow compel them, they have lives. They can't drop everything and fix their website right now, so we can release the product.
Eric Meyer: Yeah. Even if we had a hundred percent buy-in, and you never do. I mean, this all reminds me of the whole doctype switching, and standards mode, or quirks mode in CSS. Right? Very similar things happened here when I was in Netscape, way way long ago. The reason the almost quirks rendering mode exists is there was an Alexa top 10 site that had a rendering quirk. So, they were relying on basically a quirks mode behavior. And we reached out to them and got contact, and got in touch with them and said, 'Hey, this is happening. We're moving, no more standards based model like with other browsers. And here's how you would literally just change the doctype on your pages, and it'll fix this problem.' And they said, 'No. Fix your browser.' They literally refused. And several rounds of, 'Hey, no, really it's very simple.' They're like, 'No, we're not interested. Go away.' And that's why almost standards mode exists in doctype parsing. Even if you could find contact information for everybody, which you, of course never can, you're still going to, it's going to be years before everything is up to date.
Brian Kardell: Yeah. Another aspect of this that hits on the other side is that if you're unlucky enough to work for one of those domains that has the lie, has one of these lies that is, 'Well, we're going to identify ourselves properly and everything but based on the fact that at one point in time, it was required that we tell you this little lie about some quirk that you were looking into and shove you into quirks mode or whatever.' Right? And you don't know that. And you're like, 'Oh, I'm going to write something that's the latest and greatest.' And you can work on it locally, and it works great. And you can deploy it to some server that doesn't have the domain. It works great. And then you deploy it to a server that does have a domain and suddenly a chair in a different room falls over. And you're like, what is happening? And it can be really hard to get out of.But yeah. I mean, that's what kind of led me to be really interested in this is that, Alex, you said competition is good for everybody, right? There's an aspect of this that's related to evolution, right? So, we have of a predator and prey relationship here. We have this adversarial system that we've built where there are benefits on many sides that are sometimes at odds with one another over the long run. On the one side, we get past this thing and it's better for everybody. And then on the other side, we find a new way to game it and then we get a little bit more information, and we find new things that we can do, and then we decide, well, we shouldn't have let that happen, we need to tone that back, but now there's industries built around that. And it's very interesting to see how you build up complexity this way through sort of, not intentionally adversarial, but things that wind up being adversarial model, causes evolution.
Alexander Dunaev: Yeah. Actually in a philosophical way, I would summarize this like, for evolution, some imbalance is required. So, it can take different forms. Sometimes it's yeah, hunting the debris. Sometimes it's something else. But always, if we balance everything, if we kind of reach some stable point, evolution stops or slows down. So, yeah.
Brian Kardell: Interesting about this is there's aspects of this where we would really like that to slow down or stop. And other ones where maybe not, because they're actually really useful.
Eric Meyer: Yeah. So I mean, given all of this, given this history and the current state of things, and the sort of weird place we find ourselves in, I guess my question is, what's next? Or what should be next, if those are different things? Right? What's going to happen with User-Agent strings moving forward? And should there be, what would our ideal result be over the long term? What do you think Alex?
Alexander Dunaev: Well, I think there are many ideas, but to me it looks like, so what is the problem in a few words? The problem is that the UA string is used for many purposes at once. And we can tell at least two purposes, one is statistics and the other one is capabilities. And to me as the engineer, the maybe most straightforward way to resolve this would be or could be decoupling the things and using different maybe APIs to handle the different purposes. So, probably it would be better to decouple the stats completely from exchanging the content. So, probably we could have the stats as a separate feature, maybe even at the level of some infrastructure of the internet, so that the browser would send it separately from the request to content to some separate parties. At the same time, of course it cannot be done totally independent from the websites, because we need to gather stats of which browser comes to which page. Right? And that is why we need to tie it somehow so the stats are sent when the browser comes to some page and maybe opens it with some parameters or whatever, I don't know. So, what is the current way of doing this? For example, some so called internet trackers, which are teeny things embedded into the page, which just make the browser doing a request to some resource, and there they record the UA string. So, probably for this purpose of making, of gathering the stats in a new way, the browsers could have some API, which the page or some third party would request in a way untouchable and unmodifiable by the main page. So that it will have the channel for gathering the statistics, which would be independent from the website and which could not be affected by the page. And that way, the browsers would not be interested in spoofing. So, they could just send something, maybe similar to the UA string, but which would only serve this very purpose of gathering the statistics.
Brian Kardell: Well, there's a lot happening in this space, and the groups are custom slowly coming together on the different things, and cross-checking one another and everything. Definitely things will happen here. So, one of the ideas here is to limit the UA string that's sent by default. So, there's a real problem here that the UA string is sent, the complete UA string with all of its data is sent all the time to everyone. I have no negotiation part in that, and no way to track it or if users wanted to block it or whatever, it's very difficult to do. So, one of the suggestions that seems to have some legs is that we need to really pair down what's sent in there and create sort of the simplest possible minimal information, again, initial request. There is an effort for UA client hints that is along these lines. It breaks down from one string to many smaller strings, where there's no parsing involved. You get separate pieces of data. So, we can maybe stop the parsing lies. And then we can send an initial request that has very little information and then do some negotiation about which headers you would like to transmit and send, somehow, and make that an active thing. And then there's also bits in there that are about entropy and everything. But one of the challenges there is, there's no guarantee that just having separate fields doesn't mean that we'll just wind up with new lies in different places. There isn't a good sense really of the question that Alex asked about like, well, how many things are affected by this somehow? I don't know. What do you think, Eric, was?
Eric Meyer: There were so many things that were done and that we now have the hindsight to see we're bad ideas. And I know that HTTP was designed from the outset to enable some of these things. But I think what we've learned is that that is a tool that people will use to cut not only themselves, but their user's experience.
Brian Kardell: We're certainly not going to solve it here today. But I do think it is really interesting because like Alex was saying, I don't know what the effect of it is, but it is certainly a lot. There's so aspects of this where the UA string is used. And if we just suddenly stop sending all of it, I bet a whole bunch of things would go wrong on many many rails. So, it's interesting to figure out how we tame this beast somehow. So yeah, I think is, it's been interesting conversation. I got to post a blog about this as well. It's interesting to think where it will go. Thanks for having the conversation.
Eric Meyer: Yeah. And Alex, thanks for joining us.
Alexander Dunaev: Yeah, sure. Yeah. Thank you for the really interesting and educating chat. And yeah, I hope that we will have some follow-up.