Issue metadata
Sign in to add a comment
|
Smart Lock (cloud password sync) is enabled by default
Reported by
colander...@gmail.com,
Sep 28 2017
|
||||||||||||||||||||||
Issue descriptionSteps to reproduce the problem: Apparently Google Smart Lock is enabled by default. This is a security hazard as it uploads all my passwords to an untrusted third party (Google). What is the expected behavior? Smart Lock should be disabled by default, and passwords stored locally. What went wrong? My passwords were in Google's cloud, which is not under my control and cannot be audited. Did this work before? Yes Chrome version: 56.0.2924.87 Channel: n/a OS Version: Flash Version:
,
Sep 28 2017
The locally-running code is open-source and auditable. So are my outgoing network connections. My passwords being sent to Google means I have to trust code I can't see running on machines I can't control on a network whose security I can't control.
,
Sep 28 2017
This bug is about changing a default. When thinking about defaults, we need to have the average/typical user in mind. Sending to ewald@ as this is really a product question.
,
Sep 28 2017
I think this issue applies double for an average/typical user. I highly doubt any typical user is aware that if their Google credentials are compromised, so are all the passwords they've saved in Chrome (the UI certainly doesn't make this consequence clear). To enable this "feature" without their consent is a violation of trust.
,
Sep 28 2017
The premise is incorrect. Neither Chrome nor Android upload any passwords to Google unless you tell them to do that. Chrome stores passwords locally by default, it syncs them if you enable sync. Android does not store passwords at all by default because it has no local storage support for that.
,
Sep 28 2017
That is not my experience. I tested this just now and found your claim to be incorrect. I have an installation of Chrome (58.0.3029.110, Linux) with which I've saved many passwords, but never logged in to Google. (I use it only for cross-browser testing of local web apps.) The "Settings - Passwords" dialog showed me what I expect -- passwords stored on my local drive. I clicked the "Access your passwords from any device at passwords.google.com" link at the bottom of the dialog. This took me to a login screen which did not have my Google credentials (since I've never used them on this setup). I entered my credentials and was taken to the "Saved passwords" page on passwords.google.com. And THERE WERE ALL MY PASSWORDS. I could click the "eyeball" next to each to view them. To be clear, during this process, I NEVER consented, or was even alerted, that by logging into Google after clicking on that link, my passwords would be shared with Google. NEVER. This is an absolute violation of privacy and trust on Chromium's behalf, to share my passwords without my consent with a third party.
,
Sep 28 2017
OK, I tried this again, after disconnecting my account from Chrome. This time, I did notice that the login screen mentioned "Your bookmarks, history, passwords, and other settings" would be shared with Google. This click-through is far too little a warning for something a user does when initially setting up a device or a browser and then forgets about. Certainly, I never remember doing this on my Android device.
,
Sep 28 2017
I appreciate the concerns you've raised. On the Chrome team, we work hard to ensure Chrome meets a high standard for privacy and user trust. Let me address each of your points: > Passwords being collected by default As c#5 pointed out, sync is *never* turned on by default (on any platform). On Android/iOS, there is an opt-in flow during the first run experience which prompts the user to select an account from the device to sync to. On Desktop, the user is prompted to sign into Chrome (which is different than signing into a Google website) with the Google Account they want to sync to. In both scenarios, after the user either picks an account or signs in with their account, we present a native confirmation dialogue which explains the full implications of turning on sync. See attached screenshots of this confirmation screen. Your passwords are *never* shared with Google until you've explicit provided consent on this confirmation screen. > Seeing your passwords on passwords.google.com If you weren't signed into Chrome and syncing on your Linux machine, then the passwords you're seeing on passwords.google.com aren't from that machine, they're from another device where you are signed into Chrome and syncing passwords. Simply signing into passwords.google.com does *not* upload your passwords to Google. We never send your passwords (or other sync data) to Google without your explicit consent. > Control over your sync data on our servers The confirmation screen gives the user the opportunity to navigate to sync settings, where the user can explicitly disable any sync datatypes they don't want sent to Google (e.g. passwords) or set a custom sync passphrase so that all their data is encrypted with a client passphrase that Google does not have access to. These are done before sync is ever started to guarantee that Google doesn't receive your data before you have a chance to access it. Furthermore, there are other ways to control your sync data. You can visit https://chrome.google.com/sync to completely wipe your Chrome data from Google's servers (this will also turn off sync on any device where you are currently syncing). You can also visit https://takeout.google.com/settings/takeout to take your data with you before clearing it from Google's servers. I'm going to mark this bug as WontFix, given the answers above.
,
Sep 29 2017
Thank you for your detailed reply. I'm not sure I agree that the confirmation dialog explains the "full implications" of sync (that compromise of the Google account means compromise of all synced passwords), nor that a typical user would even notice the word "passwords" (it's the 3rd item in) -- to most users I suspect that click-through dialog reads: "Chrome Sync bookmarks blablabla OK, GOT IT, let me use my new phone". If I may suggest a dialog interface more respecting of user privacy: list "bookmarks", "history", and "passwords" as three separate line items with a checkbox each. Bullet lists stand out in a scan, and checkboxes make it obvious there's a choice to be made (not just "OK, GOT IT"). (Bonus points for leaving "passwords" unchecked by default, and rewording "Save password" in Chrome as "Upload password to Google Cloud".) Regardless, you've made Google's stance on privacy clear, so I won't belabor my point. Thank you for your time. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Sep 28 2017Labels: -Restrict-View-SecurityTeam allpublic
Summary: Smart Lock (cloud password sync) is enabled by default (was: Smart Lock is enabled by default.)