For Web apps to be useful and successfully compete with native applications, they need to be able to access device features, such as the camera, local file system, Bluetooth, and more. Obviously such a mechanism needs to be secure and respect user privacy. In this episode Thomas Steiner, a Developer Advocate for the Web at Google, joins to discuss Project Fugu, and the benefits and capabilities that it already provides, and will provide in the future. Thomas, who is actively involved in this project, explains the design and development process for this project, and how it’s being rolled out and tested.

Sponsors

Panel

Special Guest

Links

Picks

Aimee Knight

Steve

AJ

Thomas

Follow JavaScript Jabber on Twitter: @JSJabber

Special Guest: Thomas Steiner.

Sponsored By:

CHARLES MAX_WOOD: Hey everybody and welcome to another episode of JavaScript Jabber. This week on our panel, we have AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo, coming at you live from some sweet, sweet blueberry muffins. 

CHARLES MAX_WOOD: Amy Knight. 

AIMEE_KNIGHT: Hey, hey from Nashville. 

CHARLES MAX_WOOD: Dan Shapir. 

DAN_SHAPPIR: Hi from Tel Aviv and I'm really hungry now. 

CHARLES MAX_WOOD: Steve Edwards. 

STEVE_EDWARDS: Hello from Portland. And I had my son brought me some good pancakes this morning. So maybe not as good as AJ's muffins, but they were still good. 

AJ_O’NEAL: These are good. 

CHARLES MAX_WOOD: I have the blueberry muffin quest bars in my office. So I'm Charles Maxwell from devchat.tv. This week we have a special guest. Thomas Steiner? 

THOMAS_STEINER: In English, it's Steiner in German. It's Steiner, and I'm joining from Hamburg, Germany. Hi, or hello, good night. 

CHARLES MAX_WOOD: Cool. Do you want to just introduce yourself real quick? Let us know who you are, why you're famous, all that stuff. 

THOMAS_STEINER: Oh wait, I think you got the wrong Thomas Steiner in that case. Um. 

STEVE_EDWARDS: But you'll be famous after this podcast. Not finished. 

CHARLES MAX_WOOD: There we go. Ha ha ha.

THOMAS_STEINER: But yeah, thanks for inviting me. So yeah, I'm a developer advocate working for the Chrome team at Google. We work on making the web better. And a lot of our folks from the team, I would say, not only work on making Chrome better, but also making the web better. So we have Chrome developer advocate on our title, but essentially most of us really see ourselves as web advocates. 

CHARLES MAX_WOOD: Nice. 

 

Have you ever wondered if you could be offering a faster, less buggy experience for your customers? I mean, let's face it, the only way you're gonna know that is by actually running it on production. So go figure it out, right? You run it on production, but you need something plugged in so that you can find out where those issues are, where it's slowing down, where it's having bugs. You just, you need something like that there. And Ray Gun is awesome at this. They just added the performance monitoring, which is really slick and it works like a breeze. I just, I love it. I love it. It's like, it's like you get the Ray Gun and you zap the bugs. It's anyway, definitely go check gonna save you a ton of time, a ton of money, a ton of sanity, I mean, let's face it, repping through logs is no fun, and having people not able to tell you that it's too slow because they got sidetracked into Twitter is also not fun. So go check out Raygun, they are definitely gonna help you out. There are thousands of customer-centric, customer-focused software companies who use Raygun every day to deliver great experiences for their customers. And if you go to Raygun and use our link, you can get a 14-day free trial. So you can go check that out at javascriptjabber.com slash raygun. 

 

CHARLES MAX_WOOD: Well, if you're working on Chromium, you're working on Chrome, Brave, Opera and Edge, if I remember right. 

THOMAS_STEINER: Yeah. 

DAN_SHAPPIR: I'd like to say that we are really lucky that the good of the web happens to align so well with what's good for Google, that Google is able to throw its weight around for the benefit of all of us in that regard.

CHARLES MAX_WOOD: Yep. So when we're talking about what I'm seeing is just kind of these native capabilities for web applications through the browser, I'm curious what, what brought this along because usually we see this with things like Electron or, you know, on the phone with like React Native or things like that. And so I'm curious, is there a different use case that we're talking about here? Or are we just looking to enable apps that people have already built in different ways? Or I guess what's the use case or the area of concern here that this is supposed to solve. 

THOMAS_STEINER: So something we observed, and I probably should say before that, I used to work with partners of Google in a previous role as a technical or mobile technical solutions consultant. And something we saw was a lot of people were developing apps on native platforms for Android, for iOS, for Windows phone back then, obviously for desktop. So you have Mac OS, you have Windows 10. There's a lot of desire for people to build apps, but there's also a lot of desire for people to build an app only once. And most big brands, probably have two apps, an Android app and iOS app, and then they have a web app, but a lot of smaller companies also just have one Android app and then, sorry, one web app and then one iOS app, and they try to make things work across platforms. And more recently, we see even more the desire of, hey, can't we just make the web the most powerful platform that is supported universally, mobile devices, on desktop devices, and a lot of the capabilities that we talked about were, still are, supported in Electron, which essentially is a little bit just an enabler framework for making people program with something that feels familiar and that they can hire people for, essentially web, but that also at the same time has the capabilities of opening up all these platforms to web programmers. So if you have someone who is a JavaScript programmer, if you have someone who is a CSS designer, they can with Electron, with React Native, with all these helper frameworks build amazing applications that in the ideal case, feel native and that just essentially run everywhere so that people can program only once and then get their applications out everywhere. And we were seeing this development happening more and more. Google obviously had its head in the ring as well with Chrome OS. We had proprietary Chrome OS APIs that open up the Chrome OS platform, the native capabilities of the Chrome OS platform. And yeah, the developers wanted to go there. People really developed for these platforms. But yeah. At one point we saw like we need to make this easier. We need to allow people to just directly program for a web browser and not for a framework. So this is how eventually after a couple of attempts, what we call Project Fugu became a thing. And yeah, this is what we work on on our team now.

