Possibly redundant blanked out URLs and zeroed out capacities

[ghost]

Hello!

Some prefs are in two parts: the first disables the tech, and the second blanks the then no longer used URL or zeroes out the capacity limit.
This seems redundant and I believe I remember you started clearing those out.
Preferences 0503, 0505 and 1003 are three examples I came up with, but I can search for more if you want me to.

/* 0503: disable Normandy/Shield [FF60+]
 * Shield is an telemetry system (including Heartbeat) that can also push and test "recipes"
 * [1] https://wiki.mozilla.org/Firefox/Shield
 * [2] https://github.com/mozilla/normandy ***/
user_pref("app.normandy.enabled", false);
user_pref("app.normandy.api_url", "");

/* 0505: disable System Add-on updates ***/
user_pref("extensions.systemAddon.update.enabled", false); // [FF62+]
user_pref("extensions.systemAddon.update.url", ""); // [FF44+]

/* 1003: disable memory cache
 * [NOTE] Not recommended due to performance issues ***/
   // user_pref("browser.cache.memory.enable", false);
   // user_pref("browser.cache.memory.capacity", 0); // [HIDDEN PREF]

Please correct me if I'm wrong, I'm simply looking to help keep the user.js as tidy as possible. :)
As Pants would say: Class, discuss!

[ghost]

P.S.: I would gladly make the PR for this issue, should you give your approval! :)

[Thorin-Oakenpants]

I can search for more if you want me to

By all means, let's have a look at them. Always a good idea to revise content

... seems redundant and I believe I remember you started clearing those out

Redundancy vs defense in depth. I'm not sure what I have removed in the past, but each one was (99% sure) done on it's own merits. If you're referring to the snappening I did several months ago, that was a different reason, albeit the same goal: less clutter, less items to flip: and yes, a metric shit ton of (Safe Browsing, Reporting) URLs were cleaned out, but so were the other master prefs: so not the same.

---

Just making a point here that removing a secondary pref doesn't make the user.js any less work: i.e it still contains the itemized number with content

Looking at the above:

• 0503 in depth against normandy is never a bad thing considering how often it gets changes
• 0505 at the time, it was unclear how this was going to work, and it is even broken in some configs, and there were/are plans to change it - hence the defense in depth.
• 1003 not sure why capacity is there: I've never tested this, as I'm fine with memory cache

[bitpixl]

1003 not sure why capacity is there: I've never tested this, as I'm fine with memory cache

This can be used to stop etag fingerprinting. To prevent etag fingerprinting this way you have to disable disk and memory caching.

