World Wide Web Notes

TimsJam.com follows the World Wide Web as both a technological invention and a public space. It covers the work and continuing influence of Tim Berners-Lee, evolving standards at W3C and WHATWG, open data, Web accessibility, privacy, security, and the choices that will determine whether the Web remains open, useful, and understandable.

The site looks backward in order to see forward. It returns to the people, laboratories, browsers, protocols, standards, and arguments that built the early Web, then asks what remains of that design as powerful platforms, artificial intelligence, digital identity systems, and new forms of online control reshape how information is published, found, and trusted.

Disclosure: This page is independently written and contains no affiliate links, sponsored content, paid placements, or compensated endorsements. TimsJam.com is an independent website and is not affiliated with, endorsed by, sponsored by, or officially connected with Sir Tim Berners-Lee, the World Wide Web Consortium (W3C), Inrupt, CERN, the Solid Project, or any other organization mentioned on this page.

About The Author

Ardan Michael Blum writes the site’s independent commentary, short Web notes, and occasional longer essays.

He was born in Geneva, near CERN—the laboratory where Tim Berners-Lee proposed the World Wide Web in 1989 and had its first browser and server running by the end of 1990. He now lives in Palo Alto, near SLAC, where the first Web server outside Europe went online on December 12, 1991.

The path between Geneva and Palo Alto runs through particle physics—and through the early Web.

In September 1991, SLAC physicist Paul Kunz returned from a meeting with Berners-Lee at CERN and brought word of the Web back to California. Working with Louise Addis and Terry Hung, he helped establish a Web interface to SPIRES, SLAC’s heavily used database of high-energy-physics literature and preprints.

The first version had only a few lines and two links, but it made an established scientific resource searchable through the new system developed at CERN. Berners-Lee later called the SPIRES connection the Web’s first “killer app.”

The achievement was not that SLAC created a new body of knowledge. SPIRES already existed. The Web supplied a new path into it. That remains one of the Web’s great powers: it can make existing knowledge newly reachable across institutions, borders, and continents.

Silicon Valley did not invent the Web. CERN’s decision in 1993 to place its basic Web software in the public domain helped the system spread widely. Silicon Valley later became one of the principal places where the Web was commercialized and expanded through browsers, search engines, online businesses, advertising systems, and social platforms.

A distributed system created for sharing information became the foundation of a commercial world increasingly organized by a small number of powerful platforms.

From CERN to SLAC, and from Berners-Lee’s first proposal to the artificial-intelligence systems now shaping daily life, the history of the Web remains unfinished.

Revised August 13, 2026

Notes

August 28, 2026

Web Authentication Level 3 Is Now a W3C Recommendation

On August 25, the World Wide Web Consortium published Web Authentication Level 3 as a W3C Recommendation. The status matters: after extensive consensus-building, W3C and its Members endorsed Level 3, Working Group members made royalty-free licensing commitments for implementations, and W3C recommended it for wide deployment. It does not mean that every Level 3 feature appeared in every browser on August 25.

W3C reports that there were no substantive changes between the Candidate Recommendation published on May 26 and the August Recommendation. The publication therefore closes a standards cycle; it does not flip a technical switch. Some Level 3 features were already shipping while the document was still a draft; others remain unevenly implemented.

What WebAuthn does

Web Authentication, usually called WebAuthn, lets a website register and use a public-key credential. During registration, an authenticator creates a key pair scoped to that relying party, and the site receives the public key. During sign-in, the site sends a fresh cryptographic challenge. After user presence or verification, the authenticator signs its authenticator data together with a hash of client data that includes the challenge and requesting origin; the site verifies that assertion with the stored public key.

The relying-party website does not receive the user’s fingerprint, face scan, or device PIN. Those can be used locally to unlock the authenticator; the site receives the signed result. The distinction matters: a biometric gesture authorizes use of a credential, but it does not by itself prove civil identity or document consent to separate legal terms.

