Open Bug 1404748 Opened 4 years ago Updated 4 years ago

Privacy: Disable referers and cookies in HTTP requests from emails

Categories

(Thunderbird :: Security, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: BenB, Assigned: BenB)

Details

Attachments

(2 obsolete files)

https://freedom-to-tinker.com/2017/09/28/i-never-signed-up-for-this-privacy-implications-of-email-tracking/
https://senglehardt.com/papers/pets18_email_tracking.pdf Section 6.2

The study shows that we store cookies for HTTP requests. Indeed, Thunderbird default pref network.cookie.cookieBehavior is set to 0 = Allow all cookies. We should change this to 2 = Don't store/send cookies.

The study say that we do not send referers. This may be because we don't allow mailbox:/imap: URLs are referers, which is surely reasonable. However, the default pref network.http.sendRefererHeader is set to 2 = Allow referers. We should change this to 0 = Don't send referers, to make it more bulletproof.

Positive effects:
Less possibilities to track email reads/opens by spammers. (Mostly important when the user allows remote images.)

Adverse effects:
I don't expect negative effects on email reading. Remote image viewing is already disabled by default, for the same reason of tracking protection. I don't think 

Given that this is a global pref, it would affect the RSS reader as well.
I know that almost all websites work without referers, because that's my default setting for all web browsing since many years, and I have very few problems.
I would hope that most blogs work without cookies, but I have not tested that.
Attached patch Suggested fix, v1 (obsolete) — Splinter Review
Assignee: nobody → ben.bucksch
Status: NEW → ASSIGNED
Attachment #8914132 - Flags: review?(mconley)
Attached patch Suugested fix, v2 (obsolete) — Splinter Review
Sorry, other changes slipped in.
Attachment #8914132 - Attachment is obsolete: true
Attachment #8914132 - Flags: review?(mconley)
Attachment #8914133 - Flags: review?(mconley)
Do you think that blog fetches can live without cookies?
If not, the patch gets a lot more complex.
Also, do people make comments on blog posts within Thunderbird, using TB as a browser? If so, these are likely to break with this change here.
Like Matt wrote on maildev, you need cookies for OAuth2 authentication.
Comment on attachment 8914133 [details] [diff] [review]
Suugested fix, v2

I don't think I'm the right person to review this these days (mkmelin is probably the better choice) - and, as I understand it, cookies are still required for some Thunderbird features (like oAuth), so this sounds like too general a fix.
Attachment #8914133 - Flags: review?(mconley) → review-
Yes, agreed.
How about this:
We disable cookies, and then whitelist google OAUTH domains.
Also, when the user adds a RSS feed with full browser view, we add that blog's domain to the whitelist.
The study actually demonstrates nothing about Tb storing a cookie for an email image/link click. Do you have a testcase that proves this?  Meaning stores a local cookie for a message retrieved via imap/pop3. Yes, there is a gecko pref that defaults to 0.

A whitelist for oauth/feeds is a nonstarter imo. This sort of thing, if it's demonstrably necessary, properly belongs in content policy (where remote content blocking is already handled).
> [implement as] content policy (where remote content blocking is already handled)

That's another good option, yes.
Attachment #8914133 - Attachment is obsolete: true
The idea here is to disable cookies for everything where they are not known to be needed.

Is there any objection to disabling referers? I know that almost all websites work without referers, because that's my default setting for all web browsing since many years, and I have very few problems.
But we're not usually sending Referer, right?

For whatever browsing or web application use there is in-product, not sending it could break applications. I recall reading a paper that basically concluded web application authors can rely on Referer being there for https traffic at least. And there are good reasons to check it...
You need to log in before you can comment on or make changes to this bug.