Evercookie is not persistent in Chrome and Safari anymore

[acaporrini]

Hi, I'm testing the Evercookie persistence in different platforms and unfortunately I noticed that most of the time clearing the navigation data delete completely Evercookie from the system.

Chrome Desktop and Android: It is possible to remove Evercookie clicking 'clear all browsing data' from any time from the preferences, Evercookie can persist if i clear for example small parts of his browsing data like the history and cookies but not the image cache. Incognito mode doesn't keep track of the saved Evercookies

Safari Desktop and IOS: It's easy to suppress Evercookie persistence deleting history, website data etc.. Incognito mode doesn't keep track of the saved Evercookies.

Firefox both mobile and desktop however seems still 100% vulnerable to evercookie, even deleting all the browser history cache etc... the browser keeps the Evercookie information.

The Evercookie cross-browser persistence seems also compromised.

Is this project still in development? Can I expect in the future new releases to make it work with the recent browsers versions?

Thanks a lot

[samyk]

I personally only make minor modifications and continue to accept pull requests, always open to updates and improvements!

[bandi94]

Good for Chrome and Safari, this kind of cookies are violating users privacy, all browsers should FORBID any data storage outside the standard browsing data space. You wan't authentication.. do a normal login, create a token, store it a database and done.. not injecting malware's in freaking adobe flash ...

[blue-eyed-devil]

It is very useful tool to fight scammers. Not all intentions are necessarily to damage or spy users, but to protect them. I am running membership website and I have daily some scammer sending their stupid messages to other users. I keep blocking their IP addresses or in some cases whole countries (Nigeria, Senegal, Ghana), but they use proxies located in Canada, UK, etc., register manually and then launch bot again. So storing persistent cookie on their machine after they were banned from website can identify them and block them from certain features on the site.

[ssokolow]

Even half-incompetent scammers can write bots which shake off evercookies. Low-level HTTP libraries persist no state by default because you need to manually specify a means for storing said state after the program exits.

