Repository: getsentry/sentry

Issue:
Sentry storing IP address although it is disabled
- Sentry: 8.22.0
- Installation method: Docker
- Stacktrace / logs: n/a

Hi, I am using the symfony bundle `sentry/sentry-symfony` and a self-hosted version of sentry.
I disabled storing IP addresses:

![2018-06-07 at 19 11](https://user-images.githubusercontent.com/1032411/41115073-a57ae538-6a86-11e8-9572-6f81da426dd2.png)

but when sending a regular exception from symfony to sentry, the IP is still there:

![2018-06-07 at 19 12](https://user-images.githubusercontent.com/1032411/41115100-c1f71ef2-6a86-11e8-8f02-70de2f4567b7.png)

Is there something wrong in my configuration?


Thanks
Sentry storing IP address although it is disabled
- Sentry: 8.22.0
- Installation method: Docker
- Stacktrace / logs: n/a

Hi, I am using the symfony bundle `sentry/sentry-symfony` and a self-hosted version of sentry.
I disabled storing IP addresses:

![2018-06-07 at 19 11](https://user-images.githubusercontent.com/1032411/41115073-a57ae538-6a86-11e8-9572-6f81da426dd2.png)

but when sending a regular exception from symfony to sentry, the IP is still there:

![2018-06-07 at 19 12](https://user-images.githubusercontent.com/1032411/41115100-c1f71ef2-6a86-11e8-8f02-70de2f4567b7.png)

Is there something wrong in my configuration?


Thanks


Discussion:
FYI we're going to be changing this behavior.

1. Today we store the Client IP with events as a form of audit logging. It's only available to superusers. So this means you only see it on a self-hosted install if you're logged in as a superuser.
2. We're going to just remove this behavior when you select the "scrub IP addresses" option, as quite frankly GDPR is making a mess of our life and we dont have the energy to fight the cause.
If Sentry is going to remove the ability to scrub the IP address, it makes it no longer GDPR-compliant and therefore no longer usable for basically anyone in the EU and their customers.

Storing is some form of processing and in this case it doesn't matter whether only super users can access this information. If there's a breach, the hacker has access as well. The best thing is to simply not store it.

The GDPR is a good thing :) If it makes people's lives harder then it's also a good sign since some things basically *have* to change for the better (an enhanced data privacy).
@keichinger re-read what I said. We're going to make our scrubbing more extreme. Maybe I wasn't clear, but we're going to enforce scrubbing even the audit trail of client IPs (which is the SDK IP).

Additionally, *not* scrubbing the IP address has nothing to do with GDPR compliance, but it means you must explain to your customers that its being captured and for the reason. It's very easy to create a business purpose for this (and is a good reason IPs should **not** be PII, thanks for that EU), but it is still difficult for customers of our SaaS service as it requires publishing us.
Ah, sorry then. I read it like you were going to remove the possibility to scrub IPs and instead send them along side every request and only make them accessible for super users.

I'm not gonna comment on the second part :P It would only derail the topic since we have different opinions about this topic as it seem :)

Cheers though!
(also this change will make it into the 9.0 tagged release of Sentry)
Am I correct in understanding that this will be a purely server-side change or will it require any changes on the client side? (new SDK version, client code changes, etc.)
@jhaber server only -- you cant prevent this IP from the client side as its simply the IP the server sees (we call it the literal 'client IP', where the client is the device sending the event to Sentry)
@dcramer I am not sure I understand your comment.

In a JavaScript world, you obviously can't prevent Sentry from seeing the enduser IP, as the request originates from the enduser's device.
But my screenshot came from a PHP application. In the HTTP request, you will only receive the **server** IP, not the enduser IP. So that means, that the enduser IP is **actively forwarded** by the raven client to the sentry server.

Not sure, whether this is what @jhaber was hinting at, but this obviously can't happen in a GDPR world. :confused:
@apfelbox the conversation about if SDKs should send this value or not is a separate one. This is for the server rejecting ip data if SDKs submitted them.
FYI we're going to be changing this behavior.

1. Today we store the Client IP with events as a form of audit logging. It's only available to superusers. So this means you only see it on a self-hosted install if you're logged in as a superuser.
2. We're going to just remove this behavior when you select the "scrub IP addresses" option, as quite frankly GDPR is making a mess of our life and we dont have the energy to fight the cause.
If Sentry is going to remove the ability to scrub the IP address, it makes it no longer GDPR-compliant and therefore no longer usable for basically anyone in the EU and their customers.

Storing is some form of processing and in this case it doesn't matter whether only super users can access this information. If there's a breach, the hacker has access as well. The best thing is to simply not store it.

The GDPR is a good thing :) If it makes people's lives harder then it's also a good sign since some things basically *have* to change for the better (an enhanced data privacy).
@keichinger re-read what I said. We're going to make our scrubbing more extreme. Maybe I wasn't clear, but we're going to enforce scrubbing even the audit trail of client IPs (which is the SDK IP).

Additionally, *not* scrubbing the IP address has nothing to do with GDPR compliance, but it means you must explain to your customers that its being captured and for the reason. It's very easy to create a business purpose for this (and is a good reason IPs should **not** be PII, thanks for that EU), but it is still difficult for customers of our SaaS service as it requires publishing us.
Ah, sorry then. I read it like you were going to remove the possibility to scrub IPs and instead send them along side every request and only make them accessible for super users.

I'm not gonna comment on the second part :P It would only derail the topic since we have different opinions about this topic as it seem :)

Cheers though!
(also this change will make it into the 9.0 tagged release of Sentry)
Am I correct in understanding that this will be a purely server-side change or will it require any changes on the client side? (new SDK version, client code changes, etc.)
@jhaber server only -- you cant prevent this IP from the client side as its simply the IP the server sees (we call it the literal 'client IP', where the client is the device sending the event to Sentry)
@dcramer I am not sure I understand your comment.

In a JavaScript world, you obviously can't prevent Sentry from seeing the enduser IP, as the request originates from the enduser's device.
But my screenshot came from a PHP application. In the HTTP request, you will only receive the **server** IP, not the enduser IP. So that means, that the enduser IP is **actively forwarded** by the raven client to the sentry server.

Not sure, whether this is what @jhaber was hinting at, but this obviously can't happen in a GDPR world. :confused:
@apfelbox the conversation about if SDKs should send this value or not is a separate one. This is for the server rejecting ip data if SDKs submitted them.

Resolving patch:
diff --git a/src/sentry/coreapi.py b/src/sentry/coreapi.py
--- a/src/sentry/coreapi.py
+++ b/src/sentry/coreapi.py
@@ -344,6 +344,9 @@ def ensure_does_not_have_ip(self, data):
         if 'sentry.interfaces.User' in data:
             data['sentry.interfaces.User'].pop('ip_address', None)
 
+        if 'sdk' in data:
+            data['sdk'].pop('client_ip', None)
+
     def insert_data_to_database(self, data, start_time=None, from_reprocessing=False):
         if start_time is None:
             start_time = time()


Test patch:
diff --git a/tests/sentry/web/api/tests.py b/tests/sentry/web/api/tests.py
--- a/tests/sentry/web/api/tests.py
+++ b/tests/sentry/web/api/tests.py
@@ -397,6 +397,11 @@ def test_scrubs_ip_address(self, mock_insert_data_to_database):
         self.project.update_option('sentry:scrub_ip_address', True)
         body = {
             "message": "foo bar",
+            "sdk": {
+                "name": "sentry-browser",
+                "version": "3.23.3",
+                "client_ip": "127.0.0.1"
+            },
             "sentry.interfaces.User": {
                 "ip_address": "127.0.0.1"
             },
@@ -414,6 +419,7 @@ def test_scrubs_ip_address(self, mock_insert_data_to_database):
         call_data = mock_insert_data_to_database.call_args[0][0]
         assert not call_data['sentry.interfaces.User'].get('ip_address')
         assert not call_data['sentry.interfaces.Http']['env'].get('REMOTE_ADDR')
+        assert not call_data['sdk'].get('client_ip')
 
     @mock.patch('sentry.coreapi.ClientApiHelper.insert_data_to_database')
     def test_scrubs_org_ip_address_override(self, mock_insert_data_to_database):