DAN_SHAPPIR: Can you elaborate in more detail what you mean by these native APIs or the APIs that are being added as part of Project Fugu, what they enabled doing that was not possible before? 

THOMAS_STEINER: There's a lot of APIs that we deal with in Fugu. One of the ones I'm working on right now is, for example, the local funds access API, so that you can get access to the local funds that are installed on a person's device. I'm working on the native file system API. I've done work on the WakeLog API. A couple of folks have worked on contact picker APIs so that you can access to, that you can get access to a phone's address book. We have web OTP for SMS authentication and phone number verification. So there's a lot of APIs. We have an API tracker that everyone can have a look at. Where all these APIs and different statuses, like is this something we are working on actively? Is this something we're planning? Is this something we just have a backlog for, but not started anything yet? Is this something we have an explainer for? So this is a big document where everyone can see where we are, what we do, and essentially just get a status update on every single API with a very fine grade level. So people can dive into the box and see what is implemented in what browser version so that you can see, like, I don't know, you're interested in native file system and you're working on directories and is directory handle implemented in Chrome 86? And you can just go there and see, is it supported yet? 

AIMEE_KNIGHT: I have a question. I'm trying to figure out the best way to ask it, but it's kind of a raw revolves around like I see that all of this stuff is really important and it would be awesome to be able to use it. But how much of this do you think is like out of the developers control, meaning we have, you know, for the web, especially serve users who don't update their browsers or stuff like that. And do you think there's anything if that is like a large portion of the problem, like do you think there's a way to help that move along? 

THOMAS_STEINER: So I think nowadays most browsers have moved to a so-called evergreen model where the browser just keeps updating independent of the operating system. The big exception obviously being iOS where you still have the coupling of browser and operating system and macOS. But everywhere else, when you think Firefox, when you think Edge, when you think Chrome, the browser just updates and is evergreen. So most people, even on older Android devices that may not have the latest version of Android, would probably still have a relatively recent version of Chrome who completely ignore updates and refuse to install them. Yes, that's what I... The general population is pretty up to date when it comes to browser versions. We're talking obviously about the stable version of browsers, so not the Nike builds, not Canary builds, not the Betas and so on. But even for the stable builds, people would in general at least have the current version.

DAN_SHAPPIR: It actually reminds me of a funny thing that I recently, a few weeks back, I got this issue from Wix support about a customer was having problems with websites breaking on her browser. And it turns out that she was still running Chrome 37, which is like, I don't know what it's like three, four, five years old. How old is that? She never ever, ever update updated. So yeah, it does happen.

AJ_O’NEAL: I think I literally am not sure how that's possible. Cause like Chrome pretty much at some point just crashes. 

CHARLES MAX_WOOD: I mean, I was going to say, I get to that point where Chrome takes over and I run out of RAM and then other stuff stops working. So then my computer's not working. So I have to reboot. And when I reboot by then it's downloaded the latest version of Chrome. And so when I come back, I I'm running a new version of Chrome and it's a vicious cycle that happens. 

DAN_SHAPPIR: I was just going to say that it was just such an old version that I don't think they even had auto update. You had to specifically enable update or something like that. But go on. I apologize for interrupting you. 

THOMAS_STEINER: I guess it was something related to Windows XP because I think Windows XP is still running on a couple of old laptops that people actually would still use. But Chrome's ended somewhere 30ish. 

AJ_O’NEAL: Yeah, like in secure locations like banks, hospitals, grandmas. 

THOMAS_STEINER: I had a Windows XP laptop for the longest of time to do my taxes because the German tax administration for the longest time had an application that only would run on Windows. And the only Windows machine that I still had in my house was a Windows XP laptop. So it might've been me two years ago. Now, luckily we moved onto the web with our taxes. We still have to pay them, but at least we can declare them on the web now.

CHARLES MAX_WOOD: Yeah. One question that I'm wondering about with this, cause you're talking about all these capabilities that are, you know, essentially being added to the browser in some way. And it reminds me a little bit of some of the other web APIs we have, like web Bluetooth and things like that, that are managed by W3C. So is this just another standard that is essentially being put out there by Google, Project Fugu, or is it, yeah, how does that work?

