Security and Privacy for our times

To address the evolving threats to users’ security and privacy online, the W3C Technical Architecture Group and the Privacy Interest Group have updated the Security and Privacy Questionnaire so that developers of web features consider and mitigate modern threats to users as they design their features.

The goal of the document is to provide a framework for authors to think about security and privacy at all points throughout the feature design and specification process — ideation, initial review, iteration, and wide review. Security and design decisions should be documented and updated throughout the development of a specific feature. 

There were three significant revisions to the document:

  • When and how the document is to be used was clarified.
  • The questions themselves have been updated and revised.
  • The threat model has been updated throughout.

The security and privacy questionnaire has been utilized in a variety of ways — from using it as a starting point to consider these issues in a feature, to the basis of the security and privacy considerations of a standard. The questionnaire now makes it clear that feature developers should consider security and privacy early in the feature’s lifecycle, that the TAG will be carefully considering the security and privacy of a feature in their design reviews, and that a security and privacy considerations section of a specification is more than answers to the questionnaire.

To make it easier for feature developers, spec reviewers, implementers, and other interested parties to better understand the potential impact of a feature, questions have been updated. Broadly speaking, the updates take two forms: (1) focusing on how — rather than if — the specification handles data in general, and (2) providing context as to why that question is being asked with real world examples of where there has been security and privacy impact. 

The threat model and specific threats that a specification author should consider have also been updated. The questionnaire contains a new high level type of threat legitimate misuse. Including this threat into the Security and Privacy Questionnaire is meant to highlight that just because a feature is possible does not mean that the feature should necessarily be developed, particularly if the benefitting audience is outnumbered by the adversely impacted audience, especially in the long term. As a result, one mitigation for the privacy impact of a feature is for a user agent to drop the feature (or not implement it). Features should be secure and private by default and issues mitigated in their design; user agents should not be afraid of undermining their users’ privacy by implementing new web standards or need to resort to breaking specifications in implementation to preserve user privacy. Web technology developers should consider that features may not be implemented if risks are found impossible or unsatisfactorily mitigated. Moreover, in the questions and the mitigation sections, we highlight that not all parties on the web are equivalent in how they are handled:  specification authors may want to consider first and third parties separately in their feature to protect user security and privacy.

We hope the updated Security and Privacy Questionnaire helps authors in ensuring the security and privacy of their web features and the web platform overall. Focusing on security and privacy at the early stages of the reviews should be the standard, in line with Privacy by Design. While we don’t plan a significant review before 2024, we will keep monitoring its performance, as well as the external environment: new risks, threats, expectations. 

Finally, we would want to thank Mike West for his significant work on the previous version of the questionnaire. 

Jason Novak manages the User Privacy Compliance, Verification, and Standards team at Apple Inc; on behalf of Privacy Interest Group.

Lukasz Olejnik is an independent security and privacy researcher; on behalf of Technical Architecture Group.


Our ethics drive the architecture of the web

Ancient fragment of the Hippocratic oath on papyrus

Fragment of the Hippocratic oath. This file comes from Wellcome Images, a website operated by Wellcome Trust, a global charitable foundation based in the United Kingdom.

The TAG publishes ethical principles for spec authors and platform developers.

A big part of our job as the TAG is to help spec authors with their ideas for a new feature on the web. We help them think about things like how their proposal could work with other features, whether it might have unintended consequences, and how they can learn from someone else’s similar experience.

A lot of our advice in these design reviews comes from our personal experiences, but we also try to point to existing documents to help explain.

The more we’ve talked about the logic under our advice, the more we’ve realized how much these ethical principles are at the heart of how the web works — and therefore is some of our most important advice to spec authors. And they hadn’t been written down, which is why we wrote this finding, W3C TAG Ethical Web Principles.

The principles themselves aren’t technical, but they have substantial technical implications. And we have tried to make those implications clear. For example:

Principle: The web is for all people

Explanation: We will build internationalization and localization capabilities into our specs and websites. We must make our websites accessible for people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. We must build for users on low bandwidth networks and low specification equipment.

This work was sparked by this blog post by our co-chair Dan Appelquist, reacting to what he called “[Our] anxiety about the current state of the world and the role the web has unwitting played in making it that way. The misuse of social media to control public opinion through the spread of propaganda, bot-enabled harassment campaigns and over-reliance on biased and simplistic algorithms for content promotion are some of the unexpected consequences of a world wide ‘web of information nodes in which the user can browse at will.’”

In that light, we thought it was especially important to highlight our ethical responsibilities as web and platform developers. This finding brings together those traditions and philosophies that underpin how the web works.

As always, our docs are evolving and we welcome feedback and pull requests.

