> I'm using a salted hash to calculate unique visitors.

Where do you store the salted hash?

The salted hash is stored in a database.

Where is it stored on the client? Or is it a salted hash of the IP address used to connect? If so, the recent precedent from CNIL wouldn't consider that exempt from GDPR cookie banner unless obscured via a first-party proxy.

It's the salted hash of the IP used to connect.

I did build my approach around the Internet's backbone to future proof. Banning my approach would fundamentally break the Internet. I've made a note and will read into the precedent. Thank you for the research topic.

> Banning my approach would fundamentally break the Internet.

That’s simply false. The legal basis for processing an IP address in order to serve an HTTP request in the EU is Art 6 (b):

> processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract;

This does not give you the right to use that data for any other purpose.

The approach you’re using is called fingerprinting in the industry (relatively naive fingerprinting given it only uses IP address) and it is the ongoing subject of enforcement action in the EU. Nothing about the approach is compliant.

Frankly, if it was this easy to forgo the regulatory impact of the GDPR, every analytics service would do it (many shady ones do).

Pathview does not fingerprint. Full stop.

The salted hash (of the IP address) is used for one purpose: to count unique visits.

To associate individual page views to a single real IP address. That is fingerprinting.

Pathview does not associate individual page views to single real IP addresses.

Quite honestly, you are not competent to make that determination.

For the purposes of compliance with the GDPR, Pathview does associate individual page views with a single real IP address. From the precedent set by the CNIL ruling on Google Analytics in July, the only way for an analytics tool not to process personal data in the form of an IP address is to relay the request via a first-party proxy (and strip the referer).

Your analytics tool cannot accept HTTP requests from the users browser and be compliant with the GDPR without gaining consent. Serving an HTTP request made for the purposes of analytics is processing personal data and there's no legal basis for the processing without consent.

> The fundamental problem that prevents these measures from addressing the issue of access of data by non-European authorities is that of direct contact, via an HTTPS connection, between the individual's terminal and servers managed by Google.

> The resulting requests allow these servers to obtain the IP address of the Internet user as well as a lot of information about his terminal. This information may realistically allow the user to be re-identified and, consequently, to access his or her browsing on all sites using Google Analytics.

> Only solutions allowing to break this contact between the terminal and the server can address this issue. Beyond the case of Google Analytics, this type of solution could also make it possible to reconcile the use of other analytics tools with the GDPR rules on data transfer.

Source: https://www.cnil.fr/en/google-analytics-and-data-transfers-h...

I've removed the hashed IP address. It is no longer stored and therefore cannot be processed.

As I've said multiple times, I will be consulting with a lawyer to ensure Pathview is in compliance with relevant privacy laws. You might be a lawyer (who knows), but I am definitely not.

I think most people (including me) are looking for how it works to check if it really is (somewhat) GDPR compliant, so for example you want to know if data is stored in aggregate or also individual data (which would fall under GDPR), if individual users are tracked with some kind of identifier, how fast the identifier is deleted, if its stored in disk or only in memory, who can access the identifier, is the identifier pseudonized etc.

I'm happy to answer any question about what data is acquired and how it is acquired. I cannot answer every question about how my system processes the data. I built a novel algorithm that represents economic leverage.

Each hit is stored without personal data but including a salted hash representing the IP. Users are not tracked and are not assigned any type of individual identifier.

OK, that's what I was looking for. Storing hits with any kind of identifier is considered processing of personal data under GDPR. It doesn't matter whether you have assigned the identifier or whether you use one that the user already has (IP, device ID etc). Hashing / salting the identifier does not change that if it's still unique.

The way to make it compliant is to ask permission for using the data. Or doing your analysis without any user identifiers, but that doesn't get you much useful insights.

To be clear, I need to count unique visits without using a salted IP address even when it cannot be attributed to an individual or used to track them across multiple websites?

I do have an idea that might work for this scenario. If I can calculate unique visits differently, I can drop the salted hash from the database too. I'm guessing that should be sufficient to satisfy most privacy conscious users.

I think it's fairly fundamental; to see if a visitor has accessed one page, and later on another page, you need to track that visitor somehow. So you need some kind of identifier. Even using an IP address (hashed or not) or assigning a random ID all falls under GDPR regulation. Alternative 'tricks' like link decoration could work maybe but you have to rewrite all URLs, which is very error prone. Creating cnames for every customer is another option, called cname cloaking, but it has other drawbacks and it's probably also not GDPR compliant. Would definitely be interesting if there is a solution for this problem, as I agree that there are very valid usecases for attribution, but its very hard to do as (very limited) tracking is almost mandatory to do this. You could work 'around' legislations by checking where a visitor comes from and track (only) in those regions where its allowed, and in other areas ask for permission? You will miss visitors, but you can extrapolate counters to compensate potentially.

I can count unique sessions without using or storing the IP address or an identifier. Maybe that represents a fair middle ground?

Edit: I implemented this approach. It's less accurate but removes the need for any representation of the IP address.

Cool, not sure how you did that of course, you should probably if you want to grow this do an external code audit or something like that, but great job, also how fast you change stuff!

Thanks! The core code (capture and post-processing) sits around 250 lines. It's short enough to retain which makes iterating quick and fairly painless.

Considering I'm about 2-months in, I'm happy with the progress and general direction.

Nice! If you want to discuss more, happy to talk, see my profile for contact info