662151 - "tell web sites I do not want to be tracked" makes it impossible to log into my DSL-Routers admin area.

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect)

Description

[u130342]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0

Switching on "tell web sites I do not want to be tracked"  makes it impossible to log into my DSL-Routers admin area. It makes a POST request to the router. 

Seems others have the same problem http://support.mozilla.com/de/questions/817384.

FF5 beta/ current

Reproducible: Always


Actual Results:  
The router responds with incorrect login data.

Expected Results:  
A successful login.

The only difference I can see in the sent headers ist the "DNT: 1" line in the header. Not sure whether this is supposed to be a bug in FF. But there some countermeasures than FF could implement to avoid this problem:
1. Suppress DNT in POST requests (I think almost any tracking happens in GET requests)
2. Refine setting "tell web sites I do not want to be tracked" to allow exceptions (like cookies)
3. Suppress DNT in local subnets

Comment 1

[Justin Dolske [:Dolske]]

Sounds like a router bug to me. Indeed, the only thing "tell web sites I do not want to be tracked" does is enable sending the "DNT: 1" header.

What brand router do you have, and what firmware version?

Comment 2

[u130342]

It's a Vodafone DSL-EasyBox 803 A, Firmware Version:30.05.207. 
There's no newer firmware available.

Comment 3

[Jo Hermans]

Can you confirm that the problem disappears when you disable "tell web sites I do not want to be tracked"

Comment 4

[u130342]

(In reply to comment #3)
> Can you confirm that the problem disappears when you disable "tell web sites
> I do not want to be tracked"

yes, that's correct.

Same happens in FF4 if I enable/disable the option (just checked that).

Comment 5

[Jason Duell]

Not sure what to do here.  My first thought is to wait and see a bit how many routers are this uptight about passing arbitrary headers through on POSTs.

I assume the issue here is that the CGI script on the router (or whatever) is very jittery about seeing unknown headers (as opposed to the router barfing on sending POSTs with DNT:1 in general, which would be much worse).

Of the solutions mentioned in comment 0, I think providing a "Do not send DNT to these addresses" makes the most sense.  Though #3 (don't use for private subnets) might work--I'm trying to think of any cases where we'd want DNT for private addresses, but can't think of anything off the top of my head.

Comment 6

[Josh Matthews [:jdm]]

(In reply to comment #5)
Though #3 (don't use for
> private subnets) might work--I'm trying to think of any cases where we'd
> want DNT for private addresses, but can't think of anything off the top of
> my head.

What about testing some in-development work locally to ensure that DNT is being respected?

Comment 7

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to comment #5)
> Of the solutions mentioned in comment 0, I think providing a "Do not send
> DNT to these addresses" makes the most sense.  Though #3 (don't use for
> private subnets) might work--I'm trying to think of any cases where we'd
> want DNT for private addresses, but can't think of anything off the top of
> my head.

The DNT header is important for private networks too. Think Starbucks, hotels, airports, etc., especially with captive portals.

Let's find out what is exactly causing the problem. If it is the "DNT" header specifically, or any non-standard header. Harald, do you know how to replay the post with the "DNT: 1" header field replaced with something else like "X-DNT: 1" or "ABC: abc"? If so, please try it out and report the result. Otherwise, I can either help you out and/or we (MoCo) can just buy one of these routers to test with.

Comment 8

[Jo Hermans]

(In reply to comment #7)
> The DNT header is important for private networks too. Think Starbucks,
> hotels, airports, etc., especially with captive portals.

There are also ISP's that give their customers such an RFC1918 address. Connectivity to the outside world would then be provided by a (mandatory) proxy-server.

Comment 9

[Jo Hermans]

(In reply to comment #2)
> It's a Vodafone DSL-EasyBox 803 A, Firmware Version:30.05.207. 
> There's no newer firmware available.

From what I can see, it's made by Astoria Networks, but I don't know how easy it is to find one of these (they seem to be custom made for Vodaphone Germany). They have an office in San Jose, maybe they can help ?

Comment 10

[u130342]

I've tested some values with modify headers..

DNT: 1
DNT: a
X-DNT: 1
X-Do-Not-Track: 1

all cause the problem, 
BUT 

DNT: yes
DNT: 1.
DNT: aa
DNT: 11

These WORK! Seem it's a problem if the value has only one char.

Comment 11

[Mark Nottingham]

Try sending:

DNT:\n   // i.e., no field-value at all
DNT: 1\r\n     // i.e., the full /r/n line sep, not just /n
DNT: 1 \n    // i.e., a space before the \n

What I *suspect* is happening here is that it's chopping off the final two characters, assuming that they're /r/n, and then rejecting an empty header. Both behaviours are wrong, BTW.

Comment 12

[u130342]

(In reply to comment #11)
> Try sending:
> 
> DNT:\n   // i.e., no field-value at all
> DNT: 1\r\n     // i.e., the full /r/n line sep, not just /n
> DNT: 1 \n    // i.e., a space before the \n
> 
> What I *suspect* is happening here is that it's chopping off the final two
> characters, assuming that they're /r/n, and then rejecting an empty header.
> Both behaviours are wrong, BTW.

Hmm, FF sends \r\n so truncating can't be the problem.

With modify headers I was only to able to produce these:
DNT: \r\n -> ok
DNT:  \r\n -> fail

Wasn't able to test DNT: since modify headers deletes it then at all.

Comment 13

[Patrick McManus [:mcmanus]]

given the limited scope of the issue and the apparent broken-ness of the router this would seem to be an evangelism bug imo.

Comment 14

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Harald, thanks for the awesome work.

Could you please include the complete response headers for a GET request to that server?

If including a space before or after the 1 works, it seems reasonable to try implementing that as an ugly workaround, if this device is common.

Comment 17

[JMF]

I have a suggestion:

Besides Firefox, as far as I know this feature is currently implemented in the extensions NoScript and AdBlock Plus.
In Firefox and NoScript it works as an always on/off feature. With ABP it is possible to use filter rules to specify the addresses/domains where it is turned on or off.
I guess ABP sends its own DNT header, according to those rules, allowing DNT to work on a per site basis.

So as long as you turn off DNT in Firefox (and NoScript if you use it), you can use ABP to manage DNT, sending it for most pages, but not for whitelisted router pages.

The only thing that's missing in ABP is management of the property navigator.doNotTrack from bug 629535. Is there any interface that an extension can use to change that value per site? If not, would it be complicated to implement it?

Comment 18

[Sid Stamm [:geekboy or :sstamm]]

JMF: please file a new bug for the feature you're requesting.

Comment 19

[Cédric "chewey" Menge]

I've done a bit of sleuthing about this next door:
https://www.mozdev.org/bugs/show_bug.cgi?id=23845

Abstract: It is indeed as Harald suspected. *All* single character headers cause this.