New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 896869 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

signing in shows dialog with incorrect information when using custom passphrase

Project Member Reported by wfh@chromium.org, Oct 18

Issue description

Chrome Version: 71.0.3578.10 (Official Build) dev (64-bit) (cohort: Dev)
OS: Windows 10

What steps will reproduce the problem?
(1) Install Chrome
(2) Sign into Chrome with an account protected by custom sync passphrase
(3)

What is the expected result?

Modal dialog that pops upon Sync start is correct in every statement it makes.

What happens instead?

Dialog in screenshot shows.

I do not believe that the wording: "Google may use your browsing history to personalize Search, ads, and other Google services" is true, since a user with custom passphrase would not have these personalizations enabled as Google cannot read this data (as it's encrypted).

I think that our most privacy sensitive users (those with custom passphrase) should have a 100% factually correct dialog popped when they enable sync - especially when this dialog is modal and cannot be bypassed. The dialog should not say that "Google may use your browsing history" since this is not the case.

Please use labels and text to provide additional information.

If this is a regression (i.e., worked before), please consider using the
bisect tool (https://www.chromium.org/developers/bisect-builds-py) to help
us identify the root cause and more rapidly triage the issue.

For graphics-related bugs, please copy/paste the contents of the about:gpu
page at the end of this report.


 
sync_enabled.png
135 KB View Download
Cc: sabineb@chromium.org
Cc: zkoch@chromium.org
Labels: -Pri-1 Pri-2
As discussed extensively in our offline thread, we do not currently plan to prioritize this immediately on the sign in team. As such, until we get guidance from leads that we should prioritize this above our other work, I'm decreasing the priority to P2. Within the signin team, P1 means we plan to dedicate immediate eng resources to fix the issue (we aggressively triage our P1 bugs), which is not the case for this bug at the moment.

We can update the priority again if we receive alternative guidance.
For reference, internal thread/discussion on this is here -> http://shortn/_2HJTIp7VCW
Cc: awhalley@google.com
Cc: tangltom@chromium.org
Components: -Privacy
Status: Assigned (was: Untriaged)
This is a product question, so I am assigning this to sabineb@ for tracking.

Sign in to add a comment