THOMAS_STEINER: So first, Project Fubo is a cross-company project. So we have Intel on this project who work with us. And we have obviously Microsoft on board and we have Google on board and we all work together on this project. And the weird one out probably is Intel and you might be asking why Intel. Turns out they look at what actually is running on their CPUs and it turns out in more than 50% of cases, it's a browser. So that's why they want to make sure that whatever runs on their CPUs, it runs fast. So that's why. They actually have a browser team. And the question was on standardization. So on Fubu, we work on APIs. We start with an idea. Someone thinks, wouldn't it be great if we had X on the web? And then someone from the team comes up with what we call an explainer, where they typically even on a private GitHub repo, I don't know, Jane Dayne, whatnot, slash GitHub, blah, blah, blah, comes up with an explainer document. And just roughly outlines an API shape of the API for doing X. And people start to collect early feedback. And I was like, is this even a good idea? What do you think? Should we, should we be starting to do this? And the next level then would be a couple of possible ways this could be going. So one would be they start actually implementing and just doing something, implementing this API shape behind the flag so that people interested in X could set a flag in the browser and just test it locally on their own browser instances and see what does X do, does it behave the way it is supposed to behave? And eventually, we obviously have the objective of making everything a standard. So we at some point move these private repos, these private ideas into the WICG, the web. I always have to think about the acronym, web incubator community group web incubator community group. Here we go. Which is a standardization group that works on the, in the public, in the open, where people can come together and standardize ideas and come forward with, yeah, what should a spec look like for the API that does X. And at some point after the implementation has moved forward, we actually start with moving some of these APIs over to a proper W3C repository. So for example, this has happened for. So wake lock has a W3C repository now and an official specification. Then we come to the stage where we have something that is developed in the open that has been implemented ideally by more than just one browser, and people can then start and settle on a final spec. How should the final specification look like? We in between have something called origin trials, where we say this is a feature now that is ready enough for people to actually test in practice so that they can go and set a token on their develop so that when people using these pages and they have Chrome, that their browser would see this token and then activate the API for them. So people can test APIs with real users, origin trial. So like that, the core idea is should we need changes on the APIs, we can still make them because nothing has really shipped in the sense of fully being in the open, but it has shipped with the special activation token that people need for the origin trial. Something we had before were the so-called vendor prefixes. So you had APIs like fullscreen, for example, that had something like WebKit request fullscreen, I think was the full name of the API that eventually was so attractive that. People started using it despite the vendor prefix leading to the very paradox situation where someone like Firefox had to implement a WebKit prefixed APIs just to make them work on Mozilla browsers as well. So the idea with origin trials is to avoid that so that we don't bake an API design into the browser until it's finished. The idea then being let's wait until enough people have tried it until we have figured out what are the edge cases that we didn't discover when testing locally that we didn't discover. And we tested on our small population of Chrome engineers or developer relations people. Let's wait until a lot of people in the production world have tested it, like big companies, small companies, independent developers, screen answers. So until everyone has had a chance to find bugs, find issues, find problems with the API shape, should it be, I don't know, returning this and that, where it actually right now returns a string value, should it be returning an object or anything? So these kinds of things and eventually say, okay, the origin trial bench successfully, we may have some final tweaks to the API shape, but then we ship the API in Chrome. And we then try to move it on to the W3C to make it an actual web standard. 

CHARLES MAX_WOOD: Cool. 

AJ_O’NEAL: So what keeps people from just doing the same thing where they are using an API that, you know, you don't otherwise want them to use, right? There's just a little bit of gatekeeping. Like I have to go register my website at developers.chrome.com slash origin trials slash trials slash active. 

THOMAS_STEINER: Yeah, exactly. So people have to register their websites. Edge, by the way, has the same system. So they have Edge origin trials that people can register for. Yeah, so the key thing here really is we want to make sure that people give us feedback. So you get a token that is valid for a couple of weeks. Yeah, so you register your website at the Google site or at Microsoft's origin trial site. You get a token back. This token is valid for a couple of weeks, but typically origin trials run a couple of months, sometimes a lot longer, depending on how complex or not an API is. And then when you want to renew or when you have to renew your token, because you want to continue using the feature, there's a step in our process. And I think also Microsoft's process where you have to then enter a feedback, because what we want is we want to hear from developers. Is this actually the right thing? Is this what we're implementing is this how developers would have expected the API to work. And also what we want to hear as well is has this enabled any new use cases? What would you do if this API were to go away or were not to be implemented? Is there a workaround that you would see? So you want to get feedback and by having this token system, this is our way of enforcing feedback and asking people, if you want to continue to use this, you have to say what went wrong. People can obviously just type in not available or just whatever but a lot of developers actually do give us very valuable feedback. We invite them to then also comment on the GitHub repositories of these proposals so that we can get a better understanding where are we with the standardization process? Do we maybe go back to the drawing board or is the API in a very good shape already? 

DAN_SHAPPIR: Where do you put the token that you get? How do you actually use it? I'm just curious. 

THOMAS_STEINER: You go to the website and you get a token back to copy it and on your page, insert a meta tag where you essentially have the, what's it called? The HTTP 

AJ_O’NEAL: HTTP. HREF equivalent something. Yeah. HTTP hyphen, equiv equals quotes, origin hyphen, trial quotes, and then content equals quotes, your token quotes. And then that also needs to be put in any API requests. So if it's something that has to deal with fetch or an API that would be making a non HTML page request. It needs to be specified in the request-response headers, origin trial colon, and then token. Looking, looking here at the Microsoft docs as it were, I just looked that one up when you mentioned it. 

THOMAS_STEINER: Yeah, exactly. So as I said, it's something you copy paste. The idea is you want to send a header. If you can send a header, you use this meta. I always forget the HTTP equivalent, something, something you copy-pasted, you forget it. But the idea is you send a header with your application so that Chrome the browser or Edge the browser then knows what kind of origin trial it should activate or not. If you base64 decode the token that you get, you can see that it's actually just, I think, the origin and the name of the origin trial. And that's essentially it. So it's something that you put on the page. People don't really realize it. So users don't realize that they are part of an origin trial. For them, the browser just activates to say, then ideally, can you say it. 

DAN_SHAPPIR: Some of the APIs you're describing have not been available in browsers for a reason. And that reason is security and privacy. So for example, you described one of the APIs that you are working on, which is the obvious candidate for security and privacy issues, and that's access to the file system. So how do you go about ensuring that the privacy and security are maintained in these APIs?

