This is not necessarily a clear-cut bug per-se, but the behaviour is likely to be unexpected by some users. If you are using private browsing, you would expect Orion not to create an on-disk record of the site visited.
If you change a setting in the per-site settings, the site domain is stored in each JSON block in
website_settings.plist. Users may not expect this to happen.
If you undo or remove the custom setting, there's no reason to expect the site to still be listed (and you won't see it in preferences), but it remains listed in
website_settings.plist "forever more".
Doing Orion > Clear Browsing Data and checking everything, and picking since "All time", doesn't remove this! Therefore unless a user is aware of this plist, they have a (partial) list of sites they've ever visited lying around.
Some thoughts on handling this:
a) if a site is returned to the "default" state of local site preferences, remove the domain from the value array for each entry in the plist. This means if the site is visited and a preference changed unintentionally, changing it back will remove the site from the plist.
b) alternatively, domains in this plist could be hashed (i.e. using an HMAC) in this listing, with a per-install random seed as the key. This gives a very quick lookup when visiting a site, but frustrates any kind of easily "figuring out where your gift is coming from". This HMAC key could be erased and re-generated on a clear browsing data too.
c) consider whether these per-site settings should persist a "clear browsing data" for all time.
d) add a warning before the user changes any per-site prefences, to alert them that proceeding means the site domain will be stored.
There may be further knock-on bugs like this for some of the other "state" stores used by Orion, when browsing in private mode. As an example, downloads in private mode go into
Also, after clearing all site data for all-time, it does appear that everything has been retained on-disk. This might be a bug in its own right. Can't remember the name in sqlite, but looks like the db needs vacuum'd or similar to clear the container itself - running strings over the DB confirms the data is all still present on disk:
While the DB shows as empty in a client, it clearly isn't. The shm and wal files also still exist, and ought to be purged.