Distributed and syndicated content: what’s wrong with this picture?

Screenshot of AMP's RT article, headline: Meet Achilles the Cat, deaf animal psychic

You know those AMP URLs you get from Google search results and which often pop up on Twitter?

Instead of…  you’ll get s/…

What you’re seeing is Google’s AMP project hosting content for Russia Today. This lets Google load the page during the search results, so that when you click on the link on the search page, the text appears immediately.  (This is solving a big problem, by the way.  That shorter loading time can make the web a far more enjoyable experience.)

Facebook’s Instant Articles and Apple News operate similarly but without the benefit of being on the web or using real URLs — a much worse starting point.

The web relies heavily on the “origin policy”, which amongst other things, helps browsers manage permissions (e.g., access to your location, camera, microphone, etc.), attribute bad actions (phishing attacks), and assist you with things like passwords and filling out forms.  This core aspect of web architecture ties permissions and security settings to a particular origin, like Distributing or syndicating content removes that context by hosting one site’s content within a different site, which can confuse users and stop browsers from keeping the web safe.

In the W3C Technical Architecture Group we have been thinking about this issue.  While we understand the value these approaches provide, they also pose serious issues. Fundamentally, we think that it’s crucial to the web ecosystem for you to understand where content comes from and for the browser to protect you from harm. We are seriously concerned about publication strategies that undermine them.

We have published this finding to explain our thoughts in more detail.

The TAG’s concerns about the Digital Object Architecture and the Web

Recently, the UN’s ITU has been involved in standardising and supporting a new architecture for resource identity and resolution, the Digital Object Architecture (DOA). Descriptions of the DOA indicate that it is designed to create and manage persistent identifiers for all entities in the Internet of Things, tracking and policing copyright, interoperable medical records, and authorising access to a network resources.

URIs and URLs form a proven mechanism for identifying resources on the Web and the Internet, have succeeded at a global scale in the decades since they were introduced, and are a central component of web architecture.

If the ITU has identified use cases not met by URIs and the existing Web architecture, the TAG welcomes collaboration about what adjustments are needed — in the context of existing open standards processes.

Extensible Web Summit: Melbourne Edition

The TAG has been engaging with the developer community through evening meetups and longer “summit” events. We’ve so far run three “extensible web summit” events, two in San Francisco and one in Berlin, Our next face-to-face meeting is coming up in Melbourne in January 2016 and we thought we’d take advantage of this opportunity to meet and get feedback from the vibrant web developer community there.

So…with the help of our hosts at RMIT, we’re going to run a half-day developer event and un-conference: “Extensible Web Summit, Melbourne Edition.” This will be a half-day event in the afternoon of the 12th of January. If you want to find out more about the ethos behind the Extensible Web Summit, please visit our page at

Topics to be discussed will include the Extensible Web Manifesto  as well as other new and emerging web technologies and standards.

The Summit is free to attend and depends heavily on participant engagement. After the lightning talks, participants will create the schedule for a set of parallel breakout sessions. These discussions will be moderated and will be minuted, with the intention of informing future work.

Please register if you would like to attend. We hope to see you there!

Assuring a Strong and Secure Web Platform

At the recent W3C TPAC meeting the TAG convened a special session to discuss, among other things, Cory Doctorow’s call for a “non-agression covenant.” The concern Cory has voiced is related to the unintended consequences of certain pieces of legislation which have had a chilling effect on security research on software. Although Cory’s concerns have mostly been related the implementation of Encrypted Media Extensions, we believe there is a larger architectural issue at stake which needs to be called out. The TAG therefore agreed the following resolution:

The Web has been built through iteration and collaboration, and enjoys strong security because so many people are able to continually test and review its designs and implementations. As the Web gains interfaces to new device capabilities, we rely even more on broad participation, testing, and audit to keep users safe and the web’s security model intact. Therefore, W3C policy should assure that such broad testing and audit continues to be possible, as it is necessary to keep both design and implementation quality high.

TAG By-Election: 2015

The Technical Architecture Group normally holds an election every year for seats that have come to the end of their elected terms. However, under certain circumstances, the TAG must run a special election (sometimes referred to as a by-election). Such a special election is now taking place, to fill the vacated seat of David Herman of Mozilla. We’re lucky enough to have an impressive slate of candidates for this option position: David Baron of Mozilla, Andrew Betts of Pearson/The Financial Times, Sergey Konstantinov of Yandex (already a TAG alumnus) and Bryan Sullivan of AT&T.  All the candidate statements may be found on the official W3C election announcement.

