The Origin Trials

Phil Nash at Code 2020

Transcript

(cheerful music) - Thank you very much, John.

What's up everybody? As John said, yeah, my name is Phil Nash.

I am a Developer Evangelist in a company called Twilio. These are all places you can find me online. Please do find me online.

And if you've not heard the Twilio before, it is a communication platform that you can use as developer to do things like send receive text messages, make or receive phone calls, video chat, regular chat, all sorts of communication, anything you want to do with that, we have API's for it.

Before we get started to tell you about the origin trials today, I do want to do one quick shout out we have got a strange situation in which, I know that there's...

I'm recording this right now, but I know there's one person in the audience that won't have seen me talk before, so I just wanna say, hi to Phil, I hope this next 20 minutes listening to your own voice is not too much pain for you.

So getting on, talking about weird situations that were in, the origin trials sounded to me when I wrote this topic like, like a bit of a young adult dystopian thriller. And right now I don't feel like we need any more dystopia. So you'll be glad to hear that this is nothing to do with that.

It is more of a pleasure, a privilege, an exciting time for developers and these origin trials that we're going to talk about make our lives better and more exciting.

So you will have heard earlier today from Kenneth about the tests and things that Google Chrome team is doing with Project Fugu.

And I actually like talking about those Project Fugu things myself.

And that's what kind of brought me to this. I mean, Project Fugu is full of exciting new developments that we can use as developers.

Some of them have made it to browsers, some of them are tests right now, some of them are just explained documents on GitHub. But yeah, I've been talking about these to people. And what I found was that when we got to the bit of the process where we talked about origin trials, I would ask people, like who's heard of what an origin trial this before, I was kinda hoping to see if you hands up.

And for the most part, it was much a case of no idea what this is.

And so I thought this was absolutely important for us as developers to move the platform to understand what we have in our hands at our disposal when browsers are creating these new API's to be a part of that, to test it and to work with it. So what is an origin trial? Well, they're there to help us and help the browser's design the right API's for these new features and to make sure that they are secure and private for users as well.

And that is the absolute key for anything that we release out onto the web, because websites are just a URL away from any user, that we must make sure that we keep the privacy and security of those users in mind at all times. And the API design side of it is just simply that, if we make a nice feature but the API of it is terrible, new developers never want to use it, it will also not get used.

So that's a bad thing.

So origin trials are how we test as developers, how we test experimental web features with real users. It's sort of as simple as that.

But there's a bit more to it.

So I wanna take you back to why this is come about, what an origin trial is by starting in 2016. 2016, plenty of things went on in 2016.

But the thing I want to draw your attention to is the release of Firefox 49.

Back in the 20th, September 2016.

Not a particularly amazing release of Firefox there wasn't a huge amount of stuff in it a couple of features.

There was the addition of the web speech synthesis API, something I spoke about at web directions code last year as it happens, that was the first time it arrived in Firefox. It was also the removal of Firefox Hello.

Firefox Hello was a whole video chat platform built into Firefox based on WebRTC.

Not quite sure why Firefox itself decided that it needed to be a video chat platform. But in Firefox 49 and 2016 it got removed because it was a bad idea.

But the real thing that happened in Firefox 49 was that Firefox implemented a whole tonne of WebKit prefixed properties in CSS.

You might be asking why or what even, like there was a bunch of things webkit-linear-gradient background-clip, WebKitCSSMatrix, those three. Well, so two of those are CSS, there are some other CSS things.

The CSS matrix was a custom DOM function that would return some CSS with get computed style. And Firefox also went and implemented a whole bunch of WebKit prefixes for things they'd implemented themselves, including old Flexbox, like the earlier version of Flexbox that didn't actually get released, border radius, animations, transitions, all sorts of things like that. And so now you can use or at Firefox 49, you could use the WebKit prefix for those properties. Bit bizarre.

See, this was the old vendor prefixes, it was the time when browsers wanted to experiment with something, they'd pop a prefix on the front of it, on the CSS or on the JavaScript property.

And then you could use it, to test it out, even try it out with users.

And that was great.

It was very popular, right? We got new things into browsers and you could test with them.

I remember the first time I did a border radius for the first time, I didn't need to slice up an image into several different parts and hack some CSS together to make that work in a responsive manner.

It was great.

But you ended up with maybe JavaScript that looked a bit like this.

If you had request animation frame, for example, you could be asking for the standards based one but also the Mozilla one and maybe the WebKit one, and then also the opera one, and the Microsoft one. While this didn't actually apply to requestAnimationFrame, you only needed mores and WebKit for that.

It meant that you could either, you ended up forgetting these things or just using the prefix version and eventually breaking the web.

And that was the problem.

These were all experiments.

Or that's what they were intended to be.

