anti-FP feature request: enumerating history
See original GitHub issueFrom here: https://github.com/ghacksuserjs/ghacks-user.js/issues/458#issuecomment-402264058 and kkapsner’s reply
these APIs would also allow the history.length to be spoofed in a sneaky fashion. To be honest: it would be really simple to include this in CanvasBlocker… 😉
Since this extension now seems to be growing beyond canvas (audio now added), and only looking IMO to fill gaps in the market, I think this would be a good extra
– background–
FF has a pref, from our user.js
/* 0804: limit history leaks via enumeration (PER TAB: back/forward) - PRIVACY
* This is a PER TAB session history. You still have a full history stored under all history
* default=50, minimum=1=currentpage, 2 is the recommended minimum as some pages
* use it as a means of referral (e.g. hotlinking), 4 or 6 or 10 may be more practical ***/
user_pref("browser.sessionhistory.max_entries", 10);
I’m not knowledgeable as to how JS can use this. Sure, it can get a count, but can it read the values? JonDoNym recommends 2, and to reset it on every domain change (doesn’t matter if it is higher on the same domain)
I use 10 in my FF profile (workflow needs it), but have for years obfuscated the real value using a user script https://github.com/ghacksuserjs/ghacks-user.js/wiki/4.2.1-User-Scripts. Note that there can be issues with @run-at document-start
but not in this case with VM (GM will fail). It’s a very simple script
You can test the history value at http://browserspy.dk/document.php or take the JonDoNym test ( http://ip-check.info/?lang=en ). The result is under Tab History
If this could be built into CB, without affecting FF internally (so you still usefully go back per tab as many as the pref value), this would remove the need for the user script (which can leak it’s function name). And, if the history length can be enumerated (am I using the right word here?), then limit that to (the last) 2 as well?
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:30 (21 by maintainers)
Top GitHub Comments
Looking at the user script again I kind of remember seeing this line… but obviously did not when implementing… I think I will add a user question to whitelist reCAPTCHA when activating the protection. I do not want to add a google URL somewhere in a whitelist without the user accepting.
Yes. It interferes with other extensions like uBlock and NoScript. I even opened an issue for NoScript so they will always overwrite other extension: https://github.com/hackademix/noscript/issues/6 (I think their protection is way more important than CBs).
#214 was the first time I realized that. There are some issues for Firefox open related to this problem.