tree: 2cf28376a9d2b3974bd24b4cd6fbde8e20d30caa [path history] [tgz]
  1. BUILD.gn
  2. common_syncable_prefs_database.cc
  3. common_syncable_prefs_database.h
  4. DEPS
  5. DIR_METADATA
  6. dual_layer_user_pref_store.cc
  7. dual_layer_user_pref_store.h
  8. dual_layer_user_pref_store_unittest.cc
  9. OWNERS
  10. pref_model_associator.cc
  11. pref_model_associator.h
  12. pref_model_associator_client.cc
  13. pref_model_associator_client.h
  14. pref_model_associator_unittest.cc
  15. pref_service_mock_factory.cc
  16. pref_service_mock_factory.h
  17. pref_service_syncable.cc
  18. pref_service_syncable.h
  19. pref_service_syncable_factory.cc
  20. pref_service_syncable_factory.h
  21. pref_service_syncable_observer.h
  22. pref_service_syncable_unittest.cc
  23. preferences_merge_helper.cc
  24. preferences_merge_helper.h
  25. preferences_merge_helper_unittest.cc
  26. README.md
  27. syncable_prefs_database.cc
  28. syncable_prefs_database.h
  29. synced_pref_observer.h
  30. test_syncable_prefs_database.cc
  31. test_syncable_prefs_database.h
  32. testing_pref_service_syncable.cc
  33. testing_pref_service_syncable.h
components/sync_preferences/README.md

Background

Preferences are a generic system for storing configuration parameters in Chrome, see Preferences and chrome/browser/prefs/README.md.

Individual preferences may be declared as syncable, meaning they will be uploaded to the user's Google Account and propagate across signed-in/syncing devices from the same user.

This folder contains the code for synchronizing preferences. See components/sync/README.md for background about Sync itself.

Adding syncable preferences

For authors

Making a pref syncable requires a few things:

  • Specify appropriate PrefRegistrationFlags to the Register*Pref call.
    • Consider whether your pref should be synced as a browser pref (common case) or as an OS pref (for use on ChromeOS-Ash). Note that it must be one or the other.
    • Consider whether it needs to be a “priority” pref. The answer is most likely “no”; typically only prefs that need to be consumed on the server should be marked “priority”. Be aware that choosing “priority” has privacy implications, so you'll get extra scrutiny.
  • Add an entry to the appropriate SyncablePrefsDatabase: ChromeSyncablePrefsDatabase if the pref is in chrome/, IOSChromeSyncablePrefsDatabase if it‘s in ios/chrome/, or CommonSyncablePrefsDatabase if it’s cross-platform.
    • Specify the matching pref type (browser or OS, priority or not).
    • Consider whether your pref is particularly privacy-sensitive, and if so, point this out to the reviewer. The most common case of this is when a pref records URLs or other history-like data.
  • Add an entry to the SyncablePref enum in tools/metrics/histograms/metadata/sync/enums.xml.

For reviewers

Important: Adding syncable prefs may have privacy impact. It‘s the responsibility of the code reviewer to ensure that new syncable prefs don’t have undue privacy impact. In particular:

  • If the pref contains URLs (example: site permissions), it must be marked as is_history_opt_in_required = true, and it will only be synced if the user has opted in to history sync (in addition to preferences sync).
  • If the pref is marked as “priority” (syncer::PRIORITY_PREFERENCES or syncer::OS_PRIORITY_PREFERENCES), then it will not be encrypted. Carefully consider if it actually needs to be “priority”. (The most common reason for this is when the pref needs to be consumed on the server side.)
  • In any other cases that are unclear or questionable, reach out to chrome-privacy-core@google.com, or to rainhard@ directly.