“WebAuthn” and “passkey” are not synonyms. WebAuthn is the Web API and ceremony model for public-key credentials. In Level 3, “passkey” is another name for a client-side discoverable credential: it may be synchronized across devices or bound to one authenticator, and it can be used without the relying party first supplying a credential ID. WebAuthn also supports non-discoverable credentials.

WebAuthn is also only one boundary in the common FIDO2 model. WebAuthn connects the website to the browser or platform; the Client to Authenticator Protocol, or CTAP, connects that client to an external authenticator such as a security key or phone.

What Level 3 adds

WebAuthn Level 1 became a Recommendation in March 2019, followed by Level 2 in April 2021. Level 3’s First Public Working Draft followed on April 27, 2021. The August 2026 Recommendation gathers more than five years of work into a stable new level.

The additions fall into four practical groups:

Sign-in experience. Conditional mediation can surface credentials within familiar sign-in flows. Hybrid transport supports cross-device use, and browser hints help select appropriate authenticator and sign-in interfaces.
Developer and credential management. JSON conversion helpers reduce encoding work. Limited client-capability checks support selected workflow decisions. Signal methods let a relying party report an unknown credential, identify which credential IDs remain accepted, or update account details shown by credential managers.
Deployment across sites and frames. Related Origin Requests let a limited, explicitly declared set of origins use one relying-party ID through /.well-known/webauthn; they do not make a credential valid on arbitrary related domains. Level 3 also carries more information about embedded and cross-origin contexts.
Credential state and advanced uses. Backup-eligibility and backup-state flags describe whether a credential can be, or has been, backed up. The PRF extension can return credential-bound pseudorandom output for applications such as encryption, while compound attestation can carry more than one attestation statement.

The important limit

Recommendation status is not the same as universal product support. W3C’s June 2026 implementation snapshot reported 53 tests and 415 subtests run against development or preview versions of Chrome, Firefox, Safari, and Edge; results for some newer conditional and credential-handling features were still uneven. Those automated browser results are a dated interoperability snapshot, not a complete browser-and-authenticator support matrix.

The security promise—and the recovery problem

Correctly implemented WebAuthn is phishing-resistant because the browser binds each ceremony to the relying party, while a fresh server-generated challenge prevents an old assertion from being replayed. “Phishing-resistant” is the careful term. It is not “phishing-proof”: malicious application code, stolen sessions, compromised devices, faulty server validation, coerced approvals, and weak fallback paths remain part of the system.

Recovery is the larger elephant. A device-bound credential can be lost with a device unless another authenticator or recovery path exists. A synchronized passkey improves availability by moving protected key material through a provider’s sync fabric, but that makes the provider account, sharing rules, and recovery process part of the security boundary. NIST therefore treats sync, sharing, device management, and recovery as operational risks to evaluate rather than details that disappear behind the word “passkey.”

Accessibility and inclusion are implementation questions too. A service should not assume that every user owns a smartphone, can scan a QR code, can perform a particular biometric gesture, or can recover an account through the same device ecosystem. Services should provide accessible setup and recovery, keyboard and screen-reader support, adequate timeouts, and more than one workable authentication path where a single-device or single-modality flow would exclude users.

What changes now

For standards readers, the versioned August 25 Recommendation is now the durable reference. For implementers, the sensible next step is to compare required features with current browser and authenticator support, use the specified capability checks where available, test server-side verification and recovery, and preserve accessible alternatives. For the Web as a whole, Level 3 is an interoperability milestone—not the end of passwords, not a guarantee of secure deployment, and not the end of WebAuthn work. W3C says new features will continue in Level 4.

Being on the Web Is Not the Same as Being Open

A service can load in a browser without participating fully in the open web. Openness also depends on whether people can link directly to material, choose among compatible tools, control their data, and leave one service without abandoning everything they have created.

In a November 10, 2025 interview for The Verge, Nilay Patel asks Tim Berners-Lee whether the web’s original openness can survive closed platforms and artificial intelligence. Berners-Lee invented the World Wide Web—not the internet—at CERN in 1989 and later founded the World Wide Web Consortium to coordinate shared web standards.

