Document cache (1000) section

[smithfred]

tl;dr: proper summary documentation is actually necessary for the 1000 section, per #51.

There was discussion on #51 about how (much) to document disabling caching etc. in section 1000, and some explanatory text discussed there was removed (seemingly on the basis of "Everyone will know what Cache is and does, and whether they want it enabled or not.")

Problem is, although the user of ghacks-user.js might (and probably does) know plenty of standard stuff about browser caching, what they don't know, is if there's some disk cache-based privacy (or other) attack/risk they haven't read about.

I know in my case, when I came to this section, my immediate thought was "Wait, why is cache being disabled? Is this just an "on-disk browsing info available locally" problem? Is it a tracking issue (ETags?) Is there some other attack vector I don't know about they're preventing here?"

So seeing the mostly undocumented inclusion of cache-disabling items, they now don't know if they can safely override them.

Compare signon.autofillForms. If the user keeps their system locally secure, they might think that feature is harmless, whereas in that case, there is both a 3rd-party and 1st-party tracking issue with leaving it enabled.

Is there a similar problem with cache? Without 1000 docs, the user doesn't know.

[smithfred]

Users of ghacks-user.js will have different goals/non-goals. For instance:

• Prevent tracking/fingerprinting
• Prevent data-sharing with third parties (e.g. Google)
• Mitigate/prevent data breaches/exfiltration (e.g. history extraction)
• Mitigate/prevent system compromise attack vectors
• Prevent shoulder-surfing (+public space CCTV etc.) data gathering
• Prevent local storage of browsing history etc.

Personally my main purpose is "my personal life/interests are none of $(advertising/tracking/behemoth corp)'s fucking business", with a side of "arbitrary JS is a security trash-fire waiting to happen", but "I can keep my own machines sufficiently secure" ;)

Since the ghacks-user.js project seems to be characterised as covering different needs (customise per user's needs), then this info is needed somewhere. If not in the actual user.js file, then in an external file referenced by user.js (or easily cross-referenced).

I'm not sure that "silly-looking" or otherwise is really an important consideration, unless it actually affects usability.

A compact option might be an abbreviated key, e.g. /* F, SS - see user.js-notes.txt#1050 */

I filed this against the 1000 section since it was the first one where I was really unclear about the ramifications (a lot of others have a short explanation, or were self-explanatory to me), but you may well be right that other under-documented sections could benefit from the same.

[smithfred]

OK, I nominate the cache section for the second thing ;)

BTW great work on the whole project, much appreciated, and becoming ever more useful/necessary given Mozilla's current "leadership" and "decision-making" :J ...!

[smithfred]

There's not actually extra work in documenting this somewhere (other than in GH issue discussions), since... well, it's already being documented already, in GH issue discussions...

PS: In earlier versions of the js on ghacks, I used to add things like - FORENSICS and - SHOULDER SURFERS at the end of numbered lines but at some point it becomes ridiculous and silly looking

and info is better off in the actual user.js IMO

Pick one, you can't have both ;)

Why not just have a user.js and a user.js-notes.md, and split the docs out to the latter entirely? Keeps the user.js clean, and lets you semantically mark up the notes (for notes navigation etc.)

[smithfred]

I listed 3 different possibilities in the quoted paragraph, and the other options demonstrate that it's not that obvious. I'm neither dumb nor uninformed, and yet still the proliferation of browser threats/attack vectors makes it very difficult to know that it's a local/unlocked account risk only.

@smithfred is the first person (AFAIK) in approx 3 years, since I started this thing, to ask about cache

Not a sound analysis, you should know that ;)

IF a pref is there for a specific threat, we explain it, but for generalized threats, there is no need.

Put that at the top of the user.js file then. Presumably you're confident that consitently throughout the user.js that statement is correct too? And will continue to be the case?

[crssi]

@smithfred if you still want to enable memory cache, then follow https://github.com/ghacksuserjs/ghacks-user.js/wiki/4.2.4-Header-Editor to get rid of ETags.

[smithfred]

Your two possibilities ("something else" does not qualify)

3. Local/unlocked history access; tracking; attack (vulnerability exploit) vector. They all qualify as the point is to enumerate the possible classes of problem to demonstrate the ambiguity of undocumented pref settings, not to know them exactly. The fact that the last one is vague only strengthens the point. New vectors crop up so frequently that someone having certainty that they know all of them (and can therefore determine with certainty without documentation the purpose of a pref set) is extremely difficult.

So you already had the answers.

In the same way that someone who doesn't know the correct answer to a multiple-choice question already "has all the answers". I.e. only in a literal, and completely useless sense :J