View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 5583 | Composr | core_privacy | public | 2024-01-30 17:36 | 2024-08-09 05:50 |
| Reporter | PDStig | Assigned To | PDStig | ||
| Priority | normal | Severity | feature | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 5583: Allow downloading or purging of data from user profile | ||||
| Description | Ever since 5555 was completed, we can reasonably be confident now that the privacy system will cooperate and ensure that data from other users will not be leaked or modified. As such, we should allow users the basic ability to download or purge their data from their profile: The UI will be simplistic. Instead of presenting every database table, it will present based on hooks. There will be one tick per hook. Users tick which groups of tables they want to take action on. And at the bottom is a button to either download or purge. Every tick box is UNticked by default; we want members to explicitly tick them so they acknowledge those groups of data are actually what they want action for. Add a new property to modify_table_details (boolean $user_executed; true if the user executed the action). Then in core_cns, use modify_table_details to modify how we purge f_members if a member executed it: - f_members should be anonymised, not deleted. Add this as an allowed method, but leave at delete for the default. - Remove id, password fields, e-mail codes, etc from the list of fields to anonymise so the member doesn't get locked out of their account Purging runs default_handle_method. * Every privacy hook gets 2 new properties in info() (these are root properties, not ones on the database tables): - label: The hook label, which will show up as a label on the user's profile as tick boxes - description: A description for the privacy hook, namely to briefly describe to the user what kind of data exists within this hook / group Use the task queue when possible just like always. Also, add a new config option for specifying the number of days a user must wait before they can either download or purge their data again (probably should be a separate option for each). Defaults to 7 on both. Can be set to a negative number to completely disable a user's ability to perform that action (say if you want to require contacting staff, or if you want to require payment through the ecommerce system to do it). | ||||
| Additional Information | This is development I'd personally like to see in Composr; I'll be providing it unmetered / unpaid myself. | ||||
| Tags | Roadmap: v11, Type: Legal compliance / Privacy | ||||
| Attach Tags | |||||
| Time estimation (hours) | |||||
| Sponsorship open | |||||
|
|
Note: This interface should not present a form but rather a link to the Admin Zone privacy module if an admin/mod is viewing it (link should auto-fill member ID and username). |
|
|
I decided privacy purge days should be -1 (disabled) by default; normally we would want users to be required to contact staff directly to purge their data (or to do so while also deleting their account). But download days defaults to 7. |
|
|
This scares me a bit. Can't we default downloading to -1 too? I am worried it is very easy to have an oversight where data associated with a user is actually staff-privileged in some way. Especially in the case of addons or code customisations that might be created. |
|
|
Can you define "staff privileged" for me? And why wouldn't a user not have a right to download that data about them? |
|
|
Well there are any number of examples, this is one... Imagine an HR employee submitted a staff guide as a download, and then subsequently lost access to it (via usergroup permissions) because they changed department, and then someone else edited the description to provide something that only active people working in the HR department should see. That would get released via the automated download process, right? |
|
|
If they were still marked as the owner of said content in the metadata, yes. Perhaps we should add privilege checking on the privacy downloads system. |
|
|
That's just one example though. Another example might be private notes about a user on the warnings system somehow, that they don't want the user to see. GDPR and similar laws don't apply in all jurisdictions, and there are tradeoffs involved. I'd rather the defaults be conservative in the sense they meet GDPR, but with a little extra staff effort being needed. Staff can always turn automatic on if it is burdensome to them. I think in reality very few will actually download personal data. |
|
|
On one hand I'd argue that if a staff member has information about a user, that user should have the right to that information. But on another hand, one could argue a "warning" is actually owned by the staff member issuing it, not the member being warned. Right now, the privacy system has it that warnings belong to the member who was warned but perhaps that should be changed to the issuing staff member. If that change was made, it would fix the above issue as sensitive info not owned by the member is anonymised / excluded. |
|
|
My point is I can keep coming up with examples. These can't be treated as individual edge cases, as there are any number of them. What if some data associated with a user is copyrighted, or is sanctioned to not be released without a court order, or some kind of classified military material, or subject to export regulations. I don't think we can be making assumptions. |
|
|
I can default it to -1 but I think we should think of an alternate fix, perhaps some setting that allows a piece of content to bypass the privacy system for whatever reason. And adding privilege / access checking. Many platforms allow users to download their data via a UI. I think Composr should be no exception (and it should be the default) especially given data rights legislation popping up everywhere. Granted, I don't know if by submitting your request through a platform's UI that you are actually triggering an automatic process or if a human puts together the data for you (usually there's a delay, often days, before you get your data e-mailed to you). But point is there's a UI for it. |
|
|
I think the fundamental assumption here that anything in a content row originally added by a user X should always be accessible by user X is fundamentally unsound. There could be fields that only more privileged users can edit, that contain non-personal data that should not be released. There could be any number of things that we would never think to check for, which is why I intentionally didn't make export something a user could do themselves directly I don't think individually specifying stuff to not be auto-exportable will cut it - it's too burdensome and people will simply forget to set that correctly. It may also be the case that some sites would want that set always, making it kind of pointless. I don't agree with the assertion that data rights legislation means we need to have things perfectly automated. Just because a user has a right, doesn't mean that staff can't manually process stuff. Look at FOIA requests for example, they are burdensome to execute and take a long time (maybe even years), and often come back heavily redacted. The manual processing may not just be necessary in terms of having a human eye things over, but it may also be less costly than setting metadata given how rare I think anyone would actually be making these requests. You could just make it so that if the value is -1 it automatically creates a support ticket. |
|
|
If it's a site admin's responsibility to go through and understand the settings of Composr (especially COPPA / legal) and set them as necessary and appropriate, I think it should also be their responsibility (and therefore negates the too burdensome argument) to properly mark custom / catalogue fields that are sensitive, as it too falls within legal compliance (since it controls how the privacy system works). It's on the UI and clearly visible to them (I also documented it). And it only has to be done when adding / editing fields, not upon adding content. I don't see, except for two cases (staff notes and custom / catalogue fields, both of which can be controlled in the privacy system), how privileged fields can exist on content which potentially should never be disclosed to the user who added the content. Correct me if I'm wrong on that. How about this... * On -1, the UI creates (or redirects to the creation of) a Support Ticket for requesting the downloading or purging of data. * I document the nuances of allowing users to purge / download their data with catalogue fields. * I leave the rest of this issue up for sponsorship; if anyone wants proper catalogue field handling in the privacy system, they can sponsor the issue. It's too complex for me to implement alone, and I interpret our discussion as it is not worthwhile to code. * While I still don't agree defaulting downloads to -1, I'll do it on the principle it is an incomplete feature with nuances that must be considered. |
|
|
Realistically: - Most people are not going to read documentation unless they have a clear problem - Most people are not going to scour over the whole UI when creating their first Composr site, and will be unaware of the feature - Most people do not have time to consider the detailed ramifications of this, almost every organization is understaffed, undertrained, and over-stretched Any talk about compliance really depends on the legal environment where they are. Expectations in say China are wholly different from say the EU. Trying to impose EU standards on the rest of the world isn't really appropriate; differences in law are actually deeply cultural and also reflect the prosperity of a country, so trying to 'standardize' the particular cultural/legal/financial tradeoffs the EU has made across the world is ethnocentralism / cultural imperialism. Everything is a tradeoff, and one culture may decide limiting financially-costly burdens on organizations is more important than individual rights around data, while another might decide every-expanding individual rights are the basis for a civilization. I really don't like the concept of the Composr platform imposing laws on people that their own governments did not. I am not aware of any legal jurisdiction that requires users to *immediately* be able to download all personal data. So not having this on by default has no legal harm at all. Having it on by default could risk legal harm, or other harms, to an organization, if any small mistakes are made. If a site is getting lots of requests, they will become aware of the feature, and then may choose to turn it on after proper consideration - but I really don't think that's going to be many sites because these kinds of access rights are rarely exercised outside specific industries (like those holding financial information, doing cross-Internet tracking, etc). Here's another example: Staff notes may have been filled in/altered after content has been submitted, and is only available on the edit screen. As things stand right now it is possible for a user to have permission to add something, but not then edit it - therefore they would not normally see what has been put into this field. Again, it's just not realistic to expect people to be vetting everything on the site that would not usually be available and trying to think how to configure metadata to not expose it on a side-channel that they are barely aware of. The nuances should be documented. But my point before is there are more edge cases than we will ever think of. And we have to assume that people would made new addons, with new data available for download, and those developers would also not think about all the cases where data might accidentally get leaked out. It's just too obscure for the average website user or developer to go into detail about this, and the risks too high. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-01-30 17:36 | PDStig | New Issue | |
| 2024-01-30 17:36 | PDStig | Status | Not Assigned => Assigned |
| 2024-01-30 17:36 | PDStig | Assigned To | => user4172 |
| 2024-01-30 17:36 | PDStig | Tag Attached: Roadmap: v11 | |
| 2024-01-30 17:50 | PDStig | Relationship added | related to 5555 |
| 2024-01-30 17:53 | PDStig | Description Updated | |
| 2024-01-30 17:56 | PDStig | Description Updated | |
| 2024-01-30 18:46 | PDStig | Note Added: 0008279 | |
| 2024-01-30 18:47 | PDStig | Note Edited: 0008279 | |
| 2024-01-31 03:02 | PDStig | Status | Assigned => Resolved |
| 2024-01-31 03:02 | PDStig | Resolution | open => fixed |
| 2024-01-31 03:03 | PDStig | Tag Attached: Type: Legal compliance / Privacy | |
| 2024-01-31 03:06 | PDStig | Note Added: 0008280 | |
| 2024-01-31 03:06 | PDStig | Note Edited: 0008280 | |
| 2024-08-04 23:01 | Chris Graham | Note Added: 0009100 | |
| 2024-08-04 23:09 | PDStig | Note Added: 0009104 | |
| 2024-08-04 23:24 | Chris Graham | Note Added: 0009110 | |
| 2024-08-04 23:35 | PDStig | Note Added: 0009113 | |
| 2024-08-04 23:36 | PDStig | Note Edited: 0009113 | |
| 2024-08-04 23:40 | Chris Graham | Note Added: 0009115 | |
| 2024-08-04 23:52 | PDStig | Note Added: 0009116 | |
| 2024-08-04 23:53 | PDStig | Note Edited: 0009116 | |
| 2024-08-05 00:47 | Chris Graham | Note Added: 0009117 | |
| 2024-08-05 00:56 | PDStig | Note Added: 0009118 | |
| 2024-08-05 00:57 | PDStig | Note Edited: 0009118 | |
| 2024-08-06 01:35 | Chris Graham | Note Added: 0009125 | |
| 2024-08-06 01:36 | Chris Graham | Note Edited: 0009125 | |
| 2024-08-06 14:29 | PDStig | Note Added: 0009127 | |
| 2024-08-06 14:31 | PDStig | Note Edited: 0009127 | |
| 2024-08-08 01:37 | Chris Graham | Note Added: 0009131 | |
| 2024-08-09 05:50 | Guest | Note Added: 0009134 | |
| 2024-08-09 05:51 | Guest | Issue cloned: 5854 |