The distinction between being online and being open emerges through a comparison between podcasts and YouTube. Many podcasts can be followed through different applications because their publishers distribute feeds that compatible clients can read. A YouTube video may also have a web address, but its content and playback remain inside an ecosystem controlled by one company.

Patel complicates this example by observing that podcast discovery often depends on centralized directories. Openness is therefore not always a simple yes-or-no condition. A system may allow a choice of applications at one layer while depending heavily on a central provider at another.

Berners-Lee describes the larger principle as “digital sovereignty”: users and publishers should be able to participate as independent peers rather than merely occupying space provided by a dominant platform. He does not argue that commerce should be removed from the web. In the interview, he explicitly recognizes the importance of advertising, subscriptions, and other business models. The dispute concerns whether those models preserve meaningful choice and interoperability.

Artificial intelligence introduces a new version of the problem. Berners-Lee worries that if AI systems answer questions without sending readers through to the original websites, publishers may lose the advertising revenue that supports their work. This is a conditional warning, not a demonstrated conclusion that the web’s advertising model has already collapsed. The interview provides neither a measurement of that decline nor a timetable for it.

His proposed alternative is an AI assistant that works for its user and receives permission to use information held in a personal data store. Berners-Lee’s company, Inrupt, presents Charlie as one implementation of that idea. It draws upon Solid, a project intended to separate personal data from the individual applications that use it.

The status of this technology requires careful wording. The published Solid Protocol describes interoperable, permissioned access to externally stored data, but expressly states that it is not a W3C Standard. As of August 2026, the related Linked Web Storage Protocol is progressing through the W3C process but remains a Working Draft. Inrupt also says that Charlie’s technology is being prepared for release through selected organizations. These are active projects, not proof that the proposed model has achieved broad adoption.

Berners-Lee is Inrupt’s co-founder and chief technology officer, so his claims about Solid and Charlie combine a technical vision with a commercial interest. Patel’s interview is valuable because it does not ignore that tension. He tests the open-web ideal against platform economics, user behavior, concentrated infrastructure, and the possibility that AI may weaken the websites from which it learns.

The durable lesson is that openness is not conferred by an address bar. It depends on who controls the data, which applications can use it, and whether users and publishers retain a practical way to leave.

Read: “Sir Tim Berners-Lee Doesn’t Think AI Will Destroy the Web”, an interview by Nilay Patel, The Verge, November 10, 2025.

Note: This note is an independent interpretation and summary of the article. Readers should consult the original for the participants’ complete discussion and arguments.

August 9, 2026

30 April 1993: CERN Announces a Public-Domain Release

The Web was already in use by spring 1993. Tim Berners-Lee had proposed it at CERN in 1989, the first website and server were running, and CERN's Web software had been announced publicly in 1991. What changed on 30 April 1993 were CERN's release terms for three components.

On that date, CERN announced that it was placing three components in the public domain: the basic line-mode client, the basic server, and a library of common code. Its statement allowed anyone to use, copy, change, and distribute the source and binary code.

The release covered those named CERN components, not the internet or every Web program. Developers outside CERN could use and modify the code without seeking permission.

The software release was one part of the Web's spread, alongside accessible browsers, common standards, network connections, and work by many contributors.

The legal approach changed again in 1994. For a later server release, CERN retained copyright while granting free use and modification under an open licence. CERN chose that form in part to protect the software from appropriation and preserve users' rights.

Further reading: CERN's Licensing the Web and 30 Years of a Free and Open Web.

August 5, 2026

Linked Web Storage Tries to Separate Data from the Apps That Use It

The W3C Linked Web Storage Working Group published a new Working Draft of Linked Web Storage Protocol 1.0 on August 3. It is the latest revision of a project whose First Public Working Draft appeared on March 31.

The specification addresses a familiar problem. When people use an online application, their information is usually stored inside the same company’s system. The application, account, storage, and rules governing access are closely connected. Moving to another application may require an export, an imperfect conversion, or leaving the information behind.

Linked Web Storage, usually shortened to LWS, explores a different arrangement. It aims to give applications secure, permission-based access to data stored outside the application itself. If different applications can use the same storage protocol, a person could potentially change applications without also having to abandon the underlying information.

