VOTE: enable Tracking Protection [Edit: and SB]

[Thorin-Oakenpants]

see #102 for the discussion, and make comments there, so its in one place.

This issue is just so I can get a handle on what people want. I will make a decision on when I get some reasonable numbers of votes.

Vote by adding a reaction to this post

Proposal

In this user.js, the master branch, (we will have a lite/relaxed branch in future), to enable TP (tracking protection).

Notes:

• We recommend in numerous places that we expect users to be using uBo, which has advantages (default all windows, more comprehensive options). Despite this, as a FALLBACK for users who do not read (and one of our/my aims is to make this more accessible to everyone) and for those who do not use uBo, we should be RESPONSIBLE and enable TP (we're already responsible eg warnings etc, but we should cover as many case scenarios as possible)
• TP (at defaults) is only used in PB mode, whereas uBo is used by default on all windows. We should really MAKE people use uBo - right? - which we can still do with our warnings etc, but some people never read or are afraid of uBo etc.
• TP uses the same list as uBo a list (note: there are two lists, simple+strict, default is simple and we would leave it at that but include the pref for info/enforcing strict)
  • UPDATE: uBo uses multiple lists in default mode and covers almost everything TP does (and more), but there are some items only TP does (rare). No-one has done a comparison.
• TP (at defaults) and uBo do not clash in any way
• There are no issues over TP re security, privacy, or hourly connections for checks, or downloads - but for uBo users, it's redundant, that's all. [Edit: there are no issues over fingerprinting thru HSTS]
• The make up of what settings we use are irrelevant - this vote is about enabling it (either defaults, or enforcing to normal windows is irrelevant at this stage)
• We could leave this for a lite/relaxed branch, which will happen

That's about it really. Either turn TP on in this branch (which is our default branch), or wait until a lite branch.

Note: this would require approx 4 prefs to be made inactive (and reset in about:config), plus one new pref (inactive), and some changes to the wiki and the user.js's readme, and the 0400 section header description. That's about it.

👍 = don't disable TP (in other words end users are at default, prefs become inactive)
👎 = hell no, leave TP disabled by the user.js

[Atavic]

If enabled, leave it on the relaxed branch only.
Reason: Anti-fingerprinting.

[kaliostro2]

We have uBlock Origin , uMatrix and soon full-fledged containers with "Always open in this conteiner".

[RoxKilly]

@Thorin-Oakenpants I think the issue at hand that needs resolving is bigger than Tracking Protection. The underlying issue you need to decide (or have the community decide if you prefer) is whether you consider uBO is an officially required addition to this user.js (rather than just a "nice to have". If this projects considers uBO a baseline requirement, then there is no need to invest any time putting up safeguard for people who don't have uBO.

The TP decision is just a manifestation of the issue, but there could be others in the future.

[grauenwolfe]

I prefer it all disabled personally. uBlock Origin does a splendid job of handling tracking with on-the-fly control as well. There's too much of a grey area involving the companies and services that are supposed to prevent tracking. While I'm not 100% convinced that they are collecting and selling the very info that they protect us from I am certain I don't 100% trust any of them either.

[Atavic]

uBlock manages more lists that can be optionally activated.
uBlock-LLC/uBlock#1406
pyllyukko/user.js#16

[crssi]

Question.

Since TP is disabled by master switches:
privacy.trackingprotection.enabled
privacy.trackingprotection.pbmode.enabled

Is there really need to clear the following:
browser.safebrowsing.provider.mozilla.gethashURL
browser.safebrowsing.provider.mozilla.updateURL

?

[fmarier]

browser.safebrowsing.provider.mozilla.updateURL

Also used by the flash blocking lists.

browser.safebrowsing.provider.mozilla.gethashURL

Not currently used by anything. Also, if you disable updates via updateURL, you will never get a gethash request.

So even if we were doing gethash calls, you wouldn't see any if the other pref is cleared.

[crssi]

Thank you @fmarier. Is browser.safebrowsing.provider.mozilla.gethashURL deprecated or will be used in the future?

[fmarier]

It will be used in the future if we start serving lists that contain hash prefixes (they end in -shavar) instead of lists of hashes (which end in -digest256).

[crssi]

Just for to be sure.
TP will be PB enabled only, except when manually set the privacy.trackingprotection.enabled = true ?
SB will be non-PB and PB enabled? (don't even know if can be enabled separately, I suppose not)
I don't ask for changes, I am just asking for my personal setting: is there any real reason for PB surfing and not to enable TP on non-PB browsing?

Otherwise, bravo, you are my Queen and long live the Queen. :)
Cheers

[crssi]

OK. What in short is your opinion (not related to user.js): to enable TP also in non-PB or not?
I am asking because I don't use PB. It has too many cons for me. ;)
Thanky you

[earthlng]

I have weighed that up against the expertise of the voters

no need to insult us, thx

@fmarier what stops the big G from creating something like a rainbow table with SB hashes for every site they crawl and use it to easily know exactly which site someone visited when they send the hash to google for SB lookup?

[earthlng]

https://developers.google.com/safe-browsing/v4/lists

When using the Lookup API to check URLs, the client sends the actual URL in the request and Safe Browsing server converts the URL to a hash before performing the check

[fmarier]

And btw the URL also seems to be incorrect because @fmarier explicitly told us that this pref is not used.

You're right, the pref name was wrong in my blog post. I've updated it. Thanks!

What it really seems to do is send the full url together with some "noise" urls. And you think G won't know which of those urls even match the hash and which ones are "noise"?

The input to the API for getting the full hashes is a list of prefixes. We never send the full hash. Also, the noise entries are real prefixes that are part of the list.

When using the Lookup API to check URLs, the client sends the actual URL in the request and Safe Browsing server converts the URL to a hash before performing the check

We're not using the Lookup API, we're using the Update API. Also, we're not yet using version 4 of the API, we're still on version 2.2 until Firefox 57 or 58.

[Atavic]

@Thorin-Oakenpants

Google doesn't have a clue what got blocked in your browser from these lists.

But here it says that

In addition, a very condensed version of the page's content may be sent to compare similarities between authentic and forged pages.

[fmarier]

But here it says that

In addition, a very condensed version of the page's content may be sent to compare similarities between authentic and forged pages.

That's an ancient page talking about a long-gone version of Safe Browsing, back when it was a Firefox extension, not built into the browser.

[crssi]

@earthlng, I never hide that I am for enabling TP and SB (without G of course) and I waited a long time before voting against TP for one simple reason, this was about hardened version and relaxing setting would fit into light version.
Since I am very sure that @Thorin-Oakenpants invested a lot of time into investigating and thinking, and I do not question about his/hers expertise (I also do not question in yours and I really greatly admire you both and also others here), I changed the vote after @Thorin-Oakenpants decides to enable TP and SB (without G).
Anyway, whatever decision at the end I will take it gratefully with open hands, but will still have enabled TP and SB (without G) in my version of user.js.
But, please, do not fight too much (a little is always good), since you two are really a perfect team and you do complement each other perfectly.
Damn, expressing my self is hard and I hope you understood my answer in a good way, since it meant to be in a good way.

Love you all, cheers

[RoxKilly]

@Thorin-Oakenpants thanks for taking the time to explain your decision so thoroughly. I don't think you need to be defensive about it though.

---

@crssi wrote:

OK. What in short is your opinion (not related to user.js): to enable TP also in non-PB or not?

I have Tracking Protection ON for all browsing modes (easy list) because I just don't see any downside to using it. It is only triggered if uBlock Origin fails to catch a tracker so it doesn't replace uBO in any way, and it has yet to break a site in a way I've noticed.

[grauenwolfe]

What exact entry do I need to reset to get these back? Been vacant for a very long time.

[fmarier]

What exact entry do I need to reset to get these back? Been vacant for a very long time.

Probably these:

• urlclassifier.trackingTable
• urlclassifier.trackingWhitelistTable
• browser.safebrowsing.provider.mozilla.lists.*

[grauenwolfe]

Thank you. All of my "browser.safebrowsing.provider.mozilla.lists.*" entries were still set to blank values, resetting them did repopulate the Block Lists. Again, thanks very much.

[crssi]

@RoxKilly

It is only triggered if uBlock Origin fails to catch a tracker so it doesn't replace uBO in any way, and it has yet to break a site in a way I've noticed

Isn't it oposite, the TP within FF acts first and then uBO?

[crssi]

@Thorin-Oakenpants - I am aware of that, but what when it exists in both?

[RoxKilly]

@crssi wrote:

Isn't it oposite, the TP within FF acts first and then uBO?

TP is definitely last in line. It's easy to check though.

1. Start a Private Browsing session
2. Disable uBO
3. Go to nytimes.com and you will see a Tracking Protection alert.
4. Exit browser and start a regular session with uBO enabled
5. Go back to nytimes.com and you will not see a Tracking Protection alert b/c uBO caught the trackers first.

Alternatively, you could look at this comment from one of the original authors of TP:

[AdBlock Plus] and similar generally use nsIContentPolicy.shouldLoad to stop resources from loading. These content policy checks happen before the network channel is created, and before tracking protection checks. If you run ABP and tracking protection, it just means that ABP will most likely prevent many resources from loading before tracking protection sees them

[crssi]

Thank you @RoxKilly

[fmarier]

I notice I have these 15 persistent (they do not vanish on close) "cache" entries which the nilla FF never produces.

The only leftover files are the test-forbid-simple.* ones. That's an old test list that's been removed from Firefox. If you delete it, it shouldn't come back. The reason for the old timestamps is that some of these lists change very infrequently (especially the test lists).

If you want to clean up old files, you can also just delete that Safe Browsing cache directory and restart your browser. The lists that are needed will be re-downloaded within 5 minutes of startup if they're not available on disk.

[fmarier]

You're right, the pref name was wrong in my blog post. I've updated it. Thanks!
I'm lost. Can you please tell me WHAT pref you are talking about. And do I now have incorrect info in the user.js - because the whole 0400 section was initially based on your blog post.

My blog post was incorrectly referred to browser.safebrowsing.provider.mozilla.gethashurl instead of browser.safebrowsing.provider.google.gethashurl when talking about Safe Browsing lists (from Google).

Does killing the google URLs negate the effectiveness of the mozilla URLs (since they can no longer be updated via google's master list?)
What is the diff in usage between mozilla URLs and google URLs as per code below?

The browser.safebrowsing.provider.mozilla.* prefs are only for the Mozilla lists (TP and flash blocking). The browser.safebrowsing.provider.google.* and browser.safebrowsing.provider.google4.* prefs are only for the Google Safe Browsing lists.

So if someone wants to disable Safe Browsing only, they shouldn't touch the mozilla prefs. Similarly, if someone only wants to disable TP, they shouldn't touch the google prefs.

browser.safebrowsing.provider.google4.gethashURL (FF53) defaults to a blank string but browser.safebrowsing.provider.google4.updateURL does not. Is this the v4 Update API you're
talking about? Both prefs were introduced in FF50.

Yes, we've never used the Lookup API and never will. That's true both on v2.2 and v4.

Will the google.* be eventually replaced by the google4.* ?

Yes, we're aiming to move from google (version 2.2 of the Safe Browsing API) to google4 (version 4 of the API) in the 57/58 timeframe. The details are on https://wiki.mozilla.org/Security/Safe_Browsing/V4_Implementation.

// user_pref("browser.safebrowsing.malware.enabled", false);
// user_pref("browser.safebrowsing.phishing.enabled", false); // (FF50+)

Both these prefs must be true for the single checkbox in Options>Security to be ticked. Why are there two prefs for a single option?

The two prefs control two different things (malware v. phishing). We have the ability to control both independently but we don't think it's worth the space in the UI, so we leave it in about:config for our power users.

[crssi]

@fmarier - are there any plans for SB to migrate from G to shavar Mozilla?

[crssi]

@Thorin-Oakenpants - just thinking out loud, not demandig or whining:
Some are really unhappy for the latest changes.
What about to split now into "lite" version and leave this one still "hard"?
It will please all audience and push-up morale.
It doesn't matter for me, since I am just fine to do some diffs for myself and I am not selfish.
The version I am using I do consider "light" and there are only about 20 changes to yours.

Hmmm... this might be for a new topic?

Love you all

[fmarier]

are there any plans for SB to migrate from G to shavar Mozilla?

No plans. It's an incredibly expensive service to run, both from a network traffic point and list curation point of view. Given that the service is quite good, there are better uses of our money and engineers (e.g. working with Tor) IMHO.

[Atavic]

FYI: pyllyukko's gone relaxed-branch.

[crssi]

^^ hmm: this one bothers me:

IndexedDB could be used for tracking purposes, but is required for some add-ons to work (notably uBlock), so is left enabled

Comment: I have IndexedDB enabled on the contrary to ghacks, since it breaks a few pages that I really need. But wasn't aware that affects uBO too?

[Atavic]

It has been resolved.
pyllyukko/user.js#263