Devise: Support for GDPR

[melsatar]

Do you have any plans to support GDPR? or how we can support that using the current setup

[fakenine]

I've been wondering about this too. An option to opt out the fields that are personal data when installing devise would be nice. i.e: rails generate devise:install --gdpr true would

• remove the IP address field in the migration and the ones used to track the signin ?

[rafaelfranca]

Devise is a generic authentication solution and has no plan or need to change to conform specific legislations of countries/states. That is under the responsibilities of the applications since it is their that have the context about which information is being stored.

[fakenine]

GDPR is not a specific legislation of one or few countries/states. It concerns you as soon as you have users that are citizens of an European country (there are around 353 million internet users in Europe).

Even if you are in the US and have a little app, with one EU user, you are concerned by GDPR.

GDPR is complicated to understand, even more for junior developers/developers that build their first app. It would be a shame to have legal issues just because you left something like the tracking/registering of the user IP address in your app when installing devise.

Actually, I think we should build and have privacy-by-default tools, in order to build and have privacy-by-default apps.

Why not remove those sensitive fields (IP address, signin count ?) in the default devise generator (unlike what I said previously) ? If someone really needs them, they can add them via some option.

We can't just say "Oh, there's some new law that concerns everyone, it is very complicated and will change the way you develop applications. But we won't help you with that."

[rafaelfranca]

Why not remove those sensitive fields (IP address, signin count ?) in the default devise generator (unlike what I said previously) ?

I think that is a good compromise. If you want to do it please open a PR, but I don't think we should include an option and implement code specifically for gdpr.

[melsatar]

It is important to include that in the future release and this should be soon. All service providers around the world started to align with GDPR. As @fakenine mentioned it is not like any specific legislation for a specific country.

I hope if you can reconsider this again.

[rafaelfranca]

I just did in the comment above and I'm asking for help to implement. Just to be clear, can someone send a PR with the required changes? We will make it the new default.

[fakenine]

@rafaelfranca Thank you! I will look into this this week.

[mrsweaters]

@fakenine Would this also require encrypting the email address?

[melsatar]

Yes, and also hiding all personal data from logs and sessions, also a way to anonymize the user if the data is backed up. for example, if you take a backup from production to staging or development environment the users' data should be anonymized hashed for example.

Also, a method to export all data related to the user, and delete all users records as well

[fakenine]

I think it should be done step by step, at least removing the IP address first as it is considered as sensitive/personal data, stored by default but not used by everyone.

I don't think Devise should encrypt the email by default. It could affect performance on most apps as you would need to decrypt the email field each time you need to read it (like in a User Profile page, or an Admin Dashboard listing users for instance). What do you think?

[...] and also hiding all personal data from logs and sessions, also a way to anonymize the user if the data is backed up. for example, if you take a backup from production to staging or development environment the users' data should be anonymized hashed for example.

I think we are out of the scope of devise for this. Rails already has a way to do that via Rails.application.config.filter_parameters and you can add as many fields as you want (password is present by default).

Same thing for the export. Devise does not handle exporting/importing data from the users table. This should be implemented by the app developer on their platform, regarding what they use to export/import (like a CSV export via ActiveAdmin for instance).

[melsatar]

@fakenine I agree, part of this is out of device scope, but I think encrypting the email will be good to have at data model level but it can be default decrypted at views level. Also, this can be optional so if it affects the performance you can disable it.

[melsatar]

I think it is important to keep IP address for detecting the malicious attacks, and it can be used in other features.

[fakenine]

I think it is important to keep IP address for detecting the malicious attacks, and it can be used in other features.

I understand. What I meant was to remove the :trackable option from the default generator. That's the option that allows the app developer to track different things from the user (like sign in IP). I will submit a PR for this.

[mrsweaters]

For the IP address, can't you anonymize the ip instead? Zero the last octet of ipv4 and keep the first half of ipv6 address?

[tegon]

Closed via #4857

[metalelf0]

If you still want to track sessions, but not IPs, the easiest way I've found is to simply override the IP related methods on your resource (e.g. User):

  def current_sign_in_ip; end
  def last_sign_in_ip=(_ip); end
  def current_sign_in_ip=(_ip); end

This will allow enabling the :trackable module without any IP being saved.

[mattboldt]

I like @metalelf0's idea here. Could trackable be modified to exclude IP, but keep the sign in count & date?