The current draft describes storage as a hierarchy of Web resources. Each resource has a URI, and containers organize related resources. Applications can use standard HTTP operations to create, read, update, and delete material, subject to the permissions attached to it.

Identity and storage do not necessarily have to be managed by the same provider. The draft allows an LWS server to accept credentials from an outside identity provider. It discusses authentication through systems including OpenID Connect, SAML 2.0, and self-signed controlled identifiers. Authentication establishes who or what is making a request; authorization determines what that requester may do.

A resource manager can make information private, restrict it to particular users or applications, or make it public. The draft also describes access requests, access grants, and optional notifications that could report changes to resources or permissions.

The larger idea is that an application should not automatically become the permanent home and sole gatekeeper of the information used within it. Storage, identity, authorization, and the application interface could remain connected without being controlled by one inseparable system.

This work has a direct relationship to Tim Berners-Lee’s Solid project. The specification acknowledges that it draws heavily from the Solid Protocol, which Berners-Lee helped edit. Linked Web Storage is nevertheless a separate project being developed by a formal W3C Working Group.

The distinction matters. Solid developed an architecture in which people could keep information in personal data stores and authorize applications to use it. LWS is attempting to turn related ideas into a defined protocol that different clients, identity systems, and storage providers could implement.

The promise is considerable: information might outlast a particular application, and competition could move from controlling stored data toward building better tools for using it. But that result is not guaranteed by writing a specification. It would depend on implementations, interoperability, security, usable permission systems, and adoption by services people actually use.

Linked Web Storage Protocol 1.0 remains an unofficial proposal and a W3C Working Draft on the Recommendation track. Publication does not mean that W3C or its members endorse it. Important parts remain unfinished, including the section devoted to portability. The document may still be substantially changed, replaced, or obsoleted.

That unfinished status is part of the story. The Web began by separating documents from the particular computers used to retrieve them. Linked Web Storage asks whether a similar separation can be established between people’s data and the applications through which they use it.

Further reading: Linked Web Storage Protocol 1.0 | W3C publication history

August 3, 2026

A Related Project: HTML Notes

Ardan Michael Blum’s related project, HTML Notes, examines the language beneath the Web. It covers HTML elements and attributes, document structure and semantics, forms, Web accessibility, browser implementation and compatibility, and the open standards that help pages work consistently across browsers and devices—and remain understandable as technologies change.

Where TimsJam.com follows the Web’s institutions, history, and public consequences, HTML Notes works at the level of the individual page.

Both projects begin with the same conviction: the Web’s openness is carried by technical details. Semantic markup, accessible forms, interoperable standards, and durable links are not merely refinements. They help make pages intelligible to people and machines—and give today’s work a better chance of remaining legible tomorrow.

July 27, 2026

A Link Is a Promise

A hyperlink looks simple: a few words, a click, another page.

But a link also makes a promise. It tells the reader that the destination will still be there and that the address will continue to lead to what the surrounding words suggest.

The Web has changed its browsers, devices, styles, and publishing tools many times. One principle has remained sound: stable addresses matter. The old W3C advice, “Cool URIs don’t change,” is still a useful rule for editors and site owners.

When a website is redesigned, its past should not disappear. Old addresses should remain in place where possible or redirect readers to the appropriate new page. This protects bookmarks, citations, research, search results, and the small trails of curiosity that make the Web useful.

A single broken link is rarely a catastrophe. A site filled with broken links is different. It suggests that earlier work no longer matters and that public information can vanish whenever a design, platform, or publishing system changes.

Stable links are also a form of respect. They respect the person who saved a page, the writer who cited it, the researcher who depended on it, and the reader who followed an old path in the hope that it would still lead somewhere.

Good websites do not only publish new things. They also maintain the paths that brought readers there.

Further reading: Cool URIs don’t change and Choose URIs wisely

The First Web Browser Was Also an Editor

Revised August 5, 2026

Summary

