[GDPR compliance] No way to disable sentry and segment tracking

[aeris]

Expected Behavior

Currently, Insomnia is full of tracking with Segment and Sentry call pretty everywhere in the code base.
Mostly any action from the user is tracked, down to very precise details like how you merged you conflict

Such tracking is purely unlawful in Europe because GDPR and there must be at least a way to totally disable such feature
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

Actual Behavior

I'm tracked for pretty any action I realize inside Insomnia

Reproduction Steps

1. Go to source code folder
2. grep -r trackSegmentEvent

Is there an existing issue for this?

• I have searched the issue tracker for this problem.

Additional Information

No response

Insomnia Version

9.3.2

What operating system are you using?

Other Linux

Operating System Version

Arch

Installation method

yay -S insomnia

Last Known Working Insomnia version

No response

[aeris]

Some Sentry tracking are very dangerous
Invalid JSON ? All the data is possibly uploaded to Sentry, including sensible data…

[mxmlnglt]

This is insane... 🤯

[subnetmarco]

Invalid JSON ? All the data is possibly uploaded to Sentry, including sensible data…

This is incorrect, we are not logging request and response data, as you can see above we are logging the error stack trace within the application that does not include request/response data. We are collecting stack traces so that we can improve the reliability of the application with bug fixes.

For example, the following code will generate a stringify exception, as you can see the error does not include sensitive data:

const obj = {};
obj.hello = "world";
obj.secret = "this is an api key";
obj.circular = obj;

try {
  JSON.stringify(obj)
} catch (error) {
  console.log(error);
}

The error would look like:

TypeError: Converting circular structure to JSON
    --> starting at object with constructor 'Object'
    --- property 'circular' closes the circle
    at JSON.stringify (<anonymous>)
    at Object.<anonymous> (/private/tmp/test2.js:7:8)
    at Module._compile (node:internal/modules/cjs/loader:1368:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1426:10)
    at Module.load (node:internal/modules/cjs/loader:1205:32)
    at Module._load (node:internal/modules/cjs/loader:1021:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:142:12)
    at node:internal/main/run_main_module:28:49

[aeris]

But you don't console.log(error) in your code but captureStackTrace.
Sentry generate a full stack debug entry, which doing introspection and debug processing, possibly including pretty any variable you have on your code at this point…

[subnetmarco]

@aeris yes, but Sentry would show the public code of the ensureStringify function where the error has occurred, which doesn't include the actual contents of the variables, only the publicly visible source code of where the error has occurred for debugging purposes. Therefore the user request/response data is not logged (and there would be no reason for us to do so).

Now with that said, I am asking the team to review all the Sentry instructions. These have been there for a long time and some of them predate my direct engineering involvement into the project, so we are going to remove the unnecessary ones.

[subnetmarco]

For users of the desktop Insomnia app, we do not collect personal data about users, and the analytics does not contain any personal data. So, GDPR is not applicable. For users with an Insomnia account, the analytics similarly does not contain personal data, and the personal data we collect for purposes of the Insomnia account is subject to our privacy policy and terms of service, which we believe comply with GDPR.

We just announced Insomnia 9.3.3 GA which removes that unnecessary Sentry logging in the ensureStringify function.

We are currently tracking application usage - like how merge conflicts are being resolved - because we are about to revamp the Git collaboration flows in the application and this allows us to understand how you - the user of Insomnia - use the product so that we can build features that don't disrupt your workflow. This is standard industry practice and at the core of being able to make data-driven decisions.

[aeris]

we do not collect personal data about users, and the analytics does not contain any personal data. So, GDPR is not applicable

GDPR is not only collecting PII but processing PII. And processing PII includes transmitting PII.
Just creating a TCP connection to send data to Sentry and Segment IS sending PII (because TCP/IP transmit IP address) and covered by GDPR, and exactly the trouble of US providers given Schrems II CJUE case forbiden ALL transfer to US provider.

https://gdprhub.eu/index.php?title=DSB_(Austria)_-_2021-0.586.257

the website had transferred the data subject's personal data to Google LLC on 14.08.2020, including user identifiers, IP address and browser parameters;

https://gdprhub.eu/index.php?title=AEPD_(Spain)_-_EXP202306257

His IP address and cookies information were collected and transferred to Google U.S. through the services of Google Analytics and Google Ads, contractualized by eDreams.

https://gdprhub.eu/index.php?title=LG_M%C3%BCnchen_-_3_O_17493/20

The Regional Court of Munich awarded a data subject €100 in damages after a controller unlawfully transferred their IP address to Google LLC via the use of Google Fonts.

This is not because you don't understand the concept behind PII that you don't process PII.
PII is ANY information related to a person. IP address. Screen resolution. User agent. OS used. Event occured in Insomnia.
Whatever you send to Segment IS PII.

[aeris]

This is standard industry practice and at the core of being able to make data-driven decisions.

