6 ms·

One could still use Google Analytics by proxying the tracking events. Afaik only the IP is considered private data. So one could mask or (non-reversibly) hash t

by TekMol 3y ago

One could still use Google Analytics by proxying the tracking events. Afaik only the IP is considered private data. So one could mask or (non-reversibly) hash the IP, remove anything else which might be considered private data and then send the event to Google. A simple PHP script with a few lines of code could do that. But Google lost me by: A) Making it impossible to convert your old data into the new Analytics version B) Abandoning the API which allowed you to code your own reports. Over the years, I wrote a ton of code that talks to the API. This is all worthless now. I recently switched to self-hosted Matomo. At first I did not think much about it, but now after I got used to it, I have to say it is much better than GA. The interface is so much nicer and snappier. And more logical. Apart from that, I like that it is open source. If there ever is a point in the road where the makers of Matomo decide on a non-compatible fork, I'm sure the community will write a converter that converts the old data into the new format. And after using it for a while, it hit me: You can write your own reporting tools by just querying the MariaDB database! Using SQL is so much better than it was to fight the insanely complex and unintuitive Google Analytics API. If I really wanted to still use Google Analytics, I would just write a converter, which pumps all the Matomo events into Google Analytics. That would be a GDPR-compliant way to use Google's tools. But I don't. I'm done with Google Analytics forever. Matomo is the promised land for me.

bunnyfoofoo 3y ago
You can’t hash an ipv4 address. It’s trivial to brute force all possibilities given the limited problem space.
- leononame 3y ago
  But you could use a salt, right?
  - Qwertious 3y ago
    A salt will render rainbow tables useless, but AIUI will not prevent brute-forcing after the fact. IPv4 has ~4 billion addresses, which would be too expensive for data analytics but could be brute-forced if someone really wants this one piece of data in particular.
    - deleted 3y ago
      [deleted]
  - wyufro 3y ago
    Only if the salt is kept secret. There also needs to be a different salt value per ip, obviously. But given those conditions, it works. Of course, it would be just as simple to use the salt as-is, in that case, since you have to look it up anyway.
    - deleted 3y ago
      [deleted]
- worksonmine 3y ago
  That's why you use a salt, which is what I assume is meant by "non-reversibly".
  - sweetjuly 3y ago
    Salts provide resistance against bulk bruteforce by making it so that you can't identify which hashes are the same plaintext without actually computing all of them. The issue is still that there are not that many IPv4 addresses and so even with very heavy algorithms it would be trivial to break.
    - worksonmine 3y ago
      But there are infinite numbers of salts. Please explain how this could be brute-forced as long as the salt is used correctly? What am I missing?
      - ericpauley 3y ago
        No matter what strategy you use to hash IPs, if you can correlate to an IP you can find the original IP by just trying all options. It doesn’t matter what you do because 4B unique possibilities is just too low to prevent brute forcing while maintaining utility. If you use a random salt, then you need to store it or else the stored value has no utility. However you implement retrieval of that salt it can just be brute forced.
        worksonmine 3y ago
        The salt could be stored as a cookie and you can follow the session but never be able to reverse the hash yourself. Any match you get in the brute-force attempt might as well be a collision. The entropy can be in the salt, you're all making it sound way too easy. The requirement is "non-reversible". Given infinite time everything can be brute-forced, but this is the mossad/not-mossad problem. It's good enough for storing passwords, where the salt is plain-text.
- jeltz 3y ago
  I have not researched it but I wonder if you can even hash IPv6 addresses. The issue I see is that allocations could be too regular so even if the full space is huge most addresses may occupy a small and predictable part of it.
  - pixl97 3y ago
    Depends how you define IP in this sense. Each full individual IPv6, unlikely as most consumer devices are getting a somewhat random internal address on their network. Now, with IPv6 for most consumers the first 64 bits is generally enough to define the edge network device that would be covered by a single IPv4 these days.
    - marcosdumay 3y ago
      > the first 64 bits is generally enough to define the edge network One complication is that hashing removes this structure. If you use any good algorithm, you will need to test the entire address to recover any part of it. I am very wary of IPv6 addresses being so heavily biased into 00 or ff segments that the address space doesn't actually add much entropy. So, I'd go with no, it's not safe to hash them. But if you get some random ones, I am really not sure.
