Opera Developer News

On the Opera Desktop Team blog, there is a new experimental build available which includes support for the "Do Not Track" feature. Last year, in April 2011, the W3C invited the industry and the user alike to participate in a workshop on Web Tracking and User Privacy. A few months later, after a very successful workshop, a working group started the work on Web tracking with essentially three items in its charter:

• Tracking Preference Expression (Do Not Track): This specification defines the technical mechanisms for expressing a Do Not Track preference, for example as an HTTP header or a DOM property. It may include mechanisms for sites to signal whether and how they honor this preference.
• Tracking Preference Expression Definitions and Compliance: This specification defines the meaning of a Do Not Track preference and sets out practices for Web sites to comply with this preference.
• Tracking Selection Lists: This specification defines a format for interchangeable lists for blocking or allowing Web tracking elements and expected user agent interpretation of this format.

The work is not finished. Since the beginning of the Working Group, we exchanged around 2000 messages. There are representatives of the different stakeholders: browser vendors, regulators (USA, Europe mainly), Advertising business, Privacy businesses, Service providers and user advocacy organisations.

What does DNT mean?

Many of you may have heard about the DNT (Do Not Track) HTTP header being implemented in the major browsers, Firefox, Safari, Internet Explorer and now Opera. When the user activates it, it sends a signal to the server in its headers for each HTTP request. The current form is:

DNT: 1

This is basically no more than you wearing a badge in the streets saying that you do not wish to be tracked. This is very important to understand. We do not want to create a false sense of privacy or security to our users. This signal is being defined by the Tracking Preference Expression specification.

As a user you might then say: “So what? That doesn’t protect me.” and you would be right.

The most important document, and currently most debated, is the Tracking Preference Expression Definitions and Compliance document. We are in the process of defining what a service provider (and its associated Advertising business partners) should do when they receive the DNT: 1 signal. This is essential. Plenty of questions are raised during the discussions such as the definition of tracking, data aggregation, personal information, co-branding, etc. These are very hard questions because they are rarely technical. Some of the decisions could be very disruptive for the Web industry as large. It’s why the group is trying to forge a path that all the stakeholders will be able to live with but also to implement the specifications. If the Working Group decides a meaning for DNT: 1 and nobody is willing to implement it, because it is too hard or disruptive for their business, the users will have lost. There is a sweet spot to reach that will satisfay the Adveristing industry and the NGO and legislators.

The third document is a defence mechanism initially proposed by Microsoft. We found the proposal interesting at Opera and we decided to work on it with Opera. It fits in with our previously already available Site Blocking API. The rationale is simple. If a user activates DNT: 1, but some service providers do not behave accordingly to the meaning of DNT: 1, then there is a mechanism for users to block these sites. This last document has met more resistance than the two others and we are still working on it to have a concrete proposal in front of the Working Group.

Why is it important for Opera?

This work is very important for Opera for two reasons. We are both a browser implementer and a service provider. The recently released build will help us to understand the interactions and the issues it might create when a user is activating the DNT: 1 header. We would like to see how implementable the Working Group suggestions are on the server side too. Our social network, My.Opera, and the very useful Opera Mini browser have to be tested against the specification.

Several months ago, Paul Irish and I got an idea to create a service that would give out recommendations on which HTML5 features to use and how to use them. Finally, yesterday, we pushed that site live: html5please.us.

The pressing problem for web developers has been to know which features are good to use, which are not. Most likely, they spend hours working on sites using some new features, only to be burnt in the process using features that are not performance-friendly, having incomplete support or using the wrong polyfill.

I spent a lot of time thinking of how to best implement this such that it would be easy to work with among contributors and also be easy to compile into a single site. Tim Branyen helped in much of the brainstorming and finally we came up with a node/backbone implementation that took a set of markdown posts and stitched them into a single HTML page. The node application also automatically tries to add a link to when can i use for each of the features. I also added another check to verify these links exist and if not, remove them before being published.

Thanks to Deepak Jois for writing the shell-script that allows easy addition of new features. Connor Montgomery, Peter Beverloo and Addy Osmani also helped significantly in making sure the content was relevant and correct.

Let us know what you think and also if you could, help in the effort.