4 ms·

> Part of the issue is that data is transmitted outside the EU - but that seems easily fixable. Not quite, since the CLOUD Act [0] was put in effect. This is

> Part of the issue is that data is transmitted outside the EU - but that seems easily fixable. Not quite, since the CLOUD Act [0] was put in effect. This is the gist of the problem: The CLOUD Act primarily amends the Stored Communications Act (SCA) of 1986 to allow federal law enforcement to compel U.S.-based technology companies via warrant or subpoena to provide requested data stored on servers regardless of whether the data are stored in the U.S. or on foreign soil. And this is under "International reactions": The European Data Protection Supervisor (EDPS) viewed the CLOUD Act as a law in possible conflict with the GDPR. The German Commissioner for Data Protection has warned against the use of US based Amazon Web Services for storing sensitive data for the Federal Police. [0] https://en.wikipedia.org/wiki/CLOUD_Act https://en.wikipedia.org/wiki/CLOUD_Act

alkonaut 4y ago
This only applies to PII though? If analytics contains PII it seems that’s already problematic. I get that GA is “worse” than others in that it potentially sends more data than necessary, potentially making it possible to bind pseudonyms to real identities. But hypothetically - if GA was properly pseudonymous (e.g client generated guide transmitted, no connection to browsing history, no entropy like detailed user agent data etc, and purely client side pseudonymization) would that remedy the situation? I guess the answer is “no one knows as it’s not tried”. But it’s an interesting question because if it isn’t, then no analytics would be compliant. For example using an analytics service like Ms App Insights for a mobile app.
- generj 4y ago
  Correct, storing PII is against GA’s TOS. Which doesn’t at all mean it isn’t ingested somehow or another (and Google can trivially integrate it back to a person if they wanted to). PII is a very malleable term depending on the jurisdiction. So long as website operators are creating URLs and the data layers published into analytics there’s no way to ensure the data is truly anonymized. It just takes one slip up with a username being placed into a query string, or some other small mistake. In many organizations marketing runs the analytics, and they try to do as much as possible without developers who might notice these types of errors. It could be interesting to have browsers avoid sending user agents and otherwise minimize HTTP headers to a list of analytics domains.
  - alkonaut 4y ago
    Is the key then perhaps to NOT use the default functionality of this type of analytics? I don't use this I use a pseudonymous "hand rolled" analytics method which is simply logging specific events in the program when a feature is used, and tagging those with a random session id and a persistent random pseudonym. E.g. "user 291281223233 used feature print_document in session 129871209182 ". But I guess some of the attraction of a package like GA is that you don't have to spend weeks instrumenting your app? But I can certainly see the problem if ANY urls are sent. And I can see how weak GA would be if by default NO urls, no IPs, no User agent string are sent. You'd need to add quite a few "user_visited_page('pagename')" to your site code...

alkonaut 4y ago

This only applies to PII though? If analytics contains PII it seems that’s already problematic. I get that GA is “worse” than others in that it potentially sends more data than necessary, potentially making it possible to bind pseudonyms to real identities. But hypothetically - if GA was properly pseudonymous (e.g client generated guide transmitted, no connection to browsing history, no entropy like detailed user agent data etc, and purely client side pseudonymization) would that remedy the situation? I guess the answer is “no one knows as it’s not tried”. But it’s an interesting question because if it isn’t, then no analytics would be compliant. For example using an analytics service like Ms App Insights for a mobile app.

generj 4y ago
Correct, storing PII is against GA’s TOS. Which doesn’t at all mean it isn’t ingested somehow or another (and Google can trivially integrate it back to a person if they wanted to). PII is a very malleable term depending on the jurisdiction. So long as website operators are creating URLs and the data layers published into analytics there’s no way to ensure the data is truly anonymized. It just takes one slip up with a username being placed into a query string, or some other small mistake. In many organizations marketing runs the analytics, and they try to do as much as possible without developers who might notice these types of errors. It could be interesting to have browsers avoid sending user agents and otherwise minimize HTTP headers to a list of analytics domains.
- alkonaut 4y ago
  Is the key then perhaps to NOT use the default functionality of this type of analytics? I don't use this I use a pseudonymous "hand rolled" analytics method which is simply logging specific events in the program when a feature is used, and tagging those with a random session id and a persistent random pseudonym. E.g. "user 291281223233 used feature print_document in session 129871209182 ". But I guess some of the attraction of a package like GA is that you don't have to spend weeks instrumenting your app? But I can certainly see the problem if ANY urls are sent. And I can see how weak GA would be if by default NO urls, no IPs, no User agent string are sent. You'd need to add quite a few "user_visited_page('pagename')" to your site code...