- zyx321 3y ago
  How about this: Server-wide salt. Randomly generated every 24h or server reboot (whichever is sooner). The salt is not saved alongside the hashed IP, it is not saved anywhere whatsoever. There is no log of previous salts. You can still track a user session across multiple page calls, but the hash can not track them across different sites.
berkes 3y ago
Last time we had a privacy officer make a report on our setup, we were (unknowingly) sending much more PI data to Google than the IP. The fact that you e.g. clicked the "like button" on profiles/xxx, leaks that you have access to xxx, can like it, and have liked it. There were many more like this. Ours was a business tool. The data we were leaking was e.g. the fact Foo was employee at ACME, simply because we sent events occurring on the estate of Acme for user Foo. It's not as straightforward as proxying. Or, as we did, removing some bits from the IP.
jonasb 3y ago
Hashing the IP is not enough by IMY's decisions, none of the companies are allowed to use GA going forward. CDON used GA's IP anonymization through truncation, it was not deemed enough. [1] The IP itself becomes is not personal data after truncation but it's unclear if the truncation happens before it leaves the country. And combined with the other personal data (e.g. cookies), it is considered personal data. [2] Coop proxied all calls to GA and use the same generic IP address for all users. [3] They don't get a fine but have to stop using GA. [1] "1.3.15 Effektiviteten hos vidtagna skyddsåtgärder av Google och CDON" https://www.imy.se/globalassets/dokument/beslut/2023/beslut-tillsyn-ga-cdon.pdf https://www.imy.se/globalassets/dokument/beslut/2023/beslut-... [2] "2.2.2 Integritetsskyddsmyndighetens bedömning" https://www.imy.se/globalassets/dokument/beslut/2023/beslut-tillsyn-ga-cdon.pdf https://www.imy.se/globalassets/dokument/beslut/2023/beslut-... [3] "1.3.14.2 Coops implementering av server side container" https://www.imy.se/globalassets/dokument/beslut/2023/beslut-tillsyn-ga-coop.pdf https://www.imy.se/globalassets/dokument/beslut/2023/beslut-...
- jefftk 3y ago
  Automated translation of 1.3.14.2: 1.3.14.2 Coop's implementation of the server side container The purpose of the server side container that Coop has implemented is to improve the security related to the data sent. More specifically, the aim is to on a good and safely be able to protect the personal privacy of those registered. Server side the container acts as a proxy between the registrant's browser and the Tool where Coop has chosen to implement the server side container in a way that makes them the registered browser's public IP address is never transmitted to the Tool. Implementation can be described as follows. A registrant visits the website www.coop.se in your browser. The Google Analytics script is downloaded from the server side container instead of being downloaded directly from Google Analytics servers. This results in the registrant's IP address as well as information about user behavior, device information, customer status, online identifiers and transaction data (according to points 1–5 above under section 1.3.10) are transferred to the server side container, instead directly to Google Analytics. Once the Google Analytics script has been downloaded from the server side container, a new call is made from the server side container to Google Analytics servers. Since the call is made from the server side container, no transfer of the registrant's public IP address to Google Analytics. Coop has configured the server side container in such a way that all data as above, except it was recorded public IP address, passes through the server side container to Google Analytics. Google Analytics receives data sent from the server side container and that data (information) that has been sent is popularized in reports by the measurement set up on the website www.coop.se. The treatments that take place through the aforementioned – i.e. to receive, convert and forward the call - takes place in the working memory of the server side container. It means all processing takes place in real time and that no data is permanently stored. In other words, stored public IP addresses were not registered in the server side container and they are not exposed rather against Google Analytics servers. All communication from the browser, via server side container, to The tool is also encrypted. This process cannot be reversed as the information is not stored and the conversion not based on a one-to-one relationship that enables the use of a "key" to recreate the public IP addresses. Coop has activated Google's function for IP anonymization. It means that the IP address sent to the Tool is truncated. This is done by Google removing one part of the IP address before the IP address is stored on disk. For an IPv4 address, last is replaced the octet in the address with a zero. For an IPv6 address, the last 80 bits are replaced with zeros. The action cannot be reversed but as this action is done by Google i Coop has also chosen to implement the tool as a server side container. In Coop's case, the IP anonymization feature is enabled and applied to the generic IP address sent via the server side container. In context, however, the function is redundant considering that the server side container prevents the public of the registered IP addresses from being sent to the Tool. Coop's assessment is that server side the container as a measure is a sufficient protective measure, but that it does not harm that even have the IP anonymization function activated in the Tool. Do you happen to know which section of the ruling it is where they discuss why Coop needs to stop doing this? It's a PDF and the translation tool I'm using on my phone is a pain.