Now comes your part. The election process behind the TAG helps us to set our priorities and agenda and helps us to understand the mandate by which the W3C membership wants us to work. But this only works if the as many as possible of the W3C’s 397 members participate in the election by casting their vote. If you work for, or are affiliated with, a W3C member company or organization, find out who your W3C Advisory Committee (AC) representative is and encourage them to vote. If you don’t have such a direct relationship with the W3C, then encourage people you know who do work for W3C member companies to use their vote. The TAG has a responsibility to help guide the activities of the W3C and to help set the architectural vision for the evolving web. As we execute that mission, we want to be as responsible to the larger web community as possible. With your help, we can ensure that we achieve this goal.

Securing the Web

Today, the TAG approved a new finding, “Securing the Web.”

As the Web platform becomes more powerful, it also becomes more susceptible to a variety of attacks; someone who can pose as the server or modify content on its way to you can insert persistent scripts to track your activity, to modify what you see and even to access your data. These attacks affect all Web sites, not just “sensitive” ones, because the power the platform provides can be misused by attackers even if the site isn’t using it.

At the same time, the IAB has issued advice to design for confidential operation by default, due to the pervasive monitoring attacks that have become prevalent recently.

So, after careful consideration, the TAG has found that:

* The Web platform should be designed to actively prefer secure communication — typically, by encouraging use of “https://” URLs instead of “http://” ones.
* Barriers to adopting “https://” should be removed where feasible.
* The end-to-end nature of TLS encryption must not be compromised on the Web, in order to preserve trust.

Please read the full finding for details. It is primarily aimed at those creating W3C specifications; if Working Groups need assistance, we encourage them to engage with us.

We expect that we will continue to focus on security issues as this finding is implemented.


By design, five of the participants on the TAG are elected by the members of W3C. That means that the membership of W3C have a direct influence over the composition of the TAG and therefore over its technical direction, priorities and mandate. In practice, this has meant that in the past couple of years we have had a significant shift of focus, as W3C membership has chosen to elect candidates whose area of expertise is more oriented around the browser, who have more of an interest in the intersection between JavaScript and other Web technologies, who have been signatories to the Extensible Web Manifesto and who have had a strong belief that the TAG can play a constructive role in connecting the developer community with standards. We’ve taken this mandate seriously and embarked in a program of activities these past two years that have included developer outreach events, “summits,” new findings such as the Promises Guide and guidelines on the use of Capability URLs as well as working on API design with such efforts as Web Audio, EME, Responsive Images and the Push API.

Now an election cycle is starting and four of our seats are up for election. You now have another opportunity to shape the work of the TAG. And by “you” I do not only mean the 401 W3C members as represented by its august Advisory Committee. I mean “you” the web community at large. The nominees are put forward and the votes are cast by W3C members. So if you work for, or are associated with, one of these then you have an opportunity to influence this process via your Advisory Committee representative. If you would like to put yourself forward for the TAG election, or if you have opinions on the the slate of candidates, let that A.C. representative know. If you are not associated with a W3C member you can still get involved. Reach out to someone you know who is associated with a W3C member to let them know what you think is most important for the long-term direction of the Web or to put yourself forward for nomination. Write a blog post. Tweet and mention @w3ctag. Get involved in our discussions on our public mailing list and on Github. The W3C, as a trustee of web technologies and standards holds this position in trust of the wider web community, and the TAG, as steward of Web architecture needs to do so as well.

The nomination period ends on the 30th of November and the election itself will take place in late December and early January. Thanks for your help and support!

Introducing the Extensible Web Report Card

[Post amended to further elaborate on how the Report Card fits into the rest of the TAG’s Work]

The TAG is chartered to work on the architecture of the web.  As the Web continues to evolves from a Web documents to a Web of distributed applications, and as Javascript programming has become such an important part of web development, it’s becoming more important than ever to focus on how we add new features to the web and how we extend existing features. Last year, some members of the TAG collaborated with others in the community in some thinking which resulted in the Extensible Web Manifesto. The ideas promoted by this vision of the future, which include exposing low-level capabilities and doing so in a layered way, have influenced a lot of the work of the TAG, particularly around our specification reviews.

We’ve had feedback at some of our developer meet-ups this year that people would like a better idea articulation from us of the design principles the TAG is employing when we review specs. We’ve also had a lot of questions about how the views in the Extensible Web Manifesto relate to the TAG’s current work. We thought one way to address these questions would be to publish a review of (what we see as) some key standards and how they measure up against the ideals of extensibility. A kind of “Report Card” on the state of the extensible web that could simultaneously provide some feedback to individual standards efforts and show the community some examples of what we’re talking about. The Extensible Web Report Card is the result and it’s a document that we hope to continue to update as new information becomes available. Have a look and please feel free to comment on our work on GitHub or to fork and send pull requests.