PWAs: Past, Present, Future

The first working draft of HTML5⁠, then known as Web Applications 1.0, was released on September 1, 2005. For context, that’s almost 18 months before the first iPhone was released, over 3 years before Android was released, and over 4 years before the terms Mobile First⁠ and Responsive Web Design⁠ were coined.

Before all of that, there was this draft, this thought, of what the web could be. The first sentence of its abstract sums up its intention:

This specification introduces features to HTML and the DOM that ease the authoring of Web-based applications.

Applications. That was the vision for HTML5⁠. That vision, put forth September 1, 2005, was a powerful one: that the web could, and should, be a place for applications—not just documents. A vision we’re still trying to fulfill.

In just a few short years, the world the web lived in would experience a true paradigm shift, if ever there was one, as it moved from desktop to mobile. But this idea, that the web could be a place for applications, proved strong enough to withstand the shifting sands of computing. Even more than that, it would show the need for the web to make this shift.

But that’s getting ahead of the story.

HTML5 offline web apps

Up until the introduction of HTML5, the web was designed to only be available online. A series of connected documents. With applications as a major driving factor for HTML5, there became a need for web applications to work offline.

One of the most frequently requested features for Google's web applications is the ability to use them offline. Unfortunately, today's web browsers lack some fundamental building blocks necessary to make offline web applications a reality. In other words, we found we needed to add a few new gears to the web machinery before we could get our apps to run offline.

In May of 2007, Google introduced an open source browser extension, Google Gears⁠, designed to help make web apps work offline. While not a web standard itself, it was built on top of web standards, adding “just enough AJAX to make current web applications work offline,” with the goal of evolving it into a set of web standards.

Gears included a number of components that may sound familiar to you today:

• An SQLLite-powered database
• A local server that could cache and serve resources
• A way to create desktop shortcuts

While Gears would be officially deprecated in March of 2011 in favor of web standards that had finally caught up, its influence is hard to miss.

The earliest draft of the HTML5 spec I can find that mentions Offline Web Applications comes from October 2007⁠. A subsequent draft⁠ sums up the capabilities that HTML5 provides to help applications work offline:

• Client-side SQL
• Online and offline events
• localStorage
• And, finally, “offline application caching APIs,” later known as ApplicationCache or, simply, AppCache

AppCache was a big deal. For the first time, there was a standards-based way of telling a web browser that certain assets, your CSS, your images, your HTML, should be made available to a user when they’re offline.

It was also entirely declarative. You created a cache manifest file, put in the specific files you wanted the browser to cache, and it, through a series of built-in rules, would.

The first two browsers that would get full AppCache support were Safari 4 and Firefox 3.5, both released June of 2009. Android Browser 2.1 would later that year, then Chrome 4 and Safari on iOS in early 2010. It wouldn’t land in Opera until mid-2011 or Internet Explorer until the end of 2012.

AppCache was great in theory, but In practice, it had a lot of gotchas.

Jake Archibald described why it was so hard to work with in his A List Apart article Application Cache is a Douchebag⁠. A few key, painful, ones mentioned include:

• Files cached with AppCache would always come from the AppCache, even if the user was online
• The AppCache would only update if the content of the manifest file had changed, not if the content of the things cached changed
• Non-cached resources wouldn’t load on cached pages, even when online, by design

Replacing AppCache was the start of a new chapter towards what we know as PWAs. But before we get there, we need to take a detour to see what web apps looked like on desktops at the time.

Chrome Apps

From conversations with members of the Chrome team who were there at the time, what we today know as Progressive Web Apps started life back in 2010. At the time, there were two competing schools of thought for how to make the web a better app platform:

• One school of thought was to work with the standards process and improve the core platform
• The other school of thought was that the standards process wasn’t fast enough for the features they wanted to deliver.

The group that wanted to work through the standards process, led by Alex Russell, Dimitri Glazkov, and Alex Komoroske, went on to propose or help drive web standards including:

• Mutation Observers
• HTML Templates
• Object.observe
• Web Components
• ES Modules
• ES Classes
• CSS Variables
• and Web Animations, to name a few.