And sure, they made it into the browser code and they were there, but they were supposed to be experiments.

The prefixes were intended to be ugly, so that as developers, our idea of pure code, we'd eventually try and remove them.

Before we shipped our projects to production but we didn't, we got excited about it and shipped things straightaway.

And we shipped all kinds of prefixes all over the place, all of the time.

Again, when you have that joy of not having to slice up an image or use JavaScript animate something, of course, you're gonna use the tool that's there for you. But we also make that mistake of only doing the WebKit prefix, maybe not including prefixes for other browsers that we're experimenting with it, or not including that standard based non prefix version at the end of the day.

This ultimately did leave the web broken in certain browsers.

And that's why in Firefox 49, they released all these WebKit properties.

This led to, what I found when I was researching this topic. This is compatibility spec that's a living specification with the W3C or with the WHAT Working Group, which is a spec that tells you all of the non standard properties that a browser should implement to ensure that the web works for all users as intended.

It's very strange that this exists, but it does. And it's full of WebKit prefixes for the most part. So that was sort of our problem as both browser vendors and developers kinda getting together and shipping these things incorrectly.

Developers we got better at this with the on set of tools, thankfully, things like autoprefixer allowed us to forget about the prefixes that we were putting on front of our CSS and allow a tool to deal with that, and only slither prefixes that were would needed at the time.

Then there's Babel for JavaScript, which would allow us to experiment with new language features and other things that you couldn't just polyfill and then of course, there were polyfills for certain platform features that allowed us to not only kind of experiment that new stuff, but put it back to old browsers as well.

That's all very well.

But what about when we come to things like new web platform features, the stuff genuinely just cannot exist in JavaScript land or in CSS land? When you're talking about native file access or Bluetooth access or anything like that, we can't just polyfill that in.

It doesn't exist in the browser.

So where are we left then? And can we avoid vendor prefixes for it? Yes, that's the idea.

That's the idea where we get into all of these things, these days are sat behind feature flags.

And if you are a developer on a project, you may well have shipped your own feature flags, which allow to send software into the production version but not actually enable it or only enable it for a few users.

Feature flags allow us to do that and allow browsers do that as well.

And so, inside Chrome if you gotta a chrome://flags, you get a whole bunch of flags which you can check. But this is my favourite one.

That's the experimental web platform features. This one allows us to play with those new features as they arrive in the browser.

I also have developer tools experiments turned on, so I can get all the latest stuff in my developer tools as well.

But as you can see at the top is a warning, saying that these are experimental features. And you may lose the browse data or compromise privacy or security with these new API's.

This is not something you want users to do, ever. Notably also, these days, you can set the same kind of flags in Microsoft Edge, edge://flags.

And then we have experimental web platform features there as well, as well as other experiments, which you can play around with, most of these exciting kinda new features I'm talking about sit under that experimental web platform features, platform. So that flag exists, then it's great we can experiment with these API's on our own machines, turn that flag on, see how everything works. Send feedback if we have it and just generally get excited about these new things. But the question then is, what about users? You see, we never really want to be shipping things to our users, especially kind of these potentially dangerous API's to users, we don't wanna ship them, browsers don't wanna ship them without that proper testing as well.

This is where the origin trail actually comes in. Finally, origin trials allow us, as I said earlier, to test these experimental things with our users. What does that mean? Well, there are a bunch of origin trials available for both at the moment, Chrome and Edge both work with them. And if you go to that site for Chrome, it tells you all of the available origin trials, all the new features that are kind of inside the browser already, that we can kind of flick on.

And so origin trials, you register for them, anyone can do so.

And once you do, you kinda get a key.

And that key needs to be shared on your website as a meta tag, or you can do as an HTTP header. It looks a bit like this.

This is an origin trial meta tag, I used on my own site to play with the web share API, back in 2017.

That was a sort of another early precursor to project Fugu kind of things.

I think it may be even fits right at the start of it. And you can see a few things here, we have a feature that we're applying to the expiry date of it.

And then a content is the key that allows your origin, your URL to use this feature.

Origin trials have a bunch of rules about them. And this is what makes them work for this purpose. They have a fixed time limit.

So as you saw in this meta tag, there's actually expiry dates right there.

When it comes to the Edge, Edge is version of this, they allow your key to last for six weeks.

Origin trials can be cancelled, the feature can be pulled at any time.

But there's a couple of particularly important times, one in Chrome, they will pull the feature out if usage of it claims over half a percent of users. This is actually their current threshold for deprecating and then removing features as well.

So if a feature falls below half a percent, that's where the Chrome team are happy to then remove it from the platform.

If that usage goes above that half a percent that means that there's too much experimentation, too much excitement, maybe with developers and we're starting to ship too many things to production that are experiments.

