Secure Rendering is a way for web apps to instruct the browser to display a reference to something on screen but to disallows the actual web app and other components from accessing it.
Here is an example of where this already happens:
When you are buying something online and you need to fill out your shipping address information.
If you have autocomplete turned on, you'll get a drop down that will pre-fill the form for you. What you might not know though, is that while the browser shows you a preview of your information in the form, it does not actually make your data available to the web page until after you've clicked on the drop down.
In the case of buying something online, we do indeed need to share our address with the merchant. But what if we were looking at a weather page? It might be nice if the app could ask the browser to pre-fill the page with your city or zip code, but to not actually reveal your data to the site owner or any third party JavaScript.
We will dive into why this has many exciting implications for the future ahead, but first let's go over another example first.
Netflix and Facebook.
Many large sites already have social media widgets that will display your name, profile photo, or other information on sites you visit. Typically, iframes are used to prevent this data from being leaked to the other site. But since seamless iframes have been removed from spec, it seems most app developers choose to use connected logins over widgets. The problem is, connected logins potentially expose user data to their third party servers - something Facebook and other sites are now trying to reduce after the recent hacks.
What this means is that you're not even reusing your Facebook data, you're just leaking it.
Secure Rendering is a practical solution for businesses to protect their users while still expanding their reach and impact on third party sites. This has clear value add for most of the vendors that implement browsers, but also for users. Even new browser APIs are getting very close to this, like web component's shadow DOM - but it has a security vulnerability that allows it to be hijacked.
Putting better data security into the browser should be the obvious solution in contrast to sharing data on servers behind a user's back. This puts the user in control without any data being leaked to the sites they visit.
It could be as simple as the weather channel saying
Hello <span origin="facebook.com">{{ profile.name }}</span>!
but like with iframes, the span contents would appear completely empty to the parent site and any JavaScript, as it is not loaded under the same security context.
We have already built a prototype of this concept as a browser extension, but replaces the domain-based model with a more secure, cryptographic public-key model.
As hinted above, there is a much more exciting direction to this than having your Facebook data follow you around the internet.
Secure Rendering means the ability to have Facebook not even know what your data is, yet still render the same great user experience.
For example, if you received an end-to-end encrypted message, this blob could be uploaded to a Secure Enclave Renderer inside the browser. It would then be displayed as plain text on the site, without the app developer, Facebook, or third party services being able to access it.
But let's forget about privacy for a minute. It also would increase user convenience, boost conversion rates, improve retention, and enable faster load times. Here is how.
In the same way your browser can remember your shipping address, a lot of other repeat information can be locally managed by the browser. This means that load times are faster because they pull securely from the browser, not some extra round trip that talks to a remote server.
It also means apps can be immediately personalized and useful before needing to collect, yet again, the same set of preferences from a user as all other sites. Eliminating this friction enhances user trust, which increases sign up conversion. Overall, users win, better apps, better experiences.
Even data that does need to be collected, say to return satellite map imagery for your shipping address, can be anonymized. Rather than your precise GPS coordinates being sent up to some server, the browser could approximate your XY tile coordinate and send that up to a server, which may reveal what region you are in but not an exact location.
Browsers already run different websites in different security contexts. It is reasonable to assume that even Secure Compute for JavaScript is perfectly possible.
An application could specify a function that runs inside the isolated container of the Secure Renderer, and pass it references to data to be processed, without that container ever allowing backward access or any remote network calls. Deno by Ryan Dahl, creator of NodeJS, already has these abilities, for example.
This finally lets apps move beyond the domain name security model. An app could be a mixture of sub-components from different sources, which in turn, might request securely rendered data from Facebook, your hard drive, Netflix, and the browser.
The app would not have access to any of this data, but instead just be a view for it. Cross domain shared data views, but not shared data access.
All of these ideas are not fantasy, they're easy to prototype and can be shimmed with existing technology via extensions. The use cases for Secure Rendering are beneficial to both users and enterprises, and represents an exciting new direction for web application development that prioritizes user privacy and convenience.
If you're interested in these ideas, and advancing the decentralized web, give me a shout out on twitter. We'll be devoting energy into this and other graphics rendering advancements over the next 7 years no matter what, as it is the inevitable secure internet of the future that we all deserve.