The group that wanted to work faster than the platform created Chrome Apps.

Launched December of 2010, Chrome Apps’ goal is something you've likely heard from any number of similar solutions, from Electron to Cordova to even Progressive Web Apps today: build fully-featured applications that just happen to be built with web technology. In fact, Packaged Chrome Apps⁠ may sound familiar to you PWA developers out there:

• They could be launched from outside of Chrome, got their own app windows, and could generally behave like other apps.
• They were offline by default. Resources required to run offline came with the app, and it included APIs to make pages resilient under poor network conditions.
• New APIs were added to get low-level hardware access, for instance to USB and Bluetooth, and new shared data APIs to let you more easily inter-operate with other applications on the system.

Chrome Apps also introduced Native Client (NaCl) and siblings, allowing web apps to run C and C++ code in the browser, creating a migration path for existing codebases and better performance than could be achieved with JavaScript alone.

What these two teams learned and developed during this time would become indispensable as people took another pass at getting web apps to work offline.

Rethinking offline

In August of 2012, a group of developers and browser vendors came together to talk about AppCache⁠, first in London, hosted by FT Labs, then in Mountain View, hosted by Mozilla. The goal: talk about practical experiences with sites that developers were presently building.

Facebook, Gmail, the Financial Times and the Economist, Twitter, and Microsoft Outlook were among the participants. The conclusion? Not quite tear it all down, but pretty close to it.

The extensible web manifesto

In June of 2013, the Extensible Web Manifesto⁠ was published. Remember that group I mentioned that wanted to improve the web through the standards process? One of their leads, Alex Russell, would help write the Extensible Web Manifesto. It solidified many of the lessons he learned in that previous work.

The authors of the Manifesto had seen that, with high-level abstractions, users either needed to buy into the entire thing, or replace it entirely with an alternative. They believed that users should instead be able to be able to take control only at the points they needed to accomplish the job they wanted.

With this in mind, the manifesto offers four design principles for an extensible web:

• Focus on adding new low-level capabilities that are secure and efficient.
• Expose low-level capabilities that explain existing features, allowing authors to understand and replicate them.
• Create a virtuous cycle between standards and developers by developing, describing, and testing new high-level features in JavaScript and allowing developers to iterate on them before they become standardized.
• Prioritize efforts that follow these recommendations and deprioritize and refocus those which do not.

Enter service workers

The first commits⁠ for what would become the Service Worker spec were laid down by Alex Russell in February 2013 and by the time the first public working draft⁠ was published on May 8, 2014, the Service Worker spec was shining example of the Extensible Web Manifesto in practice:

• Where AppCache provided a high-level declarative syntax for caching and then had its own rules for deciding what to serve, Service Workers and the sibling Cache Storage API were low-level APIs that allowed users to script what should happen with JavaScript
• Using both Service Workers and the Cache Storage API, users could describe, and recreate, how the browser handled caching and how AppCache handled caching.

Chrome 45, released September 2015, was the first browser with full support for both the Cache Storage API and Service Workers. Firefox 44 and Samsung Internet would get support in 2016, and Safari 11.1 and Microsoft Edge in 2018.

By the end of 2020, some 13 years after it was first described, AppCache has officially been deprecated and removed from Chrome, Edge, Opera, and Firefox.

Service Workers, and working offline, is only part of the Progressive Web App story. Getting onto the home screen required something else.

Add to home screen

When the iPhone originally launched in 2007, it didn't have the App Store.

The original iPhone came with standard apps, Safari 3.1, and the ability to make special website bookmarks, known as "Web Clips," which would add a website to the user's home screen.

Then, on July 10, 2008, just over 2 months before Android was launched, Apple released the App Store, and fundamentally changed how people thought about software; where to find it, how to buy it, what it should cost, and what their relationship with it was.

As it turned out, software development, especially on the web, was going through not one but two paradigm shifts: the move from desktop to mobile, and the move of app discovery from search engines to app stores.

The web, though, had no app model at the point in time when conversations about software development centered on apps. The result: uncertainty that the web would survive the tectonic shifts happening. By the time the web had an answer, it had seemingly already lost.

