[Safari]'Reset Safari' clears settings

[ghost]

Since version 0.9.1.0 resetting Safari through Safari > Reset Safari or Safari > Preferences > Privacy > Remove All Website Data also wipes the extensions settings.

Browser: Safari 7.1.4
OS: OS X 10.9.5

[chrisaljoudi]

This isn't a behavior we can do much about — so it's not a bug, really. That's just Safari's policy — it wipes database storage for extensions, as well.

Sorry for the inconvenience.

[ghost]

But why does that not happen with uBlock 0.9.0.0 and earlier versions?

[chrisaljoudi]

@vkusingisnor uBlock before that used a different (inappropriate) method of storage.

[gorhill]

Workaround: Backup your uBlock settings before clearing browser data. You can backup from the Settings pane in uBlock's dashboard.

[gorhill]

@chrisaljoudi The link posted by @Mojmir50 in #1091 is Adblock Plus workaround the issue by using Safari's hidden settings API. Is this something which could be used here?

[chrisaljoudi]

@gorhill well, uBlock currently doesn't distinguish between caches storage and preferences storage — if vAPI.storage could somehow be made aware, then sure, we could use Safari's settings API for preferences.

Does that make sense?

[gorhill]

I don't understand... Why the need to distinguish?

[chrisaljoudi]

@gorhill the caches for the filter lists, etc. can't go in the settings because they don't get the 100MB quota.

Preferences can go there just fine, though.

[gorhill]

Oh ok, the "nor do they seem to have a limit of size" in ABP's blog post led me to believe this could be solution. Never mind then.

I suppose distinguishing between outright settings and cached data is a possibility I suppose. Chromium/Firefox wouldn't care about the distinction, while Safari would...

Note that cached data is usually prefixed with cached_asset_content:// (for the cached remote data), or cache:// (for the compiled lists). I could possibly unify these two into cache://[...], so this way you could detect was is throwable or not?

Edit: actually that wouldn't be a good idea to do that right now, as users filter list is also saved as cached data, however there is no copy of it elsewhere. Kind of a problem given that there is no limit in size for custom filters.

[chrisaljoudi]

@gorhill well, the main thing is the following:

As per Apple's documentation, safari.extension.settings is supposed to be used for various user preferences, not for storing large amounts of data. They provide the database API as the recommended way for storing large amounts of data — and that's what the quota of 100MB corresponds to. There's no quota for settings.

I've written a few tests, and it appears Safari is (in general) happy to let things stored in safari.extension.settings grow indefinitely. To add to that, it appears Safari likes to keep the settings in active memory, and I suspect that's why some crashes were caused when loading huge filter lists.

Arguably, this is a bug in Safari (extensions can take arbitrary amounts of memory without user knowledge). It's a serious one, at that. I'd hate for uBlock to pose that risk on the user.

Also noteworthy, it might also be a bug that Safari clears extension databases when Safari is reset.

Should I submit both of those as bug reports to Apple?

Note: while it'd be perfectly possible to switch to using safari.extension.settings for storage, that really is a hack and it feels dirty to misuse it just because of a vulnerability.