Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increase maximum total size (QUOTA_BYTES) for storage.sync #520

Open
hanguokai opened this issue Jan 12, 2024 · 6 comments
Open

Increase maximum total size (QUOTA_BYTES) for storage.sync #520

hanguokai opened this issue Jan 12, 2024 · 6 comments
Labels
topic: storage Issues related to persisting data. Topics include browser.storage, web storage, and new APIs.

Comments

@hanguokai
Copy link
Member

hanguokai commented Jan 12, 2024

Issue History

We have discussed:

#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.
@hanguokai
Copy link
Member Author

@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.

@hanguokai
Copy link
Member Author

@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.

@hanguokai
Copy link
Member Author

@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.

@hanguokai
Copy link
Member Author

@Rob--W said:

All vendors are against raising the maximum total size.

@hanguokai
Copy link
Member Author

@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.

@hanguokai hanguokai added topic: storage Issues related to persisting data. Topics include browser.storage, web storage, and new APIs. and removed needs-triage labels Jan 12, 2024
@hanguokai
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: storage Issues related to persisting data. Topics include browser.storage, web storage, and new APIs.
Projects
None yet
Development

No branches or pull requests

1 participant