Building on the trends of multiple years of data, the comScore 2015 Mobile App Report⁠, painted a stark picture of web usage on phones: users spent just 13% of their time on mobile devices in browsers; the rest was in apps. Apps were eating the world. But apps are tough business.

While the majority of time was spent in apps, comparing the top 1000 mobile web properties vs the top 1000 apps, the web had audiences 2.5x larger and grew twice as fast.

That said, while it was harder to build an app audience, app users spent 18x more time in their apps than mobile web visitors did.

Apps also seemed to be a zero-sum game; 4 out of 5 smartphone app minutes were spent on an individual’s top 3 apps. Tablets, even more so.

The big takeaways comScore had from this data were that:

• It’s easier to build a larger audience on the web quicker because of the web’s superpower: linking.
• While mobile app usage was exploding, that wasn’t at the expense of the mobile web or desktops, so they believed the key growth opportunity was in multi-platform engagement.
• Finally, app usage is a reflexive, habitual behavior where those occupying the best home screen real estate were used the most frequently.

The web at this point had already more or less won Desktop for most use cases, and it was already easier to build a larger audience faster on the web than apps. Linking and a single shared platform across mobile and desktop meant distribution on the web was much easier. What was the web missing to stay competitive with mobile apps? It lacked an app model.

The 2015 comScore Mobile App Report came about at just the right time, as the pieces needed to let a site be added to a user’s home screen were finally falling into place.

The missing piece to the app model puzzle came December 17, 2013 with the publication of the first working draft of Manifest for web apps and bookmarks⁠.

The spec, now known as the Web Application Manifest, was initially written by Marcos Caceres from Mozilla and Anssi Kostiainen and Kenneth R Christiansen from Intel. It was designed to consolidate metadata about a web app, like name, icons, and URL to open when launched, from various meta tags into a single place. Its goal: to "enhance bookmarking capabilities such as being able to add a web application to the homescreen of a device."

On mobile devices, Chrome would add support to add web apps to the home screen in Chrome 39, November of 2014. Samsung 4 would follow in 2016 and with Safari 11.3 in 2018.

Between working offline and Web App Manifests, including key features like start_url and icons, the web now had installation criteria for adding a website to the home screen. That criteria hasn’t changed much since⁠.

But, it didn’t have a name. They were just “installable web apps.”

On June 15, 2015, partners Alex Russell and Frances Berriman would coin the term Progressive Web App⁠ to describe web apps that were as reliable as, and could be installed like, mobile apps. A normal website that, when built well and earns a place on your home screen, could progressively become an "app."

The name stuck.

The first Progressive Web App

Half-way through 2015, all the pieces were in place for an app model for the web. It had service workers to allow sites to work offline or with limited connectivity, it had the web app manifest to describe how an installed site should function, and it had a name: Progressive Web Apps. It was only a matter of time before one existed.

The first PWA I can recall, and maybe the first one you can too, is The Air Horner⁠ released by Paul Kinlan midway through 2015. While fun, it’s mostly just a demo.

Or, it may be the Google I/O 2015 website, which was probably the first large-scale PWA and whose development motivated the creation of sw-precache and sw-toolkit, what would go on to become Workbox.

But, the world’s first production PWA is generally considered to be Flipkart Lite⁠ by Indian e-commerce company Flipkart, released November 9, 2015. Introducing their PWA had a dramatic effect⁠ on their user engagement. A key metric for Flipkart at the time was tracking data usage to complete the first transaction.

When comparing Flipkart Lite to the mobile app, Flipkart Lite used 3x less data. This was especially important as 63% of Flipkart Lite users were on a 2G network. Service workers and the low friction of the web's distribution model combined to make these possible.

Getting Flipkart Lite onto the home screen was important, too. 60% of all visits came from launching from the home screen, and those users converted 70% more than average users. Those two activities alone grew overall engagement 40% higher than it was before.

Flipkart proved that PWAs could compete with mobile apps when installed. But e-commerce is a space the web was already good at. To be a truly competitive platform on mobile, the web needed to be able to take on platform apps on their home turf.

