Temporary Containers redundant with TCP / FPI? #1519
Comments
|
If your use case is partitioning websites (which I think a lot of privacy-focused people were doing) then they are redundant in that sense. As dFPI partitions websites with ETP Strict, TC is redundant here. Arkenfox has preferences to sanitize on shutdown to prevent persistent storage and does not recommend using custom ETP settings (but setting exceptions instead). The threat model here excludes first party tracking as if you log into sites, they already know who you are. In-session sanitizing won't really do anything without changing your IP on other sites. This is why it's recommended you use Tor Browser if your threat model calls for it. However, people still use containers for managing multiple accounts, but this doesn't really have anything to do with tracking. |
|
Yeah, those are all fair points I agree with. But in my mind the wiki paragraph about TC doesn't reflect that properly and makes an incomplete comparison that could easily get misinterpreted if read in isolation.
Obviously I have no hard data to support my perspective here, but I assume that regular ad trackers do rely on storage primarily, as IPs are way too broad nowadays with all the shared ipv4 on mobile and DSL networks going on due to address room shortage. So in-session separation would give you additional protection in this case. Also without Tor, just clearing all data on browser shutdown is not enough either, you would need to make sure that you get a new IP from your ISP as well. Tho, the TC paragraph does mention that already, yeah. |
Might be an idea for a little add-on actually, that blocks browsing if you still have the same ip when the browser starts. 🤔 |
|
stoically
that's what sanitizing on shutdown is for. There's also "forget about this site" (right click a history item), "manage data" (selectively), ctrl-shift-del (except it doesn't respect cookie/site-data exceptions yet), and "clear data" (the lot). I get that it's manual rather than done automagically stoically
I have already stated IP is an issue. TC doesn't solve that. Neither does sanitizing. That's what VPNs are for. Or as we state in numerous places .. use tor browser if it suits The point is that partitioning is MOOT, so the only benefits from TC
Sanitizing in session IS a false sense of privacy. It's the definition of insanity - doing the same thing over and over again. Is it a bad thing? Not really. Could it help? Sure, bound to somewhere - but not everywhere - it's a FALSE sense of privacy
I am not really interested in propagating this. I've said TC was redundant with FPI years ago. It's still redundant with dFPI. remyabel2
That's actually not such a bad description, but not entirely accurate. For example we don't want (edit) any linkability - e.g. referrals, params, ids. And we obviously sanitize on close (which still does not address the IP problem), but it is built-in and does not require an extension. Are there edge cases for users to use TC? Sure. If you want to use it, that's on you. But it still doesn't solve the IP problem. Imagine if I listed it in the maybe section, then I have to add a bunch of info that people don;t read, and then don't understand. This is about the fifth issue someone has said my words are incorrect. They are not.
Anyway, I find the whole IP issue to be out of scope - we recommend Tor Browser, and there are hundreds or articles/sources for VPN info If you want to use Firefox to protect against repeat 1st party, outside of a user.js, then go ahead and use a VPN and change it all the time and sanitize on eTLD+1 + scheme close, and don't forget to keep track of when to change your IP to be sure you aren't linked. Sounds way overkill and not something I care to constantly discuss. That's why we recommend Tor Browser |
|
I'm not challenging any of the points made, I'm actually agreeing. I'd just appreciate if the arkenfox wiki paragraph about TC would mention that TC gives you proper storage cleaning, something TCP/FPI does not give you - and that, in this sense, TC is not redundant. Since, if you read that paragraph without having the bigger picture, it might give the impression of it being the same thing. Whether new storage but still same IP is something to be concerned about is the question of the personal threat model. Clean storage and new IP gives you more privacy, that's for sure. |
sanitizing on shutdown gives you "proper storage cleaning" TC is grouped in with "cookie cleaners" as a single entry but has two parts. The first part said "redundant" re 3rd parties are already isolated re dFPI. The second part doesn't say anything about redundancy and is about sanitizing. I mentioned I edited the wiki. I actually removed the word "redundant" in the first bullet point Nowhere does it say dFPI sanitizes |
|
damn, I guess I didn't save the wiki edit - weird |
|
Thanks for the edit, that solves the issue from my perspective, but of course feel free to reopen if you see the need for it. |
|
Maybe a tiny suggestion: Calling the section "Don't bother" feels a tiny bit rude. Maybe it could be worded a bit more friendly. 💚 |
|
Random thought regarding alternative naming: Maybe the sections could be ordered and named by their type of threat model / amount of convenience? |
Maybe "Redundant"? BTW I love TC 🎩 |
|
re-opening, because changes are coming |
|
I am not against using containers, or MAC. I'm not even against TC. Containers provide additional uses (such as multiple logins) and fallbacks/safeguards (see #1448). I'm still going to stick to my guns and say that sanitizing in session is not a valid solution on it's own (but it is if it's to reset a login for example - e.g. same as "Forget about this site" - so e.g. bypass paywall limit, fuck yeah, enjoy the popup cookie banner each time though) Anyway, lumping TC in with don't bothers is a bit harsh. Yes the partitioning is redundant (we're already partitioned, baring bugs), yes sanitizing in session is a false sense of privacy. But contextIDs (or is it contentIDs) are a great secondary isolation feature Also MAC + VPN support: someone correct me if I'm wrong, but I'm guessing here that the VPN only kicks in on containers you specify, and in future if not already, you can specify what VPN (or exit) to use per container? Anyway, more reasons to highlight container extensions as maybes Anyway, @stoically .. rejoice |
You're almost never going to see cookie prompts when subscribed to one or two Annoyances filters.
FWIW it's userContextId
I think this was already possible since 8.0.2, but
is going to cause DNS leaks if you are not behind a full tunnel (e.g. pac) and forgot to manually turn off uBO's CNAME uncloaking option (also discussed on this repo). But personally it would be nice to have random SOCKS5 proxies per temporary container when it happens. |
|
thanks. yup, there's lots of potential with containers as a simple means to group sets of domains |
|
@Thorin-Oakenpants Thanks for taking another look! Regarding the "sanitizing in session" perspective: For me personally that's not why I'm using TC, nor is it something I consider particularly valuable in my day to day browsing. Instead, my threat model allows me to lean more towards the convenience side, which means that I don't delete all data when my browser shuts down. Without TC that would leave me with permanent storage in the long run – and that's what TCs solve for me: They make sure that I don't end up with long-term storage for random browsing, in addition to also isolating sites from each other properly. If I want long-term storage, I use permanent containers for that. Obviously that's not as reliable or privacy-focused as deleting all data when the session ends, but it's way more reliable and privacy-focused than traditional cookie cleaners. Hope that makes sense – otherwise please let me know!
Something I started working on, but never finished and probably never will: "Random IPv6 per TC"
It was a fun experiment tho :D |
|
I find this discussion very interesting! But the question could be considered from the other end: If you have some temporary/ephemeral container extension enabled, what more bring TCP and dfpi to you exactly (under the hypothesis that the extension in use is properly functioning of course). Moreover, concerning this thread's topic I read here that @ThorinOakenpants wrote:
The "same ip" question seems to the basis of the argument. So, what about using a mechanism assigning different proxies to different containers (btw such extensions appear to exist on AMO, with few users and not updated since quite a long time for sure, but we have a principle discussion here, so let's suppose they are functioning without any bug/leak)? Edit: Some example of extensions of the "container per proxy" type (just found 3, I didn't test any of them): Alternatively, it's probably possible to get half theses features in using a temporary/ephemeral containers extension in conjunction of a proxy PAC. |
It's still inferior to Tor browser. VPNs and proxies offer dubious privacy. You are moving the traffic from your ISP to a VPN, who you have to trust not to log and to trust will not be able to provide your data to third parties (i.e, via subpoena). Even masking your IP, you are still very fingerprintable and even Arkenfox admits this. Using Tor, your fingerprint in theory should be identical to every other Tor user. Further, Tor uses relays in order to separate the IP from the data. One relay knows who you are, the other relay does not but knows your data, so long as the two cannot be put together, you are in theory browsing anonymously. This of course is defeated if you do not change your browsing habits or if they are able to put 2 + 2 together with a correlation attack, but it is much more difficult to pull off with Tor, and trivial to do with another browser even with anti-fingerprinting measures. So in other words, if your threat model requires anonymity, Tor is still the best solution. For all other cases, trying to emulate Tor is a false sense of security. |
Tor is plausibly better but the topic of this thread is not x or y vs Tor but TCP & dFPI vs ephemeral/temporary containers. No matter what, it is not entirely clear that Tor is extremely superior to the usage of rotating nested independant reputable vpns because:
|
That part was already discussed earlier. I brought up Tor to illustrate that what you're looking for probably does not offer the privacy advantages you want.
And how exactly does Tor leak DNS? If you use Tor with VPNs, this is possible, but should not happen on a regular setup.
Based on what metric? There's been plenty of documented incidents of VPNs either being malicious or incompetent. Regardless, Tor's model is trustless in the sense that you don't NEED to trust the relays because of how it routes traffic. With VPN, you do need to trust the provider. Even with a malicious exit node, if you only visit HTTPS sites, it's not really an issue. |
|
|
I can't find it now, but there was a thread on HN just the other day where someone (and there were other examples) blocked certain companies, ended up with a completely broken internet and devices would hang (or something) long story short, there are six or seven companies that control such vast swathes of the backbone and services, that it's become impossible - think akaimai, cloudflare, aws, azure, alphabet, etc. And IANAE or inside trader but I bet they all log IPs (and probably monetize it) - once someone else has your information (like an IP address), then you have lost control of that info - you do not know nor have any bearing on how that info is shared or sold The solution can only be: Tor, VPNs. Side note: this is why LocalCDN is marked as don't bother (which really seems to upset some redditors). If you protect your IP, then it's not needed. If you don't protect your IP, then it's pointless - you are a billion times better off using alternative services than pissing around with a minuscule few libraries |
|
|
that;s the one: https://news.ycombinator.com/item?id=32618018 |
|
My thoughts on the IP discussion from the targeted ads perspective:
Thought from the security perspective:
However, that leaves the question: Why does Tor exist? Why would one want to mask their IP?
Just my perspective and no claim that it's complete by any means. If you spot an error or something important that's missing, let me know! Note: This comment only concerns itself with the IP-perspective. Browser fingerprinting is a different story, even though related to some extent. |
|
You bring up some valid points but I disagree on some fronts. First regarding ads and IP tracking. I have all Facebook domains blocked on the DNS level and ublock origin also has filter lists for this. If you use Facebook then again arkenfox’s stance is that Facebook already knows who you are. You can use multi account containers to separate accounts, but trying to use Facebook “anonymously” is going to be nearly impossible with the amount of measures they take to identify users.
With Tor, it is true that Tor is useful to protect against state actors. That doesn’t mean you should only use tor for that purpose. Does and can intelligence agencies snoop on ISPs? Yes. That’s how they do correlation attacks. It does not change anything fundamental about tors security model though. The NSA can snoop on your ISP and the exit nodes ISP, but this alone is not enough to identify you without forensics work (or if the user is browsing without TLS and/or sloppy browsing habits).
Regardless, this isn’t about Tor versus VPNs versus Temporary Containers, more that different tools are useful for different threat models. I suppose my ultimate point that got lost in the confusion is that if you are trying to be anonymous with TC and VPNs, Tor is the better solution. TC and VPNs still have their respective usecases (I personally do not care about VPNs but my thoughts on those does not affect the conversation)
… On Aug 30, 2022, at 3:22 AM, stoically ***@***.***> wrote:
My thoughts on the IP discussion from the targeted ads perspective:
Something that became publicly known with regards to abusing IPs for ad purposes, was the fact that Facebook used them to determine the location of users and showing ads based on that: https://9to5mac.com/2018/12/18/facebook-location-privacy-ads-settings/. That kind of technique makes sense for them, given they – and other companies – sell ads, and the more targeted they can deliver the ad, the better they can sell their product.
Given that selling ads as targeted as possible is one of their key features, it also means that they have an interest in data sets that are as precise as possible. Mixing IPs into those ad-relevant data sets that not clearly belong to logged in users – based on storage – would introduce fuzzyness into the data sets, since without being logged in it's almost impossible for regular services on the web to assign the user to their respective data set.
People and companies using the marketing tools from companies such as Facebook never think in terms of IPs, nor do they have the ability to configure their campaigns based on them. Instead, it's always about target groups and locations.
So, basically: Using IPs for location-purposes and logged in users makes sense, trying to identify an user by using them, not so much.
Thought from the security perspective:
IPs are logged from services for the purpose of security and accountability. Basically: "How can I get the address of my user to sue them if they abuse my service?"
However, that leaves the question: Why does Tor exist? Why would one want to mask their IP?
Tor was invented as tool to protect state-level actors and especially their international communication. Hence why it made sense to make it a public project, so they can get as much traffic as possible to mask them. Those communications likely still happen over the network. You really don't want to leak your IP – and with that your location – to state-level actors, which obviously do have the means to query ISP databases one way or the other to get your precise location.
Tor is especially useful in countries where surfing on the wrong websites could get you actually into jail. In those situations leaking your IP to state-level actors, like the great firewall of china, makes you directly identifiable.
Tor hidden services are unique in what they make possible. Hosting sites while keeping the hosting party anonymous. Markets and similar sites still are popular target when using Tor.
Since Tor masks your IP, it also prevents that ad companies can serve you ads based on your actual location. It doesn't stop them from showing you ads for the IP you appear to be coming from.
And Tor lets you circumvent IP-based security measure from services you want to use – if they not already block all exit nodes.
Just my perspective and no claim that it's complete by any means. If you spot an error or something important that's missing, let me know!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
|
IP is just another fuzzy data point in FPing. e.g. is it a known tor exit node, is it a VPN, what VPN group, what ISP hub? It can used or discarded at will to help link footprints |
I'd be interested in details, like what kind of ads and what kind of perceived identification. My assumption would be that, given an unique enough browser fingerprint, they might even correlate you to an actual user or shadow account. If not unique enough, or just IP, I'd assume the general connection to a target group in combination with the IP location. My comment was solely about IPs.
Absolutely. I tried to cover that with my point about "If they try identification via IP, it will get harder with Tor". But you might've missed that, given I edited and you replied by E-Mail.
Also agreed. Just wanted to give my perspective on the IP discussion. As for which tools to use and when totally depends on the threat model and desired amount of convenience.
Yep. I just wanted to highlight my focus on IP here. I'd assume that if browser fingerprints are perceived as unique enough, they might even be used to correlate with actual user accounts, not only target groups / locations. |
Not sure what you mean by unique enough browser fingerprint. It does not take that many data points to uniquely identify someone. But when you combine browsers, OS, monitor size, addons installed, etc. you start reaching hundreds of data points. IP by itself is not that useful because users behind NAT or with DHCP can have a new IP assigned regularly. Even if you change your IP regularly, data brokers are quite good at linking profiles together.
Tor makes it look like you're browsing from a different IP and uses anti-fingerprinting. The two are required in tandem. I believe I mentioned earlier how relay A knows your IP and relay C knows your data, so long as the two cannot be tied together, the user shouldn't be identified (ignoring the usual exceptions like zero days, lack of TLS, sloppy browsing habits).
At this point I think the discussion is starting to tread into anonymity vs privacy territory. Say for the sake of example I have an online identity that is separate from my federated (government) identity. If I do all of my online browsing under that identity, even if people do not tie it to me, for all intents and purposes I am that person. So if a data broker only knows me by John Smith, all of my data can still be linked together to give me targeted advertising even if I attempt to be anonymous. If on the other hand, your goal is to decouple your federated identity from browsing habits, then again Tor is the way to go. There are way too many avenues in which someone can be identified (VPN subpoena, breaches, leaks, username/browsing history correlation, etc.) that makes any solution compared to Tor inadequate. |
That's the only point I'm challenging. Given the shortage of IPv4 and all the sharing going on, I don't think it gets used for linking to specific accounts. Regarding everything else we're on the same page. |
|
for your amusement: https://news.ycombinator.com/item?id=32661061 |
I'm not able to detail you precisely how. But in the past, Fash and Java were able to deanonymize a Tor user (because Flash and Java could bypass Tor, who handles only TCP web connections). Flash and Java never were able to deanonymize an openvpn user. You may think Flash and Java are the past. But still, I recently found a website able to detect installed apps on the device and using the detected apps list as a fingerprint. So, a wab page is in some way able to detects apps on the device where the browser is running, and so, (why not) could be able to trigger some of them to start a network connection bypassing the Tor Browser and revealing the true non Tor IP of the Tor Browser user.
Ah! The "metric" question! So If you were claiming that Tor is more anonymous than the simple usage of a socks5 proxy found somewhere on the web, I could argue "but based on what metric?", and it would be a valuable argument as there isn't yet any universally accepted metric for measuring anonymity? But whatever... When I wrote that "the probability of a server being evil is lesser when it belongs to a reputable vpn provider than when it belong to the Tor network (particularly concerning the servers acting as exit nodes)." it was based on Occam's razor metric. When a vpn provider has over the years gained good reputation, it is not in his interest to do anything that would destroy this reputation in an instant. On the other hand, a Tor exit node operator has no reputation to uphold. I don't think this means it is incentive for the average Joe running a Tor exit node to become rogue. But this is incentive for already rogue guys to run tor exit nodes
I was explicitely speaking in my previous post about "reputable vpn providers". Maybe I should have precised "competent and reputable vpn providers". And concerning those, there are several documented incidents when some of their servers have been seized, without revealing anything.
By now, most of the clearnet sites are https, but not all. And most .onion site aren't (although due to onion routing, this is far less a problem than on the clearnet). And remember that Wikileaks started out by running Tor exit nodes and sniffing traffic for documents and emails.. Edit: I corrected a missprint and replaced the sentence "And concerning those, there are several documented incidents when some of their servers have been seized, without revealing anything" where it was intended to be. |
I think you're talking about 3 letter agencies unmasking users with Flash, which is decades old and which also hasn't been an issue in ages. not to mention tor browser blocks plugins and Flash is no longer in the codebase of firefox based browsers. also the PoC that could identify installed apps was never fully functional or close to stable right? I remember it gained traction but then it died down quickly, I can't remember the name. someone correct me if I'm wrong.
you are describing an attack where a certain website forces the tor browser to open a not better specified app, in order to force it to make a connection to a not better specified endpoint that the attacker should also control to some extent (and at what point of the network would it be and how would it correlate the traffic), in order to log an IP. this doesn't seem real or reasonable, it's best to set the record straight.
just by design, the way Tor works. which also easily answers the rest of the points, eg. why you'd rather trust Tor vs a VPN provider or why most onions services are not HTTPS. |
https://www.submarinecablemap.com/ I'm going slightly OT but I love this map. click on the cables connecting the US to Europe through the Atlantic Ocean, and to Asia through the Pacific Ocean: these companies you mention own a good number of these submarine cables, they are also telcos at this point. |
The same design that allowed so much TorHiddenServices to be closed by the police, and their operators, identified and arrested?
Ok, so, tell that to the famous bomb hoaxing Harvard student... The police has been able to identify him because he has used Harvard's free Wifi and was the sole user of Harvard's network using Tor at the precise moment where the threat has been made. Tor over Vpn is better than Tor alone, at least for those who try to not be identifie. I think it's not so hard to understand. |
Using a VPN with Tor is complicated and not recommended in most cases.
In terms of identification, a VPN is not any better than public wifi. Both can be logged, both have audit trails.
That is circumstantial evidence, but not enough to persecute. If the police use a geofence warrant to find a list of suspects in an area where a crime is committed, that doesn't mean any of them actually committed the crime. His poor OPSEC, not Tor alone, led to enough evidence.
Sure, and there's been many cases where someone using a VPN was identified by the FBI either due sharing the logs or poor OPSEC. There's a difference between exploiting an inherent flaw in Tor's security model and old-fashioned police work. |
|
stop the VPN vs Tor discussion - this is about TC and a decision has already been made (to change it in the wiki) |
|
@stoically - DONE: https://github.com/arkenfox/user.js/wiki/4.1-Extensions#-optional - any nits? |
In the DON'T BOTHER section I think is clear what TC is not going to provide, but can't see why it is recommended. I think something more explicit should be mentioned in the OPTIONAL section, maybe explaining better the disposable nature of the containers and some use cases? |
look harder - the very first point. I'm not going to regurgitate use cases. It can't hurt and there are other edge use cases, e.g. if you use a VPN and hop, or to repeatedly bypass paywalls in session, whatever - but I'm not going to hold hands and write everything up |
|
Mmm I guess it's me but I find this part confusing: "this is not why it is recommended as optional". I think it's confusing because, by the way I read it, it's like the "why it is recommended" part is missing in the sentence. If I'm not overlooking or misunderstanding badly something, maybe that very part can be replaced by just saying that users should pay attention to what is mentioned in the DON'T BOTHER section. What about something like:
|
|
what's so confusing .. |
|
Lol I'm very sorry but I can't get it! 🙃
Why is it then? Still, I get that other addons like for ex. Request Control, Redirector or Smart Referer are listed without explanations, so yea I guess is up to the user to understand why when not explained in the wiki? |
we've been through this ... try harder - the first point for starters |
Oh boy 😆
If it is, then that looks to me like a cautionary note not a recommendation! I mean, I know why it is recommended (hopefully! 👀): because of the disposable nature and on-demand tab "shallow"(?) sanitization. MAC benefits are super clear, why is TC recommended as an optional addon? Please tell this poor droid how to logic 🤖 |
No, that's linked to as a reason to NOT use it POINTS/REASONS for leveraging containers
goodness gracious. Does anyone else have a hard time understanding this? |
|
The first point, even if that bug didn't exist: e.g. you disable ETP for a site to make it work properly, you're still isolated |
|
Those points are crystal clear to this unit! 🤖 💡 (forced decomissioning is authorized if the statement result false). Are you mentioning TC mainly because of the containers and not really for the temporary nature? So basically as an alternative to MAC? (isn't MAC required for TC to work?) As an aside, I can't really see a benefit using TC instead of a normal container regarding the bugzilla ticket. Just to recap, when a cookies-exception rule for a site
I don't remember is TC auto container when navigating other domains on by default? |
I just said the sanitizing part is NOT the reason, and I want to make that painfully clear because it's a false sense of privacy. So what do you think is left? I didn't say to not sanitize with TC, I just said it's not the reason people should be using it
TC is there (optional) because it shouldn't be in don't bother (that doesn't make the points about dFPI already existing and sanitizing in session being a false sense of privacy, moot, bugs aside) - which is what this whole issue was about. TC needs to be listed because if it wasn't people would badger me, and besides, it's good to point out the sanitizing false sense of privacy and to show that cookie extensions lack dFPI compliant APIs, but TC doesn't If you can't see any benefits, then read this issue. As I said, I never listed it in don't bother for useful edge cases, but because dFPI already existed and sanitizing in session is a false sense of privacy.
IDFCare. If you want to use TC go for it, otherwise, who cares. Take all your configs and edge cases and examples and burn them. And YES, it adds an extra layer of isolation and protects from that bugzilla, regards of the config, because the origin attribute is still keyed by contextID - and TC can clean up after itself if you want, so fuck the exceptions for sanitizing on close. And if it's a permanent container, then you can configure it to not clean up after itself, or to do so. I do not use TC, and IDNotFCare. Take all your questions about TC to the TC repo. Not my fucking problem I considered the points raised by stoically, and no one denied me my points. But because there are edge cases, and because of that bugzilla, I agreed that we should move it. My job is done. End. Of. Story. |
|
sorry for the tone, but seriously, I've had enough .. locking |
|
I'm very sorry! |
Looks good, thanks! |
Hey, I've noticed that you mention that TC is redundant with TCP / FPI. From my perspective that is not the case. I've written down my thoughts on that here https://github.com/stoically/temporary-containers/wiki/Comparison#total-cookie-protection and I'd be interested if I'm wrong with my claims?
You also mention that "in-session clearing is a false sense of privacy". Generally I agree, however, with TCP and FPI you get long-term storage. While with TCs the storage is gone together with the container, so I feel like that's a distinction that could still be highlighted. Also, personally, I'd say that if the bar is "everything that doesn't give you full privacy is a false sense of privacy" then that rules out everything besides Tor browser still.
Thanks for your efforts and please let me know if you spot inconsistencies in my perspectives.
The text was updated successfully, but these errors were encountered: