Content is updated by Ardan Michael Blum in Palo Alto.
Note: 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.
October 2, 2026
Imagine a local historian publishing an essay for anyone to read. She welcomes readers who arrive through search, and she wants other writers to link to her sources. Yet she objects to the essay becoming material for training a commercial AI model. These wishes are compatible as statements of intent. The difficult question is how to communicate them to machines, and what that communication can accomplish once the writing is publicly available.
The Internet Engineering Task Force is working on part of this problem through its AI Preferences group, known as AIPREF. Its charter calls for a common vocabulary, ways of associating preferences with content, and a method for reconciling multiple statements. The intended achievement is practical: different systems should be able to receive a publisher's wishes and understand them consistently. That would give publishers a common language for a conversation currently shaped by particular services and their controls.
As of October 1, 2026, the vocabulary draft, version 08, remains unfinished and explicitly lacks working group consensus. Its categories are AI Training, AI Use and Search. Search directs users to source material through references or links; any excerpts must help assess relevance. Generated summaries are excluded. A preference allowing Search overrides overlapping categories and covers training whose models and outputs stay exclusively within those search conditions.
Consider the differences that any useful vocabulary must confront. Under the proposed vocabulary, AI training modifies a generative model's learned parameters; training for exclusively non-generative tasks is excluded. AI use covers other inputs to a generative model that the user did not directly provide. Meanwhile, a publisher might welcome a result that directs readers to an article while questioning a service that supplies an answer from it. These concerns involve different relationships between publication and reuse. Calling every activity “AI” makes the publisher's actual choice harder to describe.
Google already offers an instructive example of a control tied to particular products. Its Google-Extended documentation describes a robots.txt token covering training future Gemini models for Gemini Apps and the Vertex AI API for Gemini. It also covers grounding in Gemini Apps and Grounding with Google Search on Vertex AI. Here, grounding means supplying content from Google's Search index to a model when it responds to a prompt. Google says the token does not affect a site's inclusion in Google Search and is not a ranking signal. It also has no separate HTTP request user agent: existing Google crawlers retrieve the material. Google's guidance for AI Overviews and AI Mode points instead to Googlebot crawling directives and Search's snippet and indexing controls. Those Search features fall outside the Google-Extended control described here. A publisher therefore has to read the product scope as carefully as the instruction itself.
The IETF's companion attachment draft, version 05 proposes two ways to carry preferences: an HTTP header, sent alongside content, and an additional rule in robots.txt. The latter would add usage preferences for material whose crawling the file allows. Both mechanisms remain proposals. Their attraction is that a publisher could associate a statement with the material that a system encounters, rather than relying on someone to find and interpret a separate notice written for human readers.
However, robots.txt has a precise limitation. RFC 9309, the Robots Exclusion Protocol specification, says its rules are not access authorization and cannot replace security measures. A cooperative crawler can follow a restriction while the page remains technically accessible. A server that requires authentication controls access through a different mechanism. Confusing the two creates false reassurance, particularly for a publisher who assumes that a declaration prevents all retrieval or copying.
Expression, interpretation, and enforcement deserve separate attention. A publisher may communicate a clear preference, a recipient may correctly understand it, and a dispute about conduct may remain. AIPREF's charter expressly excludes technical enforcement and auditing of AI training. The group's intended contribution is a shared way of stating intentions that participating systems can interpret.
Publishers evaluating a company's promise to respect preferences would also need evidence. Useful questions concern how instructions are recorded, which operations they govern, and how complaints are examined. A statement that a service supports a protocol leaves those practical matters open. Records and explanations could help a publisher assess its conduct. Their availability would have to be established with each service. Such accountability needs to be considered when a service claims compliance.
Nor does the absence of technical enforcement resolve the legal position. The vocabulary draft deliberately leaves applicable law and its exceptions intact. Whether particular conduct is permitted or prohibited cannot be inferred merely from the presence, absence, or technical strength of a preference signal. Equally, the word “preference” should not be treated as a legal conclusion about the significance of a publisher's statement.
Time creates another complication. Under the attachment draft's proposed approach, updated robots.txt preferences would not retroactively apply to previously retrieved material. They would apply after a crawler obtains the revised instructions and retrieves the affected material again. This makes the proposal more specific than a general promise that publishers can change their minds. A preference system needs an account of when instructions apply, as well as an account of what they mean.
For independent publishers, a shared vocabulary would reduce the need to explain the same distinction separately to every service. Its practical value would depend on adoption and on controls that people can understand well enough to use deliberately. The task for standards bodies is to make intentions legible across systems; the task for recipients is to make their handling of those intentions accountable. Publishers should be able to see where a signal applies, what a service promises, and how it responds when its conduct is challenged.
September 23, 2026
A new Web feature can begin with a modest complaint. Authors repeatedly build the same kind of interface, browsers handle parts of it differently, and someone asks whether the platform itself should provide a common solution. The idea may appear in a public issue, but it cannot become reliable across the Web merely because an issue attracts support.
Consider the Popover API. It gives a page a way to display content above other content and manage some of the behavior involved in showing and dismissing it. The Open UI W3C Community Group incubated the idea before an April 2022 proposal brought it to the HTML Standard's issue tracker. Open UI makes recommendations to standards groups; it does not define the final standards. Its proposal had already changed from a new <popup> element to a popup attribute after discussion of accessibility and broader uses. Today's HTML Standard uses the name popover, but that sentence skips much of the work between an idea and something people can depend on.
The path raises a larger question for a Web that no single company runs. Who is allowed to propose a change, who writes the shared rules, and who decides whether software will follow them?
WHATWG maintains the HTML Living Standard, among other Web standards. Its work is visible through specifications, issue trackers, proposed text changes, and associated tests. A contributor can bring a problem to the relevant public repository, as happened with popovers. An editor then has to weigh the proposed behavior against existing pages, feedback, and what independent browser implementations can realistically support.
Under WHATWG's Working Mode, adding a feature requires support from at least two implementers. Such support does not bind either one to release it. Changes to required behavior should also receive community review, corresponding tests, and implementation bug reports where browsers disagree with the proposed behavior. The editor makes a judgment about the text; a workstream participant can appeal certain conflicts to the Steering Group. WHATWG also offers an optional stages process for larger proposals. None of this turns an online popularity vote into an HTML feature.
The popover proposal then met a more revealing test than an expression of support: review of the actual changes to HTML. A first pull request was merged on January 12, 2023, and reverted that day while reviewers worked through unresolved behavior. In a revised pull request, writing a test exposed missing checks in the proposed algorithm; the author changed the text, and the revision was merged on January 27. A public proposal could start the discussion, but reviewers, the editor, implementers, and tests all affected what finally entered the standard.
The popover record shows why review continues after text is drafted. In March 2023, a compatibility issue reported that a site had already used popover as its own attribute. In browsers giving the word its new HTML meaning, some of that site's content disappeared. This is a documented report about one site, not evidence of widespread breakage. It shows the constraint on every proposed browser feature: existing pages are part of the environment in which a new rule must work.
Under a 2019 agreement, WHATWG and W3C collaborate on a single version of HTML and the Document Object Model. The editing work takes place in WHATWG repositories, while W3C helps its community raise issues, review proposals, write tests, and bring review drafts to W3C Recommendation status. That arrangement concerns HTML and DOM; the two organizations also have other work of their own.
At W3C, a charter sets a Working Group's scope. Member representatives, invited experts, and W3C staff may participate in the group, and people outside it can comment on public drafts. A public comment deserves consideration, but it does not automatically make its author a Working Group participant. The group's chairs seek consensus, document objections, and guide the work through review.
The current W3C process takes a specification through public Working Drafts and a Candidate Recommendation phase, where implementation experience is gathered, before a Recommendation. The Working Group requests advancement; W3C staff check the requirements, and representatives of member organizations review the Candidate Recommendation before W3C decides whether to publish it as a Recommendation. W3C examines more than whether somebody wrote code: it considers independent, interoperable implementations, deployment, and problems discovered while implementing. A Recommendation records W3C endorsement of a standard. It does not install the feature in every browser or settle every question about its use.
The site's account of Web Authentication Level 3 provides a recent example. It became a W3C Recommendation on August 25, 2026, after years of work. The publication links to a June 26 implementation snapshot using development or preview browser builds, with some failures and timeouts. The document's status and the recorded state of implementations answer different questions. One concerns the standard W3C endorsed; the other helps show what tested software did at a particular time.
The Internet Engineering Task Force, or IETF, develops many of the Internet protocols on which the Web relies. Its process guide says anyone may submit an Internet-Draft. An idea that gains traction can be taken up by a Working Group, revised through discussion and review, and considered by the Internet Engineering Steering Group before publication as a Request for Comments, or RFC. Decisions in a Working Group rely on rough consensus: participants have to address technical objections, rather than simply count votes.
HTTP Semantics, RFC 9110, is an Internet Standard and a useful example of this route. An RFC number alone, however, does not identify an Internet Standard. The RFC series also contains documents with other statuses, and some RFCs come from streams outside the IETF. Readers need to check the document's stated status as well as its title.
These processes meet in an actual Web visit. HTML describes a page and many of its interactions; HTTP describes how clients and servers exchange requests and responses; other W3C specifications may define an authentication API or accessibility requirements. No single standards organization writes every layer.
A specification describes intended behavior. Browser teams decide what they will implement, when they will ship it, and how to handle incompatibilities they find on real sites. Server operators, application developers, and publishers make their own implementation and adoption decisions as well. A published standard has practical force when independent products can use it consistently.
Patent rules also affect who can implement the result. W3C and WHATWG require certain royalty-free licensing commitments from participants, under the terms of their respective policies. Public access to a specification is only one part of making it usable by others.
For many browser-facing features, web-platform-tests provides shared tests that can be run in different browsers. A test can expose a disagreement between two implementations or reveal a missing step in proposed text, as happened with the popover revision. The tests themselves are reviewed and corrected; a green result covers the behavior that was tested, and a testing plan must consider what is missing. Test results alone cannot settle every accessibility or security question. Protocols and other specifications can require different forms of testing.
This creates an uneven distribution of influence. Anyone can raise an issue in many of these public processes, but an organization able to devote engineers to specifications, tests, and a browser engine can do more to advance or delay a proposal. That is an inference from the processes' implementation requirements and the separate decision to ship software. Much of the technical debate can be examined in public. Some W3C review channels are limited to members, and public participation does not give everyone the same time, resources, or formal role in decisions.
When a headline says the Web is getting a new capability, first find the proposal or issue. Look for the problem it identifies, the alternatives considered, and feedback from people who will use or be affected by it. Then check which organization is working on the relevant specification and what status the document actually has.
After that, look for tests, implementation reports, browser release information, and compatibility concerns. These records will rarely tell a perfectly straight story. They do show whether a proposal is still an idea, has become agreed text, is being tested, or has reached the software people use.
The Web changes through that sequence of choices. Contributors identify problems; editors and working groups shape rules; reviewers question them; implementers try them; tests expose differences; and people publishing and using sites live with the results. Public records let more people examine and challenge many of those choices while the shared Web is still being made.
WHATWG Working Mode, optional stages process, and HTML Standard: popover
Popover's first proposed text, reversal, and revised proposal
W3C Process Document, WebAuthn Level 3 Recommendation, and its implementation report
W3C Patent Policy and WHATWG Intellectual Property Rights Policy
IETF standards process guide, RFC 9110, and the RFC Editor's explanation of RFC status
web-platform-tests project, test review checklist, and testing-plan guidance
September 8, 2026
The world’s first website had an unusual subject: the World Wide Web.
Created by Tim Berners-Lee at CERN, the first site did not begin with news, shopping, photographs, or a personal homepage. It explained the new information system itself: what the Web was, how to use it, what software was available, how to create a server, and where to find other information as more of it came online. CERN describes the first website as being dedicated to the World Wide Web project itself.
There was a practical reason for this. At the beginning, the Web had a bootstrap problem. Before people could find large amounts of useful material on it, somebody had to explain how to connect to it, use a browser, operate a server, create documents, and add new information. The first website therefore served partly as documentation and partly as an invitation to build more of the Web.
The original WorldWideWeb program also combined browsing and editing. The early Web was therefore not conceived simply as something people would read. Its first software allowed users to create and edit hypertext as well as follow links.
The first HTTP page was created at CERN at the end of 1990. Berners-Lee later identified its original address as being on nxoc01.cern.ch; the machine subsequently became better known through the info.cern.ch name. The first browser and the first Web server were both running on Berners-Lee’s NeXT computer. Berners-Lee discusses this early history in his Web FAQ.
A surviving November 1992 version of the project page shows how broad the site’s purpose had become during the Web’s first two years. It introduced the World Wide Web as a system intended to provide access to a large universe of documents, then linked readers to sections headed “What’s out there?”, “Help,” “Software Products,” “Technical,” “People,” “History,” “How can I help?” and “Getting code.” The page can still be viewed through CERN’s preserved World Wide Web project page.
That structure is revealing. The site did not merely describe a finished invention. It contained many of the things needed to expand the system itself. Readers could learn about browsers and servers, examine technical information about protocols and formats, obtain software, and find instructions for contributing.
A surviving page devoted to helping the Web grow encouraged people to put information online, suggest new servers, write software, maintain subject areas, and tell others about the Web. The system was being explained to people who were also being invited to extend it.
The documentation was itself hypertext. Instead of producing a manual about hyperlinks and leaving the new system outside the explanation, the Web’s developers could demonstrate the idea by using it. A page describing the project could link directly to its software, technical details, history, people, and increasingly to information elsewhere.
The explanation was also an example of the thing being explained.
This mattered because Berners-Lee was not simply trying to distribute one piece of software. Adoption required other people to run browsers, establish servers, publish information, and make links. He later described the Web’s early years as a period of persuasion in which the project needed clients for additional computer platforms and “seed servers” that could provide examples and reasons for others to participate. His account of this period appears in A Very Short Personal History of the Web.
The early site also shows that the Web was conceived as more than a collection of HTML pages. Its technical material discussed protocols, addressing, servers, data sources, implementation guidelines, and ways of connecting existing information systems to the Web. Early server software could provide gateways into information already held in other systems. The surviving technical documentation shows how broadly the Web was already being treated as an information architecture rather than simply a publishing format.
That point is easy to miss when looking backward from today. The early Web was not built on the assumption that all useful information would first have to be recreated as new websites. One of its strengths was the ability to place common addressing and hyperlinks around information that already existed. Berners-Lee described the Web as flexible enough to provide hypertext views of other information systems rather than requiring each of those systems to be replaced.
There is also an important date to clarify. August 6, 1991 is sometimes presented as the birthday of the first website. The history is more precise than that. Berners-Lee says the first HTTP page existed by the end of 1990. On August 6, 1991, he posted information about the WorldWideWeb project to the alt.hypertext newsgroup, helping introduce the project to a much wider Internet audience. His FAQ distinguishes these dates.
Nor should the version visible today be mistaken for a perfect snapshot of the page as it appeared in 1990. Berners-Lee has said that he did not retain a very early 1990 or 1991 copy. A November 1992 archive preserves much material from the Web’s early period, while CERN later undertook work to restore and preserve the first website at info.cern.ch.
The first website being about the Web itself was therefore more than an amusing historical coincidence. The new medium needed to explain how it worked, show what it could do, and give other people the information required to extend it.
Its first subject was, in effect, how to make the second website, and the third, and all the ones that followed.
For further reading, see CERN’s short history of the Web, the preserved World Wide Web project page, and Tim Berners-Lee’s personal account of the Web’s early development.
The strongest improvement is the distinction between what we know about the original 1990 site and what we can actually inspect in the November 1992 archive.
August 28, 2026
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.
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.
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.
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.
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.
August 17, 2026
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
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
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
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 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
Revised August 5, 2026
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
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
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 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
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/
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