Making PWAs capable

By design, the web is less capable than platform apps; its drive-by nature makes exposing many APIs and features a security risk. But...

When the web is capable of delivering a particular experience, it can compete.

Linking, and the lack of gatekeepers to get your site online, give the web a better distribution model than app stores. A change to how PWAs get installed paved the way to closing this capabilities gap.

The initial implementation of PWAs on Android was by design minimal; basically they were glorified home screen shortcuts. They didn't show up in the app drawer, they didn't show up in the app switcher, they didn't really "feel" like apps besides having a home screen icon.

On Android, the base unit of administration for an app is an APK, or an Android Application Package. The APK is how Android deals with things like:

• Notifications
• Running in the background
• Targeting for sharing
• Backup and restoration
• And more!

After the successful launch of Flipkart Lite and momentum behind PWAs started to build, the initial implementation’s lack of integration needed to be fixed. On May 10, 2016, the first CL for Web APKs was merged into Chromium⁠.

WebAPKs were a big deal for how Progressive Web Apps would evolve. Dominick Ng, a lead for Progressive Web Apps at Google at the time, shared: "WebAPKs really built the foundation of the deep system integration that we've pursued ever since." That deep system integration started life as as Project Fizz.

Project Fizz, named to compliment GIN, an early codename for Chrome, had been around since 2014, not as a formal team, but as a collection of teams within Google, with the goals of:

• Bringing top-requested APIs to the open web
• Creating infrastructure that enables new capabilities to be experimented with and exposed in risk-limiting ways.
• Optionally enable web apps to receive the same UI treatment and integration as mobile and desktop apps

Fizz was responsible for a lot of early PWA work, including Service Workers, Background Sync and Push Notifications (enabled with the availability of WebAPKs). They also introduced Web Bluetooth, first available in Chrome 56 released January 2017, and Web USB, first available in Chrome 61, released September 2017, the first two new powerful APIs specifically designed to close the app gap.

Fizz would evolve into Project Fugu and the current Capabilities project⁠, pretty much keeping the same mission and focusing on bringing these new powerful APIs to browsers. It would also move beyond Google to a cross-company effort, including significant contributions from Microsoft and Intel.

From tab to taskbar

When Progressive Web Apps were first launched, they were originally envisioned only for mobile devices as a way of helping the web compete with mobile apps. But the web is more than mobile! The benefits of PWAs extend not just to home screens, but to taskbars too! By allowing PWAs to be installed on desktop devices, the promise of write once, install everywhere could start to be fulfilled.

Prior to PWAs coming to desktops, Chrome had something called Bookmark Apps. Built on the foundation laid by hosted Chrome Apps, bookmark apps, so called because they were something between a bookmark and an app, were what was created if you added a site to your desktop. In 2018, when Chrome started work on bringing true Progressive Web Apps to desktops, the implementation was forked from these Bookmark Apps.

Rollout of desktop PWAs started with ChromeOS, version 67, released May 2018. It would take another 3 releases, to Chrome 70 released October 2018, to add Windows and Linux support and yet another 3 releases, to Chrome 73 on March 2019, for Mac to get support.

Much like on mobile, desktop PWAs, from the start, proved that websites could earn their place on taskbars, often without much effort.

At Google I/O 2019⁠, Hulu shared their story of creating a desktop PWA to replace a legacy Windows desktop app they had.

Just like comScore said about mobile back in 2015, Hulu reiterated that, even though the legacy app had poor reviews and lacked features, users kept using it because it was ever-present, just a single tap or click away.

They started small, with a simple offline fallback service worker and a manifest file; just enough to make their replacement installable. It took 1 developer 2 weeks to build, QA, and release their new experience. That was one sprint for their team, literally the fastest they could possibly deliver results.

In the 3 months since launch, they saw 96% of their legacy app users adopt the new PWA, and compared to their website, saw a 27% increase in return visits and a 5.5% increase in engagement.

Desktop PWAs would come to Edge 79, January 2020 and to Safari on Mac September 2023.

Today

And that brings us to today.

