NOnotdang·Oct 21, 2020
Here is the issue if you are interested. It's still not closed:
https://github.com/stoically/temporary-containers/issues/371
In Facebook Container for Firefoxstoically
temporary-containers
TypeScript2018–2025
stoically / temporary-containers
temporary-containers
Firefox Add-on that lets you open automatically managed disposable containers
19Distinct people
21Mentions
0Explicit recommenders
905GitHub stars
What to know before exploring
What it is
Firefox Add-on that lets you open automatically managed disposable containers
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- mozilla/multi-account-containers · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 5:05:26 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year21 dated mentions
Observed mentions: 2018-04-18 01:11:23 UTC to 2025-11-12 06:07:51 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 4 | 0 | 4 |
What Hacker News says
5 sourcesIn temporary containers you can set up what should happen on different actions (left click, ctrl+click, etc) and different domains.
https://github.com/stoically/temporary-containers/wiki/Globa...
In Facebook Container for FirefoxI reworded my comment. My point remains in that a lot of possible issues disappear if I just choose to destroy the entire directory. There is a clear difference between one Chrome instance (and all its associated windows/tabs) segmented into one profile directory and in-process segmentation. The issues at [1] seem to invoke unexpected behavior in that you're asking for a new temporary container but you can't know ahead of time if that's what you will get. I'm writing "seem" because it's not clear from the description how that interaction works. They could be better worded.
With segmentation enforced at instance boundary (rather than in-instance), there is no unexpected behavior of this sort. All links open in the segmented instance that the browser window/tab you're using belongs to. If you want a new container, you start a new instance a
Read the rest
nd you know that's exactly what you will get. There is no possible "fail open" result. Note that I'm not saying the Firefox behavior you described is a major issue, just that it proves you can have unexpected scenarios.
Moreover, jedberg is correct in that cross-profile data leaking is possible (partly what I meant by "implementing profiles" properly), except that it's very easy to see if that's happening without auditing Chrome. Use a tool that records all filesystem operations (e.g. dtrace on macOS).
At the end of the day, I choose one set of trade-offs over another.
[1] https://github.com/stoically/temporary-containers/wiki/Isola...
Make sure to disable container sync when using this combination. It's easy to accumulate hundreds of temporary containers which somehow hoses your Firefox profile on Mozilla's sync server (and can also produce gigabytes of logs in your local profile directory).
It seems it's currently impossible to recover your profile once you reach "Maximum bytes per object exceeded" - the remote end won't even let you delete the offending data.
[1] https://github.com/stoically/temporary-containers/issues/371
[2] https://github.com/mozilla/multi-account-containers/issues/1...
In Google sued for secretly amassing vast trove of user dataWell, there are definite benefits to being in full control of profile segmentation.
You have no idea what the extension is doing unless you audit it. And even then, there are second-order effects that could surprise you [1]. Plus, the extension writer has to maximally cover the set of possibilities where a site can store/retrieve data. These are a lot of unknowns you're trusting and assumptions you're making.
It's far simpler to treat the profile directory as contaminated waste and nuke it at will.
The only assumption you're making is that the browser implements a profile in a given directory properly.
[1] https://github.com/stoically/temporary-containers/wiki/Isola...
In Google sued for secretly amassing vast trove of user data