Closed Bug 1370217 Opened 3 years ago Closed 7 months ago
Option to override/turn off Content-Language header
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. https://tools.ietf.org/html/rfc3282 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 [184.108.40.206]) by mt03.unseen.is (Postfix) with ESMTPSA id 78725542DC1 for <email@example.com>; Tue, 6 Jun 2017 03:08:09 +0000 (GMT) From: firstname.lastname@example.org To: email@example.com Subject: Test Message-Id: <firstname.lastname@example.org> 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". Why? 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: https://dxr.mozilla.org/comm-central/rev/cad53f061da634a16ea75887558301b77f65745d/mozilla/dom/base/Navigator.cpp#1881 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.
Status: UNCONFIRMED → NEW
Component: General → Message Compose Window
Ever confirmed: true
Comment on attachment 9115194 [details] [diff] [review] Avoid-spellchecking-language-disclosure-in-Content-Language-header.patch Coming to think of this, the approach isn't right. We store the language in the message so when you save a draft (or template?) and later edit it again, you get the spellcheck language restored. Just storing en-US all the time will destroy that function. You should check bug 1169184 where this feature was added and then make sure the language is not sent out if your preference is set, maybe around here: https://hg.mozilla.org/comm-central/rev/5855f51dead5#l6.12 Saving a draft also goes via the send pipeline, so you need to be careful.
Attachment #9115194 - Flags: review-
Comment on attachment 9115194 [details] [diff] [review] Avoid-spellchecking-language-disclosure-in-Content-Language-header.patch Review of attachment 9115194 [details] [diff] [review]: ----------------------------------------------------------------- Agreed it would be better to just avoid setting the header if a pref is set. For the patch, please make the summary start with "Bug 1370217 -" and also add the name of the pref you add to the message
Comment on attachment 9116025 [details] [diff] [review] Bug-1370217-Add-pref-mail.suppress_content_language.patch Review of attachment 9116025 [details] [diff] [review]: ----------------------------------------------------------------- Looks good. r=mkmelin I'll add a test for this as well Sent to try now: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=c52c8c09b81cde41fce4a5e9dfeb8d92ae356077
Attachment #9116025 - Flags: review?(mkmelin+mozilla) → review+
Status: ASSIGNED → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.