Let users delete their profiles when DeviceShowUserNamesOnSignin is disabled |
|||||
Issue descriptionThere's some policies that can make it impossible for a user to delete their account (DeviceShowUserNamesOnSignin, MinimumRequiredChromeVersion, DeviceUserWhitelist). We should come up with ways in which users can retain the ability to delete their account. Context: https://groups.google.com/a/google.com/d/topic/chromeos-privacy/1Cbn414-SBY/discussion > there will be many ways for admin restrictions to prevent the deletion of user data (put the device in lost-and-stolen mode, hide the pods as you suggest, put the device in auto-start-public-session mode, etc). If a device is marked as lost-or-stolen there's probably a reason for it and blocking deletion in that case seems reasonable. I'm mostly concerned about the admin (unintentionally) blocking deletion as a side-effect of another action (e.g. hiding user pods). > Is the option for the user to do a stateful clear sufficient as a fallback, so we don't have to go through all of these features now and in the future to build some kind of "delete my data" escape hatch? I wouldn't consider wiping the device a reasonable alternative because this clears the state of *all* users on the device. I'd expect that the collateral damage could be a significant deterrent to that. I don't think that we need to go through all existing features individually, it's probably sufficient to treat two cases: a) the pod of a specific user is hidden from the login screen b) the login screen itself is hidden Let's get together after Easter and brainstorm potential solutions. Cc'ing Christian since he might be interested in integrating account deletion into Clear Browsing Data.
,
Mar 27 2018
We might take that occasion to discuss whether the model of any user can delete any user is still valid in an ARC++ world where significant state may be accumulated in users profiles.
,
Mar 27 2018
Whoops, collided with Drew's comment. I agree that we should get UX and PM input on this, especially if we decide to widen the scope to revamping user deletion in general.
,
Apr 2 2018
,
Dec 11
Marcus can you prioritize this privacy-related feature?
,
Dec 12
+zalcorn who has been thinking about this as well.
,
Dec 13
Took a stab at this a go/cros-byebye
,
Dec 13
Thanks Zach! There's a couple of open questions on that doc, e.g. https://docs.google.com/a/google.com/document/d/1he2rp3dyJi_LRQHa3kRQg6ZnqMhTHaLvTa4_eLh80FQ/edit?disco=AAAACAwwdFI.
,
Jan 9
,
Jan 9
One additional way we could approach the problem is to have users' accounts and associated data automatically remove themselves after being hidden from the login screen for (n~=30) days. This would have the additional benefit of removing users data when they no longer have physical access to the device.
,
Yesterday
(45 hours ago)
jessejames@ - Following up on a question from Issue 919809 : "Do you have a way of tracking post-mauve follow up work?" Is there a bug label that we can apply to indicate this? |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by atwilson@chromium.org
, Mar 26 2018