Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Privacy option: Disable storage of IP addresses #6474

Open
mastuser opened this issue Feb 14, 2018 · 17 comments

Comments

@mastuser
Copy link

commented Feb 14, 2018

Mastodon appears to log the full user IP addresses (last address in use).

In order to comply with German privacy law and to allow for anonymous use by activists, could you please create an option to disable the storage of IP addresses (possibly making it default)?

Privacy is why many people decide to use Mastodon over Twitter. We wouldn't want a case like this.


  • I searched or browsed the repo’s other issues to ensure this is not a duplicate.
  • This bug happens on a tagged release and not on master (If you're a user, don't worry about this).
@Openmedianetwork

This comment has been minimized.

Copy link

commented Feb 15, 2018

nice to have an option to keep it for a set time as well as not save it at all.

@bortzmeyer

This comment has been minimized.

Copy link

commented Feb 16, 2018

A case of the police asking data from a Mastodon instance is http://www.laquadrature.net/en/node/10335 (in french only)

@bortzmeyer

This comment has been minimized.

Copy link

commented Feb 16, 2018

Another possibility would be to retain only a prefix (of configurable length) of the IP address. Many programs allow to do so, such as the Web cache Squid.

@Miaourt

This comment has been minimized.

Copy link
Contributor

commented Feb 16, 2018

Keeping a prefix would be a cool compromise :o
It's useful if we want to quickly check for people making multiple accounts in order to harass 😕

@hellekin

This comment has been minimized.

Copy link

commented Feb 16, 2018

People who want to harass on the Web know how to use VPNs or botnets.

@Miaourt

This comment has been minimized.

Copy link
Contributor

commented Feb 16, 2018

So let go those who aren't?
IP prefix isn't legally able to inculpate someone of something, it just help modération :/

@hellekin

This comment has been minimized.

Copy link

commented Feb 16, 2018

Well, theoretically...

@mastuser

This comment has been minimized.

Copy link
Author

commented Feb 16, 2018

If you choose to implement anonymization by truncation of IP addresses, please note that for effective anonymization, German DPAs require

  • truncation of the last 2 Byte of IPv4 addresses
  • truncation of the last 12 Byte of IPv6 addresses
@bortzmeyer bortzmeyer referenced this issue May 2, 2018
2 of 2 tasks complete
@bortzmeyer

This comment has been minimized.

Copy link

commented May 2, 2018

Also, it is not just a matter of law (and the label "legal" is misleading). Above all, it is a political issue: do we want to protect the privacy of the users?

@mastuser

This comment has been minimized.

Copy link
Author

commented Jul 11, 2018

As has been pointed out in the thread linked above, logging IP addresses for 12 months (ip_cleanup_scheduler.rb) is not GDPR compliant (and also politically dangerous for activists). Activists using anonymous accounts require services that do not log IP addresses.

I am not sure how to disable the storage of IP addresses altogether. Having ip_cleanup_scheduler.rb clean up ip addresses every time and with no delay would still not prevent them from being stored for a certain amount of time. Also the current_sign_in_ip would still be stored. Maybe removing :trackable from user.rb altogether would work?

I am also not sure whether there is a time limit on IP logging in the session_activations table.

@rixx

This comment has been minimized.

Copy link

commented Jul 11, 2018

Okay, so as far as I can tell, Mastodon keeps only the current and last used IP address, which is already much better than a full log.

Furthermore, Mastodon doesn't seem to use those addresses at all – my current workaround of just plain update users set last_sign_in_ip=null current_sign_in_ip=null doesn't seem to have any negative impact. (Yes, this is not a solution at all, but when used via cronjob it's better than not doing anything to mitigate the situation.)

@Gargron Gargron added suggestion and removed enhancement labels Oct 20, 2018

@ThomasLeister

This comment has been minimized.

Copy link
Contributor

commented Oct 29, 2018

Me and many other Mastodon admins would very much appreciate if there was an easy way to disable IP address logging / storing. :-)

Also see: [German]: Mastodon: Datenschutz und Sicherheit verbesserungsfähig

@Perflyst

This comment has been minimized.

Copy link

commented Feb 5, 2019

update users set last_sign_in_ip=null current_sign_in_ip=null

Is this still working? Running this via bin/update does not remove IP addresses shown in users security settings.

@rixx

This comment has been minimized.

Copy link

commented Feb 5, 2019

This is an SQL query, not something to be run with bin/update. As it touches the database, please do not just replicate this without understanding what it does.
The complete command to be run as the postgres user is /usr/bin/psql mastodon -c "update users set current_sign_in_ip=null, last_sign_in_ip=null; update session_activations set ip=null;"

@Perflyst

This comment has been minimized.

Copy link

commented Feb 7, 2019

Why do we not just remove the x-real-ip or x-forwarded-for (nginx or apache) in the vhost? This would disable all IP storing, or am I wrong?

@rixx

This comment has been minimized.

Copy link

commented Feb 7, 2019

We'll switch to that option soon – we did not consider it at first because we weren't sure what else might break when removing IP addresses entirely (from caches, etc). Since other administrators have chosen this option, it is now clear that it is safe to do.

@ichi-i

This comment has been minimized.

Copy link
Contributor

commented Aug 27, 2019

Any news on this?

@rixx have you made that change then?
Did you simply remove these lines:

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

from the vhost? Was anything else necessary?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.