jhpacker 3y ago
One of the sites (coop.se) in this decision did use a server-side GTM container to mask the IP before it was sent to Google, but they were still told to stop using GA, but they weren't fined. The DPA said that the _gads, _ga, and _gid cookies were enough to be identifiable. I don't follow the logic there, but that rules out using a proxy for compliance (at least done as coop did it).
nazka 3y ago
My company is Matomo too and wanted to use it to track how the user uses the WebApp. But Custom Actions are deprecated and Custom Dimensions are not made for that. Do you use any analytic tool to track what the users are doing that is GRPD compliant? I am looking for something where I can track which button he pressed, how many times, which part of the app are the most used and underused, do some funnel of the happy paths, things like that. Like not to know who is the user but really app based and how the user uses the app. Before I used to use Google Tag Manager for that. But it’s not GRPD compliant so I can’t use it.
- pyrale 3y ago
  Depending on your knowledge of the browser, it's not extremely hard to rollout your own barebone analytics. If you're only interested in session data without collecting any cross-session knowledge, all you have to do, basically, is tag your page and listen to dom events.
ukuina 3y ago
A, especially, is atrocious and caused multiple small companies I know to ditch GA entirely. They had years of GA data that is impossible to export without BigQuery shenanigans. It is impossible to believe a team as well-funded as Analytics could/would not find a way to automatically migrate gtag.js to GA4. They should have made the upgrade transparent by simply converting requests behind the scenes so legacy analytics properties could exist perpetually, while forcing new property registrations to use GA4.

by TekMol 3y ago

bunnyfoofoo 3y ago

You can’t hash an ipv4 address. It’s trivial to brute force all possibilities given the limited problem space.

leononame 3y ago
But you could use a salt, right?
- Qwertious 3y ago
  A salt will render rainbow tables useless, but AIUI will not prevent brute-forcing after the fact. IPv4 has ~4 billion addresses, which would be too expensive for data analytics but could be brute-forced if someone really wants this one piece of data in particular.
  - deleted 3y ago
    [deleted]
- wyufro 3y ago
  Only if the salt is kept secret. There also needs to be a different salt value per ip, obviously. But given those conditions, it works. Of course, it would be just as simple to use the salt as-is, in that case, since you have to look it up anyway.
  - deleted 3y ago
    [deleted]
