Option to override/turn off Content-Language header



2 years ago
2 years ago


(Reporter: mozilla, Unassigned)


52 Branch

Firefox Tracking Flags

(Not tracked)


User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:45.9) Gecko/20100101 Goanna/3.2 Firefox/45.9 PaleMoon/27.3.0
Build ID: 20161109284099

Steps to reproduce:

Content-Language is a new header, which is forcibly put into going messages since Thunderbird 52, which contains information about user’s dictionaries, a minor metadata for fingerprinting.

RFC 3282, on which this feature is based, warns about potential privacy breach in “Security considerations” paragraph, nonetheless there is no option to override/turn off Content-Language header.
We could do an option to turn it off.

4. Security Considerations

   The only security issue that has been raised with language tags since
   the publication of RFC 1766, which stated that "Security issues are
   believed to be irrelevant to this memo", is a concern with language
   ranges used in content negotiation - that they may be used to infer
   the nationality of the sender, and thus identify potential targets
   for surveillance.

Personally I don't quite understand the issue. When sending an e-mail, heaps of headers are sent, including your e-mail address and name (usually). Also your mail providers MTA adds more routing headers so you can follow the path of the e-mail. That the e-mail was written using a particular dictionary is not much more identifying than the information already sent.

What am I missing?
Severity: normal → enhancement
Heaps of headers are modified by privacy-aware email providers to reduce metadata leaks.
In the example below you could see IP is cloaked and timestamp changed into UTC+0.

Received: from Unknown (ml01.unseen.is [])
	by mt03.unseen.is (Postfix) with ESMTPSA id 78725542DC1
	for <xxx@xxx.xxx>; Tue,  6 Jun 2017 03:08:09 +0000 (GMT)
From: zzz@unseen.is
To: xxx@xxx.xxx
Subject: Test
Message-Id: <20170606060757.e60f2bf7720f90535b25e3ec@unseen.is>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Date: Tue,  6 Jun 2017 03:08:09 +0000 (GMT)

User is able to specify any name or omit one, same goes for mail agent, but dictionary metadata is out of control.
Some would wonder upon receiving a letter from Iceland, written in English, but with dual Eng-Rus dictionary used.
As I said, we can do an option to turn it off.
Please do, sir.
Perhaps it’s better to let override Content-Language like it's done with general.useragent.override than just turn on/off.

Let’s say a new option is called “general.contentlang.ovverride”, then if it is
- not set (default), then Content-Language is inserted like now,
- set to blank, then Content-Language is not inserted at all,
- set to custom string (e.g. “en-US” regardless dictionary used), then Content-Language is inserted with that custom-string.

What do you think? Any ETA?
I don't think we can distinguish between "not set" and "blank".

ETA would be a few versions down the track, if I did it soon it would go into TB 55 beta due out after next Monday, and then hit TB 52.3 six weeks later, no promises made. This is a small tweak with little risk.
> I don't think we can distinguish between "not set" and "blank".

I’m looking at how general.useragent.override option is implemented:
- default installation has no such string in about:config,
- user is able to create one blank (then header is not inserted at all) or filled with whatever he likes.
You mean "space", right? If you've done the research already, kindly paste the line number here, so far I can only see:

I'd have to go looking for the space processing.
Any updates on this?
Not really. We're and open source contributor driven project, so a patch is welcome. That would be about a three line change:

1) Define the new preference in mailnews.js
2) Retrieve it and act on it when the header is written out. I'd have to look where that goes.
   Like many times, the research here will take longer than the implementation.
You need to log in before you can comment on or make changes to this bug.