I'm using this method as I've found no negative impact on my browsing performance (I never have alot of tabs open, maybe that's why) and I don't need an extra addon.

Disable cache at all time
Problem: Caching advantages are discarded
Info: Not only disk-cache, but also memory-cache must be disabled

source: ETag Fingerprinting

(this source is linked by @claustromaniac on his ETag Stoppa firefox addon page)

[Thorin-Oakenpants]

This can be used to stop etag fingerprinting

Yes. Disabling both disk and memory cache. The point is that the other pref already disables memory cache (or it should, I have not tested) - i.e Aeriem was talking about redundancy

[ghost]

@Thorin-Oakenpants: Thanks for the reply! I understand some of these are needed, that's why I wanted your opinion on the matter first. :)
I'll get started and submit a PR when I'm done, this way we'll review where we can do some cleanup and where in-depth defense is better.
A quick response to your thoughts on 1003: you removed the capacity pref from 1001 (disk cache), saying it was redundant (#732), which is why I thought we should apply the same treatment to 1003. :)

[Thorin-Oakenpants]

I can only find one reference on DXR to browser.cache.memory.capacity (I only searched for memory.capacity: pays to search for shorter strings)

• https://dxr.mozilla.org/mozilla-central/source/netwerk/test/unit/test_bug650995.js - which doesn't really tell me anything exciting

Bug 650995 from FF7 (yup, seven) doesn't really tell me anything either, except that

 // -1 = determine dynamically, 0 = none, n = memory capacity in kilobytes

So the only question that remains, I think, it to test it. How do you test a memory cache? about:cache seems useless, it only tells me that despite using memory cache, and having numerous tabs open and Firefox being open for hours, that I have zero memory cache

memory
  Number of entries: 	0
  Maximum storage size: 	32768 KiB
  Storage in use: 	0 KiB
  Storage disk location: 	none, only stored in memory 

That's a bit useless. What about about:memory? Or maybe I need to turn of etag stoppa. IDK. Why does everything always come down to me testing things? Why doesn't OP provide empirical proof that the pref is redundant? IDK sigh

[ghost]

I'm not sure why you want to test it, Pants. Don't we already know that disabling both disk and memory cache stops etag tracking? Is there something I'm missing?

[Thorin-Oakenpants]

provide empirical proof that the pref is redundant

Testing if the second pref is actually redundant

[Thorin-Oakenpants]

In a new FF70 profile, I disabled disk cache, cleared everything (ctrl-shift-del) for all time, and restarted. Opened network inspector, and loaded a small test page. Then I reloaded the test page (it's a bookmark: no hard-reloading)

On the reload, it reported everything cached (in memory, since disk was empty)

So far so good. Then I cleared everything, changed browser.cache.memory.enable to false and closed and re-opened the browser. Opened the network inspector, loaded the test page, re-loaded the test page.

On the reload, it re-requested the items (because they are no longer in cache)

On a whim I repeated the test with browser.cache.memory.capacity = 0 (i.e .enabled was at default) and this is not a substitute for .enabled AFAICT. That entry is 0 bytes, and refers to the URL of the test page.

Anyway, don't care about the capacity pref on it's own, only if it's redundant. And I'm now 99% sure that it is

[Thorin-Oakenpants]

The question now is, do we remove browser.cache.memory.capacity, or add this extra info line for those who want to limit the capacity rather kill it off

// capacity: -1=determine dynamically (default), 0=none, n=memory capacity in kilobytes

@earthlng Would there be an edge case for limiting capacity (in terms of privacy etc)?

[earthlng]

^^ Nothing that I can think of.

FYI: commit where you added browser.cache.memory.capacity was 7d89436

[Thorin-Oakenpants]

ahh OK .. thats #169 then

[Thorin-Oakenpants]

OK, so I'm thinking this should go. It's not related to tracking, FPing, security, privacy. @earthlng , just thumbs up if you agree, and I'll commit the PR and close this

[earthlng]

The current PR also removes the UITour url pref. Is that the one you want to merge?

IDK if we need to remove the memory.capacity pref because people who want to disable the memory cache may want to make sure that the cache is actually disabled by doubling down in case mozilla ever fucks up the code behind one of these 2 prefs. Similar things have happened in the past and personally I like redundancy to disable the things I absolutely never want, like UITour and other shit like that.

[Thorin-Oakenpants]

Ahh OK, that's right, its got extra shit in it. Nah, I just meant to remove this capacity pref.

UI tour is probably not going to change. It's there so remote code can't hook into it

[Thorin-Oakenpants]

OK, that's cool. I'm happy either way with this one. It's inactive and doesn't add/remove any extra work IMO. I'll add the extra line though.

[Thorin-Oakenpants]

Unlike this user.js, I don't recommend disabling in-memory cache

Huh? This user.js doesn't "recommend" disabling memory cache: It mentions it in the header section comment, but doesn't actually do it: which should imply that users use the other suggested methods, such as TC

edit: should we we-word that section or the note on the pref itself?

[claustromaniac]

To be honest, I had to re-check that section after posting that comment, but yeah the implication that disabling it helps against fingerprinting is still there, and while it can help, it can also hurt.

[claustromaniac]

It reads...

 ETAG [1] and other [2][3] cache tracking/fingerprinting techniques can be averted by
      disabling *BOTH* disk (1001) and memory (1003) cache.

and then below...

/* 1003: disable memory cache
 * [NOTE] Not recommended due to performance issues ***/

[Thorin-Oakenpants]

I think we're over-thinking this: which is not always a bad thing :)

The note is because it does impact perf, as a general rule. It would probably be more severe the more tabs/content open and the lower the machine specs, I guess. So that's fine.

So how would we reword the header section? What exactly are the tracking/FPing downsides to disabling memory cache - is it the forward/back button thing? And compare that to the upside of disabling it - i.e all the potential tracking/FPing?

[claustromaniac]

What exactly are the tracking/FPing downsides to disabling memory cache - is it the forward/back button thing? And compare that to the upside of disabling it - i.e all the potential tracking/FPing?

Disabled or enabled, it can be exploited via behavioral analysis, by establishing patterns by linking speculated situations of in-memory cache usage (or no usage if disabled). That's all. There are no other upsides/downsides de-anonimizing-wise and tracking-wise as far I know.

And yes, the browser uses it mostly for its Forward and Backward navigation actions, plus a few other even more uncommon situations (like reloading the page by clicking the address bar and hitting Enter).

If this were my project, I guess I would just remove its mention in the header section, and expand the entry below to something like:

/* 1003: disable memory cache
 * [NOTE] Not recommended due to performance issues. Benefits of disabling it are arguable at best ***/

[bitpixl]

@claustromaniac, I just wanted to be thorough with my sources. So disabling the in-memory cache does nothing against ETag tracking. Does this mean disabling diskcache alone is enough to stop ETag tracking? From reading this link you provided on your ETag Stoppa addon page, I 'assumed' (dangerous, I know... but alot of this stuff is over my head and I think highly of you) both of the caching needed to be disabled to prevent the ETag tracking. So, what does this mean? Do I need ETag Stoppa or is disabling diskcache sufficient?

[claustromaniac]

Does this mean disabling diskcache alone is enough to stop ETag tracking?

Yes, at least in Firefox.

From reading this link you provided on your ETag Stoppa addon page, I 'assumed' (dangerous, I know... but alot of this stuff is over my head and I think highly of you) both of the caching needed to be disabled to prevent the ETag tracking. So, what does this mean?

My guess is that whoever made that site either:

1. does not know how the in-memory cache actually works (can't say I blame them, most people don't seem to either, in fact I used to assume it was similar to the disk cache myself not that long ago), or...
2. is simply playing it safe by making a generalization that is harmless at worst. E.g. if they omitted that statement and the memory cache turned out to be a real ETag tracking vector in, say, Vivaldi, they would be leaving important information out.

Also, I don't fully agree with their use of the terminology. For instance, I don't consider this ETag exploit a passive technique, and I don't consider it fingerprinting either, but who knows, maybe that's just me.

Do I need ETag Stoppa or is disabling diskcache sufficient?

Just in case: No, ETag Stoppa is not necessary if the disk cache is disabled.

[Thorin-Oakenpants]

I don't think there is any better choice here. People do forced reloads, people clear cache on close, or use extensions to periodically clear cache. That's what this js does. Additionally FPI isolates cache. PB mode clears it's cache: and I read recently that 24% of FF users use PB mode (I would assume thatr means not all the time: just that they open PB mode windows).

I don;t want to say that Benefits of disabling it are arguable at best because I think that is misleading. It can definitely stop tracking. I think I can tweak the header section by changing a few words

e.g "another solution" -> "a better solution" etc

[claustromaniac]

I don;t want to say that Benefits of disabling it are arguable at best because I think that is misleading. It can definitely stop tracking.

Do you have any proof? I've never found any PoCs showing any way to exploit in-memory cache, and I've read MDN documentation extensively. But most of all, I've tested numerous things, including network monitoring with external tools (some of them wrote by myself) and I'm not just assuming anything when I say that content loaded from the in-memory cache does not trigger network requests, and the in-memory cache is seldom used by Firefox.

I know a lot of people has said that in-memory cache has risks, but my guess (my only guess, because the rest are not guesses) is that those folks were just assuming the in-memory cache worked similarly to the disk cache (and they were/are wrong).

But what do I know.

[Thorin-Oakenpants]

^^ I was thinking of Etags: that's definitely tracking (edit: if used that way)

Sorry: I'm confused over what you mean by in-memory?

Edit2: on it's own, IDK, you probably know more than me, but we just said that disabling it (with disk) stops tracking

[Thorin-Oakenpants]

hows this

  ETAG [1] and other [2][3] cache tracking/fingerprinting techniques can be averted by
  disabling *BOTH* disk (1001) and memory (1003) cache. But there are better solutions.
  ETAGs can be neutralized by modifying response headers [4]. A hardened configuration
  with Temporary Containers isolates every tab [5]. Alternatively, you can *LIMIT* exposure
  by clearing cache on close (2803), or on a regular basis manually or with an extension.

^^ edit: I was also going to add something about FPI in there

[claustromaniac]

I was thinking of Etags: that's definitely tracking (edit: if used that way)

ETag tracking requires conditional requests to take place. How can you exploit the in-memory cache for that when content fetched from it does, again, not trigger network requests?

Sorry: I'm confused over in-memory?

It's the semantically correct name, but I'm no language cop, so I'm not trying to correct you or anyone else on that. Most people just refer to it as "memory cache", and everyone knows (or not?!) what is meant by that, so that's OK.

[Thorin-Oakenpants]

Ahh OK. But I don't think I can really say "tracking/fingerprinting techniques can be averted by disabling disk and memory cache" and then later on say "disabling memory cache is arguable".

I'll just assume here, that no one is silly enough to disable memory but allow disk!!

I think with the header edit: it's now painfully clear that with the memory prefs inactive, we telling people that we don't think this is the best way to go. Is the section re-write good to go?

Edit: I don;t use TC, and that wording isn't quite right. It isolates every page? every domain? still not right.

[claustromaniac]

I don't think I can really say "tracking/fingerprinting techniques can be averted by disabling disk and memory cache" and then later on say "disabling memory cache is arguable".

And why should you? I don't want to tell you what to do, but when I said I would add something like that to that note, I also said I would stop mentioning the memory cache in the header. Because I see no reason to. Because I'm not aware of any way it can be used for tracking, because of that thing I've been repeating many times, and disabling it is not significantly less risky fingerprinting-wise than leaving it enabled.

I don;t use TC, and that wording isn't quite right. It isolates every page? every domain? still not right.

You can set it up to isolate per domain (and not sub-domains), or per sub-domain, and there are many other ways to use it. It's very flexible.

[claustromaniac]

I doubted myself for a moment (I do that all the time, believe it or not), and I found out I'm not entirely right, but not entirely wrong either. It's even more complex than I thought.

I'm going to share with you my findings when I can. Should I open a new issue?

[Thorin-Oakenpants]

I have to admit I'm just not quite getting your point about the first sentence in the section header - that thing as you so put it. And I want to make sure I'm not doing something based on a misconception

Yeah, let's close this and start a new conversation. I'll use the new issue as my tracker for improving the section 1000 info