worksonmine 3y ago
That's why you use a salt, which is what I assume is meant by "non-reversibly".
- sweetjuly 3y ago
  Salts provide resistance against bulk bruteforce by making it so that you can't identify which hashes are the same plaintext without actually computing all of them. The issue is still that there are not that many IPv4 addresses and so even with very heavy algorithms it would be trivial to break.
  - worksonmine 3y ago
    But there are infinite numbers of salts. Please explain how this could be brute-forced as long as the salt is used correctly? What am I missing?
    - ericpauley 3y ago
      No matter what strategy you use to hash IPs, if you can correlate to an IP you can find the original IP by just trying all options. It doesn’t matter what you do because 4B unique possibilities is just too low to prevent brute forcing while maintaining utility. If you use a random salt, then you need to store it or else the stored value has no utility. However you implement retrieval of that salt it can just be brute forced.
      - worksonmine 3y ago
        The salt could be stored as a cookie and you can follow the session but never be able to reverse the hash yourself. Any match you get in the brute-force attempt might as well be a collision. The entropy can be in the salt, you're all making it sound way too easy. The requirement is "non-reversible". Given infinite time everything can be brute-forced, but this is the mossad/not-mossad problem. It's good enough for storing passwords, where the salt is plain-text.
jeltz 3y ago
I have not researched it but I wonder if you can even hash IPv6 addresses. The issue I see is that allocations could be too regular so even if the full space is huge most addresses may occupy a small and predictable part of it.
- pixl97 3y ago
  Depends how you define IP in this sense. Each full individual IPv6, unlikely as most consumer devices are getting a somewhat random internal address on their network. Now, with IPv6 for most consumers the first 64 bits is generally enough to define the edge network device that would be covered by a single IPv4 these days.
  - marcosdumay 3y ago
    > the first 64 bits is generally enough to define the edge network One complication is that hashing removes this structure. If you use any good algorithm, you will need to test the entire address to recover any part of it. I am very wary of IPv6 addresses being so heavily biased into 00 or ff segments that the address space doesn't actually add much entropy. So, I'd go with no, it's not safe to hash them. But if you get some random ones, I am really not sure.
zyx321 3y ago
How about this: Server-wide salt. Randomly generated every 24h or server reboot (whichever is sooner). The salt is not saved alongside the hashed IP, it is not saved anywhere whatsoever. There is no log of previous salts. You can still track a user session across multiple page calls, but the hash can not track them across different sites.

berkes 3y ago

Last time we had a privacy officer make a report on our setup, we were (unknowingly) sending much more PI data to Google than the IP. The fact that you e.g. clicked the "like button" on profiles/xxx, leaks that you have access to xxx, can like it, and have liked it. There were many more like this. Ours was a business tool. The data we were leaking was e.g. the fact Foo was employee at ACME, simply because we sent events occurring on the estate of Acme for user Foo. It's not as straightforward as proxying. Or, as we did, removing some bits from the IP.

jonasb 3y ago

Hashing the IP is not enough by IMY's decisions, none of the companies are allowed to use GA going forward. CDON used GA's IP anonymization through truncation, it was not deemed enough. [1] The IP itself becomes is not personal data after truncation but it's unclear if the truncation happens before it leaves the country. And combined with the other personal data (e.g. cookies), it is considered personal data. [2] Coop proxied all calls to GA and use the same generic IP address for all users. [3] They don't get a fine but have to stop using GA. [1] "1.3.15 Effektiviteten hos vidtagna skyddsåtgärder av Google och CDON" https://www.imy.se/globalassets/dokument/beslut/2023/beslut-tillsyn-ga-cdon.pdf https://www.imy.se/globalassets/dokument/beslut/2023/beslut-... [2] "2.2.2 Integritetsskyddsmyndighetens bedömning" https://www.imy.se/globalassets/dokument/beslut/2023/beslut-tillsyn-ga-cdon.pdf https://www.imy.se/globalassets/dokument/beslut/2023/beslut-... [3] "1.3.14.2 Coops implementering av server side container" https://www.imy.se/globalassets/dokument/beslut/2023/beslut-tillsyn-ga-coop.pdf https://www.imy.se/globalassets/dokument/beslut/2023/beslut-...

