Deleting the currently-active profile should not open one of the other pre-existing profiles |
|||||||||||||||||
Issue descriptionChrome Version: 62.0.3188.2 (Official Build) dev (64-bit) OS: Linux, probably applies to all desktop What steps will reproduce the problem? (1) Start with fresh user data dir (2) Create a second profile (3) Close all windows of the second profile (4) Delete the first profile What is the expected result? The profile picker should be shown. What happens instead? The second profile is opened. This is problematic from a privacy perspective because the 2nd profile may contain data that belongs to a different user and the current user might not want to be exposed to it.
,
Aug 24 2017
,
Aug 25 2017
Tested this issue on Skytap env with Win2k12 as server and Win7 as Client Preconditions : 1. Enabled user data directory policy. 2. Enabled force sign in policy Steps followed : 1. Launch chrome in client machine 2. Sign into two profiles 3. Close 2nd profile windows 4. From 1st profile window, click on manage people 5. delete 1st profile. Observations: ------------- After closing 1st profile window, immediately 2nd profile window is opened. Attaching the screen-cast for reference. tnagel@ could you confirm this is the issue you are experiencing ? or did i missed anything while reproducing the scenario. Thank You...
,
Aug 25 2017
Yes, that's the problem. (Setting policy is not a precondition for it, though.)
,
Sep 4 2017
Assigned to Matt for prioritization.
,
Sep 4 2017
,
Sep 4 2017
,
Sep 5 2017
Able to reproduce this issue on Windows 10, Ubuntu 14.04 and Mac 10.12.6 with chrome #60.0.3112.113, canary #63.0.3206.0 Issue broken in M57. Bisect Info: =========== Good build : 57.0.2929.0, Revision Range - 434071 Bad build : 57.0.2934.0, Revision Range - 434580 After executing the per-revision bisect script, i got the following CL's between good and bad build versions =========================================== https://chromium.googlesource.com/chromium/src/+log/56f03f53c9dd7cd2977b6e06dd724f07187124a7..198d711e1e047b20d235c430a697f1b39a651b08 The suspecting Change Log is : ----------- https://codereview.chromium.org/2519953004 Note: ====== 1. In mac machine, issue exists in earlier M50 builds. 2. Since the author is not available in owner's list, assigning it to the one of reviewers for further triage bauerb@- Could you please help us to reassign this issue to the right owner.
,
Sep 5 2017
,
Nov 10 2017
This doesn't feel like a P1 issue. You can always open another user's profile by just going to the user manager and selecting the other profile. Profiles don't provide any guarantee of privacy or security from other users on the same machine. I'm demoting to P2.
,
Dec 11 2017
Elias: It's a difference whether a user actively needs to seeks out private data of another user or whether the user is inadvertently presented with private data of another user. I don't mind whether this is P1 or P2 as long as it will be fixed. Given that this has regressed almost a year ago, I don't think that pursuing a fix *now* could be considered undue haste. Bernhard, make I kindly ask you to chime in on this?
,
Dec 12 2017
Re "actively" seeking out vs. "inadvertently presented": even if we change the behavior such that the user manager is presented upon profile deletion, the user would be looking at the user manager screen which just contains the second profile, and it would be one click away from opening that profile. I would not consider that "actively" seeking it out; it's right there in front of you. Either way, I don't think Bernhard is the right owner, since this is really a profiles thing. The sign-in team is extremely bandwidth constrained, as we're heads down focused on Unity + Dice. I'm cc'ing Mihai for help triaging within the sign-in team and marking as Available for someone to pick up. Mihai (and others): desired behavior is to open the user manager when a profile is deleted, instead of the next available profile on the machine. Thiemo - if someone on the privacy team has the bandwidth to pick this up, they are more than welcome to help us out :)
,
Dec 13 2017
+anthonyvd who's also an owner of //chrome/browser/profiles. Anthony, Mihai, could you please take a look at this regression and find an eng owner for it? I'm not familiar with the code, but it's really a very simple request. (Bumping this up to P1 again because it's a regression of something that used to work.)
,
Dec 13 2017
I this we must bump this back to P1 as otherwise we will not have the time to work on it (at this point, the whole team is focused on DICE and I'm afraid this bug will just get lost otherwise). I am assigning this bug to David as he needs to ramp up a bit on UI.
,
Dec 13 2017
Thanks a lot, Mihai!
,
Dec 13 2017
To be very clear: this is a much lower priority than working on Dice. This is a minor regression that from my perspective does not have any significant usability, privacy, or security implications. Mihai, I don't think David should spend his time fixing this with everything else he's working on for Dice. We can discuss this during our next 1:1, but this is the reality of being a small engineering team with a large number of UI surfaces that we are responsible for. We have to prioritize appropriately. If this is a very quick and easy fix, then I'm happy for David (or anyone else on the team) to make it. If there is complexity involved (i.e. more than .5-1 days of engineering time), we should punt on this for now.
,
Dec 28 2017
Any progress on this, David? Should we bump down the priority per #c16?
,
Feb 10 2018
Bumping down the priority of this to P2 given how swamped we are with Dice.
,
Mar 12 2018
--Chrome Identity automated triaging-- This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 1
,
Sep 3
--Chrome Identity automated triaging-- This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||
Comment 1 by tnagel@chromium.org
, Aug 21 2017Components: Enterprise