The proper solution is to do what reCAPTCHA does and start everyone off untrusted and allow them to earn a reputation score. (In reCAPTCHA's case, reducing the number of CAPTCHAs you have to fill.)

For a forum-style site, which I assume yours at least resembles, I'd recommend some of these ideas:

• Users must earn the ability to include links in their posts
• Users must earn the ability to send private messages at all
• Failure messages for posting links should only be distinguishable from success messages if you parse the actual English text. (Perhaps with some randomization of the phrasing of both the success and failure messages to complicate parsing)

For some sites I run where bots mistake my contact forms for blog comment forms, disallowing the strings </a> and [/url] (case-insensitively) with a polite "please change your link into a bare URL and re-submit" was enough to completely kill off said misdirected blogspam.

If you're interested, I could share some of the other techniques I have planned to give myself some defense in depth once my more wiki-like rewrites go live.

[ssokolow]

Also, if you decide you do want to do some kind of keyword/phrase blacklisting as a quick way to stall a spambot while you come up with a better solution, look up an implementation in your language of choice for the TR39 Skeleton algorithm for Unicode confusables.

(The Unicode people actually designed an algorithm and maintain a character mapping table for resolving that annoying "looks close enough" character substitution that spammers use (eg. 𝔭𝒶ỿ𝕡𝕒ℓ) back to what humans would recognize it as.)

Just beware the Scunthorpe problem.

[nicolasconnault]

I have an unusual scenario where evercookie is extremely useful and doesn't impinge on users' privacy. Our business has thousands of screens in permanent locations throughout the country. These act as Digital Out-Of-Home (DOOH) advertising platforms, and connect to a central web server to receive data about which ads to play, and send back data about which ads were played and clicked on (these are touch screens). Each screen needs to be configured to be identified correctly by the server. Evercookie enables the device to store its unique ID permanently.

Unfortunately, it's possible to clear evercookie now on Chrome, which is the browser we're using in kiosk mode.

[ssokolow]

That sounds like a case of "definitely not the right solution for the problem" to me.

If you control the software, there are much better solutions. (Which one I'd recommend depends on how much of the stack you control and how things are configured and provisioned.)

If you don't control the software, then it's just an exercise in fooling yourself because it was ALWAYS possible to flush an evercookie... the only question was how much effort evercookie had spent working around the browser developers' intentions and, thus, how much effort it would take to force evercookie back into line.

[nicolasconnault]

We control the stack. The concept is that all the Kiosks have minimal configuration and software installed. They only have Chrome installed with a batch file on the desktop to open chrome in kiosk mode to the same URL. The first time they open the URL they have to identify the device by entering a unique registration code provisioned through the main server by an admin person.

Originally we had each kiosk use a URL param with a unique ID, but that requires a unique install script for every kiosk, which was a royal pain when we did a complete stack upgrade and needed to remotely connect to each device to update the URL.

The stores renting the kiosks will not, in almost all cases, have any good reason or even the skills to clear the cookies or re-install the OS, which are the only two conditions under which the cookie will be cleared. This just seemed like a low-tech, simple solution.

I'm all ears if you have better suggestions :)

[ssokolow]

The first solution that comes to mind for me would be to launch chrome with --enable-easy-off-store-extension-install and use a custom Chrome extension.

Those have access to storage that's intended to be robustly persistent and you could then have the extension make the persisted data visible to the server in whatever way you prefer. (eg. re-adding the cookie to the cookie store as needed, using the chrome.webRequest API to modify outgoing requests, etc.)

You may also want to read the Documentation for Administrators since it has instructions for automated custom configuration, extension pre-installation, and locking down what can be changed.

[nicolasconnault]

Thanks I'll look into that!

[DaanBiesterbos]

Is this still an issue?

In response to the common privacy panick crowd, there are valid reasons to use these technologies although I do I agree you should get user consent. I have recently acquired an online game that is suffering from an increasing number of cheaters. Players are happy to agree to technologies like this if it helps me to get rid of them. And I hate to break it to you. But software is as powerful as it can be dangerous. You can build great software, or nasty software that does a lot things you don't want it to do. This should not be possible, that should not be possible. Nonsense. Technologies are not good or bad (generally). People are. How software is used determines what should or should not be allowed. That is why we have laws and a legal system that should ultimately be the judge of what is allowed and what isn't. Sure, it is not perfect, but perhaps focus on that instead? "Breaking the law should not be possible". But assuming that evercookie makes use of a valid protocol than using it this way is legal isn't it? Assuming that flash users have given Adobe consent making it possible in the first place. When a system supports a given technology, and the user gives a website consent to explicitly use this technology to collect data that the user is aware of..... Than how is the browser responsible for blocking such technologies? I am not opposing privacy, nor am I saying companies should be allowed to do what they want. I am saying that we have a legal system to protect people. And also; people who don't know what they are installing should not have an opinion about which technologies are used for reasons they don' t understand.

[ssokolow]

The problem is that abusive users of such technologies generally don't get stopped by the law because of things like American regulatory capture and cheaters have an incentive to learn how to emply the same techniques.

It winds up being like DRM... keeping honest folks honest but getting bypassed by determined dishonest folks.

The proper solution is to design a system with two properties:

1. Anything tied to a specific user is tied to a server-side user account that can only be created and modified in ways you define.
2. User accounts start out untrusted and have to earn the system's trust.

Then the utility of getting into the evercookie arms is drastically reduced because shaking off their reputation score sets the cheater back significantly and cheating can be made less harmful by tying their power to do harm to their reputation score.

[ciampolo]

Firefox protects properly against all of the methods by container tabs. No need for the user to do anything ever again besides just initially activating container tabs.

This is in contrast to anything based on Blink/Webkit where you have to delete storage after every domain visit and can't have multiple tabs open else the tracking will go on.

Firefox solves this properly since it does not reject anything. It just tells the website that all the storages are empty or only contain data that the current tab placed inside it.

Whoever uses anything but Firefox should not care about web privacy. It is a literal oxymoron.