PWAs are here, can be installed on any device with a web browser, and there's lots of work going into making them even more capable, letting the web compete more and more with desktop and mobile apps.

The Capabilities project⁠ has launched almost 60 new APIs between Chromium 71 and 118, including:

• Expanded hardware support with WebHID, Web Serial, and Web NFC
• Deeper OS integration with File System Access, a Contact Picker API, and Web Share and Web Share Target
• And has even expanded what installed PWAs are capable of, with the badging API, app shortcuts, and the File Handler API.

Web apps have become so capable, that even Photoshop is now available on the web⁠! Photoshop used WebAssembly to port their existing C++ code to the web and the Origin Private File System to ensure even their largest files could be performantly worked on.

Creating PWAs is now more accessible than ever, too.

Modern meta-frameworks and bundlers, including Next for React, Nuxt for Vue, and Svelte Kit for Svelte, as well as Astro and Vite, all have built-in or widely supported extensions for creating PWAs, including zero-config options.

There are developer tools, like Lighthouse, that can be used to test if your website meets installation criteria (and more!) including as part of your CI/CD process, libraries like Workbox to help you build and maintain your service workers, allowing you to quickly implement and leverage common caching and serving patterns, and tools like Bubblewrap⁠, and those powered by it like PWA Builder⁠, to simplify the process of bundling your app for distribution in stores.

Speaking of stores, Google Play, the Microsoft Store, and Samsung’s Galaxy store all support listing PWAs, letting them take part in the app store discovery, preview, and review ecosystem.

Take Boosteroid, a Ukraine-based independent cloud gaming provider, for example. Boosteroid lets users stream everything from indie games to high-end AAA titles through their PWA, letting anyone play their favorite games regardless of where they are or their computer’s hardware. By improving their web experience and publishing their PWA to Google Play, they found a 60% increase in their Y-o-Y ChromeOS users and ChromeOS playtime increased by 30%.

And Clipchamp, an in-browser video editor that had never been available in an app store before, saw their PWA installation rates increase by 97% a month in their first five months after upgrading to a PWA and getting listed in the ChromeOS Play store⁠, with PWA users having a 9% higher retention rate than standard desktop web users. Their video editor? It also got an overhaul, moving from NaCl to Web Assembly.

Clipchamp’s success with PWAs isn’t unique. On mobile:

• From a May 2021 case study⁠, Mainline Menswear, a UK-based online clothing retailer, saw a 55% increase in conversion rate for their PWA versus their mobile site along with a 12.5% higher average order value order value and 243% higher revenue per session.
• From a June 2021 case study⁠ Blibli, an e-commerce marketplace in Indonesia, found their PWA genreates 10x more revenue per user than their previous mobile site, reduces bounce rate by 42% and shows an 8x improvement in mobile conversation rate.
• From a May 2021 case study⁠, Orange Polska S.A., a leading telecommunications service in Poland, saw a 52% increase in conversion rate for their PWA versus their previous mobile site along with 30% faster average loading time and an 18% increase in session depth.

On desktop, we’re seeing the same thing.

• From a December 2020 blog post, Kapwing, an online image, video, and GIF editing platform, saw that within the first five weeks of launching their PWA-ified website, the number of people creating videos through the PWA grew 36%, outpacing overall website growth and therefore indicating a higher retention rate among creators who installed the PWA.
• From a December 2020 case study⁠, Corel Corporation’s Gravit Designer Pro, a powerful vector design tool that also offers Windows, Mac, and Linux apps, saw PWA users are 24% more active than any other install type account for 31% more repeat users than other platforms and are 2.5x more likely to purchase Gravit Designer Pro.

Over the past six years, we’ve learned a lot about what it takes to build a successful PWA.

When they were first introduced, PWAs were about push notifications, working offline, and being installable on phones. There was a push to make your whole site work offline. And an App Shell model that favored single-page apps, and refactors, was encouraged.

Today, we know that any way you want to build your site, single-page or multi-page app, as a static site or a dynamic one, are all great options for building your PWA. We’ve seen that with even minimal work, adding a custom offline page and a web app manifest to make a site installable, produces big results without needing to re-architect your site, add lots of features, or ensure everything works offline. And we’ve learned that, outside chat and social networks, basically no one likes push notifications.

