3 ms·

Generally I like what noyb does, but I dislike how advertisement and product analytics seem to be thrown into the same basket. There are third-party companies l

Generally I like what noyb does, but I dislike how advertisement and product analytics seem to be thrown into the same basket. There are third-party companies like Mixpanel and Amplitude that you can send your users' data to, but they will only process it for you, and not for anyone else. Same with third-party companies like RevenueCat that help you with implementing in-app purchases. Very different situation than sending data to Google or Facebook who will then use it for everything they do. Not all third-parties are the same.

Nextgrid 3y ago
The objective of the GDPR is to give the data subject better control over how their data is used. Maybe the user doesn't want you to stalk them for analytics or "product improvement" (biggest tech industry lie of the past decade), regardless of whether other third-parties also get in on the action?
- sixstringtheory 3y ago
  I hardly think something like a crash report diagnostic is stalking, though. Maybe you could make the case for transaction conversion funnels. That’s really a case by case basis for which analytics provider is being used and how the product owners consume them.
  - uoaei 3y ago
    If your crash report service is reporting personal data, then your crash report service is written incorrectly from the perspective of respecting user privacy.
    - sixstringtheory 3y ago
      I’ve developed crash reporters for years now. The only way personal information is making its way into crash reports is if the app developers put it there. Otherwise it’s function names, the OS version, binary images that were loaded into the app, the time it happened. Certain termination reports do contain small memory dumps and/or register values, so theoretically could could contain decodable PII. This is something the OS vendor provides, not the developer of the app or the crash reporter.
      - uoaei 3y ago
        I didn't mean to make it seem like I'm calling you out specifically, just thought it worth clarifying that there's no a priori reason that PII should be included in a crash report. Sounds like we agree.
        earthnail 3y ago
        Crash reports often include pseudonymous information, like device type, OS version etc., that help you understand the environment your crash occurred in. They also very often include identifiers that aren't personal, but allow you to understand whether this crash that happened 100 times happened for 100 users or just 100 times for the same user all over. That's very important information to have when debugging. The verdict is still out in many legal jurisdictions on whether such pseudonymous information is private enough. The classic example is IP addresses. Pseudonymous information always has a high risk of being abused for fingerprinting and thus denonymising. I feel that there needs to be a trade-off though: on public datasets, people should be very careful with pseudonymous identifiers. On things like crash diagnostics that are never meant to be shared I feel they're perfectly fine. That's why I dislike a general discussion where all PII is bad and evil without context.
        sixstringtheory 3y ago
        Absolutely agree! I’ve pushed back in the past when more analytics-type data was being considered. It can definitely be done anonymously and I believe users should always be given transparent options.
- jamil7 3y ago
  > or "product improvement" (biggest tech industry lie of the past decade) Do you mean monitoring and analytics in general don't improve products? Or that "product improvement" is a commonly used excuse to harvest user data?
- earthnail 3y ago
  My stance is that by grouping all of them into the same bucket, we stop differentiating. And asking average users to make an informed, differentiated decision on a topic as complex as this feels wrong.
iamacyborg 3y ago
> There are third-party companies like Mixpanel and Amplitude that you can send your users' data to, but they will only process it for you, and not for anyone else. These tools are increasingly developing new features that allow them to act more like a "CDP", essentially allowing you to send data from the tool to something else. Want to send data from Amplitude to Facebook? That's easy https://amplitude.com/blog/amplitude-customer-data-platform https://amplitude.com/blog/amplitude-customer-data-platform

Nextgrid 3y ago

The objective of the GDPR is to give the data subject better control over how their data is used. Maybe the user doesn't want you to stalk them for analytics or "product improvement" (biggest tech industry lie of the past decade), regardless of whether other third-parties also get in on the action?

sixstringtheory 3y ago
I hardly think something like a crash report diagnostic is stalking, though. Maybe you could make the case for transaction conversion funnels. That’s really a case by case basis for which analytics provider is being used and how the product owners consume them.
- uoaei 3y ago
  If your crash report service is reporting personal data, then your crash report service is written incorrectly from the perspective of respecting user privacy.
  - sixstringtheory 3y ago
    I’ve developed crash reporters for years now. The only way personal information is making its way into crash reports is if the app developers put it there. Otherwise it’s function names, the OS version, binary images that were loaded into the app, the time it happened. Certain termination reports do contain small memory dumps and/or register values, so theoretically could could contain decodable PII. This is something the OS vendor provides, not the developer of the app or the crash reporter.
    - uoaei 3y ago
      I didn't mean to make it seem like I'm calling you out specifically, just thought it worth clarifying that there's no a priori reason that PII should be included in a crash report. Sounds like we agree.
      - earthnail 3y ago
        Crash reports often include pseudonymous information, like device type, OS version etc., that help you understand the environment your crash occurred in. They also very often include identifiers that aren't personal, but allow you to understand whether this crash that happened 100 times happened for 100 users or just 100 times for the same user all over. That's very important information to have when debugging. The verdict is still out in many legal jurisdictions on whether such pseudonymous information is private enough. The classic example is IP addresses. Pseudonymous information always has a high risk of being abused for fingerprinting and thus denonymising. I feel that there needs to be a trade-off though: on public datasets, people should be very careful with pseudonymous identifiers. On things like crash diagnostics that are never meant to be shared I feel they're perfectly fine. That's why I dislike a general discussion where all PII is bad and evil without context.
      - sixstringtheory 3y ago
        Absolutely agree! I’ve pushed back in the past when more analytics-type data was being considered. It can definitely be done anonymously and I believe users should always be given transparent options.
jamil7 3y ago
> or "product improvement" (biggest tech industry lie of the past decade) Do you mean monitoring and analytics in general don't improve products? Or that "product improvement" is a commonly used excuse to harvest user data?
earthnail 3y ago
My stance is that by grouping all of them into the same bucket, we stop differentiating. And asking average users to make an informed, differentiated decision on a topic as complex as this feels wrong.

iamacyborg 3y ago

> There are third-party companies like Mixpanel and Amplitude that you can send your users' data to, but they will only process it for you, and not for anyone else. These tools are increasingly developing new features that allow them to act more like a "CDP", essentially allowing you to send data from the tool to something else. Want to send data from Amplitude to Facebook? That's easy https://amplitude.com/blog/amplitude-customer-data-platform https://amplitude.com/blog/amplitude-customer-data-platform