Changes between Version 7 and Version 8 of RightToErasure
- Timestamp:
- Apr 9, 2018, 2:02:09 PM (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
RightToErasure
v7 v8 1 1 = Right to Erasure = 2 2 The [https://en.wikipedia.org/wiki/General_Data_Protection_Regulation European GDPR law] provides for a "Right to Erasure". An interpretation of this law is that it gives users the right to have all of their data stored in an electronic system deleted from that system if they request it. This proposal exists as an attempt to satisfy that requirement of the GDPR law. 3 4 There will be a feature flag that must be enabled in order for this feature to be available on a project website. The feature flag will control the display of the link to the /request_delete_account.php page and it will prevent the use of /request_delete_account.php unless the flag as been enabled. 3 5 4 6 == User Experience == … … 134 136 135 137 === confirm_delete_account_action.php === 136 On the confirm_delete_account.php page, then token should be included as a hidden field. The confirm_delete_account_action.php page that receives the request should validate both the users password and the users token before processing. Only if both are valid should this occur. If they are both valid, then the user .delete_request_time will be set to unix_timestamp().138 On the confirm_delete_account.php page, then token should be included as a hidden field. The confirm_delete_account_action.php page that receives the request should validate both the users password and the users token before processing. Only if both are valid should this occur. If they are both valid, then the user account will be deleted based on the logic below. 137 139 138 140 139 === delete_account. php===140 The delete of the account is final and is not recoverable in anyway. Th e delete_account.php script would be a script that runs once a day that seeks user records that have a value of delete_request_time < unix_timestamp() - 24*3600 and delete_request_time > 0 (in case for some reason a 0 gets inserted instead of null).141 === delete_account.inc === 142 The delete of the account is final and is not recoverable in anyway. This process is designed so that projects can customize what happens when an account deleted. There will be two options implemented and the projects will be able to customize this to meet their needs. A configuration option will be available to choose which method to use. The default will be the 'data anonymization' approach. 141 143 144 ==== data anonymization ==== 145 146 ==== full delete ==== 142 147 For each user identified, the delete_account.php will consist of the following actions: 143 148 * An entry will be inserted into the user_deleted table … … 176 181 * user_submit_app - don't know what to do with these 177 182 178 === Final Removal 183 184 === Final Removal === 179 185 A script that runs once a day will be developed that removes entries from the user_deleted and host_deleted tables when create_time indicates that they are over 60 days old. This provides sufficient time for consumers of the data export to receive notification of the deletion and to remove the data from their system.
