In the past few days I’ve released ScriptSafe for Firefox and pushed out updates for Chrome and Opera. There were some new features, but what’s notable is the work behind syncing which I will detail in this post.
One of the items in the changelog is: “Improved syncing reliability and added support for handling data compression (to be switched on in an upcoming update)”
Reliability encapsulates the following features:
- if an Options page is open on a device and new settings are detected and downloaded, the Options page auto-refreshes to ensure it reflects the latest data
- if the download process detects incomplete data, it will stop and alert you that it will disable syncing to prevent your ScriptSafe instance from being overwritten with incomplete data
- the period between an action (i.e. adding a site to the whitelist) and syncing in this update has been reduced from 30 seconds to 10 seconds
- the sync storage will be cleared prior to syncing the new data to remove any stale/unused data
- each synced data item is prefixed with a timestamp matching the sync timestamp to ensure that they are always unique and up-to-date
The newest updates for ScriptSafe for each respective browser includes support for data compression. And as noted: it is to be switched on in a future update. “Future” being the amount of time where virtually all users will have the newest version.
ScriptSafe for Firefox already has data compression fully switched on as it is a fresh start from 0 users. Opera Browser currently doesn’t support syncing for extension data but when it does ScriptSafe will be ready.
Chrome is the main concern since it has over 180,000 users and change must be gradual, unlike the Firefox build.
The risk of releasing compressed syncing too early is people losing their settings they’ve set up over the years, which is the last thing I want to happen and one of the reasons why the newest release for ScriptSafe took the time between v184.108.40.206’s release date and v220.127.116.11’s: I tested it intensely on various devices, operating systems, and Chrome versions.
In my testing I also created a prototype v1.0.9.x:
- v18.104.22.168 sends and recognizes only legacy data (uncompressed)
- v22.214.171.124 recognizes both legacy and compressed sync data, but sends data only in legacy form
- v1.0.9.x only sends compressed sync data
I’ve created an interactive page where you can try out the compression:
The more data there is, the higher the compression ratio.
Over the years I’ve had users report that they’ve reached the sync storage quota (102,400 bytes), so this is something that I’ve always had at the back of my mind to implement.
Some quick testing shows that with compression, users are able to sync around 411,872 bytes of uncompressed data, which is almost four times the current amount. And as a bonus: it obfuscates the data that’s being stored.
So, it will come in due time once everyone’s devices has had an opportunity to upgrade to at least v126.96.36.199.
(I must note that it only syncs data to the official browser servers: Google for Chrome and Mozilla for Firefox. No funny business, there is nothing in the code that sends data to any third-party server.)