Closed Bug 902573 Opened 6 years ago Closed 4 years ago

Privacy enhancement: Create option for local time disclosure via RFC allowed MUA Date header

Categories

(Thunderbird :: Preferences, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: jacob, Assigned: jacob)

References

Details

Attachments

(1 file, 3 obsolete files)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36

Steps to reproduce:

Please see #776397 for details on previous work on this topic. We wanted to break the older bug into two different bugs - this should help with some confusion and to ensure that the discussion stays focused.

For this bug, we wish to add an option that allows a user to change the Date header in outgoing email. This header discloses the local clock/timing information and when Thunderbird is composed with The Tor Network ala TorBirdy, we find that this is one of two major issues leaking information about a user's computer.

We think that it is reasonable to offer three possible states - there may be other states:

  Keep the Date header as it is now (eg: leak timing information including time zone to network)
  Keep the Date header and ensure it is in UTC (eg: allow some clock disclosure but not time zone to network)
  Remove the Date header entirely (eg: let the first upstream MTA sort it out)

Keeping the Date header would be the default state. It requires little discussion, we think.

Changing the default time zone to be UTC would prevent disclosure of the user's time zone, thus preserving the geographic anonymity of the user. This would also allow the user to see mail in their local time zone, which is currently not possible when using TorBirdy as we're all UTC, all the time. We might also want a corresponding option to shave the clock or to randomize it - this is currently out of scope.

Removing the Date header is allowed by the relevant RFCs. The MUA is not required to disclose the local date or time information. The first MTA will add a date header.

This is outlined here:

  http://tools.ietf.org/html/rfc6409#page-4

   For example, the message may lack a proper 'Date'
     header field, and domains might not be fully qualified.  In some
     cases, the MUA may be unable to generate finished messages (e.g., it
     might not know its time zone).

It is also clear that whatever time is included in the message is SHOULD rather than MUST according to RFC5322 ( https://tools.ietf.org/html/rfc5322#section-3.3
 ): 

   The date and time-of-day SHOULD express local time.

We are allowed by relevant RFCs to compose and send messages in any of the above mentioned states.

We'll attach a patch that allows for such a Date header state shortly.
(please prefix bug numbers with "bug" to get them autolinked - like bug 776397)

You should get the patch reviewed.
https://developer.mozilla.org/en-US/docs/Developer_Guide/How_to_Submit_a_Patch#Getting_the_patch_reviewed
Assignee: nobody → jacob
Blocks: 776397
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86_64 → All
Comment on attachment 787177 [details] [diff] [review]
Patch for preventing local timestamp disclosure via Date header

Just to re-summarise my comments on the other bug for easy reference here:

- The patch here is assuming that MTAs will always insert the date when sending a message. I've seen at least one case where this doesn't happen.

- Thunderbird doesn't handle the no-date case nicely.

- There's been no assessment of other Mail clients handling an incoming email with no date.

If this was turned into extension hooks, I think I'd be less likely to block, but having a preference (even a hidden one) where a user can shoot themselves in the foot, isn't useful to anyone.
Attachment #787177 - Flags: feedback-
How would you like this patch to be designed? The reason I ask is so that we can work on it accordingly, based on what you think is an acceptable change to the Date header.
As already stated, the blockers for me are the fact that Thunderbird isn't able to handle the no-date case, and there has been no apparent assessment of how other clients handle a no-date message.