And so yes, the standard industry practice is just totally unlawful in Europe.
"Improve services" is currently very touchy given the EDPB and WP29 guidelines and is more covered by consent (so opt-in) and not legitimate interest (and so, opt-out). And in all case, it MUST have a way to disable it.
It's just totally forbidden to force such feature without a way to disabling it somewhere, because "necessary for contract" is rejected

EDPB, 2/2019, Processing for ‘service improvement’
https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines-art_6-1-b-adopted_after_public_consultation_en.pdf

Online services often collect detailed information on how users engage with their service. In most
cases, collection of organisational metrics relating to a service or details of user engagement, cannot
be regarded as necessary for the provision of the service as the service could be delivered in the
absence of processing such personal data. Nevertheless, a service provider may be able to rely on
alternative lawful bases for this processing, such as legitimate interest or consent

[subnetmarco]

An update here:

• We are not storing personal data, even the gray area of storing IP addresses and user IDs has been removed:

  • chore: rm userId from sentry [INS-4260] #7804
  • chore: hash userID on segment [INS-4260] #7805

• We don't store the IP addresses in Sentry or Segment:
  

• We offer a way to disable the metrics by using the product without having to create an account (the Scratch Pad).

• By creating an account you are accepting our terms of service and privacy policies that disclose our data processors.

• Because we are not communicating/storing any personal data and it's impossible for us to identify a person or company with the data, I believe we are outside of the scope of GDPR, EDPB and WP29.

  • The European Data Protection Board (EDPB) and the Article 29 Working Party (WP29) provide guidelines and recommendations on interpreting GDPR. If our activities do not involve personal data, we believe to be generally outside the scope of their guidelines.

• Sentry itself most likely stores the IP addresses for compliance, security and abuse prevention, which falls under the lawful basis for processing under GDPR.

[aeris]

Once again, GDPR is not only collecting/storing PII but processing PII. Transmitting PII is such processing.

https://github.com/Kong/insomnia/blob/develop/packages/insomnia/src/main/sentry.ts#L16

insomnia/packages/insomnia/src/main/analytics.ts

Line 74 in 0915d4d

const allowAnalytics = settings.enableAnalytics || userSession?.hashedAccountId;

Opt-in/out is not active if user is logged in. This is a GDPR violation.

By creating an account you are accepting our terms of service and privacy policies that disclose our data processors.

This is a pure GDPR infringment. EDPB 2/2019, point 48

Online services often collect detailed information on how users engage with their service. In most
cases, collection of organisational metrics relating to a service or details of user engagement, cannot
be regarded as necessary for the provision of the service as the service could be delivered in the
absence of processing such personal data. Nevertheless, a service provider may be able to rely on
alternative lawful bases for this processing, such as legitimate interest or consent.

So ToS are NOT a lawfull basis for such Sentry/Segment processing. You have to rely only on legitimate interest, most probably only on consent (you can't pass the triple test legimitate interest, because this processing is not necessary in all case, so 2nd test is KO in all cases).

it's impossible for us to identify a person or company with the data

Totally wrong position. From EUCJ decision (EUCJ, C-582/14, Breyer, 19 October 2016, point 43), identification must be considered not only from YOUR point of view, but from any other way to identify the data. So you, Segment, Sentry, Segment/Sentry subcontractor (Google & Amazon), any law enforcement, data leak reprocessing with other public database, etc.

43 In so far as that recital refers to the means likely reasonably to be used by both the controller and by ‘any other person’, its wording suggests that, for information to be treated as ‘personal data’ within the meaning of Article 2(a) of that directive, it is not required that all the information enabling the identification of the data subject must be in the hands of one person.

And identification must not only be for real civil identity, the only fact it can be assign to a single people is enough. Data must be robust to individualization, correlation and inference to be real anonymous data. If not, there are PII.

Sentry itself most likely stores the IP addresses for compliance, security and abuse prevention, which falls under the lawful basis for processing under GDPR.

Totally not. Same EDPB 2/2019, point 50

As WP29 has previously noted,26 processing for fraud prevention purposes may involve monitoring and
profiling customers. In the view of the EDPB, such processing is likely to go beyond what is objectively
necessary for the performance of a contract with a data subject. However, the processing of personal
data strictly necessary for the purposes of preventing fraud may constitute a legitimate interest of the
data controller27 and could thus be considered lawful, if the specific requirements of Article
6(1)(f)(legitimate interests) are met by the data controller

So once again, ToS are NOT a lawfull basis, and in such case legitimate interest are NOT valid, don't pass triple test and so requirements are NOT met.

In all cases, using Segment and Sentry is a violation of CJUE Schrems II, and even if there is DPF after that since july 2023, currently there is FISA 502b, H.R. 7888 RISAA and other US legal text, and so US providers as NOT lawfull in Europe.

Your posts just proof you have just no idea at all about GDPR.

[aeris]

Spoiler : all those information are NOT anonymous, and so are PII

[subnetmarco]

Update: We are currently looking into this with our lawyers.

Spoiler : all those information are NOT anonymous, and so are PII

The user ID has been removed in the PRs I linked earlier, this will go into action starting from the next release.