A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

[Idea] Allow websites to store data in the browser/OS sync feature

simevidas
2018-11-04

Warning: This is just a random idea that I had.

Browsers and operating systems can sync the user’s data and preferences across devices (e.g., I use Firefox Sync and iCloud syncing.)

What if websites could leverage this system to sync the preferences of their visitors without having to log them in?

Example scenario:

  1. A user visits a gaming site regularly.
  2. Over time, the user’s preferences become known to the site, e.g., which types of games they like and what kind of content on the website they view the most.
  3. The site displays a section that invites the user to sync these preferences via the browser’s sync feature.
  4. The user chooses to do so, and the browser shows a prompt: “Would you like to store your preferences on this website in browser sync?”
  5. Now, if the user has browser sync enabled on a different device and opens the same website on that device, the site will be able to access its stored preferences for that user and update its UI accordingly.

The amount of data that an individual website could store this way would of course be limitied (I’m thinking small-ish JSON strings). The API would be similar to the Storage API: The site has to request storage/access rights, and the storage-request prompt can only be triggered on user interaction.

This system would solve the problem for users where they have to create accounts on each website. When I as a user visit the same website on multiple devices, I want to have one, continuous experience, but creating accounts on every single website and logging in constantly is a bad experience.

*thinking pause*

Wait a second. Websites could just sync the user’s anonymous session cookie via this system. That would be another option.


Ok, why is this a bad idea? :grin:

yoavweiss
2018-11-04

I’d guess the main argument against such a mechanism would be privacy and user expectations. One could argue that while users expect their e.g. usernames/passwords to be synced between devices, they wouldn’t want other information to be synced at the same time. With that said, might be worthwhile to run this by privacy conscious folks to see what they think.

mkay581
2018-11-04

So this would require the user to install a browser sync add-on or something on all devices? If so, not sure why I (as a user) would want to do this extra work to install a browser add-on just so that the website publisher can track my behavior. I would assume that, if the user hasn’t created an account or logged in, they probably don’t want to be tracked.

simevidas
2018-11-04

Firefox Sync is a built-in feature. I’m pretty sure other browsers include features with the same or similar functionality.

Creating an account and logging in is generally annoying, both for the user (creating a strong password, opening the confirmation email, being signed out unexpectedly) and for websites that don’t want to go though the trouble of implementing a login system.

For example, a very simple website might want to let the user set a few preferences, and then have those preferences work multi-device. Why would every website, no matter how small, have to perform login when it can just store and access the visitor’s preferences via a simple JavaScript API that uses the user’s browser sync as a storage location?

jhpratt
2018-11-04

I’m huge on privacy considerations, and I’m of the opinion that this would be okay, given that it’s encrypted. I imagine most vendors would do so, anyways.

mkay581
2018-11-04

Oh I see. So you’re proposing an alternative storage API that will allow us to store tiny pieces of data for any given session that can be persisted across devices? Sounds interesting, but how do you propose accurately associating the data with the same anonymous user across devices? IP address? Just because a user is on the same IP address and accesses the website from a difference device, doesnt necessarily mean its the same user.

DanielHerr
2018-11-04

It seems like the easiest way to do this would be using the credential management api to sync the anonymous user id.

simevidas
2018-11-04

Actually, I think I was overthinking it. The Storage API already exists. All we need is for browsers to start syncing that data across devices.

I haven’t started using the Storage API yet, so I don’t know all its details, but I feel browsers could already start syncing that data if they wanted to (it could be an option in the browser’s settings: “Sync website persistent data”).

I don’t think there is a need for that. For example:

  1. I view content X on website
  2. Website stores “user likes X” via Storage API
  3. Browser syncs storage data across my devices
  4. I open same website on different device
  5. Website reads “user likes X” and updates start page to show more X

Done. The website doesn’t care who I am, it just needs a place to store my browsing habits, preferences, etc. that works across devices. Storage API + browser sync would enable that.

mkay581
2018-11-05

I see. I guess I’m not quite sure of how this proposed storage API knows that the user in Step 2 is the same user in step 5. Someone above mentioned the Credential Management API, but not too familiar with it yet or whether that will be a viable solution.

simevidas
2018-11-05

If the website reads “user likes X” via the Storage API, then that means that that website has set this value in the past in the same browser. So, unless multiple people use the same browser, it’s the same user.

If the browser were to start syncing this data across the user’s devices, as I have suggested, that would still mean that it’s the same user, since you have to sign in into the browser to activate browser sync.

mkay581
2018-11-05

Yes, there is a good chance its the same user, but there are a lot of cases where multiple users use the same device and browser in a household of multiple family members and they each may or may not sign into the browser. So there’s room for inaccuracies. There is no reliable way to determine that, in every case, we’re dealing with the same user.

DanielHerr
2018-11-05

If multiple users are for some reason sharing an account, why would we need to identify which person is using it? They would be sharing data on every site saved on the device, so why would it be any different with synced data?

mkay581
2018-11-07

The original proposal was to collect and sync data on a user’s behavior on a website so, that on other devices, that website will be tailored based on that data. I’m assuming this was proposed to be helpful and give the user a better web experience on all devices. How can this data be all that helpful to a user if this data is intermingled with the behavior of other users of a shared device in the same household?