A patch which made TB handle the no-date case nicely, along with an assessment of other mail (and webmail clients) would be a good first step.
Could then this be split into two patches: one which leaves it as it is or sets it to UTC. And another which removes it altogether? I think that there is no reason why not to include the first one. And then the second one can get a longer treatment.
(In reply to Mitar from comment #6)
> Could then this be split into two patches: one which leaves it as it is or
> sets it to UTC. And another which removes it altogether? I think that there
> is no reason why not to include the first one. And then the second one can
> get a longer treatment.

Agreed, a pref for using UTC would be a fine (first) step.
I am working on this and will send a patch for the same soon. I have already made changes in jsmime.js and sent a PR to its Git repo(https://github.com/jcranmer/jsmime/pull/2). After that change gets accepted and merged to main TB source, we can then apply the TB patch that I will send in sometime.
In this patch, I am setting the options of useOnlyUTC before all methods of jsmime are called which can create HeaderEmitter object in them. I am not sure if this is the best approach for the same. Please do let me know if I can improve it any better way.
Attached patch bug902573.diff (obsolete) — Splinter Review
This patch checks if the "privacy.resistFingerprinting" boolean pref is true. If so, it rounds the Date down to the nearest minute (to prevent fingerprinting of small offsets) and formats the Date header with a GMT timezone.

This patch requires the patch at bug 902580, comment 7 be applied first.
Attachment #787177 - Attachment is obsolete: true
Attachment #8572743 - Attachment is obsolete: true
Attachment #8671094 - Flags: review?(Pidgeot18)
Depends on: 902580
Attachment #8671094 - Flags: review?(mkmelin+mozilla)
Comment on attachment 8671094 [details] [diff] [review]
bug902573.diff

Review of attachment 8671094 [details] [diff] [review]:
-----------------------------------------------------------------

Hi, thanks for the patch.

Can you please add a test for this? I'm currently rewriting this code in JS, and I can't guarantee that this won't be regressed without a test.

<https://dxr.mozilla.org/comm-central/source/mailnews/compose/test/unit/test_messageHeaders.js#198> should be an easily cargo-cultable test function for checking the values of particular headers. Just copy that function into a new function, set a preference in that function (see the testContentHeaders function later in the file for how to do that), and add the new function to the end of the test array at the end of the file. Ideally, the test you add should ensure that the seconds field is set to 0 and that the GMT timezone is used, if that is the intentions I think you mean from this bug.

::: mailnews/compose/src/nsMsgCompUtils.cpp
@@ +246,5 @@
> +{
> +  bool resistFingerprinting = false;
> +  nsCOMPtr<nsIPrefBranch> prefs(do_GetService(NS_PREFSERVICE_CONTRACTID));
> +  if (prefs) {
> +    prefs->GetBoolPref("privacy.resistFingerprinting", &resistFingerprinting);

Please change the pref name to mail.mime.avoid_fingerprinting, and also add it to mailnews/mailnews.js with a comment explaining what it does.

@@ +307,5 @@
>          finalHeaders->SetAddressingHeader("Return-Receipt-To", from);
>      }
>    }
>  
> +  PRInt64 nowMicroseconds = PR_Now();

This should be PRTime.

@@ +312,5 @@
> +  bool resistFingerprinting = ResistFingerprinting();
> +  // To reduce the chance of fingerprinting the clock offset,
> +  // round the time down to the nearest minute.
> +  if (resistFingerprinting) {
> +    nowMicroseconds = ((PRInt64) (nowMicroseconds / 60000000l)) * 60000000l;

Add in a const PRTime minute = 60 * 1000 * 1000; (or minuteInMicroseconds) and change this line to:
nowMicroseconds = (nowMicroseconds / minute) * minute;
Attachment #8671094 - Flags: review?(mkmelin+mozilla)
Attachment #8671094 - Flags: review?(Pidgeot18)
Attachment #8671094 - Flags: feedback+
Attached patch bug902573.diffSplinter Review
Thanks for the review. Here's a new version of the patch with the unit tests and changes as requested.
Attachment #8671094 - Attachment is obsolete: true
Attachment #8684089 - Flags: review?(Pidgeot18)
No longer depends on: 902580
Comment on attachment 8684089 [details] [diff] [review]
bug902573.diff

Review of attachment 8684089 [details] [diff] [review]:
-----------------------------------------------------------------

As I rather suspected, the test you added doesn't pass:
 0:17.97 TEST_STATUS: Thread-71 testFingerprintingAvoidance FAIL [testFingerprintingAvoidance : 282] Date header should have GMT timezone. - 360 == 0
    /src/build/trunk/mail/_tests/xpcshell/mailnews/compose/test/unit/test_messageHeaders.js:testFingerprintingAvoidance:282
    _run_next_test@/src/trunk/comm-central/mozilla/testing/xpcshell/head.js:1467:9
    do_execute_soon/<.run@/src/trunk/comm-central/mozilla/testing/xpcshell/head.js:659:9
    _do_main@/src/trunk/comm-central/mozilla/testing/xpcshell/head.js:208:5
    _execute_test@/src/trunk/comm-central/mozilla/testing/xpcshell/head.js:519:5
    @-e:1:1

This is because despite the work that goes into constructing the date/time string in nsMsgCompUtils.cpp, the actual date/time string is constructed via code in jsmime.js, so you're not actually hiding the timezone parameter.
Attachment #8684089 - Flags: review?(Pidgeot18) → review-
The patch in this bug does not have any string changes, so could land post string freeze, so please keep working the issues so that we can get it into TB45. We can land in aurora(TB45)  when ready.
As it turns out that the Date header is actually constructed in jsmime.js(In reply to Joshua Cranmer [:jcranmer] from comment #13)
> Comment on attachment 8684089 [details] [diff] [review]
> bug902573.diff
> 
> Review of attachment 8684089 [details] [diff] [review]:
> [snip]
> This is because despite the work that goes into constructing the date/time
> string in nsMsgCompUtils.cpp, the actual date/time string is constructed via
> code in jsmime.js, so you're not actually hiding the timezone parameter.

It turns out that jsmime.js allows a browser extension to provide an alternate generator (aka "emitter") for any header. So I wrote a patch for torbirdy, that rounds the Date down to the nearest minute. See https://trac.torproject.org/projects/tor/ticket/6314#comment:17. Thus we don't need an additional patch in Thunderbird. Resolving this ticket as WORKSFORME.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
What about the timezone?
(In reply to Magnus Melin from comment #16)
> What about the timezone?

Currently, torbirdy is setting the timezone to UTC using 
  env.set('TZ', 'UTC');

Alternatively, we could provide a modified Date/header generator from torbirdy JS code to provide a UTC-formatted date.
What about us who do not use torbirdy, but still want privacy on our sent e-mails? Why is this closed?
(In reply to Mitar from comment #18)
> What about us who do not use torbirdy, but still want privacy on our sent
> e-mails? Why is this closed?

This ticket was originally opened to add a pref primarily for torbirdy's use, but in the process we learned more and found another approach. But you are welcome to re-open the ticket and continue working on it. That said, if you are concerned about your privacy while using Thunderbird, I recommend using torbirdy.
There are different threat models here. I am satisfied with having my own mail server which then sends stuff further, but I do not want that each e-mail by itself store and transmit information about my location which could then be mined later on.

I do think this should be something available in core Thunderbird. Not that people have to install extensions to gain additional (and easy to add) privacy. It is like do-not-track for e-mails. It should be core.
From comment 0, the relevant RFC says "The date and time-of-day SHOULD express local time." I have not tried to understand all of the issues here, but it seems to me that the default state of Thunderbird should be to follow the "SHOULD" state whenever reasonably possible, yet leave open the option of additional privacy through an addon if appropriate. So for users who believe "I do not want that each e-mail by itself store and transmit information about my location" they have a choice, but the default follows the RFC SHOULD. That is not an absolute rule, but I would need a but of persuasion to support a change here.
I understand and respect the concerns of those who want to randomize the Message-ID, but I don't like the apparent fact that this is being forced on everyone whether they like it or not.  There ought to be a way to turn this randomization on or off; this was suggested earlier via a "privacy.resistFingerprinting" option flag, but this idea was apparently dropped.
That was bug 902580, not this bug. Anyway, message id's are supposed to be unique so of course they need to be random.
Thanks.  I've reposted my comment at bug 902580.

I agree that Message-ID values must be unique, but no, that does not require them to be totally random.
(In reply to Kent James (:rkent) from comment #21)
> From comment 0, the relevant RFC says "The date and time-of-day SHOULD
> express local time."

There is also a clear way to make an exception provided few sentences afterwards:

> Though "-0000" also indicates Universal Time, it is
> used to indicate that the time was generated on a system that may be
> in a local time zone other than Universal Time and therefore
> indicates that the date-time contains no information about the local
> time zone.

Moreover, timestamp is still in local time - tells you the local clock so one can determine if that clock is maybe off - but it does not reveal the timezone.

I think there should be a setting in Thunderbird to allow setting timezone to "-0000".
You need to log in before you can comment on or make changes to this bug.