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)
Thunderbird
Security
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.
| Assignee | ||
Comment 1•4 years ago
|
||
| Assignee | ||
Comment 2•4 years ago
|
||
Sorry, other changes slipped in.
Attachment #8914132 -
Attachment is obsolete: true
Attachment #8914132 -
Flags: review?(mconley)
Attachment #8914133 -
Flags: review?(mconley)
| Assignee | ||
Comment 3•4 years ago
|
||
Do you think that blog fetches can live without cookies? If not, the patch gets a lot more complex.
| Assignee | ||
Comment 4•4 years ago
|
||
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.
Comment 5•4 years ago
|
||
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-
| Assignee | ||
Comment 7•4 years ago
|
||
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).
| Assignee | ||
Comment 9•4 years ago
|
||
> [implement as] content policy (where remote content blocking is already handled)
That's another good option, yes.| Assignee | ||
Updated•4 years ago
|
Attachment #8914133 -
Attachment is obsolete: true
| Assignee | ||
Comment 10•4 years ago
|
||
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.
Comment 11•4 years ago
|
||
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.
Description
•