Hmm not sure what we should do as a short term solution here, since making the UI usable for this scenario on android will take some time. There are several problems here related to not exposing the exceptions model correctly in the android UI.

My thoughts on a short term fix:
1) Stop syncing exceptions that users can manually modify on desktop, which are: JS, cookies, notifications 
2) Make sure that exceptions like http://* show up in the android UI.

Thoughts?

Is there any reason that we only allow users to add exceptions when the default setting is changed?

Ugh tough. The end goal for mobile settings (which tries to be minimal as possible) would not necessarily be to make exceptions more robust on mobile. But definitely minimizing the disruption/breakage between platforms is OK. If we don't sync some features would privacy request that we label it somehow so users are aware? Or is there an existing model we can pull from that already does this? <fingers crossed>

Actually there are more settings we should probably not sync because of the same issue:
-keygen
-automatic downloads
-popups
-javascript
-cookies

(In which case we might as well not sync any content settings to mobile because it doesn't leave many)

A bit of background:

Re #0: Content settings are stored as preferences, and the Sync team has recently started syncing preferences to mobile. That's why this happened now.

Re #1: It seems that nonstandard exceptions are intentionally omitted in WebsiteAddress#create(). I can understand how we got there with the site-centric model, but that's a bug - we should show nonstandard patterns *somewhere* in the site settings menu.

Possible solutions:

a) If we want to have consistency among all platforms, fix the UI on mobile. The desktop MD UI needs to have a way to handle nonstandard exceptions anyway, so we can just reuse that.

b) If we want to keep the exclusively site-centric model on mobile as per #3, then we must stop syncing nonstandard exceptions. However, syncing standard exceptions and not syncing nonstandard ones will lead to unexpected behavior where some sites might get permissions that they weren't supposed to have. So we will have to stop syncing completely. Basically return to status quo ante.

c) If it makes sense to sync some things only between desktop instances or only between mobile instances, we should revisit Adrienne's issue 587230.

I think that b) is the easiest to do and also the least surprising (because it has always been like this). We just need to change all registrations as platform=desktop, and run a cleanup code on all exceptions on which WebsiteAddress#create() fails. I guess Rebecca will be also happy with that because we'd keep the simpler model?

As a user, I am happy to stay with the old behavior in option b), and as a developer, that certainly sounds easier.

I'm OK with the simpler model (B) if msramek@ is (I was worried about privacy implications so happy to have your insight there!) Kind of a bummer that things are no synced across platforms, but definitely better than being surprising and broken.

B also sounds easiest and simplest. Are there reasons we should not do this? What was the reasoning for syncing -- just that people might want the same settings x-device?

emilyschechter: I guess one reason is that we have always sync'd some of these settings across desktop profiles, just not to mobile. But the mobile UX is too different at present.

msramek: did the change to start syncing settings only just hit ToT recently? If so, maybe we can just unsync the settings and there very small number of users affected can just reset their chrome profiles?

CL up at https://codereview.chromium.org/2298633002/ to stop syncing.

Re #9: I think the general idea of Sync is that users should have to set the vast majority of their settings only once across devices - which means settings should be by default synced unless there is a reason not to.