THOMAS_STEINER: So all the APIs that we work on are reviewed by our security team. So it's not just that an engineer comes up with a cool idea. There's a security team that tries to find weak points in this API implementation. Is there something where things could go wrong? We have W3C technical advisory advisory group who are asked to review each of our proposals. So they would find weak spots that maybe our internal Chrome team wouldn't have found, or vice versa. And we also submit everything to Mozilla and WebKit to ask for their position. This essentially means a lot of the APIs get seen by a lot of different people with a lot of different viewpoints. So some viewpoint of a browser vendor might be, we want to prevent this from happening, so they want to find weak spots. The other way around might be, we want to have this shipping, so they might play down on certain aspects. Ideally, this shouldn't be happening. Sure, that a lot of people get their eyes on a proposal. We try to find all the weak spots, all the implementation weaknesses where things could go wrong. And also just by making sure a baseline checklist is maintained, like for example, only making available powerful features. When there is a secure connection, we try to get a lot of the early API design issues. If you think back, geolocation originally just worked over regular HTTP requests. So everyone who could sniff the connection could then sniff also geolocation responses. All this has been rectified by now, but we try to not make these errors from the past again. Obviously, with each API, we do learn new attacks. We do learn about new issues people come up with. But essentially, we try to make sure that we get it right. We ask developers for feedback. We ask the Herti experts for feedback. So we try to get as many eyes as possible. And then for the very complete case of the native file system API, we just make sure that certain things just can't be accessed. So something that would be fatal to access on a Linux system would be et cetera passwords. So there's a block list of files and directories that you just may not access from a web application. And this includes your downloads folder, but as I said, also just sensitive files like or folders like your windows system 32, like these kinds of things. There's just no way around it because the API makes sure that you can't access these, these, these folders with these files. 

DAN_SHAPPIR: Is the general approach is, is it of limiting the API's capabilities or is it to request permissions or is it both? What's the general approach with this?

THOMAS_STEINER: It's a mix of everything. So essentially what we try to do is we try to make sure that the API feels right for developers. So native file system is a good example because there you have tiered access. So you have read access, you have write access, you have folder access, so you can grant access to an entire folder. And then we think of what is the permission model still happening? Like VS code, there's online version, there's PWA version of VS code. You probably wouldn't want to grant every single time you open the app access slash something, something projects. You just want this permission to be persistent. But when you think of other APIs, geolocation might be a good example. Maybe you want to grant access to a certain feature like your current location only once or only for one hour, but you don't want a website to persistently get access to your current location. So everything in between prompts with an expiry date prompts with like they just can't work because you have, as I said before, you have a system directory, for example, so the prompt would tell you, you tried to do that, but it actually doesn't work to pickers where in the case of hardware APIs, you have to specifically pick a device that you want to use. What else? We do have an approach where we say, look, we want to have this like local fonts, but we actually allow vendors or have it in a spec that vendors could also just lie. So rather than giving access to all local files, a vendor could lie and just give access to the website fonts and say, look, this browser has Arial like every other browser in the world. Whereas another browser could say, we are a browser who wants to enable design apps. So we want to give access to corporate fonts that people have installed locally and that they want to access from the web and like Google census or internal Google font that you can only find on Google devices. So if you want to grant access to this and then have a design application that works with this font, you could do that. So it's very nuanced, very, yeah, like we want to make sure to get it right for average people. And we do have a UX team internally that also reviews what should the prompt be asking? Is this something that regular web developers would understand or, sorry, not web developers, regular web users would understand? Would they understand what are the implications of clicking yes here or clicking no there? So we have this UX team who also makes sure that we formulate these prompts in the right way. And sometimes we just also have use cases that in the context of, for example, idle detection come up where we say idle detection is an API that gives you access to, is the user currently using their computer or are they idle in the sense of the screen is blocked, they may be away from their keyboard, or maybe they're just busy in another application, but not in the browser tab. So why do we want to know that? Because a lot of chat applications are run on more than one device. So you have maybe, I don't know, Slack running on your mobile device, but also on your desktop device. So the use case here would be. If we know that you're idle on your desktop, but yet that you were active on your mobile, maybe this is where you should be receiving a notification, not receiving the same notification twice. So long story short, what we tried initially was to pair or group the notifications permission with idle detection. A lot of people pushed back and said, like, wait, I just want to know if the person is using their computer. This has nothing to do with notifications in certain use cases. So one use case would be, for example, a banking website where you log in and then you go somewhere else, like, I don't know, your, your notes application on a Mac and you look for someone's banking account number, and then you go back to the tab and the software has logged you out. This is a very annoying thing for users to happen. So you were still using the computer, but the banking website thought because tab was no longer actively used, you were not using your computer. So they locked you out with idle detection. This is a use case where you could legitimately prove to the API in the browser that you're still using the computer, but you're just not interacting with the banking tab right now. So the banking tab could be kept open in a sense that you don't get logged out. And you can come back to the tab and paste in whatever banking number, banking account number. So for this use case, you don't need notification access. And we all know how annoyed people are by notification access prompts. So this is why eventually we decoupled it and said, look, this is something else is idle detection. We don't need notification access. Even if a lot of use cases are grouped with notifications, but it's not the only way to present this permission. 

 

Are you stuck trying to figure out how to get to the next stage of your developer career? Maybe you're just not advancing fast enough in the job you're in, or you're trying to break in in the first place, or for whatever reason you keep going to interviews and it's just not working. You want to land that dream coding job, but it just doesn't seem to be working out. Well, Johnson Mez has written a book for you called the complete software developers career guide. He walks through each stage of the development career and all of the things that you need to do in order to move up, keep learning, keep growing, and find that next job that's going to get you where you want to go. So if you're stuck and trying to figure this stuff out, go pick up the complete software developers career guide. It's the number one software development book on Amazon. It's sold over 100,000 copies so far. I actually have friends of mine that reach out to me and go, hey, do you know this John Sonmez guy? Cause his book is awesome. So go get the book. You can get it at devchat.tv slash complete guide. That's devchat.tv slash complete guide.

 

