Tag Archives: W3C


What should the W3C TAG do next?

I am running for election to the W3C Technical Architecture Group (TAG).

What is the TAG known for? Well, primarily the Architecture of the World Wide Web, Volume 1 which was created in 2004. This document summarized principles, constraints, and good practice notes as of that time.

Since then the TAG has reviewed architectural issues on what appears to be an ad hoc basis, producing what are known as “TAG Findings“, expert answers to specific questions.  I surmise that the visibility and usefulness of these has been less than it could be, probably since W3C working groups are not always either aware of them at all, or not sure which might be applicable to the problems they are working on, or if they’ve seen them, not sure how to apply them to the specific problem they are facing.

The TAG has also devoted much effort on work that has not reached conclusion, given the wide constituency and difficulty of the problems they have worked on. In some cases the work has stopped with “draft findings, in other cases only discussion on the mail list. A lot of good ideas and information may be lost but it is hard to tell.

The W3C is in a sea of change, including movement toward “living documents” as opposed to versioned dated documents. The idea of versioned documents was simple – a group agrees to approve a definitive version as of a date in time, making it a standard. The benefits of this approach are clear – there is a static document that can be referenced, will not change, and for which consensus can be clearly recorded. The issues are also clear: with faster development cycles static documents can become out of date more quickly making it misleading to have a static approved document as the target of links when newer corrected material is available yet not readily found.  The solution to this issue is to have continuously updated drafts, so that the latest version is the definitive version, so called “living documents”. The concern here is that the process can spin out of control, with editors adding what they will without checks and balances – “if you don’t spot it, you must approve it”could become the new mantra. We need both – a rapid cycle time as well as clarity of approval and agreement.  (The solution in progress appears to be pull requests in git accepted by those we trust).

What does this have to do with the TAG? Well the TAG is part of this sea of change as well, as reflected in the previous TAG election where a common theme was that the TAG need work less on abstractions and closer to the needs of developers and working groups. There is a desire that the TAG produce material relevant to current work on web applications (and other topics) and that this material can be easily found and used.

It seems the time has come for an new volume of the Architecture of the World Wide Web, addressing topics related to Open Web Platform applications, APIs and programming, open data, and security and privacy.  I’d argue for a new volume, as I’d rather not see history rewritten (e.g. to expunge XML, despite it’s continued use in various communities). It is usually easier to correct and improve a draft than to create a new one, so the TAG should seed the process of “documenting and creating consensus around principles of Web architecture” by creating a new Architecture of the World Wide Web volume and working with the W3C community to get it right. This continues the original TAG mission yet represents a change from the recent past in how it is done.

I suggest that focusing on addressing high priority issues of the web architectural evolution and interoperability with the focus of producing a specific document can give the TAG focus and enable  feedback, organizing “findings” and issue resolution into a specific result that can be readily shared. I can help with this, both with the writing and creation of this new work as well as collaborating with the TAG, in the Working Groups and communities (such as PING and others). What I can do, as a member of the TAG, is to get this started, organized, written down, and communicated so that the work of the TAG is visible and useful to the community and so the community can get involved to make it better.

W3C Workshop on Web Tracking and User Privacy

One topic that is getting a lot of press lately is privacy on the Internet, especially web tracking [Notes].

The W3C held a “Workshop on Web Tracking and User Privacy” on 28/29 April 2011, for which an agenda with links to presentations workshop papers and a final report are available.

This is a difficult topic since there is a need for a balance between what appears to be a legitimate need to enable advertising-based business models to support “free” content and the ability of users to protect their privacy, not losing control over their own personal data.  

Discussion at the workshop reflected the privacy needs of individuals on the web as well as support for business models driven by advertising. Technical proposals such as an HTTP do not track header and use of tracking protection lists were considered.

Ed Felton of the FTC noted five desired properties of a “Do Not Track” mechanism in his slides:

  1. Is it universal? Will it cover all trackers? 
  2. Is it usable?  Easy to find, understand and use?
  3. Is it permanent? Does opt-out get lost? 
  4. Is it effective and enforceable? Does it cover all tracking technologies? 
  5. Does it cover collection in general and not just some uses like ads? 

A significant issue noted at the workshop is that “user expectations may  not match what is implemented”. One example is that the discussion is not about “opting out of ads” but out of “tracking”, so even with opt-out, ads might still appear.  More complicated for users is that nuances might be possible such as allowing 1st party tracking but not third party tracking – yet what does this mean at the edge cases? Is a subsidiary a third party? What about outsourced work? This could be confusing for users and lead to results that are not what they expect or want. As mentioned at the workshop, the details will matter here.

Craig Wills of the Computer Science Department, Worcester Polytechnic Institute noted that first parties have a responsibility for not “leaking” privacy information to third parties by not being careful in their implementations. This is detailed in his paper.

Helen Nissbaum made an important point during the discussion. Consent is not always needed, but only when user expectations are not met (or there is a risk of not meeting user expectations, I assume). Consent is not needed every step of the way. This relates to the theme of avoiding unnecessary user interaction, avoiding meaningless dialogs and increasing usability.

