Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
RE: 7.2 M2 - GDPR Exports Are Not In The Hands Of The User In Liferay
It seems that the wrong user has access to everything GDPR related. Taking exporting data as an example.
Problems
Only the site admin can access these exports, which means the site admin now has to transmit the users data over a network via email or some other method, if by email now that export has to be handled for Erasure from the email system also. This is such a burden on the organization particulary if they recieve many requests.
Suggestion
Give the user not the site or portal admin access to everything related to GDPR.
This isn't meant to be un-constructive feedback, but it seems that the whole approach to this need sto be made user centric which will benefit the user and the organization processing the requests. It's a good first go, but some iteration in design is needed, currently the wrong user has access to the data.
- The EU citizen in this case is User "T1"
- The site admin in this case is User "Test"
Problems
- The requester has to go outside of the portal to start the process
- The requester doesn't know what can be exported so cannot know how to ask the question correctly
- The requester cannot download the exports from the portal
- The provider has to transmit the export via another network tool and this data could be subject also to Erasure
- The requester cannot delete their exports, they have no control over their data
Only the site admin can access these exports, which means the site admin now has to transmit the users data over a network via email or some other method, if by email now that export has to be handled for Erasure from the email system also. This is such a burden on the organization particulary if they recieve many requests.
Suggestion
Give the user not the site or portal admin access to everything related to GDPR.
This isn't meant to be un-constructive feedback, but it seems that the whole approach to this need sto be made user centric which will benefit the user and the organization processing the requests. It's a good first go, but some iteration in design is needed, currently the wrong user has access to the data.
This issue with the wrong user having access to GDPR is easily seen because in this case, the user "Test" who can process and access other people's data (blogs threads etc) ... user Test is not able to access their own GDPR settings? In this example the user "Test" being a portal admin currently logged in cannot export their own data. The portal admin now has to ask someone with the same level of access like another portal admin to export their data and again the data is in the wrong hands.
That's the whole point of GDPR is that the control is in the users hands, the data is still in other people's hands and not the user. It's backwards.
That's the whole point of GDPR is that the control is in the users hands, the data is still in other people's hands and not the user. It's backwards.
Keep this in mind and join the 7.2 beta program when it's up: https://community.liferay.com/blogs/-/blogs/liferay-7-2-milestone-2-release
Thanks for the feedback Lee.
I definitely agree with the principle of giving end users greater transparency and control over their own personal data. This sort of "privacy dashboard" is a feature we're continuously evaluating as the market's understanding and need for data protection unfolds.
For our first iteration of data protection tools, we decided on admin-centric tools for the following reasons:
In 7.2, we're making improvements to the administrative interface for deleting/anonymizing a user's data which should be available by phase 2 beta (not ready by phase 1 alpha). Beyond 7.2, we'll definitely give further consideration to the user-centric privacy dashboard.
I definitely agree with the principle of giving end users greater transparency and control over their own personal data. This sort of "privacy dashboard" is a feature we're continuously evaluating as the market's understanding and need for data protection unfolds.
For our first iteration of data protection tools, we decided on admin-centric tools for the following reasons:
- GDPR does not require automated self-service tools for users to export/delete/update/etc personal data. GDPR does require the organization (the data controller) to handle such requests (within 30 days). Thus our first goal was providing the organization with tools to manage personal data.
- When a user does request personal data from an organization, the data that an organization must provide will almost never reside solely within a Liferay instance. The organization must collect personal data from all internal systems that hold user data. So as a Liferay.com end user, if I request an export of my personal data, Liferay, Inc. must provide the data from not only Liferay systems like community.liferay.com, www.liferay.com, etc., but also internal third-party applications like Hubspot, Marketo, Salesforce, Zendesk, etc, etc. So there's seldom a case where a Liferay instance providing an automated self-service "export personal data" button to the user is fully compliant with the law. It will almost always require the organization's administrators to get involved unless the organization has built a fully automated system that pulls data from every internal application housing personal data.
- The exports are executable programmatically, so it's not programmatically difficult to make these exports available to the end user or make subject the exports to a larger automated workflow that's pulling data from multiple applications.
In 7.2, we're making improvements to the administrative interface for deleting/anonymizing a user's data which should be available by phase 2 beta (not ready by phase 1 alpha). Beyond 7.2, we'll definitely give further consideration to the user-centric privacy dashboard.
Yeah good points!
If the user has exports generated though it would be nice if they could download those directly from their account settings and also trigger a request from the account settings / be notified in the notifications centre.
If the user has exports generated though it would be nice if they could download those directly from their account settings and also trigger a request from the account settings / be notified in the notifications centre.
The other issue with the user not being able to download exports comes when the export contains GB's of documents. I exported a user to try out the functionality and it presented a 1.4GB compressed file.
The problem for the organisation would be re-transfering that file, they would have to download it from Liferay handle it in some other mannor to get it to the user using a different service ... that's a problem, not just on bandwidth but also storage. If the file is there in Liferay, let the user download it from Liferay (could be a link in an email) but none the less, let the user download their export.
The problem for the organisation would be re-transfering that file, they would have to download it from Liferay handle it in some other mannor to get it to the user using a different service ... that's a problem, not just on bandwidth but also storage. If the file is there in Liferay, let the user download it from Liferay (could be a link in an email) but none the less, let the user download their export.