Hello,

Release early, release often and whatnot. As it is unlikely that I will have much time to work on this before the next alpha[0], I will tag 0.0.11 now.

Changes in version 0.0.11 - 2017-07-18: * Bug 22910: Deprecate the volatile extension dir option. * Bug 22932: Add experimental Amensiac Profile Directory support.

As of this release `about:addons`'s get addon pane is no longer supported at all, reflecting the (unrelased) change made to Tor Browser.

As an additional defense in depth measure, addons inside the profile directory are explicitly and individually read-only bind mounted into the container, and even installing addons manually by copying the XPI into the profiles.default/extensions subdirectory will not work without altering the container setup and recompiling the sandbox.

Note that the mechanism for whitelisting addons is somewhat more fragile than I would like, and in an ideal world, the Tor Browser addons would both be stored in `browser/extensions`, and cryptographically signed with a Tor Browser specific signing key. But it's an imperfect world, and in a perfect one, I'd be dealing with chromium instead[1].

The Amnesiac Profile Directory feature behaves basically as one would expect. At launch time the profile directory is copied into a tmpfs mount inside the container, so all changes made to the profile are non-persistent. The option is hidden under the `--advanced` command line flag, because it's experimental and I don't want to deal with people asking why the browser ate their preferences/bookmarks.

The emphasis is on "Profile Directory", any files in the Downloads/Desktop directories inside the container are left as is, because I couldn't think of a sensible way to handle that, and a browser that can't be effectively used for downloads is rather worthless.

No special handling "the user ran the update with the setting enabled". Odd/undesirable behavior may happen, so don't do that. The UI option to enable the setting is clearly marked as "Experimental" for a reason.

Regards,