Questions to ask before tracking include:

  1. Is  it necessary to collect the data
  2. Can the goal be accomplished another way, with less data

Regulations and laws should not be overly prescriptive with respect to technology details, otherwise as the technology changes they lose effect. Instead they should focus on the policy and goals. This is similar to mandating fuel efficiency in cars rather than the way it is achieved.

Apparently enabling some tracking but not all tracking, for a variety of parties, is difficult.

Workshop participants recognized the complexity and difficulties of the topic but also the need for steps to be taken in the near term. During the workshop goals were mentioned that included providing  transaction transparency, relevant information, and  meaningful user choices. It is clear that some changes may be required.
Workshop participants noted that there is much research into the economics of “do not track”.

John Morris of CDT enumerated in his slides the typical objections raised with respect to implementing mechanisms to increase user privacy and indicated how they might be addressed, for example relying on  non-technical mechanisms such as reputation, law or regulation rather than technology for enforcement. 

Given the various stakeholders and concerns, the principle of doing what is “reasonable” seems to apply here, just as in other aspects of law. 

Thus it is not surprising that there was general acceptance by workshop participants of adopting a middle-ground approach – specifically there was no objection to the proposal from CDT that includes the following definition:

“Tracking is the collection and correlation of data about the web-based activities of a particular user, computer, or device across non-commonly branded websites, for any purpose other than specifically excepted third-party ad reporting practices, narrowly scoped fraud prevention, or compliance with law enforcement requests.”

As noted in the W3C workshop report, possible next steps include the W3C chartering a general Interest Group to consider ongoing Web privacy issues and a W3C Working Group to standardize technologies and explore policy definitions of tracking.


[1] Retargeting Ads Follow Surfers to Other Sites, August 29, 2010, New York Times

[2] How to Fix (or Kill) Web Data About You, April 13, 2011,  New York Times

[3] Tracking File Found in iPhones, April 20, 2011, New York Times

[4] Apple, Google Collect User Data, April 22, 2011, Wall Street Journal

[5] Avoiding Mobile Trackers, April 22, 2011, Wall Street Journal

[6] Facebook hit by privacy complaints, June 9, 2011 Financial Times

(edit – added paragraphs at end re CDT proposal)

W3C Identity in the Browser Workshop

The W3C recently held a workshop on Identity in the Browser for which a number of position papers are available as well as a blog post, agenda with presentation links, and a workshop report.

I submitted a position paper and gave a presentation noting that requirements that are simple to express can have large consequences in terms of complexity and implementation. I mentioned as an example to efforts in the Liberty Alliance to avoid correlation of identity across service providers through the use of opaque name identifiers. Another example is  managing policy definitions with multiple parties involved in setting policy.  I also highlighted the applicability of the FTC Do Not Track requirements mentioned in the previous W3C workshop on Web Tracking and User Privacy.

The workshop was well attended, including significant attendance and interest from  a wide variety of stakeholders.

Possible next steps were focused on incremental improvements to current technology, with the intent of achieving results in a short time frame, including  

(a) Creating a standard for tagging web form fields so that password fillers can work reliably (e.g. know which field is user name, password etc )

(b) Enabling crypto functions available to Javascript applications, with the approach of encouraging re-use of secure implementations rather than use (mis-use) of primitives 

(c) further discussion of the broader issues on a mail list.

There was a useful review of requirements with rough agreement on most of these. Discussion of the failure of some earlier attempts at addressing these issues included mention that this is a wicked problem, that usability is essential, that it must be a decentralized and user-centric system  and that the buy-in of all stakeholders, including web service providers is essential, and that there must be incentives for all.

Note was made of the relevance of the NSTIC (US National Strategy for Trusted Identities in Cyberspace)  initiative.

There were many interesting papers, a small sampling is the following:

Federated Browser-Based Identity using Email Addresses, Mike Hanson Dan Mills Ben Adida

The Emerging JSON-Based Identity Protocol Suite, Michael B. Jones, also see the slides

(edited first paragraph to update link to workshop report and provide link to agenda with presentations)

A call for reasonable Web Tracking and User Privacy

rea·son·able – (see http://www.merriam-webster.com/ )
a : being in accordance with reason reasonable theory>
b : not extreme or excessive < reasonable requests>c : moderatefair reasonable chance> reasonable price>d : inexpensive

At the W3C workshop on Web Tracking and User Privacy there were a number of themes.

One theme is that there are different business interests related to tracking user activity on the web and different definitions of tracking. For example, 1st party tracking might involve a web site recording information to maintain a shopping cart contents, something a user would typically expect. Third party tracking might be used to provide advertisements to a user based on their activity. This may or may not be acceptable to a user but relates to efforts to fund a site that may provide value without charging a fee.

Some tracking offers end users value, whether it be in supporting “free” services or in providing targeted ads that are useful and of interest. 

Of greater concern is the lack of transparency and accountability – tracking without user knowledge or permission and the potential for misuse of the information due to inappropriately long retention or 

Another theme is that usability is important and this includes not burdening users with needless and numerous prompts for permission. In fact, given experience with security prompts such as those related to SSL/TLS certificates,