The first Web browser was not only a program for viewing pages. Tim Berners-Lee's WorldWideWeb application, first made operational at CERN in 1990, was a browser-editor: it could display a page, let an authorized user revise a document, apply structural styles, create links, and save it. Its limits were important, however. It could edit files to which the user had access, but it could not write changes back to an arbitrary page over HTTP.

As the Web spread beyond CERN, simpler browsers reached more computers more quickly than the original NeXT application. Browsing and authoring became separate activities, and editing moved into source-code editors, visual authoring tools, wikis, content-management systems, and eventually browser-based applications. Modern browsers once again contain powerful editing capabilities, but those capabilities are normally controlled by individual applications rather than exposed as a universal Edit-and-Save command for the Web.(...) Read more: www.timsjam.com/first-web-browser-editor/

July 21, 2026 | Revised August 5, 2026

Charlie: Tim Berners-Lee and Inrupt’s Plan for AI That Works for the User

In 2017, Tim Berners-Lee described a personal artificial-intelligence assistant called Charlie. Unlike an assistant tied to the interests of a technology platform, Charlie would work for the individual using it. Because the user would control its access to personal information, it could provide useful context without placing that information permanently inside one company’s system.

That early idea is now being developed by Inrupt, the company Berners-Lee co-founded with John Bruce. Its foundation is Solid, an open Web project built around personal online data stores called Pods. Solid separates data from applications: information can remain in a user-controlled store while selected applications, organizations, or AI systems receive permission to use particular parts of it.

Charlie is not primarily another large language model, nor is it intended simply to replace services such as ChatGPT or Claude. Inrupt presents Charlie as a personal AI intermediary between a person’s data and the outside AI systems that person chooses to use. For each task, Charlie would identify relevant information in a Solid-based vault, prepare the context an AI system needs, and ask for the user’s consent before sending it.

This separation is central to the proposal. Under Inrupt’s model, personal memory would not belong exclusively to one AI provider. It would remain in a portable store governed by consent controls. Charlie could then supply selected context to different AI systems without giving them unrestricted access to the original data or requiring the user to rebuild the same personal history inside every service.

Inrupt says Charlie is designed to remove personally identifiable information and, where appropriate, replace other details with altered but comparable values. The goal is to give an AI system enough context to produce a useful answer while limiting what the provider can learn about the individual.

This should be understood as a proposed privacy protection rather than a guarantee of anonymity. The National Institute of Standards and Technology notes that de-identification can reduce privacy risks, but that some de-identified information can still be re-identified. Charlie’s effectiveness would therefore depend on what information is removed, what remains, and what an outside system might infer from the remaining context. Altering more data may improve privacy while also reducing the accuracy or relevance of the answer.

Inrupt has presented banking as one possible use. A financial question might require information about income, spending patterns, and account balances without necessarily requiring a person’s name, account numbers, or complete transaction history. A bank could help manage the data vault and technical infrastructure because it already holds relevant financial information and has an established, regulated relationship with the customer. The customer would still approve what information could be shared.

Berners-Lee and Inrupt co-founder and CEO John Bruce presented Charlie at SXSW London on June 3, 2026, and discussed it again at VivaTech on June 17. Charlie is not yet generally available. Inrupt says it is working with selected companies and governments to make the underlying technology available through organizations with which people already have relationships.

The most important feature of Charlie is therefore not its name, personality, or ability to produce answers. It is the proposed architecture behind it: the personal data store, the intermediary controlling access, and the outside AI system would remain separate.

Whether that architecture succeeds will depend on the clarity of its consent process, the security of the personal store, the effectiveness of its privacy protections, and its ability to work across competing AI services. But the principle is clear. Charlie carries Berners-Lee’s long-standing argument for an open and user-controlled Web into the age of artificial intelligence: useful technology should work for the person using it, rather than requiring that person to surrender control to the platform providing it.

Further reading: Berners-Lee’s original Charlie concept; About Solid; Inrupt’s introduction to Charlie; and Inrupt’s banking proposal.

July 20, 2026

Web Authentication Level 3 Advances at W3C

