It is not clear to the user that payment information is not encrypted with custom passphrase. |
||||||||||||||||||||||||||||||||||||||||||||||||
Issue descriptionThis template is ONLY for reporting privacy issues. Please use a different template for other types of bug reports. PRIVACY ISSUE It is not clear to the user that payment information is not encrypted with custom passphrase. Visiting chrome://settings/syncSetup VERSION: Chrome Version: 70.0.3530.0 (Official Build) canary (64-bit) (cohort: Clang-64) Operating System: Windows 10 Version 1803 (OS Build 17134.228) REPRODUCTION STEPS Please provide detailed reproduction steps, and any additional information below. Include an URL demonstrating the issue and attach a screenshot if applicable. Be sure to include in your description how this issue affects your privacy. 1. Visit chrome://settings/syncSetup see screenshot. It says "All data was encrypted with your sync passphrase..." and yet I am now learning that my payment data is not. The payment data needs to be moved to a new page or separated from the sync data to make this clear.
,
Aug 29
Can you clarify what is "payment data" in this case?
,
Aug 29
,
Aug 29
re: #2 I'm talking about "Payment methods and addresses using Google Pay", see screenshot in #0.
,
Aug 29
Mathieu, could you triage this please?
,
Aug 29
Over to Durga to figure out the best way to convey what's going on. Technically, Payments data comes from Google, so by design it can't be encrypted with a custom passphrase.
,
Aug 29
I think the UI just needs updating to make it clear that this data is not encrypted with custom passphrase, because right now I think it's misleading to users.
,
Sep 3
+ewald@, +sabineb@ Assigning to sabineb@, as the Sync team owns this UI. The solution could be something as simple as pushing the passphrase item a few rows up and explaining that it only applies to the rows above. For the record, we discussed this with ewald@ recently in the context of new checkboxes in the sign-in section. The passphrase doesn't apply to "Activity and interactions", but those aren't even sent for passphrase users. It also doesn't apply to Drive suggestions, but in that case no data is uploaded in general. So we came to the conclusion that no immediate change to the UI was necessary because of these additions, until the first item is added that actually collects data to which the passphrase doesn't apply. As it turns out, this is already the case for Payments.
,
Sep 4
There is no mention of "Drive suggestions" in the privacy whitepaper. What are those?
,
Sep 4
,
Sep 5
This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone. All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 5
Targeting same release as Unity, see issue 811351.
,
Sep 6
To be clear, this is entirely orthogonal to Unity. This UI has existed in this state for a long time, and Unity isn't changing anything related to how data is encrypted or how we communicate which data is encrypted with your passphrase. You can look at the current sync settings page by forcing #unified-consent to "Disabled" and noting that the same issue exists. Thus, removing the RBS label and the M-70 label. "Drive suggestions in the omnibox" is a new feature that is being added which searches your Drive as you type in the omnibox and returns suggestion results there. The omnibox team is putting a setting to turn the feature off on this screen as well, but it doesn't exist yet (I don't know what the timeline for their launch is). Like Martin mentioned, it's also not really relevant here, since it doesn't collect/upload data. I agree that this is a question for the sync team (Sabine) + privacy team (Rory, who I'm also cc'ing) to figure out.
,
Sep 6
,
Sep 6
I feel this is important, as it's deceptive to users to say "All data was encrypted with your sync passphrase..." when it's not. eisinger@ -> how can this work be prioritized? How can I escalate this?
,
Sep 6
I think this only affects desktop.
,
Sep 6
This affects iOS and Android as well, where the UI also says "Encrypt all synced data with your own sync passphrase." It's a little different, since the "Encryption options" dialogue is its own thing, instead of just being an embedded section underneath the rest of sync settings. But the core issue remains that we don't clarify that technically it's not *all* "synced" data, since you can sync credit cards that are not encrypted with your passphrase. Also, just want to clarify that I'm not arguing that this work isn't important or shouldn't be prioritized. I'm just making it clear that it's unrelated to Unity, so should be prioritized separately from it.
,
Sep 11
The NextAction date has arrived: 2018-09-11
,
Sep 13
hello - I wonder if there was any update on this bug? I think this is quite important given the users who enable "sync passphrase" are probably the most privacy sensitive of all our users, so it might be surprising to them that this data is not encrypted with the sync passphrase.
,
Sep 14
Thx Chris for the offline ping. I only rarely check the eisinger@ account
,
Sep 14
ok, so I think I see two issues here: 1) There are now several features on this page that are not encrypted with the sync passphrase (as they simply aren't related to sync). 2) The data that goes to Gpay isn't encrypted with the custom passphrase, but the metadata that goes to the sync server is. in any case, it's not clear to the user what's going on. For simplicity, we could probably just treat payments as not encrypted, and find a solution to message to the user what is fully encrypted and what is not fully encrypted?
,
Sep 14
Even though it seems that it has been like this before, I do agree that we need to fix this. jtonollo and I will work on coming up with a solution for the UI and then circle back with the eng team on the implementation.
,
Sep 21
Ping jtonollo and/or sabineb: Has there been any progress on this?
,
Sep 21
,
Sep 24
hello, has there been any progress on this? I think it's really important that we are explicit and very clear to users about how Google stores users' data. I think this work should be given the highest priority - especially as many users who use Custom Passphrase are "security thought leaders" and so it's even more important to be clear about the expectations and limits of the Custom Passphrase feature in Chrome.
,
Sep 25
Fully agreed. We're on it. Will report back once we have something to share.
,
Sep 27
,
Sep 27
,
Sep 28
Friendly ping! Could you please provide any update on this issue as it has been marked as a stable blocker. Thank You!
,
Oct 1
[bulk edit] - This issue is marked as a stable blocker for M70. We are two weeks away from M70 Stable. Please take a look urgently!
,
Oct 8
Friendly ping to look into this issue and to provide further update on this issue as it has been marked as a stable blocker. Thanks!
,
Oct 8
The updates should be landing this week, but given that this involves string changes and that the M70 Stable cut is coming in a couple of days, M70 doesn't seem feasible at this point anymore. Updating to M71.
,
Oct 9
Taking this over since I'll implement the changes.
,
Oct 9
,
Oct 9
Pending CL: https://chromium-review.googlesource.com/c/chromium/src/+/1270740 Before/after screenshots for desktop attached (corresponding to PS4 of the CL).
,
Oct 10
Before/after screenshots for Android attached.
,
Oct 10
Great! As just discussed, please add a space line between the two sentences at the bottom. Thanks!
,
Oct 10
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2366cbba92529fe6e4998287e71727184384b762 commit 2366cbba92529fe6e4998287e71727184384b762 Author: Marc Treib <treib@chromium.org> Date: Wed Oct 10 13:49:23 2018 Update sync passphrase strings to make clear that Payments isn't covered Bug: 878849 Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs Change-Id: I7bf008caa5abb3c94f67f067b936518dd63dd8eb Reviewed-on: https://chromium-review.googlesource.com/c/1270740 Commit-Queue: Marc Treib <treib@chromium.org> Reviewed-by: Hector Carmona <hcarmona@chromium.org> Cr-Commit-Position: refs/heads/master@{#598308} [modify] https://crrev.com/2366cbba92529fe6e4998287e71727184384b762/chrome/android/java/strings/android_chrome_strings.grd [modify] https://crrev.com/2366cbba92529fe6e4998287e71727184384b762/chrome/app/generated_resources.grd [modify] https://crrev.com/2366cbba92529fe6e4998287e71727184384b762/chrome/app/settings_strings.grdp [modify] https://crrev.com/2366cbba92529fe6e4998287e71727184384b762/components/sync_ui_strings.grdp [modify] https://crrev.com/2366cbba92529fe6e4998287e71727184384b762/ios/chrome/app/strings/ios_strings.grd
,
Oct 10
,
Oct 16
Verified on 72.0.3582.0 Canary, iPhone X iOS 11.4.1 strings added, Looks good. https://drive.google.com/file/d/1GLs1Y0BHM0ECdRpiyPsBNHjCD8O3vJAF/view
,
Oct 17
Verified on 71.0.3578.9 Beta in iPhoneX(iOS 11.4.1), iPad 8plus(iOS 12.1 beta) and iPad Air(iOS 12.0.1) All strings looks good Link to screenshot: https://drive.google.com/drive/folders/1DwCvSOj7_Ij7jNMAcO5GDIEgMg9pLJC-?usp=sharing |
||||||||||||||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||||||||||||||||||||||||
Comment 1 by palmer@chromium.org
, Aug 29Components: UI>Browser>Payments Services>Sync
Labels: OS-Android OS-Chrome OS-Fuchsia OS-iOS OS-Linux OS-Mac OS-Windows