Crypto is not a new internet.

It’s the old internet, lit up with state and memory.

In this post, in collaboration with Dawn, we sketch a new way of thinking about the Verified Internet (VI).

By shifting risk from developers and users to a more muscular browser, and with an incremental upgrade to HTML, we think we can open crypto (the computer, not the coins) to a broader developer audience: improving UX and reducing risk for both users and developers.

Crypto teams, battled-hardened from building into the most adversarial computational environment in history, are primed to rebuild the browser as a terminal for a verified internet.

If you want to join the HTML+ debate straight away, here are the links:

• Mission Statement for HTML+
• Dawn’s Article introducing HTML+

This article has had many eyes on it, and grateful for the feedback of: Ben Levy (Geometry), Tom Waite (Dawn), Kobi Gurkan (Geometry), Hactar (Anon), Federico Carrone (Lambda), Justin Drake (EF), Jens Groth (cryptographer), Vitalik Buterin (EF), Jason Morton (EZKL), Charlie Songhurst (investor), Zac Williamson (Aztec), Joe Andrews (Aztec), Srikar Varadaraj (Bluebirds), Brandon Gomes (MVUP), Chloe Northcott (Geometry), Arthaud Mesnard (Geometry).

1. The Internet Adrift

We’re all dimly aware of the risks of generative software on the internet, and the rising importance we’ll soon start to attach to cryptographic marks, from digital signatures (proof of human ID) and more sophisticated technologies like proofs of computation (proof of software ID). But our browser isn’t ready.

At the same time, crypto technologies are serving us a common, syncronised, verified “internet computer”. Again, our browser isn’t ready.

This article suggests a better way to help users tap into a Verified Internet, and a way to make it easier for web developers to access, with a small tweak to HTML.

CONUNDRUM 1: CRYPTO AND THE WEAK WALLET

In crypto, few take responsibility for risk.

We call it “Web3”: a clutch of classical web apps calling over to experimental “protocols”. But for all the user knows, these protocols might be a simulation, hidden from view by the application.

Consider what a weird ratio of protocols to applications we have today (1 to 1, give or take). Protocols should be stable and ubiquitous and few.

The application, having no prior relationship with the user, constructs the transaction unchecked. Metamask passes it across to the user:“I’m just the messenger; you check this transcript. If this goes wrong, it’s on you”.

The average user clicks and prays. They’re vaguely, anxiously aware they might be charging headlong into disaster, but unable to sense-check what they’re about to do. The pulse quickens. They’ll do this as infrequently as possible.

It’s a strange kind of trust reduction, isn’t it?

Today’s browser, and today’s wallet, are both weak.

The giants of web browsing mostly seek to avoid crypto’s manifold risks: rolling out a product full of regulatory and financial risk to hundreds of millions of users, for unproven dividends in user benefit, makes no sense.

But imagine TLS, if the browser pushed responsibility for secure connections to some plugin. Imagine if it asked the user to hand-check exponentiation on the Edwards 25519 curve, or check a public key to a registry.

And looking ahead a bit —

Verification costs are plummeting, proof costs collapsing, and 4-5x data replication with error correction will be fine for most of us (cf AWS).

Crypto is coins in the sky today.

But at its limit, crypto is the full extension of cloud computing, plumbing our digital histories into a collective global state.

Yet with applications and wallet plugins too fearful to plug the risk gap (the risk of writing to decentralised systems), crypto does not evolve.

CONUNDRUM 2: THE UNVERIFIED WEB

Even on the traditional internet, we’re facing a surge of unverified information, blurring fiction with reality.

The “oracle problem” (using data from the outside world), is increasingly a web problem, not just a crypto problem.

Sign Everything, a 2022 post Fred Wilson, discusses the sudden urgency of the digital signature. But is your browser ready to check for human signatures, or identity-check artificial intelligence?

A COMMON CURE: THE BROWSER STEPS UP

One piece of software sees it all, crypto and web.

The browser.

This window on the world has done it before: Netscape introduced TLS to secure server-client connections in the 1990s.

It’s time for the browser to step up again, and become the secure terminal for the virtual computer.

With incumbents standing aside for you, and too many startups to count killing their company momentum with a ‘lights out’ token event, the path for startups to build the terminal for the verified internet lies wide open.

2. Mission Statement for the Strong Browser

SUMMARY OF GOALS

Here’s what a VI-ready browser should do:

• allow you to safely read and write to digital state
• safeguard your digital state
• verify people (signatures over content)
• verify AIs (models modifying content)

If you can lift a heavy risk burden from the user, be their shield and let them freely explore, then there is your business opportunity: bridge the trust residue that protocols cannot extinguish.

That’s where you earn your premium.

DECPRECATING THE “WALLET”

Let’s abolish this antique expression, the “wallet”. It limits us. It suggests a thin slice of crypto’s ambition.

It’s like calling your computer a “calculator”.

The wallet is a browser.

WHY A STRONG BROWSER ADVANCES US

By transferring all remaining trust assumptions from app-security to browser-security, we make two advances —

For Users: Crypto is now easier to access and less fraught with risk

And given this muscular browser, we can drop the adoption barriers for applications too —

For Developers: We should take advantage of this strong browser, and with a simple HTML extension, bring easy crypto primitives to any web app.

Here’s how we give back the UX dividend to developers.

3. HTML+

HTML+ extends HTML to enable crypto reads and writes to crypto state.

The browser takes on the role of injecting verified data, or creating a transaction out of a tag: not the application.