W3C has proposed advancing Web Authentication Level 3, commonly known as WebAuthn, to a full W3C Recommendation. The current published specification is an updated Candidate Recommendation Snapshot dated May 26, 2026.

WebAuthn allows websites to authenticate people using public-key credentials rather than depending solely on conventional passwords. It provides part of the technical foundation for passkeys, physical security keys, and sign-in systems in which a fingerprint, face scan, or device PIN verifies the user locally.

During registration, an authenticator creates a public-and-private key pair for a particular WebAuthn relying party. The website receives the public key, while the private key remains protected by the authenticator. During sign-in, the authenticator uses that private key to prove that the user controls the registered credential.

The browser mediates communication between the website and the authenticator. Authenticators must not perform an operation without user consent, and credentials are scoped so that they cannot ordinarily be used by an unrelated relying party. These properties help limit phishing and prevent a stolen password database from being used in the conventional way.

WebAuthn does not mean that biometric information is sent to the website. A fingerprint or face scan may be used by the device to unlock a credential, but the website receives cryptographic proof rather than the biometric data itself.

Candidate Recommendation status indicates that a specification has received wide review and is being tested through implementation experience. W3C proposed advancing Level 3 to Recommendation on July 20, 2026, but that process does not mean that every Level 3 feature is already supported consistently across every browser, operating system, authenticator, and authentication service.

More: Updated Candidate Recommendation: Web Authentication Level 3

July 17, 2026

W3C’s Security Interest Group Publishes a Draft Threat Model for the Web

W3C’s Security Interest Group published the first Group Note Draft of Threat Model for the Web on May 26, 2026. Work continues in the public editors’ draft.

Web security is often discussed through individual problems: compromised accounts, malicious scripts, insecure connections, tracking, deceptive interfaces, vulnerable browser components, or unauthorized access to stored information. A threat model provides a structured way to examine what needs protection, where trust boundaries lie, how an attack might enter a system, and what harm could follow.

The draft examines the Web at several levels. Its high-level model identifies relationships among users, browsers, remote websites, network infrastructure, stored browser data, and the underlying operating system or device. A more detailed browser model considers privileged browser processes, sandboxed content, networking, storage, graphics, media, extensions, and other possible points of attack.

The document is intended to inform reviews of new and revised web specifications. It includes established parts of the web security model, such as separation between origins and browser mediation of sensitive capabilities, while also considering security and privacy goals that have not yet been achieved consistently across the platform.

The draft identifies assets that require protection, including personal data, credentials, cookies, browsing history, local storage, encryption keys, private network resources, and information about a person’s device and activities. It also considers threats arising from websites, browser extensions, third-party services, networks, and the browser’s need to process material received from untrusted sources.

The document remains incomplete. Several sections, including parts of the threat analysis and evaluation process, are still being written. It is a Group Note Draft rather than a finished standard, and W3C states that it is informative, may change, and is not expected to become a Recommendation.

Even at this stage, the work matters. A new browser capability or web specification may alter access to personal information, device features, network resources, or stored data. A shared threat-modeling framework can help reviewers examine those consequences before a technology becomes widely deployed.

Source: Threat Model for the Web

Legal Matters

This page was created independently of the individuals and organizations discussed, none of whom had editorial control over its contents. It contains no affiliate links, sponsored content, paid placements, or compensated endorsements. Neither the author nor this website received any payment, free or discounted product or service, preferential access, travel, hospitality, gift, or other material benefit connected with this page. Unless expressly disclosed otherwise, neither the author nor this website is affiliated with, sponsored by, endorsed by, or officially connected with any individual or organization mentioned. Names and trademarks are used only to identify the subjects discussed. A mention does not, by itself, constitute a recommendation or endorsement.

Please review the website's full Privacy Policy, Disclaimer, and Further Terms found at https://www.timsjam.com/legal/

Contact

For project inquiries, corrections, accessibility assistance, or general questions:

Ardan Michael Blum

345 Forest Avenue
Palo Alto, 94301, California, United States

Telephone: +1 (650) 427-9358

Online: Contact Form

Google Sites

Report abuse