DAN_SHAPPIR: I'm really glad or happy to hear that you're investing effort in coming up with the really appropriate permission dialogues because if there's one thing that really annoys the heck out of me when I'm using the web these days are all the permission notifications that I get whenever I access like literally almost any website where they ask me for cookie permissions on the other, on one hand and notifications, permissions on the other, and I have and I need to accept the cookies, but I want to block notifications and I'm always worried that I'll accidentally do the reverse and up allowing notifications when I meant the cookies. So how do we get around the potential avalanche of permission requests? I mean, if I have a website that needs to access, let's say, I don't know what else you might need notifications, but it's let's say geolocation and the camera and maybe a USB device and I don't know what else. And I'm like going to be inundated with all these notification, permission requests. How is it going to be handled? 

THOMAS_STEINER: That's a couple of ways we think internally and also externally. So most of these thoughts are public on repos somewhere off the W3C. So one way is to just say, is there a way to group permissions semantically? So typically when you have something like Zoom on the web, you would have access to the camera and to the microphone at the same time perfectly valid use case to say, this is a VC video conferencing software. It needs both. So if you know that a lot of permissions are asked together frequently, like before, I said the example with idle detection and notifications, maybe is there a way to just group them? And I'm not saying that we have solutions or that we have implemented this in all cases, but like camera and a microphone today can be grouped, so you can ask for them together. So the idea here is, is there a way to find out what kind of permissions can go together and what makes a coherent story for the user as well? And one idea could be to just say, we group applications into categories and we say, this is something like an editing application, so you might want to get a grant access to the clipboard to the file system to, I don't know, local fonts maybe even, but you don't want to give access to geolocation because a text editor doesn't know your geolocation commonly. And then we could say, this is a video conferencing app. So as I said, microphone and camera, we could say this is something like, I don't know, a shopping application. So it might not need any permissions by default, but a lot of these applications need a shipping address. So maybe if you have shipping address and when you maybe then also, which happens in some markets in order to order something, need to confirm your phone number. Maybe then having web OTP as a permission or as an API that can be used on this website group together would make sense. So this is one approach. Semantic permission bundles or whatever you want to call it. Another approach that people are thinking about is maybe, is there a way to just list in something like web app manifest? What would be the permissions that this app is going to ask eventually? So that we can say, you want to install what not, a text editor, PWA, it knows beforehand, it wants to use clipboard and file system and what not, local fonts, so that then on install, you could say, yes, okay, I'm fine with that. We've seen from native applications, this is not necessarily something a lot of people understand immediately. Or sometimes you're also just like, I'm fine with two of those, but not the third. So you want to accept but not all of them. If everything is asked for permission at the beginning, there's just no way around it. So maybe there's something in between where it could say, as long as we list the permissions in the manifest, but then ask for them ad hoc only when they're needed, maybe this could work. Maybe certain permissions could then even work without a prompt. We have some PWIs that can go on the Play Store with trusted web activity, where certain permissions are granted automatically. For example, notifications will be granted automatically on the Play Store. So these kind of thoughts and circumstances. And as I said, it's pretty nuanced. We want to make sure that we get it right. The worst happen is what we call permission fatigue, where people just automatically click no or some people assume automatically clicking yes in order just to get into a site. So we want to make sure that all this doesn't happen. And something else we are looking for is just something where we look for what do the majority of people do for this site. And some of this data actually is publicly available. So there's a Chrome user experience report where you can get information about how people use your notification prompts. Do people on your new site say yes or say no? And do people on your whatnot shopping site say yes or no to a notification prompt. So with this data, we can then also make an educated choice and say, we want to show this prompt or we might want to show a more silent prompt. So you might have seen a blog post from the Chromium team, a couple of, what was it months back, I think, where they wrote about more silent or more quiet notification prompts. So choosing how to present a prompt, should it be a blocking prompt? Should it be a prompt that is a modal prompt, everything in between? And this was probably a very long winded response to the question. So as I said, it's nuanced. We want to get it right. We don't always get it right at the first try, but we try to improve. 

STEVE_EDWARDS: I understand the prompt fatigue. I know for instance, for Mac users, when Catalina came out, there was, they tried to increase the security and so speaking for myself, there was a ton of security prompts, you know, this app wants to use this and that and the other pretty soon. You're like, yes, yes, yes, or no, no, no. So I totally understand about the prompt fatigue. Cause what happens is pretty soon you start saying yes to stuff that you probably might not want to say yes to.

AJ_O’NEAL: Or just go into the settings and turn it all off and reboot into safe mode and disable it so things work again. 

STEVE_EDWARDS: Right. But yeah, my point being, I even outside of, you know, the websites and you know, OS is that's a real issue. 

AJ_O’NEAL: Oh man. Yeah. Catalina has been such a pill and it's some of its security policies are incompatible with High Sierra and below. So if you make your app work, just file permit. Oh yeah. 

DAN_SHAPPIR: Yeah. That was a big issue. Sorry go on.

