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 https://www.rt.com/sport/…  you’ll get https://www.google.co.uk/amp/ s/www.rt.com/document/…

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 rt.com. 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 extensiblewebsummit.org.

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.

TAG Developer Meetup : 22 July in Cambridge, Massachusetts, USA

The TAG will be holding a developer meetup along side of our next face-to-face meeting in Cambridge, Mass. The event will be in the evening of the 22nd of July, will be hosted by Akamai and organized by the BostonJS meetup group. Thanks to both Akamai and BostonJS for helping us out!

As with our previous TAG developer meet-ups, this will be a pretty simple format. We’ll get the TAG members up on stage for a panel discussion about some of the topics we’re covering. We’re going to let you know what we’re working on, answer questions and hopefully engage in some spirited discussion. The event is open to anyone interested in web architecture, web development, web standards and the future of web tech. It’s free to attend and you do not have to already be a member of BostonJS to attend (though you will have to join that meetup group if you want to register). The event is also listed on lanyrd (though you must register on the BostonJS meetup group to attend).

Capability URLs: We Need Your Feedback

The battle for web security and privacy is fought at many levels. Sometimes common practice in web application design can lead to data leakage with untended consequences for users. A good example of this came up recently where confidential files shared through common web-based document sharing services were being exposed unintentionaly to third parties because the private URLs used to share them had been unintentionally leaked.

URLs that allow a user to access an otherwise privileged resource or information are called Capability URLs, and while they can be powerful, they can also cause potential problems when used improperly.

TAG member Jeni Tennison has been working on a draft defining the space of capability URLs and outlining some good practices for usage. We think this document should be useful for web builders who are thinking about incorporating this pattern into their applications. We think it’s pretty good, but we need your feedback before we finalize it and release it as a TAG finding.

The draft may be found here: http://www.w3.org/TR/capability-urls/ and if you have feedback you are encouraged to raise an issue on github or e-mail us on the TAG public mailing list. Thanks!