Our specification is deliberately light at this stage: we want the community to help us build this.

SAMPLE CODE

A <w> tag will enclose regions of a page designed to be populated by verified data. We also suggest general purpose read /write tags that will be VI Browsers interpretable.

Here’s some sample code:

FIRST EXPERIMENTS

Of course, payments are the low-hanging fruit.

We need to keep our sense of reality in-check: solid, reliable, cheap, modestly-programmable payments are the full extent of the early win.

But we can ship them in a way that gives developers the full reward of the benefit. Crypto payments (as an example) are now just a <send> tag, loaded with an address: the browser does the rest.

Whilst this interpretative model might limit protocol-level experimentation, we think it dramatically lowers barriers to integration by web developers outside the industry.

That in my mind is the right trade-off: protocols harden and earn trust over time and are few in number. Applications iterate quickly, and ease of integration is key to crypto’s success.

4. The Strong Browser and HTML+

With the application doing less, here’s what the browser must now take on.

THE INTENTIONAL BROWSER

Ah yes, intents.

We’ve watched the intents debate from the touchline this year. It seems a very fiduciary subject, and a jarring thing to implement at the protocol level.

But “best execution” is exactly what our muscular browser is primed to do.

By allowing HTML scripting on the webpage, and inheriting from the Netscape philosophy of pushing rendering choices onto the browser, we similarly push transaction construction and read-interpretation onto the browser in the HTML+ setting.

Take an example: a <SEND> tag needs to be translated into a routing decision. No doubt the browser will typically opt for the low risk strategy, leaning on minimal hops and battletested protocols as much as possible:

• Payments: Execute a ERC-20 Transfer()
• Streams: Open a Sablier v1 stream
• Swaps: Switch assets on Uniswap

The user need never worry about L2s or bridges. And nor should they!

This is a first step towards the burying of Layer 1 and Layer 2 protocols deep into the unseen, stable recesses of our future verified internet.

THE STRONG BROWSER AND VERIFIED READS 🟩

Marc Andreessen selected blue for hyperlinks when building Netscape.

In a nod to history, I suggest we opt for green for verified content.

Rendering conventions will have to be jealously guarded by browsers to avoid malicious applications from presenting unverified data as verified, or risky transactions as safe CTAs.

There’s no point in over-specifying how browsers treat verified data: that’s ultimately the browser’s job.

Examples might include:

• Pricing data from Uniswap will be populated and highlighted by the browser, so you will know that ETH/USD 1,589.79 ⬆ 2.40% has been taken from a verified source
• A green-bordered image carries a signed hash from a known photographer or publication house (perhaps with a link to a maintained register)
• An original video has been optimised by a trusted AI, and the AI supplies a proof of deformation which the browser checks, to ensure the transformation was authentic, and borders the video in green if the checks pass

THE STRONG BROWSER AND WRITE SECURITY

Security (and its regulatory burdens) is now the remit of the browser.

We acknowledge a trade-off here: this new breed of strong browser is likely a heavily locked-down environment. It is plugin unfriendly, at least at first. The risk of rogue scripts is not worth it: not yet.

We think this isn’t a huge loss, though Google Drive users may disagree.

THE STRONG BROWSER AND PRIVACY

Privacy (and its regulatory burdens) is now the remit of the browser.

We all know that the payments transaction graph is going to have to be secured by cryptography: governments in time will not just permit it, but enforce it. Geopolitics surely enforces this.

Pay or stream primitives in mix public-private state systems such as Noir or Leo will allow the browser to maintain and manage user privacy. It means the browser has the privilege of keeping the user’s secrets, and the burden of KYC / AML.

THE DOOR TO DIAGON ALLEY

Most browsers will not see these new HTML+ tags, like all good Muggles. If the browser is not VI-ready, the tags will simply not render, and the user experience is unaffected.

5. Afterthought: The Web Vacuum?

And the browser itself might be a moving target.

Just as wallets are concluding they should be browsers, browsers are becoming web vacuums. (this expression borrowed from Charlie Songhurst).

The browser-vacuum seems likely to emerge as a powerful concierge: selecting and combining and summarising and rendering the world’s knowledge and opinions, and drawing them into the user’s field of view. It might transmute page layouts, blow up content, improve legibility, or even conjure whole pages on the fly.

I think this same convergent ambition goes by a lot of names: the Wallet, the Strong Browser, the Web Vacuum, the Everything App and the Virtual Private Computer —

They all mean a universal digital window, which learns our preferences, keeps our privacy, and becomes our virtual House Elf: watchman, bard, and defender.

The browser has a lot of growing up to do. Let’s get started!

6. Other Reading

My proof readers kindly pointed out other areas of work that have been done along the lines of a verified internet.

• PCD Team Page, a 0xPARC project

Verified AI-generated web content:

• Fighting Deep Fakes, by Daniel Kang
• ZK Proofs to Fight Disinformation, by Dan Boneh and Trisha Datta

Here, for info only, is a parallel effort to push more expression down into the protocol level of HTML, away from crypto:

• HTMX, baking AJAX, CSS Transitions and WebSockets into HTML

And for balance, an article that warns about the risks of granting greater interpretive powers to the browser:

• Reckless Limitless Scope, by Drew DeVault

Tom and Isaac unearthed some fossils that show the Slartibartfasts of the web were expecting us. The early internet architects assumed digital cash would be flowing through the veins of 2023’s internet:

• 402 Payment Required (Mozilla)
• Payment Request API (Mozilla)
• And Chrome’s ready too