Brian Kardell: Okay. Hi, I am Brian Kardell. I'm a developer advocate at Igalia.
Eric Meyer: And I'm Eric Meyer, also a developer advocate at Igalia. And we have two guests today, one returning, one new. So I'm going to hand it over to our returning guest, Rick. Say hi.
Rick Byers: I'm Rick Byers. I'm a area tech lead on Chrome, responsible for a bunch of web platforms that we do in Chrome.
Johnny Stenback: I'm Johnny Stenback. I'm on the Chrome team as well. I work with Rick and work with, Interop Tooling is a team that we run that does ecosystem tooling kind of stuff and standards work as well. And there's a set of folks that do that kind of stuff. I've been in the browser business for quite a while. I worked at Mozilla for a very long time before I joined just about nine and a half years ago or so.
Brian Kardell: Yeah. And you helped organize the BlinkOn stuff with us and were one of the people who helped us set up the history of the web, things that we do, which we really enjoy, and we do on Igalia Chats.
Johnny Stenback: That is true.
Brian Kardell: I would love to get you on. I've never asked you because it feels weird to ask you to approve having yourself as a guest, but I'll put you on the spot here and just say that's my idea. And I would love if you would come on and do one of those. I think that would be great. But today we have you here to talk about origin trials. So I think that a lot of developers are familiar with different things from different eras of the web platform. We used to use prefixing a lot to experiment with things. We don't do that anymore. We'll talk about why, but now we have a nightly or Canary or a tech preview. And then a lot of times we also have flags, like either build time flags or run time flags or things to separate out the experiments a little bit. But then there's this other thing that I know mostly through Chrome. I don't really know exactly how it came about. It's neither. It's almost like it's a flag that can be flipped on and stable, but isn't fully stable yet. Is that right?
Eric Meyer: Yeah. What's the history of origin trials and what are they?
Brian Kardell: Exactly.
Rick Byers: Sure. So let me start with the fundamental tenet. I think in any platform as you're trying to find product market fit for APIs, there's a tension, especially for a standards and open platform like the web, is there's a tension between having the best possible design and having the tightest possible feedback loop. And often, feedback loops are really important. I think we used to sometimes think the way to get the best possible design is do the most review. And I think what we found is review is useful, but not as useful as actual experimentation, actually trying things in the wild, especially with real customer. And so, the best way to find product market fit and good API design, I think we've learned kind of painfully from some failed experiments is to actually let people try things and learn from where it doesn't work and work really hard to shorten your feedback cycle time. And so, this is what WebKit prefixes, not just WebKit, but Moz and prefixed APIs were designed to be that. Let's have a low overhead way of shipping out some ideas that people can try, but we won't really bake them into the web until we really understand them. And as many people know, that kind of failed miraculously or failed-
Brian Kardell: Spectacularly.
Rick Byers: Spectacularly, that's what I was looking for. Thank you. In terms of we were kidding ourselves. If they were successful, then they were locked in, and we couldn't change them. Now maybe there were some, even when they weren't successful, they were hard to delete, but we really struggled with that tension. And my recollection, I'm sure there's multiple people have different stories on this, but let me just tell you the story I remember from starting. And I got to credit, again, I'm sure lots of people deserve some credit, but I'm going to credit Jacob Rossi from the Edge team. I remember a TPAC near San Francisco Airport, I think it was 2014 TPAC, and it was one of the breakout sessions. And Jacob proposed a breakout session to talk about this problem. What do we do about prefix? So shortly after Blink forked from WebKit and we had said that we weren't going to be doing prefixed APIs anymore, we were going to focus on the standards path. And Jacob was really pushing this, well, how do we actually give ourselves a tight feedback loop? How do we make it safe to fail? It's something Alex Russell talks about a lot, is you want to get tight feedback loop and great API design. You want to make it really cheap to fail because most ideas are bad ideas. And so when we say the only way to really test something is to spend two years in a standards group designing it and get lots of people, have lots of investment in it before you ever get to find out, that's an incredibly expensive way to fail. And it means people have a real aversion to failing, but failing isn't a bad thing. Failing is how we find product market fit. So we want to make it as cheap as possible. And Jacob Rossi just led this brainstorming session at TPAC that a bunch of us jumped into and said, 'Yeah, there probably is some way.' And we were incredibly worried about repeating the WebKit prefix problem and ending up with things that got burned into the web that were really not mature or not on a great standards path. So we had all these ideas about all these things that we could do to make sure to prevent that from happening. And out of that, I think at the time I think I was... Oh, maybe I wasn't managing the team yet. Eventually, I became the director of our Blink team, funded, built up this team that Johnny now runs. But I think before then it was just, there was a bunch of us who knew this was a really important problem, and we made the case, a guy named Jason Chase, who put a bunch of time into just trying to build out some of these ideas that came out of that TPAC stuff to start trying to experiment.
Brian Kardell: Yeah. I mean, this is the stuff that I was talking to Alex about for a year or two before that is stuff that led to extensible web manifesto that talks about this feedback cycle and the importance of being able to fail. And the thing that I really like about doing that in JavaScript is that the cost benefit is pretty good. So there's a standards proposal. It's JavaScript, but try it because maybe it will solve your problem. And then maybe, maybe, you'll be able to remove it at some point. Probably not. Don't count on it. You know what I mean? But in the meantime, try it and see if it fits. It gives you an opportunity to, you don't have to follow the spec for years and years and years. It's just like, here's the thing, try it. And if it works, great. We'd love to hear that. If it falls short, we'd want to hear that too. And since it's JavaScript, you are in charge of when you remove it, when you update it, when you upgrade it. I thought that's a really ideal thing, but this is something that is, you ship it, and it's gated though, behind. Can you explain the mechanism of how it's gated? Because, I don't know, if I wanted to have a thing like I do, I want to have a thing, several things actually that I'm interested in having. And if I develop them, not everything needs to have an origin trial, but some things have origin trials. And what do I do to create an origin trial, and what does somebody else do to use it? Because you have to do both, right?
Johnny Stenback: Yeah. So effectively, it all starts with, in the case of origin trials, that's on the Chrome team, somebody develops a feature and so forth to come up with an idea, put it out there in a release gated behind a trial. And then if somebody wants to use it, Google for Chrome origin trial and you'll find it. And there's the origin trial console where you can register for trial. So you'll see a list of trials. You click on whatever trial and hit register, and you have to give the domain, has to be pretty specific HPS, whatever, all this stuff. Fill it out, and then you effectively get a token from that registration. And given that token, you can go to your own website and put that in a link in the page, et cetera. There's a few mechanisms, headers and so forth that you can sort of signal to Chrome that you're now a participant in this trial. And then, once Chrome sees that, then that feature becomes enabled for your users on your website. And that's kind of the mechanics for using these.
Rick Byers: One of the key pieces there, and I think the piece we've learned over time, we didn't know which pieces were going to matter most. There's a bunch of criteria, like we have a usage limit, for example. When we started origin trials, we said all origin trials were run for a period of time and stop before shipping an API. There'd be a break. We had all these things to try to prevent burn-in. And one of the key things was when you get a token, you basically click into a form that says, I understand this is experimental and will change. It will not be available forever. I think that ended up being even more valuable than we thought it would be. There's some psychological aspect with web developers of just the acknowledgement. It increases the chance that people are going to program a little defensively. They're going to make sure to, knowing that the API is not necessarily always there because they're going to have a feature check there. Worst case and something goes wrong, we could always just burn the name, unship the API. And I think that more than, curious for Johnny's opinion, but I think that more than anything, just making sure people are explicitly opting in to something that they know is time limited and experimental and subject that seems to be... That was the hope with prefixes, but there was no kind of explicit comment. There was nowhere where you click and say, 'I understand this.' And in practice, because they weren't time limited, I think was a big part of it. The fact that we generally don't run an origin trial for more than a year is kind of generally our upper limit and people know that, I think ends up making it safe to experiment without risking.
Johnny Stenback: Absolutely. And another important piece of this as well, through this registration process that we have, we effectively get this set of email addresses the Chrome team can contact as well if something is about to change or whatever. It's rare that we do that, but we have that ability. And we also know if we're going to turn something off or whatever, look for in terms of breakage on the web and so forth, more so than if it was just more of the prefix, then it was like, well, we had no real idea. Plus, like Rick said, we keep track of how much usage for these features as well. And we have the ability to back off, ultimately turn off the trial too if necessary.
Rick Byers: And we should also say origin trials aren't, though it started with Chrome, well, it really started with Jacob on the Edge team suggesting it, but Chrome was the first. But Chrome's not the only browser that has origin trials. Edge has origin trials as well. They both run the same ones that Chromium upstream has. And I believe there's been some cases where they've run their own origin trials that aren't in Chromium upstream. I think Opera as well has some. Opera and Firefox both have some kind of more limited types of origin trial.
Johnny Stenback: Yeah. I remember from long ago myself, when origin trials was becoming a thing in Chrome, I was at Mozilla at the time, and we were kind of hearing about it. And I think the consensus at the time was that it seemed like we understood what the problem was that they were trying to solve and agreed, but it seemed more complex than we were willing to invest in terms of setting something like that up and managing it or whatever. But we did do a couple of instances at Mozilla where we, rather than having this whole trial mechanism in place and registrations and so forth, we literally, if we worked with some partner and we wanted to experiment, we literally would hard code an allow list or whatever particular API, which obviously doesn't scale. And it's not great. But that was a thing I remember that we did a few times.
Eric Meyer: Yeah. So rather than you maintaining an allow list, now it's the system where people opt into being on the-
Johnny Stenback: Exactly.
Eric Meyer: ... allow list effectively. And obviously, you've set it up. It reminds me of at least once upon a time, the Google Maps API key. You're registered to get a key, and then you put it in the header of your page or your site or your whatever. And then you could use the Google Maps API. This sounds very similar, and I wonder how many developers realize that they can do this, right? I mean, hopefully more will find out as a result of listening to this that yes, you absolutely, as a site maker maintainer, can participate in origin trials. You can make it so that your users get whatever the thing is that you're trialing.
Rick Byers: And part of the point in the design is that we really don't want to distinguish between whether you're the biggest tech company in the world or a small one person shop. The overhead is very low. I've registered origin trials for my personal website. You go to the console, basically put in a couple fields of information, click a couple agrees, get a token and drop it into an HTML tag on your webpage. It's really that simple. And that's why we didn't want... Sometimes there's been discussion, should we have some process for trying to vet and understand how people are going to use it and whatnot? And many of us have argued, I think it's good for the openness of the web to say, no, this isn't an allow list of trusted partners. So for example, one of the implications of that is we have to go through all the same security and privacy reviews for an origin trial that we would go through for a full launch because attackers can access origin trials just as easily because we thought it's an important principle that wherever possible, experiments are available even to any website they would like.
Johnny Stenback: I was going to say another piece that we, this has changed quite a bit, but there's a feedback mechanism built into the origin trial program as well where I believe there was wording that we never, I don't think actually enforced this, that you had to give feedback on the trial or on the feature with, I forget the timelines, but every so many weeks or whatever, or you would potentially be kicked out of the trial. I don't think we ever did that, but that was a thing that we did, which in the end, from the implementation perspective and so forth, complicated things quite a bit. And also of course data retention and whatever since we had feedback from users and whatever, but that's all gone now. That's it.
Rick Byers: The main effect that this ends up happening, if I think back to those conversations we were having in 2014, we were really struggling. We're like, wow, this is a really hard trade-off. We want standards. We want full interoperability, but we also want it to be cheap to fail. And we want to be able to have a really tight feedback loop and go from idea to testing in deployment in matter of weeks. How do you square that with the idea of a formal standards process that has standards maturity and recommendations, whatnot? They feel like they're fundamentally intentioned. And what blows my mind the most thinking back about that history is it turns out they just weren't actually intention. I think we were deeply worried that this was a fundamentally intractable problem. It turned out to be actually highly tractable. We've now done, I don't know, Johnny, do you know numbers, but hundreds of origin trials. I'm not aware of a single one that has led to some kind of compatibility problem where we've felt required to keep something that we wanted to change or that others argued to be changed as part of a standards process. And I think it's really helped relieve the tension on this pressure around standards maturity. I mean, there's still tension there. There's still a tension to balance. It's not uncommon that even after a year of origin trials, you're still not quite at the place in the standards group where you're comfortable saying, yes, this is 100% mature and nothing's ever going to change about it. That's obviously maturity. There's multiple levels of maturity, so I don't want to say there's no tension there at all, but it's just trying to put myself back in the head space we were in in 2014. It's kind of remarkable. It's a really happy, maybe even accident of history that we haven't been stuck in this point of having to fight all the time the way we did before 2014 where we felt like either we had to tell a partner, 'Sorry, we really can't solve your problem for two years because that's how long it's going to take us to get to rec in the standards group,' or say, 'Oh, we're just going to ship whatever the heck we want, and maybe we can figure out a standard later for some interoperability.' It really seems like we found a suite that gives us a win-win in a lot of cases. And I don't want to argue that it's perfect by any means, and we make mistakes. We do make mistakes all the time, but relative to all of the fear that we had and all the ways we didn't want to mess up on either side, we didn't want web businesses thinking... We have a real problem with web businesses thinking that there's no point in asking anything from browsers because by the time they get it, they're going to be moved on and have new careers, and it's going to be five years later. And we now have so many great counter examples, so many partners that we've been able to give them something quickly, and they've said, 'Oh, wow. Now that makes me want to work with browser vendors. It makes me want to actually try to help be a part of the process of making the web better and really expand the pool of people engaging in web standards,' because they feel like they can see some results from their work in a timeframe that's relevant. And at the same time, we've not, I assert, and I would be happy to hear some counter examples, but I'm not aware of any case where we've had to pay the cost of the consequence where we've gotten stuck with something because of an experiment.
Johnny Stenback: I'm not aware of any cases like that either.
Eric Meyer: Yeah. So you say that part of the, or a big point of origin trials is to get a very tight feedback loop, but that you're not actually enforcing getting feedback. Is there automated feedback you get? And if so, what kind of automated feedback? How does that-
Johnny Stenback: There's not automated feedback per se. What we used to do was that we had this external system that collected feedback for us, and we sort of, in wording, tried to force people to do that. In practice, we never got super useful feedback through that. It happened, but the more important feedback is through more direct collaboration with sites that we either work with independently of the trial per se, or maybe through them. Knowing that some site is using it through the registration process, we can reach out and so forth. Today, there are still two mechanisms for feedback that's made available. There say effectively we give the feature author, typically Chromium contributor starts a new feature, the ability to include a link to say, 'Give feedback here.' So that's usually a GitHub repo or something. And then we also do create an internal Google group that gets registered, this is all automated, where participants can send stuff. Part of the challenge here is that if we sometimes obviously work, and this is true for everybody, work with partners that are willing to give potentially us feedback, but don't necessarily want to say something publicly. That is less and less common, I would argue. So the number of feedback pieces that we get to the internal groups is pretty close to zero today. So most of it's directed to the spec repo or whatever the feature owner decided was the right place. And that still happens. And of course there are other channels that we can get feedback through by working directly with some partner, whether that's an internal Google party or whatever or some other companies doing stuff.
Rick Byers: One sort of automated feedback, maybe one of the most pieces of valuable feedback is usage. And so, one thing that the API owners, myself and others like to do when someone's asking to ship an API, especially if there's an API that's a little bit controversial, if there's some argument of why this API is bad or has sendable properties, one of the things we like to ask, 'Okay, who used you in your origin trial? What are people saying about your... ' And one of the most telling signals is, 'Well, we did an origin trial, but turns out nobody used it.' If I see that as an API owner, I'm like, 'Well, this isn't ready to ship then. You don't have evidence or product markets.' And so just being able to measure the usage, I think, is one of the valuable type of automated. It doesn't happen a lot, but certainly generally it helps people self-censor. I think in the past we have sometimes shipped an API that has ultimately gotten effectively no usage. Request auto complete comes to mind. I think there's been a couple others. Those APIs don't get shipped now because generally they would've gotten no usage in origin trial either.
Brian Kardell: Yeah, we're kind of beating around a whole bunch of the reasons that I wanted to ask you guys to come on because I've been aware of origin trials for a long time, but there's a lot that I don't know about them actually that I have kind of had some private conversations for a while that I think would be useful to talk more about them and share a little bit of that so that we know. So for example, what does it mean? How many do you need? So if you have zero, that's pretty bad, but what if you have two? Do you need 10, 100? What's the most that you ever run? And looping back to a thing that Rick was saying about you might do this and collect a bunch of feedback and then you're still not super confident, but you have more confidence in those standards discussions. One of the things that seems to happen a lot in those standards discussions is, and this is not picking on Google, I'm super grateful that Google does the R&D, and you do the majority of R&D. So of course you're the example that I'm going to use because you're on here, and that's what we're talking about. But it also happens with Apple. It also happens with Microsoft where you do a lot of work and then you come back, and you say, 'Oh, we're very positive. We worked with partners. We have the data, but sort of trust us.' And it's like, 'Well, what's the data though? Can you tell us more than that?' It would be great to know we worked with 32 partners, and there are these rough classifications. Is there some way we could share more about what we're learning from these and what they mean so that we can have more confidence, and we can have a better discussion? Because I think that the standards thing does get easier if you feel like you're handing over some of the R&D. Do you know what I mean? It's not just like, 'Trust us, we did the R&D. Here it is. Take it or leave it.'
Rick Byers: 100%. And I'll own, one of the most infamous examples of what you're talking about is the prompt API that got a lot of press. I ran a bit of a postmortem reflection process for that. And one of my takeaways was I think I made a mistake as an API owner of Prompt API because to ship, there was some vague statement about partner support. And look, it is a hard trade-off because as Johnny was saying earlier, a lot of partners are not comfortable with us using their names. We can't go and say this company, this company, this company, if we don't have their permit. Now maybe that's something we should talk about changing. Maybe we can design the origin trial system where the only way you can get a token is if you're willing to say publicly that you're using this token. Maybe that's possible.
Brian Kardell: I mean, you could imagine anonymizing it a bit, right? A site that's about-
Rick Byers: We try to do that.-
Brian Kardell: A site that's about design that serves hundreds of millions of users a month, something like that. Yeah.
Rick Byers: Yeah. But then we do end up... I agree with you, it shouldn't be a trust us. It should be a, we're going to show you our homework, and we're going to show you the work. And that's why I think this has worked out better in the feedback process. Increasingly we tell people, 'Hey, if you want to see this ship, go comment on this GitHub issue or go in. We need your opinion. There's a bunch of debate on this particular design point. If you want to have this API, if you don't want to just let the origin trial expire so that you don't have it anymore, we need you to go engage publicly here in GitHub.' And I've seen a bunch of positive... when we frame it in that terms. It's like, I had a partner ask me once, it was a major bank, I won't use their name, but it was a major bank, and they said, 'Well, when's this API going to graduate from origin trial to shipping?' And I said, 'Well, look, you're the biggest user of this. If you don't have anything to say about it publicly, maybe never. This API may never ship.' And they're like, 'Oh, but if you can give us and help explain why this is valuable for you, then that can greatly increase the chances rather than later.' But I agree with you that that's an area that we could do better on. We should think about, are there structural things we can do to how we run origin. There's a bit of a distinction here. Part of what you're talking about is not about origin trials, but it's about our Blink launch process and the process we have for launching new features which very much, I mean, this dates back to the WebKit fork. Right from the time we forked WebKit into Blink, we had this public announcement that we were going to do all of our API launches, public process. The idea being to encourage transparency and accountability and a place so that when we get it wrong, which I think we made some mistakes with the Prompt API, we have a place where we can talk about the mistakes we made, what we learned, and it's a great example. And certainly I've used, since that incident as an API owner myself, I've put more effort in the intent to ships when I see developer signals. I go look at them more often and push back a little bit more often and ask what specific evidence can you point to? Everybody likes to say developers love my API, but what I want to see is show me the evidence. What are they saying about it?
Brian Kardell: Yeah, exactly. I mean, I know that Apple does user studies sometimes. Microsoft does user studies. They do testing for accessibility. They do stuff like that. I don't feel like that ever gets delivered in terms of here's something that you can go interrogate if you want to. You can see we hand in the homework and then at least people feel confident that they don't need to worry too much about it. Whereas, we also do this with specs and explainers where you have to have a whole lot of things. What are the things that you considered? What are the alternatives you considered? All that kind of stuff. But at some level that also makes it more stuff to consume. I think one of the nice things about this is that it is really about testing the product market fit, like you say. There's lots of famous examples of the best thing doesn't always win. The thing that wins wins. I don't know that it matters that we didn't hold out for Betamax because we all had VHS, and it was just fine. So yeah, I think there are probably things that could have been better than HTML. There are definitely things that could have been better than JavaScript, but we move forward. And we move forward imperfectly. So I like this model of, how can we experiment? How can we experiment more safely and things like that. There's a flip side of this that we haven't talked about yet that is, what do you call it? A deprecation trial, is it?
Johnny Stenback: Yeah, reverse origin trials sometime.
Brian Kardell: That's what I think of it as, like a reverse origin trial where it's like we're going to remove this from the platform, and XSLT is... We've done a couple of shows on XSLT, the removal of XSLT. And will that be a reverse trial? Would it go that way?
Eric Meyer: According to the Chrome Origin Trials website, it is right now. You can register for an XSLT.
Brian Kardell: So what that does is keep it on, right?
Johnny Stenback: Exactly that. And those trials are a little different. Rick mentioned earlier that the trials tend to be time bound, and that's somewhat true for deprecation trials too, or reverse origin trials as well. But we tend to be much more flexible on the sort of extend timeline for those trials because sometimes these deprecations turn out to be much harder than we anticipate, or sometimes we anticipate that they will in fact be very, very difficult. And we want to give ourselves time to actually give the ecosystem time to adjust and so forth. But yeah, they're effectively the same thing as far as the origin trials program goes.
Brian Kardell: So they're the same thing, but I have a nuanced question with this one. So because I see we have browser properties like Wolvic and things like that where I know we need to... It's much more prevalent of not Chrome, where you need to say, for whatever reason, Bank of America, not actually, but just as a hypothetical, needs me to lie to them to tell them I'm Chrome or else they won't deliver to me. Or because their logic thinks that I'm not Chrome, they think that I don't support this, but I do. There is a shared thing that has gone around called the web of lies that the browsers have traded. Here's the lies that we need to tell. Meta has a huge list of ones that they need to tell for their XR browser, and we have our own. And I know Apple does. And those are generally added because it's like, hey, big important property breaks, and we're unable to get them to deal with it. And that would be bad for us, and it would be bad for our users. So we're going to put this sort of hack in that we hope is temporary, but who knows when it will actually get out of there. Microsoft also had, and you said, Johnny, that you had something at Mozilla that you had hard coded in. Microsoft also had, I called it the naughty lists where they would put you on this list kind of like that. I wonder with the reverse origin trials, does Chrome also, or have you ever, or would you ever consider putting somebody on yourself as opposed to them submitting a thing? Do you understand the question I'm asking, or was it clear?
Johnny Stenback: Yeah, go ahead. I think they're somewhat different situations where yes, there are situations where we, as a browser vendor, want a property to change in some way because of web compatibility or whatever. We tend to deal with those cases probably much less so than other browsers just because we're a market share. But reverse origin trials are sort of specifically because we're actively, usually collectively with other browser, aiming to remove something from the web platform. And that's not just us, but everybody has a shared view that this thing needs to go, whether it's XSLT or unload handler or whatever. And then that gives us a sort of path to slowly roll that out, and it still does rely on the properties that potentially break because of this deprecation, participating and registering for a deprecation trial and then including the token, the website and so forth.
Brian Kardell: So the reason I ask this one is because I know for a fact that there are a lot of schools and government things that have XSLT. It's not always the only way to get at something, but they have things that utilize XSLT. And I know that, especially right now for reasons that we don't need to get into, finding a budget to make those changes is not always doable. And some of those have been just running on steam for the last 10 years even. They just barely have any budget at all. And so, whoever wrote those systems is graduated 10 years ago and don't work there anymore. They have no budget to have something. And I wonder if you saw something like that, can you imagine Google being like, 'No, we need to add this one ourselves,' and proactively try to find them? Or that's not a thing that you would do?
Rick Byers: I mean, I think we're very cautious. We want to be careful to be treating the web equivalently and not playing favorites or anything like that. But we certainly explored a bunch of things in this direction with privacy in mind, turning off third party cookies, actually getting... I think no browser has really succeeded at fully disabling third party cookies without some site specific hacks, at least some pretty sketchy heuristics to try to balance this trade off. So I don't think it's out of the question that we would do it. I think there's a cost, and I think the cost... In some ways, a browser like Chrome, I feel more responsibility to take some of the pain on ourselves. I understand why Wolvic browser, you've got to do this. You're not going to get the sites to change for you. And so, you have no choice, and you got to do the thing that's easiest for you. And I worry a little bit about the temptation to just say, 'Oh, well, we can solve this problem ourself with a list of site specific hacks in a way that doesn't really lead to an interoperable and standards-based web in the long run.' For example, the kind of things that people complain about is, 'Hey, this stuff worked great on my staging server until I deployed it in public with my actual URL, and then it- '
Brian Kardell: I complained about that at BlinkOn actually because we were on the naughty list at my other work, and it's very hard as a developer to debug that and to figure out why this thing worked fine. And then suddenly, it works totally not fine when you deploy it.
Rick Byers: In some ways we're trying to balance. We started this program years ago that we called web platform predictability. We want developers to be able to bet their business on the web. And part of betting your business on the web is that you can trust that it is going to be a reliable, stable platform. And that really means that we're not depending on a lot of heuristics. It's a platform that you can reason about and that behaves in a consistent and predictable way. And breaking changes are a problem for that. Absolutely. Part of the reason we started this program is to be more rigorous about how we approach breaking changes and make sure we're not incurring much cost. But I think there'd be a trade-off to manage here. That said, I did push for one fun one that might be a fun story. There was a period of a few years where I think it was what we ended up deciding to do, I think we were trying to align the mousewheel event. There was all these inter-op issues with the mousewheel event. I think it was like, is it called wheel or mousewheel? I think Firefox had mousewheel. We had wheel at WebKit. I forget the exact details, but there was interop problems that seemed intractable, and we thought we finally had a solution for it. Then we found that there was this one particular library that was really common across the web for enabling smooth scrolling, for turning wheel clicks into animated scrolling. Unfortunately, it wasn't even just a common source file name. It was a gist that people then copied and pasted into their own websites and got into some templates on WordPress and stuff like that. We're like, 'Well, either we're going to give up on having interoperability on wheel events with Firefox, or we're going to find a way to hack this.' And so, I did an intent to ship. I think I did it. I was at least involved in doing an intent to ship for a heuristic that says, 'If a wheel event listener ever has the function name sc_wheel, then set the passive bit on the listener by default.' And it's a crazy hack, but it wasn't an origin specific hack. It turned out it was exactly the one thing we needed to be able to gain interoperability on how most wheels behaved. We shipped that, and I think I just LGTMed the patch to remove that hack. After that being in the code for five years or something, the web changed enough that it was no longer needed, and we removed that hack just recently.
Brian Kardell: It's funny because we're trying to prevent things from escaping the lab. These are amazingly interesting experiments, but they are experiments. And we don't want them getting out there, and there are all kinds of examples of things that are not even documented anywhere, but people just discover and then build really useful things on. And then you can't change it. And this is really interesting because it's an example of a browser vendor doing it in the other direction.
Eric Meyer: I just want to make sure I understand with the reverse origin trial. I'm looking at the trial for XSLT page as I'm speaking. So basically it says XSLT was deprecated last December, and it's going to be disabled by default around mid-November of 2026 as of Chrome 158. The deprecation trial is listed as available from Chrome 152 to 175, which these days is not as long as it sounds because now it's every two weeks. But that's still, it's 46 weeks. It's a while. So from 152 to 175, this origin trial will be active. It ends on August 30th, 2027, so just over a year from when we're recording those. During that time, by default, Chrome users will not have XSLT support, but if you are using XSLT on your site and you want people to still get that XSLT support and also give signals to Google that it's being used, you would register for this reverse origin trial, origin trial, whatever you want to call it, so that the functionality will continue on your site. Then hypothetically, if it turns out that there's enough usage, then as this origin trial comes close to closing, you might end up saying to all the other browser vendors, 'We ran a reverse origin trial, and it turns out 5% of the web uses this. We can't just turn this off yet. We need to figure this out.' Or you go to the other browser vendors and say, 'Turns out 16 people used it in the last year. It's okay. We can do this.' So that's how this works, yes?
Rick Byers: Yeah. There's just a little bit more complexity in that part of our story about XSLT is also we have, I don't know if we're calling it a polyfill or not, but we have, I think the WASM implementation of XSLT. And so site developer has a choice. Ideally in a bunch of cases, they just drop in this library that we've... And then that works forever. It removes the security risk from memory problems, plus code that we know is in the browser leading to security bugs, and it moves it into WASM sandbox where it's safe, control of the developer. And so, that's the better choice. I think there are some, and I'm not up-to-date on all of the exact details, Freed is the one that's driving this, but if I recall from chatting with, there's some Edge cases where sources of XSLT don't match that exactly. And so, the deprecation trial is another option that developers can pick, and maybe it's a little less risky for you if you're worried about there is obviously a WASM blob that you have to deploy at your site that has a cost to it. So maybe you use the deprecation trial in order to give you time to test out the WASM polyfill solution, one possibility. But certainly as I understand, I think I should go double check the stats, but none of anything in web compatibility, nothing is set in stone. We're always trying to evaluate the cost benefit trade off. There's all sorts of signals, and certainly like you Brian, you were talking about government websites, school websites. Absolutely want to create cost to schools, try to rely on a variety of signals. We can find partners like... We've tried to do everything we can to make it very, very cheap. Say like, 'Hey, just drop this on your site and just work as they did before.' Ideally even better. You're going to get better interoperability now because now it's going to work for all the browsers, including all those that... So I think that this is still one that I think is open whether all of our plans for deprecating XSLT will work out.
Eric Meyer: Right. Okay. But I mean that's the general way that these things work. XSLT, yes, has this extra story to it, but if you were trialing something else to take out, I'll rewind it 16 years. If this had been in place, you could have done this with, potentially you could have done it with CSS visited styling as an example, just to see what the usage is and to trial the removal of that over let's say the course of a year. Yeah. Okay.
Brian Kardell: App cache. We could have with app cache, that's for sure.
Johnny Stenback: Yeah. And one thing that we obviously try hard to do before we even started reverse origin trial is to understand the use of open web ahead of time. So coming to the end of a reverse origin trial and realizing that 5% of the web relies on it is something we try very, very hard to avoid. And it also happens since there have been general... Maybe Rick can speak to this, but I don't know that we have a strict sort of guideline for we will let a reverse origin trial run for n years or whatever, but we've certainly had some that have run for many, many years. So we can certainly and have in the past extended reverse origin trials as well. So we just then require registrants to get a new token, and they buy themselves more time.
Brian Kardell: So another question that I had in my list of things to ask you, and part of the reason I wanted to talk is that I thought we've had these for 10, 12 years now, something like that roughly. And I'm just curious, we should have a lot of data now. It would be really cool to see a talk about this, you know what I mean? To see a BlinkOn or Google University kind of talk that talks about this, but also looks at the data in terms of how many have we run? Let's say it's 300. How many failed? Because they should, right? We expect them to. If they're not failing, maybe we're pushing too hard. How many shipped in all browsers versus remain Chromium? There are a lot of interesting data points that would be really fun to look at and to think about, I think. And I'm just curious about basically-
Eric Meyer: Do we know any of those?
Brian Kardell: I don't know if you know the answer to any of those.
Johnny Stenback: I don't have any numbers off the top of my head, but I mean, there's certainly an order of hundreds of trials that we've run in the past. Another thing that might be interesting to look at is number of participants per trial, that kind of stuff. But it also turns out that's a hard question to answer because we get a lot of... People try to sort of be clever and register trials for domains they don't own, like random people.
Brian Kardell: Oh, wow.
Johnny Stenback: Doesn't buy them anything, but that's in our system, so we see those, so filtering those out.
Rick Byers: I just did a quick search, and in my inbox at least I see 505 Blink dev threads with experiment in their subject name. So that's probably a pretty close approximation to the number of origin trials we've done. It's probably a little lower than that, but 450 or something like that is probably the number of origin trials we've done. It's a good question how we could connect that with how many of those have shipped. We might be able to do a Chrome status query thing, but I agree with you. That would be a great BlinkOn talk. Think about who we could ask to give that talk. Probably someone on your team, Johnny, or you.
Brian Kardell: We asked people, 'Hey, we're going to do a talk on origin trials with some people,' and we didn't say who was coming on or anything, 'but if you have any questions.' And a couple of people responded, and one asked what I thought was a pretty interesting question. We have done a lot of things to prevent things from escaping. And I think so far, largely origin trials haven't by that definition. Although again, it would be interesting to look at the data to see if maybe some things shipped that shouldn't have or that are maybe more aggressive than other things in terms of did they advance beyond just Google. But the WebMCP thing, somebody said, 'Well, this one actually, somebody recently, I don't know, was it ChatGPT or somebody just said we're just enabling it by default. It's just on. There's a downstream Chromium.' And I had never really thought of that happening. And I know that there's this big contest with WebMCP that a lot of orgs are behind. And so the question was just sort of like, is this going to be an example of something escaping, or what will you do with that if WebMCP, you deem it's not ready for prime time or whatever? Will it stay in Chromium, and it would just be off behind a flag? Anyway, yeah, I'll just sit back and let you-
Rick Byers: It's an interesting question. We do actually have an example that I'm aware of that's kind of fascinating. WebVR was in origin trial for quite a long time in Chrome, and Samsung decided to ship it on by default in their browser. I think even their regular Android browser, it was on by default. Now that WebVR has a long history, and I think for whatever reason, probably for independent reasons, the group working on it ended up pivoting it to something called WebXR instead. So it was kind of convenient. By the time we actually shipped something for real in Chrome, it had a different API name. So we didn't have to worry about compatibility with the thing that shipped in Samsung browser, but that's always an option. Like I was saying earlier, worst case, we burn the name, and we ship WebMCP under a different API name to ensure we don't have compatibility issue, with code that was in ChatGPT. But I'm hopeful that won't be necessary. A lot of the times the changes we end up making, we can make incremental and compatible, but -
Brian Kardell: Does it just get kept it in Chromium? But do then they have to become the sort of code owners for that place? Do they have to commit to keeping it up and dealing with the security fallout of that and everything? They have to keep the budget going for it?
Rick Byers: No, no. Look, the Chromium open source project has a policy of maintaining code only for shipped API. So if some downstream fork of Chromium wants to ship something that was not actually shipped upstream, then at some point in the future, upstream Chromium may delete that feature entirely and that downstream fork is going to have to figure out, do they want to maintain the feature in their own fork, or do they want a common base? We're not going to maintain a debt in the upstream Chromium code base for the benefit only of one downstream that decided a different... I think it's a valuable policy, right? It's actually good that all Chromium forks are fully autonomous and able to ship whatever they want. I like that principle. Competition is good. It's healthy that browsers can compete, but also they need to own the costs of that decision. And if they want to go and do a bunch of stuff and ship a bunch of non-standard APIs for their browser, all the power to them. Our standards process is voluntary standards process, but don't incur the costs for everybody else in Chromium who's not doing it.
Brian Kardell: Yeah. I think it's a really interesting thing because you do have so many partners in Chromium, and now we even have supporters of Chromium browsers. It is interesting to think about how the government, not the government, the governance plays into all of this and how do you come to agreement about what is upstream? Do you imagine that you can have some things that are upstream that Chrome doesn't use? Are there examples of that?
Rick Byers: The example I know best is request storage access or storage access API. That was one where there was a period of time there, it existed in WebKit, and Edge wanted it. And Chrome said our plans for third party cookie application do not include this API. We do not expect to ever have this API. And I think Edge proposed landing it in Chromium anyway, and I and others supported it landing in Chromium. We though it was a reasonable API to exist in the Chromium open source project, even if Google Chrome had no plans of using it. Now maybe that's a little unfair because I personally suspected we were just wrong, and we were going to need the API. And ultimately that is what happened. We ended up changing our mind and deciding we did want that API. But I think in a situation like that, I would've been happy to take that position for another, especially an API that's shipped in another browser. There's an API that shipped in WebKit. Someone wants to land it in Chromium for their browser. We still have a policy. We still have to make sure that things are actually usable in Chromium. So there still has to be a test suite. We can't have dead code, so people would still have to land tests for it. I even encouraged the Edge team for that feature. I said, 'You should do an intent to ship for it' in my opinion. That even if Google Chrome doesn't want to turn it on, that doesn't mean it might not make sense to have it on by default in Chromium, but there aren't a lot of examples.
Brian Kardell: So we're kind of running out of time, but I would like to ask real quick before we're done, are there any examples that are kind of in your mind about something that is in origin trial right now that you would like more people to sign up for experiments with and give you feedback on?
Johnny Stenback: I'd say one is WebMCP. We would love more feedback on it. Go to the WebMCP repo on GitHub and give it there. That'd be great.
Rick Byers: Yeah. I was trying to refresh my memory trying to make sure I don't say something stupid. I've been on vacation for a little while, and I've forgotten what's actually gotten to ship yet. I would've said HTML and Canvas, but I can't remember if that's actually gotten to ship yet or not. But that was one I was really excited about. Has it, Johnny?
Johnny Stenback: That has not shipped.
Rick Byers: It has not yet? One, these APIs that have pretty big changes to the architecture web. WebMP is a good example. An example that's kind of now past the stage now, but the PEPC controls that we've done, the user media, geolocation APIs, those are great origin trial on. We went through a number of iterations on really what's the right way to integrate a permission control into a website. Origin trial was really useful for those. I think those are both out of origin trial.
Brian Kardell: Okay. Let's call it there. I want to say thanks to both of you for coming on and informing us, having a nice discussion about all this stuff. And hopefully it helps inform our listeners about what origin trials are and how to be involved. So thanks.
Rick Byers: Awesome. Thank you all. And of course, we love the engaging in the web standards community and the web developer community. There's all sorts of tricky trade-offs to balance here, and I don't think any of us would argue that Google or the Chromium open source project has found the perfect optimal spot for all of these trade-off spaces. So appreciate the dialogue and discussion and the criticism.
Brian Kardell
Eric Meyer
Rick Byers
Johnny Stenback