ublock / block list bypass

[ghost]

#114
Since the issue remains open but seemed to have died out years ago so I can't reply to the original issue; I'll throw in my method here.

All the 'easyprivacy' block script is doing blocking out the request for anything containing the path "/evercookie/". You can bypass block scripts by just changing the name to anything else. It is a very ez-pz thing to step around.

To fight against block script patterns that may occur after first method fails:
For best results just random cache the php file names with a list of random names.
For better results have the name list be around 1000+ random names / hashes and guid formats.
Then check if the request was handled or not. There are different ways this can be done.
If not re-generate with the next name in list and delete old cache. Repeat until true or error out page.

Most block script regex patterns can't even match against that kind of generation and is much better than hash / guid caching your file / directory names.

[ssokolow]

...and, conversely, if you care about privacy in the face of bad actors and want to ensure evercookie and related technologies are defeated on a technical level without giving yourself decision fatigue:

1. Enable first-party isolation, so each domain gets its own set of third-party cookies. (For cross-site use of analogues to evercookie.)
2. Install an extension like CanvasBlocker which is capable of forging responses (ie. returning random data) when a non-whitelisted site tries to fingerprint or read pixel data out of a <canvas> element. (CanvasBlocker also does the same for other known types of fingerprinting such as audio API fingerprinting.)
3. Configure cookie whitelisting and install an extension which flushes un-whitelisted cookies and local storage when you close the last tab for a given site. (Ideally, your combination of browser and extension will support an option to handle cookies, Flash LSOs, all HTML5 "... Storage" APIs, and and IndexedDB from the same whitelist under the general heading of "site user data".)
4. Make sure that Flash and any other plugins your browser may still support are handled by a whitelist.
5. Set your browser to flush its cache on exit and, if you can find an extension to do it, every 24 to 48 hours. (This should handle cache and ETags-based methods.)
6. If you're using Firefox, go into about:config and set browser.sessionstore.privacy_level=2 to prevent things like window.name from being persisted in the session restore system.
7. Set signon.autofillForms to False, so Firefox's password manager will always behave as if you have multiple accounts saved in the password manager for the given site. (To prevent sites from watching for un-prompted auto-fill to identify you even when you're choosing not to log in.)
8. Make sure you're running a modern enough browser to have closed the CSS history leak.
9. look up an appropriate solution for disabling HTTP Strict Transport Security (HSTS) pinning in your particular browser and install HTTPS Everywhere to mitigate the reduced security. (eg. on non-Windows platforms like Linux, emptying the browser's HSTS store file and then using chattr +i to set it immutable in a way distinct from the usual "Do I have write permissions?" that things check for.)
10. Look up browser-specific instructions for ensuring that TLS session resumption identifiers get cleared along with your cache and HSTS pins.
11. Look up browser-specific instructions for clearing your HTTP Public Key Pinning (HPKP) pins, and investigate alternatives for regaining the security they offered. (This may eventually not be a problem, as Chrome deprecated this feature starting with version 67.)
12. Enable the standard browser-internal stuff like Firefox's tracker blocking as an extra layer of protection against the companies with the most budget to try to work around your efforts.