THOMAS_STEINER: Something from a Chrome point of view that is really bad is when you have double permission. So you have on Katowino, for example, when you for the very first time ask for access for an API, that then you first need to ask, may Chrome, the browser use geolocation and then may example.com use geolocation. So you have this double prompting. And if someone then accidentally clicks no and blocks the entire browser from asking for geolocation from notifications from whatnot, then no other site ever can request this permission again. So there's definitely a lot of careful design that you want to make sure that you get the prompts right and make sure that people know what they're clicking. And yeah, so Windows 7, I think, was the first operating system where people got really annoyed with this when Windows 7 started asking for literally everything and every single time you wanted to make the smallest change, ask for confirmation. Do you really want to do that? Catalina got a little better because at least they ask it only once. But yes, setting up a new Mac OS system can be quite annoying until you have to make your initial choice or set of choices for all your apps. 

DAN_SHAPPIR: One API that you mentioned several times, I think you also said that you actually worked on it, is the access to local fonts. And I recall that there was this whole thing about it recently because Safari basically said that they oppose this API. Not that they're not, that they don't want to implement it. Now it's like that they don't want to implement it ever or something like that because they're concerned about its use for fingerprinting. So what happens when something like that happens? Does that literally kill the potential of having the CPI? Does it mean that we will always just have it in Chrome but never in Safari? What happens in situations like this? 

THOMAS_STEINER: So in the worst case, yeah, this is something that can happen that a vendor just chooses to not implement a certain API. Apple, they have gone public with this blog post where they wrote about 16 APIs that they consider harmful and that are harmful and that they are not gonna implement. What we want is ideally for them to still implement it so that it gives back something. But as I said before, when I mentioned the API, that they maybe lie and just say, this browser has the set of website fonts installed like all other browsers on this planet so that people at least can still use the API. Yeah it might just happen that some vendors never implement a certain API. We try to avoid that, of course, but it can happen. And what we want is we want at least to have a public record that we ask everyone. So that's why I said, we file the request for Mozilla's position. We send the email to the WebKit, that mailing list asking for an official WebKit position on each API. We have the tag review. And like that we have on the record that a lot of people, a lot of experts have been consulted and then we go forward with a decision, which could be in the worst case only one vendor or only one engine implementing a certain API. So yes. 

AJ_O’NEAL: So I've been looking at the list of the Chrome origin trials. There's a lot of interesting stuff there and some stuff that makes me sad. Like that we're getting rid of AppCache. AppCache actually works really well once the bugs got fixed. So there's, it's interesting that it's not just new stuff. There's also old stuff in here. Allow sync XHR, which yeah, it's kind of scary to me that we're now saying it's okay to break websites that have certain features by just removing them and you got to remove it or your site's going to stop working with that functionality. Cause you know, not breaking the web has been something we've striven for for a long time, but there's, yeah, there's, there's the, the idle detection, like you said, uh, the origin isolation so that the tab runs in a different process. That's almost like, you know, going back a step in terms of, you know, the trade-offs of performances. At one point we wanted everything to be in its own process and then we didn't. And now apparently we do again. That's like just kind of neat to know that a website has control over whether or not it's tab is its own process. Pointer lock, unadjusted mouse movement, raw mouse movement. Like I wouldn't, I wouldn't even know what that is. Maybe if I was more a front-end person, but I thought the mouse movement that we got was the raw mouse movement. I I'm curious about that one. What is that? Do you know? 

THOMAS_STEINER: Let me make a couple of points first. So your first one was on outcast removal and synchronous removal of a synchronous API. So these are so-called reverse origin trials where, as I said, we're removing a lot from features. We're removing things that have been, yeah, by experts determined to be bad APIs, bad decisions that were initially taken. And in these cases, yes, we actually break the web and make stuff incompatible just because they were horrible choices and current more secure, more adequate choices exist. This may in the extreme case actually mean that some site that you built 20 years back may no longer work, at least on browsers that implement or that take these changes on board, which ideally probably still should be all of them. But yeah, this is definitely something that can happen. When it comes to all these different APIs, you will always find a link where you can click through for more info. And a lot of these APIs may seem a little niche. They may be only relevant for a certain population of web developers. And I don't have concrete details on the most one, but I'm pretty sure it has something to do with games. Games in a browser want to get the rawest mouse movements, literally the signals from the mouse so that they can pass them on as fast as possible. A lot of these features, like you said, origin isolation, sound weird. The problem really is on the web, we can't have nice things. So it's all idea of having a CD or you cache certain APIs. And then if you are an example one.com and on example two.com and they both happen to be using the same CDN resource. But then if you go on example.com example two.com. But then your cache would respond to this request. Sounds nice in theory. It is nice in practice as well, but people have been abusing it by just grading unique JavaScript files for each single user, and then they have whatever something, something hash ID, something JS that they make you load. And then when you move on to the next page, they check for the existence of this file, and if they know that it's being served by the cache in that sense, they know that you're the same user. So people have been abusing this for just identifying you across different sites that seemingly have nothing to do with each other apart from maybe embedding the same ads or the ads from the same advertising provider so that they could then knit all these different profiles together and still say you are this person interested in shoes and also in wines, whatnot. So they sell this as an advertising profile. And unfortunately, this requires us to in this case, make the web a little slower. Interestingly, I was surprised as well by this. It is a number of only, I think three-ish percent of performance decrease that you get by that just because the caching effects at web scale are not that big. So a lot of people still bundle. 

AJ_O’NEAL: Wait, say that one more time for people in the back. Yeah. That you said, you said that the caching benefits are what? Not that big? 

THOMAS_STEINER: They're not that big in practice, just because a lot of people in practice decide to bundle what not jQuery or React or whatever with their sites. They have special builds. So commonly you have vendor dot something hash dot JS, and you have app dot something hash dot JS. And if you look into vendor, you can see there's two instances of load dash and one instance of react and maybe one version of jQuery, but they bundle all together in one file. Would they be loaded from a different CDN? It might, sorry, from the same CDN, then it might have this caching effect that everyone was expecting it to have. But as I said, in practice, the effect was relatively low. So I was negatively surprised by that. 

