Giters

w3c / webextensions

Charter and administrivia for the WebExtensions Community Group (WECG)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Increase maximum total size (QUOTA_BYTES) for `storage.sync`

hanguokai opened this issue · comments

commented

Issue History

We have discussed:

  • the maximum total size for storage.local at #351 . It is increased from 5MB to 10MB.
  • the maximum total size for storage.session at #350 . It is increased from 1MB to 10MB.
  • #510 concentrates on the "Maximum item size" for storage.sync, not "Maximum total size".

#351 originally discussed "Maximum total size" for storage.local and storage.sync , now leaves that issue to storage.local only.

This Issue

This issue concentrates on "Maximum total size" (QUOTA_BYTES) for storage.sync. At present, storage.sync has 100KB limit. This limitation has existed for a long time. As user devices and cloud storage capabilities improve, should it be increased now?

The browser's built-in support for data synchronization is great, because it's non-trivial for developers to create their own cloud synchronization service. This requires developers to:

  • establish their own account system and/or obtain authorization from third-party storage services (e.g. Google Drive, iCloud, Dropbox).
  • cloud syncing also means that extensions collects user data and storage it on extension's server, and users may be concerned about their personal privacy.
  • cloud syncing have costs. Developers not only need to spend time developing, but also need to bear the corresponding costs on a long-term basis. This means that developers need to charge users, otherwise it will be difficult to provide this service.
commented

@fregante said:

Great to see that storage.local has been bumped to 10MB. Can storage.sync also be increased? 100KB is quite a small amount of data for 2024.

commented

@Juraj-Masiar said:

I'm using storage.sync in several of my extensions and I highly support this upgrade. Although, to be realistic, 1MB may be too big upgrade for browser vendors. I would be happy even with 512KB or 256KB.

commented

@oliverdunk said:

This is the trickiest one to change since we would need to make sure the syncing mechanism in Chrome is able to handle it. Happy to discuss it but I suspect there would be some hesitation.

Agree that there aren't any steps to take with storage.sync though.

commented

@Rob--W said:

All vendors are against raising the maximum total size.

commented

@dotproto said:

To add a bit of context, vendors are against raising total storage limits because of the impact this would have on their synchronization services. The sync storage area is primarily meant as a way for extensions to share configuration or settings data across logged in browsers. It is not meant as a general purpose storage solution. Developers that need a way to store and sync larger amounts of data should consider standing up their own backends or look into cloud storage solutions.

commented

In the original issue, I updated for developers' own cloud service.

it's non-trivial for developers to create their own cloud synchronization service. This requires developers to:

  • establish their own account system and/or obtain authorization from third-party storage services (e.g. Google Drive, iCloud, Dropbox).
  • cloud syncing also means that extensions collects user data and storage it on extension's server, and users may be concerned about their personal privacy.
  • cloud syncing have costs. Developers not only need to spend time developing, but also need to bear the corresponding costs on a long-term basis. This means that developers need to charge users, otherwise it will be difficult to provide this service.