Specifically for content settings, we believe that the user uses them to express a trust relationship with a site (e.g. this site can set cookies, this one can't), and that relationship is probably not going to be bound to the device. We made an exception for some of the more sensitive settings such as geolocation or media, since user might be for example fine with geolocation on their home computer but not on the tablet they carry with themself.

Re #10: We're definitely syncing to mobile on the M54 branch, so we will have to merge the CL back. It probably started a week-ish before the branchpoint; let me ask +ewald@ if he knows when exactly?

Re #12 sounds good. Keep in mind, the only people who will be broken are those who have used a build of Chrome Android that syncs these settings to mobile AND have strange wildcard patterns. I would guess this is a very small group of people.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/905d12e32159a88e8495092a9271e9e3c7971449

commit 905d12e32159a88e8495092a9271e9e3c7971449
Author: raymes <raymes@chromium.org>
Date: Thu Sep 01 01:09:42 2016

Stop syncing content settings on Android

Currently the UI on Android doesn't allow content settings to be
manipulated in the same ways as on desktop, which can leave users
in a broken state. Stop syncing them for now.

BUG= 642184 

Review-Url: https://codereview.chromium.org/2298633002
Cr-Commit-Position: refs/heads/master@{#415829}

[modify] https://crrev.com/905d12e32159a88e8495092a9271e9e3c7971449/components/content_settings/core/browser/content_settings_registry_unittest.cc
[modify] https://crrev.com/905d12e32159a88e8495092a9271e9e3c7971449/components/content_settings/core/browser/website_settings_registry.cc
[modify] https://crrev.com/905d12e32159a88e8495092a9271e9e3c7971449/components/content_settings/core/browser/website_settings_registry_unittest.cc

+Sync folks

The motivation for syncing prefs to mobile is kind of the same as the motivation for sync in general: a more seamless cross-device experience for our users who have multiple devices. In general, I'd expect my preferences that I've expressed on desktop to be carried over to my mobile phone (with some exceptions that msramek@ mentioned).

You can track the launch for syncing mobile prefs to settings in Issue 374865. First CL landed August 11, but it's currently behind a Finch-controlled flag (we're using Finch as a killswitch in case something bad happens), and I'm not exactly sure when the change to ramp it up on Dev/Canary rolled out.

If the UI on mobile for managing content settings is too different from desktop and not sufficient, I'm fine not syncing them for now. It would be great to try addressing the deficiencies in the mobile UI, unless we fundamentally think that they should remain different, and content settings should be per-device (or at least per-device-type).

Will we be merging this change from #14 to M54 as well?

We will need to merge #14 to M54. raymes@ - can you take care of that once it's had some time to bake on ToT?

Your change meets the bar and is auto-approved for M54 (branch: 2840)

Verified that it's not syncing those settings on ToT Android.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e09dbfded78b0b63783567dd69dc7e1814176802

commit e09dbfded78b0b63783567dd69dc7e1814176802
Author: Raymes Khoury <raymes@chromium.org>
Date: Mon Sep 05 01:45:23 2016

Stop syncing content settings on Android

Currently the UI on Android doesn't allow content settings to be
manipulated in the same ways as on desktop, which can leave users
in a broken state. Stop syncing them for now.

BUG= 642184 

Review-Url: https://codereview.chromium.org/2298633002
Cr-Commit-Position: refs/heads/master@{#415829}
(cherry picked from commit 905d12e32159a88e8495092a9271e9e3c7971449)

Review URL: https://codereview.chromium.org/2307393002 .

Cr-Commit-Position: refs/branch-heads/2840@{#147}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/e09dbfded78b0b63783567dd69dc7e1814176802/components/content_settings/core/browser/content_settings_registry_unittest.cc
[modify] https://crrev.com/e09dbfded78b0b63783567dd69dc7e1814176802/components/content_settings/core/browser/website_settings_registry.cc
[modify] https://crrev.com/e09dbfded78b0b63783567dd69dc7e1814176802/components/content_settings/core/browser/website_settings_registry_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e09dbfded78b0b63783567dd69dc7e1814176802

commit e09dbfded78b0b63783567dd69dc7e1814176802
Author: Raymes Khoury <raymes@chromium.org>
Date: Mon Sep 05 01:45:23 2016

Stop syncing content settings on Android

Currently the UI on Android doesn't allow content settings to be
manipulated in the same ways as on desktop, which can leave users
in a broken state. Stop syncing them for now.

BUG= 642184 

Review-Url: https://codereview.chromium.org/2298633002
Cr-Commit-Position: refs/heads/master@{#415829}
(cherry picked from commit 905d12e32159a88e8495092a9271e9e3c7971449)

Review URL: https://codereview.chromium.org/2307393002 .

Cr-Commit-Position: refs/branch-heads/2840@{#147}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/e09dbfded78b0b63783567dd69dc7e1814176802/components/content_settings/core/browser/content_settings_registry_unittest.cc
[modify] https://crrev.com/e09dbfded78b0b63783567dd69dc7e1814176802/components/content_settings/core/browser/website_settings_registry.cc
[modify] https://crrev.com/e09dbfded78b0b63783567dd69dc7e1814176802/components/content_settings/core/browser/website_settings_registry_unittest.cc