DAN_SHAPPIR: Yeah, it kind of, we had think a lot of people would download stuff from cloud flare or places like that with the assumption that somebody else, some other website would probably download it as well in that way they'll benefit because it will already be locally cached. And like you said, this double keyed cache mechanism that was introduced to avoid fingerprinting and breadcrumbs and stuff like that kind of kills it. By the way, the interesting discussion that we had with your advice, also from Google several episodes ago, also touched on these things and on effective ways to deliver resources that would still benefit from caching. I would like to say that there is still even a benefit in even in a double keyed cached world because things get cached in CDNs. So maybe they don't get cached in the browser, but they are still potentially at some CDN endpoint that's that might be closer to you because they're being served to a lot of people from a common source. But like you say, it's the web and we can't have nice things because people abuse the nice things that we want to have and it's really annoying because all these APIs that you mentioned, it's basically the fact that it's taking so long to get them, has to do with the fact that a lot of them can indeed be abused if you're not extra careful about how you implement them. I remember, for example, one API that you mentioned about access to the clipboard. This is an API that has been introduced and removed and then reintroduced and then removed by various browser iterations for years. I remember an API that existed on some version of Internet Explorer, I don't know, 15 years ago, and then got removed because people were using it to copy passwords or inject stuff into the clipboard to do bad, bad things. They would try to push all sorts of macros into office documents that you might have open in the background and all sorts of weird stuff like that. So it's definitely a problem with people are a problem. 

THOMAS_STEINER: We have this famous case with iOS 14 where a pretty big site got caught for reading the clipboard on every single or not site app for reading the clipboard on every single load. So this definitely does happen and we can see operating system vendors in this case but also browser vendors potentially. They can innovate there and say, we might not implement this API exactly like that, but we may have a separate step. So Safari, for example, requires a special click on the, uh, paste events so that when you paste something that then, or is it read? I forgot. So I think it's paste when you paste something that you then have this double confirmation that the API chat can't just be called programmatically, but you have this button that always appears that is not part of the website, but just part of the browser UI. So we do have this. Vendors can implement a spec and validly so, or spec conformantly, but at the same time also just have additional steps, hurdles, security measures. So that's pretty good about the web because it's an open platform where people can do things the way they want, but still be spec compliant. 

 

Leveling up is important. I spend at least an hour every day learning ways I can improve my business or take a break and listen to a good book. If you're looking to level up, I recommend you start out with the 12 week year as a system to plan out where you want to end up and how to get the results you want. You can get it free by going to audible trial.com slash code. That's audible trial.com slash code.

 

DAN_SHAPPIR: Chuck, I think we need to push towards picks, I think, in terms of the time. I would also like to be first, because I would have to leave soon, if it's possible. 

CHARLES MAX_WOOD: Dan, why don't you go first then? 

DAN_SHAPPIR: Yeah. I have the one pick, and that's the thing that's going on with Mozilla. To be honest, I'm not an expert exactly on what's going on there. I understand it on one hand. They've let a whole bunch of people go. And on the other hand, they just renewed their agreement with Google, which potentially gives them a whole lot of cash. So I don't know exactly how this works. I think they let go something like 250 people, which is a lot for an organization like Mozilla. And I literally don't know what's going to happen with the future of their browser and other tools. Actually, the thing that bothers me almost the most is what's going on with the Mozilla Developer Network, MDN. I don't know about you guys, but I'm a huge user of MDN. Like every time I search for some API, it usually starts by MDN and then the name of the API just to make sure that I get my response from MDN and not from somewhere else and they essentially let go of all the paid employees, Mozilla employees, that worked at MDN. So MDN still exists, but it's essentially now it's all going to be based on volunteers and not on paid Mozilla employees anymore, and I don't know how that's going to work. And I really, really hope that MDN is not going to die because I just don't know how I would make do without it. I'm thinking that a lot of organizations that have, like certainly the bigger organizations that employ web developers should step up and, and find ways to fund this project. We really can't afford to lose it. And we can't, even if it survives, but survives badly, that would be really, really bad in my opinion. And that's my pick for today. 

CHARLES MAX_WOOD: All right, AJ, what are your picks? 

AJ_O’NEAL: Give me a second. I'm opening up my list. Think I had something ready. And hands here. Okay. Yeah. So I'm going to pick comrack, which is a markdown renderer written in rust. It's total download load size is something like two to three megabytes, depending on whether you're on Mac, Linux or windows. And it supports common mark. It's actually a clone, like a, like feature for feature of get homes, get hub zone C mark. So it's got full GitHub flavored markdown support. It's got all of the standard extensions, as well as just a plain common Mark rendering mode. And so I was really excited to find that and really excited that the author was willing to put up prebuilt binaries so that you can have a small, lightweight, simple way to render Markdown without having to have an entire tool chain installed for an application. Like as, as you may have picked up on some of you, I really like it when there are standalone utilities that don't require having to have Python installed first or node installed first or Ruby installed first or the go compiler or the rest compiler or the C plus plus compiler, et cetera. So it's really nice to have just a small and simple tool. And I've got a cheat sheet up for it on web installed.dev slash C O M R A C, which I'll link to there. And then I am also going to pick one of the products that I have worked on. Sonos radio because it is different. Like it's, it's not for the Spotify type people per se. It's, it's a very more like, dare I say mature curated experience. There's a focus on one, you know, a paying customer, somebody that's actually bought a device that's $100 or more about, I think they might have some that are in the lower $50 or something like that, that also would have this. But the Sonos is a device, a speaker device for those that don't know, I just kind of assumed that most people know about that, but I'm sure some people don't because they're in Walmart, Ikea, Best Buy, wherever you go, there's Sonos speakers these days. But anyway, the cool thing about Sonos Radio is that it's focused on the space in between the songs. And that sounds kind of weird, but you know, almost like it's like an ad or something. But well, I guess that's what it is. It's overlays and ads. It's like the conversational bits, which is it's done in a different way. It's more like what you'd hear on the traditional radio and less like what you're used to with online services, because you've got like the DJ type people that are speaking over songs as they transition and fade. And they give like really good little short bio snippets of artists or short like history bits of songs. And so it's just this very, like, if you're a music enthusiast, it's a very nice service because it, it just has that feeling to it that you're, you're more connected with the songs and the artists and the what, and the transition between the two feels purposeful, not just on accident, like between two songs, et cetera. Anyway, that's my, that's my, my plug for Sonos radio. 

