Thank you. Presets are coming before this summer, when the very experimental NoScript Anywhere and “classic” NoScript will be merged.

1. There is not possible not to set an option by default.
Even if you let people choose actively, that is an option you choose, between choosing actively or not.
2. As a not tech savvy user, I do not want to face dozens of choices i do not even understand.
3. SUGGESTION. Perhaps the best choice is to inform new users that noscript comes preset to highest level of security and privacy but "you could later change this settings as you get familiarized with it and decide to change them".
4. the do not track me would become a great tool for policy regulations!

I think it’s worth re-stating that: Creating a binding contract with something as flimsy as a near-anonymous header is very difficult in the first place. If you, as an end-user, don’t even bother to actually action it and then ’sort of’ delegate that responsibility to a third-party (but not even in writing or through a T+C or something legal)… then it’s tough to see how a court is going to be able to make any use of it.

The kind of vagueness automatic opt-in by a third-party creates is exactly the kind of thing that don’t lead to binding contracts. It only takes one of the many possible vague elements to be rejected to create a lasting precedent that could kill DNT for good.

DNT is going to be tough enough to make work in a court of law (not necessarily just in the US, as well). This seems like a big hurdle it doesn’t need.

Easy. "Although the header was included by a piece of software which, you admit yourself, added the feature in an automatic update without your intervention - you have not at any point taken any explicit action to identify yourself as part of this scheme. I submit that your actions MUST supersede any action taken indirectly by your computer system to whose behaviour you are not legally beholden."

The law cares about positive actions - not bits sent over headers. In such the same way that if a web site makes you erase all your files (because you weren’t using NoScript), you are not held legally responsible. ‘The computer did it for me/him/her’ is not considered a valid argument.

The legal basis of DNT is reliant not on the header (which is simply an identifier of intent) but the actual act of opting-in to DNT itself. I suspect simply having an update silently pushed onto your machine would not stand up in court and would form the basis of any defense/prosecution against DNT.

I would instead suggest that if the user is using NoScript/DNT functionality for the first time, they are asked simply if they want to opt-in in a two second process. Strikes me as much more legally sound. At the very least, it should be nestled in the software’s contract of use, creating some kind of binding agreement that you accept and recognise you have chosen to opt-in to DNT in a legal sense.

The issue is that DNT is legally dilute if you do not opt-in. DNT is a legal mechanism applied to the user, not a blocking technology you can just ‘flick on’ to prevent another technology from triggering.

(Disclaimer: Not a lawyer)

It’s been noted fairly widely already that tracking has concrete potential for individual fingerprinting. Aggregation of even simple behavioural patterns would be plenty for those in the thriving fraud business to sharpen their already acutely successful tools. Any kind of tracking increases insecurity.
This alone, for anybody who identifies NoScript as primarily a security tool, is a good reason to have this header turned on - if only yet as a vote for some kind of pressure for servers to honour it. Even if only a few popular sites honour it, it would interrupt tracking possibly enough to make fingerprinting less effective. At least it would slow down the development of individual fingerprinting, which I feel sure is the target of data miners everywhere. This addition of headers is only first baby steps in a pressure movement to cap behavioural tracking before it takes off.

Addressing your second point, *Michael*, there are those in the Mozilla security group who disagree with you, and say that advertisers don’t anticipate more than about 7 percent of the online advertising market will be this specific third-party behavioural kind (among the many other kinds already very much in use) by 2014. So that at the most, the use of this header will cap, not kill the development. Advertisers will move around obstacles, not lose money. That’s how they operate.
As much as we NoScript users fondly imagine ourselves to be the vanguard of careful Fx users, it won’t even make much difference to that 7percent development whether there even exists a do not track header in an add-on because according to AMO’s figures for 2009 (I haven’t seen their 2010 report yet) there are around half a billion (500 million) Fx daily users, and to be kindest to the very popular ABP, at most around 15 million daily users of ABP. There even fewer of us fabulous NS visionaries :-)
About 3 percent at most combined of all Fx users. So what’s 3 percent of 7 percent going to do to dissuade advertisers from keeping on exploring the possibilities of third-party behaviourals? It’s no hole in their revenue to continue exploring its potential if only a smear of users signal they don’t want it.

Your third point is only of value for fingerprinting if tracking by default becomes a web standard. What I trust is already happening is that browser development is already moving strongly against it and that all browsers will have default no-track. Giorgio and Wladimir’s initial concept shows the wider web community what should be the standard if blanket tracking is to be deprecated by the whole community.

And any web site that has conditional access? NoScript users aren’t passive. If they know what a server blocks, and still want to use a site, they know what to toggle, surely. And the experience of ABP users with sites that started out conditionally blocking ABP users was that overwhelmingly the sites backed down at protest. Very few sites run this kind of conditional access these days. Why should it be different in the future?

For those who would like a little more insight into tracking than our small NS perspective, Arvind Narayanan has a good overview in his blog
http://33bits.org/2010/09/20/do-not-track-explained/

And actually, even for those who do not want to be tracked, this "feature" does the opposite:
1. No website site supports this, so users are still tracked. There is _no_ gain at all.
2. The more users are sending this, the less likely it will ever be implemented on server side. Advertisers want to make revenue. Would Google honour robots.txt if Apache and IIS installed it by default, denying everything? So better only activate for those who really care for not being tracked (as soon as someone implements it server-side).
3. As said before, it adds to the fingerprint of every NoScript user, making it _easier_ to track them.
4. It identifies me as a NoScript (or ABP) user. Websites can choose not to send any content to me. Instead, they can show a message telling me that I must uninstall NoScript/ABP to visit the site. This happened to me a few years ago using WebWasher, one of the first ad filters. It added its name to the UserAgent.
Testing for JavaScript execution is much more difficult. Especially because I can block the ad server and allow the content server. Since search bots also do not execute JavaScript(*), this is not an option for most websites anyway.

(*)Prefbar allows you to change the UserAgent

A few strong arguments to disable the "feature" by default.

Even more interesting, in a train-wreck, bloody-heads-next-to-a-freeway-accident way, is the bizarre projections of political motivation people in the comments project on others with different preferences than themselves ("script disabled = paranoid, ‘hippys’ want to be tracked, etc.). They make for interesting sociology papers.

If NoScript was mainly trying to be a security blanket for people who cannot understand what it does, things might be different… but it’s not.

I think that both the tracker-cookie approach and the header approach are needed, since many tracker methods do not rely on cookies.

Another advantage of the header (which affects locations like the university where I work) is that it enables optionally-anonymizing proxies to recognize when the client browser needs to actually allow tracking. There are environments where we are required to anonymize by default, but this breaks certain websites. Previously, any solution required teaching the users how to switch between two different proxies. We haven’t yet begun using the header for this, but it looks promising.