It’s no longer a question of if you can, or should you, make your site a PWA. It’s a question of why haven’t you yet.

But maybe that’s not fair. Sure, making a site installable is now easier than ever, and there are benefits from even that little bit of work, but is that enough?

Even with all of the advancements we’ve seen with the Capabilities project, and the growth PWA adoption, there are still places today where the web can’t deliver the experiences users and developers want. As we look to the future to fill in these gaps, we’ve run into a blocker: the web’s security model.

The drive by web

Because the web aims to be safe and secure by default⁠, its security model needs to be very conservative. Any new capabilities added need to be safe for a casual user to accidentally comes across through a URL. At Google, we call this the drive by web.

Drive–by web APIs are generally considered safe if they can be explained in one of two ways:

• Their power, and potential danger, can be understood directly by the action the user is taking, like with Web Share and Web Share Target or App Shortcuts
• A clear and easy to understand permission prompt can be presented that allow users to make an informed choice, like Web Bluetooth and USB or the File System Access API

Unfortunately, this precludes a number of really important APIs that developers need to deliver the experiences they want.

Remember Chrome Apps? Well, while they were deprecated just about everywhere in 2020, they’re still supported on ChromeOS.

As we’ve been working with partners to turn down support on ChromeOS and migrate them to web apps, we’ve found that many of the APIs they need couldn’t be made safe for the drive-by web.

We needed a more secure environment in order to expose these APIs.

A high-trust security model for web apps

A high-trust security model for web applications needs to be thought of differently than the drive by web.

Not only do we need to consider how users perceive what power a web app can have, we need to take into consideration attack vectors that may seem more relevant for native apps.

We ultimately landed on three core requirements for a high-trust security model: web apps needs to be packaged, isolated, and stand-alone.

Packaged

What would happen if, say, your server becomes compromised and starts serving malicious code? Or your DNS gets compromised?

Bad situations like these can become untenable security risks when opening up system-level APIs for web apps. Because of this, even basic web building blocks like servers can no longer be explicitly trusted.

To gain access to the new high-trust security model, sites will need to package all the resources they need to run into a Signed Web Bundle, concatenating these resources together with an integrity block. Doing so allows websites to be securely downloaded in their entirety and the contents to be inspected and verified before installing and running.

Isolated

But bundling code and verifying it before running breaks down if things like storage and permissions aren’t separated from the app’s main website. It also doesn’t do any good if you can get around that by downloading and running code from somewhere else on the internet.

In order to maintain the trust set up through packaging, websites opting in to a high-trust security model need to be isolated, too. This means three things:

• Running on a separate protocol (isolated-app) with a package-specific host, isolating it from the drive-by web and other installed apps.
• Declaring what permissions you’d like to use up-front, in your webappmanifest.
• Opting-in to a strict set of Content Security Policies and CORS/COEP headers.

Stand-alone

These changes aren’t just big for developers, they’re big for users, too. Because apps running with a high-trust security model don’t quite install the same and don’t quite work the same as normal websites, they’re only able to run in a stand-alone app window. This also reinforces for users that these may be more capable, and may get access to system level APIs, like native apps.

A spectrum of trust on the web

With this, I’ve come to think of security and capabilities on the web in terms of a spectrum.

The drive-by web has the lowest trust security model because it needs to be most accessible, and therefore has the least access to a user’s system. Installed web apps get a little more trust, and can integrate a little deeper into a user’s system. Users can generally switch between drive-by web versions of apps and installed versions without problem.

Then there’s the high-trust, isolated web applications.

They act and feel more like native apps and can get access to deep system integrations and powerful capabilities. Users can’t jump between them and the drive-by-web. If you need this level of security, or these capabilities, there’s no going back.

When trying to decide where on this spectrum you should aim for, default to the lowest-trust security model that you can. This will give you the greatest reach, require you to manage the least amount of security concerns yourself, and will be the most flexible for your developers and users.