CHARLES MAX_WOOD: All right, Amy, what are your picks? 

AIMEE_KNIGHT: I am going to go with, um. I have like two lists. I have my Evernote list and then I just have everything I star on GitHub, which I tend to neglect sometimes for picks. So I'm going to go over to what I've starred recently in GitHub. And I'm going to pick a repo that is just a bunch of Nginx configuration snippets and the explanation of them. Cause I think this kind of stuff would have been really valuable to me way back in the day and a lot of it still is valuable now, can be it for me.

CHARLES MAX_WOOD: All right, Steve, what are your picks? 

STEVE_EDWARDS: I'm going to go with book today. Let's buy, grab it off my bookshelf here, if you think I'd be prepared. They're historian of mine, his name's Rodney Stark. He's a professor at Baylor University in Waco, Texas. And it's book about the Crusades. It's called God's Battalions. And it's in his typical style. It's very, very detailed on the before and the after and what happened during the Crusades. You know, I think there's a lot of fallacies out there about the Crusades. I certainly have heard them repeated in multiple parts of the world. And it's just a real good, straightforward, unblemished history as to what was going on before, what caused them, what happened during, and so on. So just a really good, thorough book. 

CHARLES MAX_WOOD: Nice. I'm going to throw in a few picks on my own. Lately, I've been reading this book. I don't know if I picked it last week, but it's called Leadership in Turbulent Times. And it's kind of an interesting look at some of the US presidents, namely Abraham Lincoln, Theodore Roosevelt, Franklin Roosevelt, and Lyndon Johnson. Some of them aren't necessarily my favorite president, but it's interesting to see the background and how they made calls regarding what they had to deal with. Because yeah, they all went through different things in their presidency and had to make some difficult calls. So anyway, yeah, those are my picks. Thomas, do you have some picks for us? 

THOMAS_STEINER: So my pick is, I guess, a website or web app rather that I've been contributing a very, very tiny bit to, which is called Excalibro. It's a cartoon style drawing app. And it was founded by Christopher Chedot from Facebook. And I read this blog post where he just wrote about, I made this little app back then, it could do a very small set of the things that can do today. His approach was to say, look, I grant everyone right access to the repo, or push access to the repo from the beginning. So I was intrigued and I was like, wait, that's, that's a very courageous move to say, to just say everyone can get push requests from the beginning. I looked around and there were a couple of things that people implemented and that started working on was this amazing community where just. Random folks contributed amazing features ranging from, I don't know, just a couple last ones were blue points. So you can have diagrams that have blue points in between them. And if you move one box, the arrows will stay connected to the blue points and actually just reorient, depending on the orientation of the boxes and stuff. It has an amazing dark mode. It has whatnot a component library where I can just say, I need this and that component frequently. So you can just put it in a shelf and then pull it out and have your own custom shapes that you can just occasionally use whenever you need them. And my tiny contribution was that I implemented a native file system access to this API. So it was just essentially a little contribution that allowed people to save files and open files again actual files. So people could just then press command save, but just magically save, not download. And not if you have worked with apps like that in the past, you would have a download for every single iteration of the files. You would have file one, file two, file three, file four, and so on. So you were not overriding files, but you were actually downloading them each time for a new file. So this small change that feels very natural, but just a relatively big move for that, for this application. And it also uses a couple of Fugu APIs. I absolutely, absolutely can't take credit for them. They just did it. Like you can copy images into it. You can paste images into there. It has a right click menu. It's a full blown desktop PWA. It runs on mobile. It's just a very well-made responsive application. And the best about it is the community. And yeah, I'm happy to have to make this super tiny contribution to it. And I invite everyone A to try it and B to contribute to it. The community is really great. 

CHARLES MAX_WOOD: Cool. All right, Thomas, if people want to connect with you on the internet, where do they find you? 

THOMAS_STEINER: I'm Tomajak almost everywhere. So that's T-O-M-A-Y-A-C on Twitter, on GitHub. That's my domain name as well. So that's the way you have to find me. And yeah, so I'm happy to answer more, I don't know, detailed questions that didn't get an answer in the podcast. And yeah, looking forward to hearing from folks. 

CHARLES MAX_WOOD: All right. Well, thank you for coming. This has been really, really interesting. 

THOMAS_STEINER: Sure, thanks for having me. 

CHARLES MAX_WOOD: All right, we'll wrap up folks and we'll have another episode next week. 

STEVE_EDWARDS: Adios. 

CHARLES MAX_WOOD: Max out. 

AJ_O’NEAL: Adios. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit C A C H E F L Y dot com to learn more.