jefftk 3y ago
Automated translation of 1.3.14.2: 1.3.14.2 Coop's implementation of the server side container The purpose of the server side container that Coop has implemented is to improve the security related to the data sent. More specifically, the aim is to on a good and safely be able to protect the personal privacy of those registered. Server side the container acts as a proxy between the registrant's browser and the Tool where Coop has chosen to implement the server side container in a way that makes them the registered browser's public IP address is never transmitted to the Tool. Implementation can be described as follows. A registrant visits the website www.coop.se in your browser. The Google Analytics script is downloaded from the server side container instead of being downloaded directly from Google Analytics servers. This results in the registrant's IP address as well as information about user behavior, device information, customer status, online identifiers and transaction data (according to points 1–5 above under section 1.3.10) are transferred to the server side container, instead directly to Google Analytics. Once the Google Analytics script has been downloaded from the server side container, a new call is made from the server side container to Google Analytics servers. Since the call is made from the server side container, no transfer of the registrant's public IP address to Google Analytics. Coop has configured the server side container in such a way that all data as above, except it was recorded public IP address, passes through the server side container to Google Analytics. Google Analytics receives data sent from the server side container and that data (information) that has been sent is popularized in reports by the measurement set up on the website www.coop.se. The treatments that take place through the aforementioned – i.e. to receive, convert and forward the call - takes place in the working memory of the server side container. It means all processing takes place in real time and that no data is permanently stored. In other words, stored public IP addresses were not registered in the server side container and they are not exposed rather against Google Analytics servers. All communication from the browser, via server side container, to The tool is also encrypted. This process cannot be reversed as the information is not stored and the conversion not based on a one-to-one relationship that enables the use of a "key" to recreate the public IP addresses. Coop has activated Google's function for IP anonymization. It means that the IP address sent to the Tool is truncated. This is done by Google removing one part of the IP address before the IP address is stored on disk. For an IPv4 address, last is replaced the octet in the address with a zero. For an IPv6 address, the last 80 bits are replaced with zeros. The action cannot be reversed but as this action is done by Google i Coop has also chosen to implement the tool as a server side container. In Coop's case, the IP anonymization feature is enabled and applied to the generic IP address sent via the server side container. In context, however, the function is redundant considering that the server side container prevents the public of the registered IP addresses from being sent to the Tool. Coop's assessment is that server side the container as a measure is a sufficient protective measure, but that it does not harm that even have the IP anonymization function activated in the Tool. Do you happen to know which section of the ruling it is where they discuss why Coop needs to stop doing this? It's a PDF and the translation tool I'm using on my phone is a pain.

jhpacker 3y ago

One of the sites (coop.se) in this decision did use a server-side GTM container to mask the IP before it was sent to Google, but they were still told to stop using GA, but they weren't fined. The DPA said that the _gads, _ga, and _gid cookies were enough to be identifiable. I don't follow the logic there, but that rules out using a proxy for compliance (at least done as coop did it).

nazka 3y ago

My company is Matomo too and wanted to use it to track how the user uses the WebApp. But Custom Actions are deprecated and Custom Dimensions are not made for that. Do you use any analytic tool to track what the users are doing that is GRPD compliant? I am looking for something where I can track which button he pressed, how many times, which part of the app are the most used and underused, do some funnel of the happy paths, things like that. Like not to know who is the user but really app based and how the user uses the app. Before I used to use Google Tag Manager for that. But it’s not GRPD compliant so I can’t use it.

pyrale 3y ago
Depending on your knowledge of the browser, it's not extremely hard to rollout your own barebone analytics. If you're only interested in session data without collecting any cross-session knowledge, all you have to do, basically, is tag your page and listen to dom events.

ukuina 3y ago

A, especially, is atrocious and caused multiple small companies I know to ditch GA entirely. They had years of GA data that is impossible to export without BigQuery shenanigans. It is impossible to believe a team as well-funded as Analytics could/would not find a way to automatically migrate gtag.js to GA4. They should have made the upgrade transparent by simply converting requests behind the scenes so legacy analytics properties could exist perpetually, while forcing new property registrations to use GA4.