While we think these high-trust isolated web applications, and the APIs that are enabled by them, are important, we also believe that you should only reach for them if you can’t deliver your experience otherwise. Because of this, we’re taking the same approach for APIs, aiming to only release APIs for the high-trust security model as a last resort.

High-trust APIs

But what kind of APIs would need this high-trust security model?

One of the kinds of apps we’ve been looking to enable are Virtual Desktop Infrastructure, or VDI, applications, and they’ve got some specific needs that make deploying a fully-featured one on the web today difficult.

In the world of desktop virtualization, VDIs are somewhat unique: instead of running a virtual machine locally, VMs are run on a server, and you connect to that server to access the device.

This can come in the form of:

• A remote desktop, where you’ve got a window that’s the full display of the VM
• Individual streamed applications
• Or some combination of the two
• All while being lag-free for things like video playback and conferencing

While a remote desktop solution can be built today on the web if the server supports WebSockets, like Chrome Remote Desktop⁠ many servers don’t. Add in providing a seamless streaming app experience, or letting users pin apps from their remote session for easy access, and you’re getting beyond what can be accomplished today. And beyond what the drive-by web’s security model can handle.

A number of APIs are going to be needed to make this a reality, but three are ready for you to start experimenting with today. Let’s take a look at them.

Borderless display

Imagine you’re streaming a Mac app to your Chromebook. The whole window gets streamed, including the app’s window title bar. This creates an annoying user experience: the streamed app’s title bar underneath the OS’s title bar. The Borderless display mode removes the OS’s title bar, letting apps fully render their own, including specifying areas users can use to drag it around.

Why does this need to be a high-trust API? Spoofing. A blank window with no window controls could be used to spoof anything; a desktop, an app, a website. To mitigate this, not only is this only available to IWAs, it requires a user accepting Window Management permissions for the IWA before it will work, which can be revoked at any time.

Direct Sockets

While WebSockets and WebRTC are great for sustained connections between modern web servers and clients, there are a slew of other servers, devices, and client needs that either can’t be covered with them or can’t be updated to include support for them. For those, access to lower-level socket connections are needed. The Direct Sockets API introduces the ability to create TCP⁠ socket and server connections, and UDP⁠ socket connections.

Why does this need to be a high-trust API? Both WebSockets and WebRTC are by design tightly constrained to prevent abuse. These are not, allowing the same power as native TCP and UDP connections. Configuring TCP and UDP connections, or explaining what they're capable of doing in an easy-to-digest prompt, is difficult, because they rely on IP addresses and ports and allow for many complex usecases. So, in order to open these up, we need a high-trust security environment. The isolation enforced in this environment prevents common threats with these connections, while packaging allows the actual usage of these APIs to be inspected.

Controlled Frame

Today, there are two main embedding mechanisms available on the web:

• iframes⁠, which allow you to embed most content and communicate between the main website (the parent) and the embedded content (the child) through postMessage⁠
• fencedframe⁠, which allow you to embed content while maintaining isolation between the parent and the child and explicitly preventing communication between the two

But VDI apps (and many other apps) may need something more. Imagine trying to use a video player or hold a virtual meeting through a VM streamed to your desktop; lag would be terrible. So maybe you’d embed the video instead on top of the stream, but then you wouldn’t be logged in. And someone may be able to navigate away from it while it’s embedded. All of this means the current suite of tools doesn’t cut it. Controlled Frame allows websites, even secure websites that otherwise can’t be embedded with iFrames, to be embedded. These embedded websites can be monitored and can even have JavaScript and CSS injected into them and have messages sent between the embedder and embedded. You can think of them kind of like native app WebView⁠.

Why does this need to be a high-trust API? Just like in-app browsers, the parent now has access to, and can change, anything and everything in the embedded content. This can potentially expose users’ private data and subject them to tracking or fingerprinting or spoofing attacks. Much like with Direct Sockets, the isolation and packaging of the high-trust security model help to mitigate these issues by providing boundaries in which this can run and allowing the actual usage to be inspected before launching.

Try it out!

After reading the Isolated Web App documentation, try out the Getting Started with Isolated Web Apps tutorial.