So if an origin trial gets too popular, it gets pulled. It's good.

It's also cancelled if there's a security breach, like if something does go wrong with an API, the browser can just turn it off immediately. The feature may also change during the trial. These trials are for feedback both from users and developers.

So there is feedback that requires it to change, it might do.

And the feature after the trial has finished may or may not ship, you may never see it again, it might be decided as a bad idea all around. And one of the things that passing an origin trial does not make that feature a standard, it gets a closer to going on to the standards track. But it does not mean that this will be implemented by other browsers either.

So as a developer, if you are working with an origin trial, if you're using one of these new API's, you must write your code defensively, I think this is really important.

You must progressively enhance the code, you gotta test for the existence of the feature because it may not be there.

You should actually test for the existence of the parts of the feature you're using because they could change. And the second and more important thing really is just give feedback about it.

Don't just implement the feature and send it off into the wild the browser's who are taking part of these origin trials want that feedback, both on the developer experience and the user experience of the whole thing. I wanted to really call out the fact that the feature may change because I've seen this happen in some of the more recent API's, these features may well change underneath you. That happened Wake Lock API.

The Wake Lock API allows you as a developer to request to the system that the screen doesn't go to sleep.

Really useful if you're doing things like a game that doesn't require touching the screen as an interaction or any other kind of sort of interactive things but that don't require actual input anytime. The Wake Lock allows you to keep that awake. Navigation in maps is a very good example of that. And so, acquiring the Wake Lock back in the first version of its origin trial, was done using the navigator Wake Lock objects, the request function and that would return a promise and actually return a promise that never resolved successfully.

And that was weird.

And so if you wanted to release that lock, you actually use the abort controller, which is, it's a way of cancelling promises that came out of the cancelable promise debates from a few years ago as well.

The abort controller is something that is used with other promise based things like the Fetch API. And this is how you would abort or release the lock on a screen, you'd create an abort controller and use that signal descend into the wake lock request and then abort it later when you needed to. And this was weird.

Developers didn't like this, because you're like a never resolving promise is a very weird thing to deal with.

And I promise that you eventually have to cancel. Very strange experience.

And so partly through the origin trial, it changed and now that promise will actually resolve when the lock is successfully acquired, you can listen to events on the resultant.

So this becomes a wake lock sentinel now, so you can listen to events on it, such as when the browser itself releases the lock, even if you didn't ask for it.

And then you can use that sentinel later to just release the lock yourself.

So if you'd implemented the first version of this and you didn't keep up to date and change and check your code and make sure it was working as expected, this would have changed on the way. So there's origin trials they can change underneath you. So you must as I said defensively programme against this and progressively enhancing because eventually Wake Lock is also getting taken away before it gets released. So origin trials are not standards and this is important as well.

And it's important that we as developers understand that but also use it as a way to petition other browsers as well. I know this recording is being played a bunch of time later. But I recently, only very recently saw this article on tracking prevention in WebKit, which is said up front that WebKit in Safari will not be implementing Web Bluetooth web MIDI, magnetometer, NFC, battery status, ambient light, all sorts of API is that the Chrome team been excited about and developers have been excited about getting things into people's hands.

One of the reasons they are not going to do this is the ability for malicious kind of scripters to use this to fingerprint users browsers and kind of de-anonymize things.

It's understandable as a protection mechanism for users. But on the other hand, there's a lot of exciting things in this list that it's sad to see not implemented in other browsers.

Mozilla has sort of agreed with this and there's a more in depth mailing list article, mailing list comments to read on what they think about this as well.

But this was WebKit very public kind of web page on this and (laughs) that it named and listed all these API's, a number of which have gone through Project Fugu and our origin trials and excited developers about. So a little bit of a downer near the end there but if these API's work for you and you think they work for your users as well, there is good reason to then petition browsers to include them or work on ways to make them not a vector for attack.

Notably, also tracking protection fingerprinting is only one of the reasons that WebKit is saying, they won't implement these things.

It's just part of the reason.

But ultimately, the web itself has a lot to offer, both us as developers and then allow us to offer to users and it's getting better as well.

We need to get it right, between browsers and developers we need to not make the mistakes of the past that caused certain browsers to have to implement other browsers things.

We need to make sure we don't get things wrong for users as well.

And keep that security and that privacy in mind as well. But I want to get you to experiment, I want you to take all those things that you saw in Kenneth talk earlier, starting implementing them, play around with them on your own sites, but then see which ones are going to apply for your production applications, for your businesses as well and see how that's gonna help. And once you experiment, send that feedback as well. It's the only way that we can all agree on this is to get as much feedback as possible, get into the hands of the browsers and of the API creators and then get these API's released as production. I'm excited about the future of the web.