I’ll use the example above (with a few edits) to illustrate my point:

  1. User 1 views content X on website via a shared computer in a multiple user household
  2. Website stores “user 1 likes X”
  3. Browser syncs storage data across shared computer, user 1’s mobile phone, and user 2’s mobile phone
  4. User 2 views content Y on website via the same computed in Step 1 (above)
  5. Website stores “user 2 likes Y”
  6. Browser syncs storage data across shared computer, user 1’s mobile phone, and user 2’s mobile phone
  7. User 2 opens same website on mobile phone browser
  8. Website reads “user 2 likes X and Y” and updates start page to show more X and Y

The problem here is that user 2 actually never looked at X, but the website shows content based on user 1’s behavior, which is inaccurate. The same will be the case for user 1 and Y content. I fail to see how this feature would be useful to these users, if this is likely to be the case.

simevidas
2018-11-07

I don’t think this scenario is possible. Browser sync requires the user to (1) create a password-protected account and (2) manually set up sync for each additional device. Two different people have no reason to use the same Google or Firefox account in their mobile browsers (unless one of the users is spying on the other, or something like that).

Note that browser sync captures everything, incl. the user’s browsing history and all their saved logins. If a household uses the same desktop browser, they have no reason to set up browser sync in that browser, esp. in Chrome’s case since that would mean that one of the people would have to sign in using their Google account and then stay signed in while others are using the browser.

mkay581
2018-11-07

Certain browsers will automatically log the user into the browser when logging into their gmail for instance. I can see someone accepting browser sync after having unknowingly been logged into the browser, which would make my scenario possible, no?

simevidas
2018-11-07

Yes, Chrome. But it also logs the user out of the browser when they log out of Gmail. And sync still has to be enabled separately via Chrome’s UI.

If someone logs into Gmail, enables sync, and still lets other people use the same browser without logging out first, then the browsing activity of these other people will be synced under that user’s Google account. This is not a problem with snyc.

Note that your scenario, as you described it, still isn’t possible since two people use different Google accounts on their devices, so only the primary user’s mobile browser would be synced with the desktop browser. Again, sync works as advertised, and it’s the user’s problem for letting other people use a browser that is logged into their Google account.

To summarize, adding website data to sync would not fundamentally change how sync works, as sync already stores the user’s browsing history and stored passwords. In other words, if one user’s sync includes data from other users, then the user has to fix that on their end.

tomayac
2018-11-07

Hmm, sounds like this could be a nice addition to Persistent Storage.

reillyg
2018-11-07

As an aside, Chrome Apps/Extensions have a storage API that includes synced storage. It looks like this is also included in Web Extensions.

simevidas
2018-11-08

Ok, I’ve read up on the Storage API (probably should have done this sooner :sweat_smile:) and posted a summary on my website.

So it turns out, that can be a lot of data, potentially even 100+ MB for a single website that has been granted persistent storage. Probably too much for browser sync.

However, if there was a way for websites to declare some of their data as “synced storage,” that could work. So websites would be able to promote a size-limited subset of their total storage as syncable, and then the browser would know that that part of the site storage is safe to sync.

nolanlawson
2020-05-24

This is an old topic, but I’d like to +1 it.

I noticed that when you transfer data from one iOS device to another (e.g. you buy a new phone), all of your apps come with it, including webapps you’ve pinned to the home screen. But sadly if you’ve set any user preferences, then you have to set those all over again.

So websites would be able to promote a size-limited subset of their total storage as syncable , and then the browser would know that that part of the site storage is safe to sync.

This would be ideal for the PWA I’ve built, Pinafore. Most of the data it stores in IndexedDB/Cache is not critical to be synced across devices (e.g. cached HTML/CSS/JS resources, cached social media posts), but there are some user preferences (theme color, notification preferences, etc.) which are basically a very tiny JSON file that would be nice to sync across the user’s devices.

Allowing the web developer to clearly specify which data should be synced would also solve the problem of “partial” data. The web developer would have full awareness that a newly-synced session might have the “synced” data but not the “unsynced” data. (Origin storage like LocalStorage and IDB are guaranteed to be all-or-nothing, completely cleared or not cleared at all.)

I’d guess the main argument against such a mechanism would be privacy and user expectations

This is tricky. The value of this API to me, as a web developer, is that I could store user preferences across devices without having to know anything about their identity, and behind the scenes Apple/Google/Microsoft/etc would sync their data for me. Unfortunately this very fact would allow me, the developer, to gain some knowledge about the user’s Apple/Google/Microsoft account.

I imagine an API like this would probably have to, at a minimum, be gated based on site engagement – e.g. it only activates if the user actually installs the PWA to their home screen. Perhaps UAs could also decide to be more explicit about this – the first time you boot up a PWA on your new phone, the browser might ask “Transfer site data for example.com from your old phone?” or something like that.

There’s also the question of update cadence and how one device may be notified of changes on another device. But because it’s probably too much to ask of developers to choose a conflict resolution strategy, maybe this API would be best as a simple key-value store with no expectation that the keys will sync together. (E.g. I update keys A and B on device 1, I update keys B and C on device 2, and now on device 3 I may get any combination of A, B, and C from those devices – developers shouldn’t make any assumptions about data integrity or transactionality.)