Closed elaine-jackson closed 1 year ago
It's already possible to use Tor in the whole browser by setting up Tor as a SOCKS5 proxy for Chromium. I suppose some UI to make this configurable for private tabs wouldn't hurt.
@Eloston And on ParrotOS you can enable anonsurf and force all traffic including DNS/WebRTC traffic (enforced with iptables/netfilter) to route thru Tor that said integrating a Tor binary into ungoogled chromium would make the privacy benefits of Tor more accessible to people.
I don't see any benefits of bundling Tor. All users of Tor already install a Tor client themselves (from what I've seen), so there would be marginal benefits at best; it will certainly complicate an already complicated packaging process.
On the other hand, adding features to improve interoperability with Tor is fine to an extent. I will need to see what the implementation is like before I can make a decision.
Here's how you can use Tor for specific domains in Chromium.
1) make sure you have Tor proxy for SOCKS5 (in Linux, "apt-get install tor" should be enough) 2) install Proxy SwitchyOmega extension 3) make a new PAC profile 4) create a PAC script, like this for example which uses the proxy for reddit (not for 3rd party domains!), for all .se domains, and for one .onion url
This is laborious, and this can potentially leak your real IP (if you for example don't write all the needed 3rd party domains for the website you want to browse through Tor), but that's how you can do it if you really want it.
@tonowoe We're well aware extensions exist for this task. We are looking into an integration where it's a native feature of the browser.
@intika
The more i read issues the more i think ungoogled-chrome will become a whole different browser on it's own
If the development momentum grows, this might happen. There isn't much else that can be done relating to removing Google integration, which is why I started venturing into other areas.
I am not against ungoogled-chromium evolving further beyond, and outgrowing its given name. But IMO, at least a small team of people would be necessary to make that a reality.
may be a lot more to maintain if you are doing it alone, or may be get paid by search engines and working on the project full time if it's not already the case :D :P
For personal reasons, I don't believe I will reach that level of involvement. In addition, I will not want to be paid to work on this project.
I use ungoogled-chromium with TOR socks proxy. However I find a difference comparing it to Tor browser bundle (TBB). I don't know why but some websites which use Cloudflare show captcha challenge test while the same sites work on TBB without showing that. Testing in command line with the exact same headers which TBB sends also results in recaptcha page:
curl <url> \
--proxy socks5h://127.0.0.1:9050/ \
-H 'User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0' \
-H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' \
-H 'Accept-Language: en-US,en;q=0.5' \
-H 'Accept-Encoding: gzip, deflate, br' \
-H 'DNT: 1' \
-H 'Upgrade-Insecure-Requests: 1' \
--compressed
So it seems to me TOR socks may not be enough and TBB may be adding something else to the whole picture.
Thoughts?
And one more thing: the feature to request a "new identity" in TBB is essential for avoiding the possibility of fingerprinting based on site visits associated with UA string + IP address. TBB can request at least a change in the IP address. However in UGC all we can do is wait for (~10 minutes) until the tor service connects another socket. So ideally a function which can spoof UA an IP (periodically, manually or more fine controlled) would be great. Not sure what programming that requires though... (trusting UA-spoofing extesnions is questionable too)
Tor have nothing to do with the scope of this project... at best a fork should be made for that purpose
Tor have nothing to do with the scope of this project... at best a fork should be made for that purpose
Well, this issue has not been marked as rejected but as enhancement and is still open which I read as "open to discussion". So I don't quite see the reason for downvoting my comment which is on topic for both Tor and privacy in general.
@anchev i know that you are on topic here regarding this issue, i down-voted the comments about integrating tor as a feature because this is out of the scope of uc which is more or less cleaning chromium not bundling other security related application/extensions/protocols... thus said nothing prevent anyone from integrating this to the browser in a fork, and or PR a light acceptable modification like proxy per tab or proxy in incognito mode as @Eloston already mentioned
Plus the asked feature is something that have to be done on the other end (tor extension/tor proxy) not in UC
I didn't suggest integration or any particular development strategy. I just read what @Eloston said:
I suppose some UI to make this configurable for private tabs wouldn't hurt.
and shared some observations and general privacy considerations along these lines (as Tor is about privacy).
...as a SOCKS5 proxy for Chromium. I suppose some UI to make this configurable for private tabs wouldn't hurt.
@anchev I didn't know about the identity rotation feature of TBB. Is it not possible to do this in an extension?
@intika I believe Tor integration should be fine if it's an optional feature. However, like I said earlier, I will need more information about the implementation for me to decide. Namely, what kinds of features beyond the capabilities of extensions would be included? How will these features be implemented?
Is it not possible to do this in an extension?
I am not aware what extensions can and cannot do, so I cannot answer. But you can take a look at Tor Browser's User Manual which explains about managing identities.
I believe Tor integration should be fine if it's an optional feature.
My thoughts exactly. It should be up to the user.
Namely, what kinds of features beyond the capabilities of extensions would be included?
AFAIK TBB runs its own tor service. It also includes that security slider which I personally find fairly useless as one who cares about online anonymity would generally always keep it on "Safest" position as the moment JS comes into action the game of cat and mouse changes quite a lot in favor of the mouse.
Another thing which should be given special thought IMO and which is currently problematic in TBB (being a Firefox fork): the "fingerprint" which can be created by extensions themselves. Example: extensions like uBO which connect to various hosts to update their lists etc. This is a privacy problem because one can be identified by the pattern of the hosts one connects to which does not depend on IP address, UA string or cookies. Right now there is this issue related to Firefox's bug which causes "private browsing" (AKA incoginto mode in Chrome) to always force an update of all lists in uBO. While there is no such bug in Chrome (respectively UC) I think it should still be considered and addressed properly if a Tor-like or similar extra privacy features are implemented. For example: in "anonymous mode" (or whatever it may be called) such connections should not be made through the same identity which the actual browsing uses. Otherwise anonymity can be compromised.
Similarly: special care should be taken to warn the user that browsing the web itself may create a detectable pattern. To prevent this: Ideally each HTTP request should be made through a separate identity. However while this may work for sites which don't require a login (cookies) it may be problematic for ones which do. I am not aware of how this can be done efficiently. Just sharing some thoughts on the subject as many people falsely think that it is enough to hide one's IP address in the Tor network and that gives them the perfect hide away.
Something got messed up with my previous account, so I had to create a new one.
During registration at GitHub I noticed another issue: a cookie (tz) which in which I saw the local timezone (with city). TBB doesn't leak this info, UC obviously does (even through Tor).
@anchev Chromium allows you to spoof the timezone with an environment variable. Does TBB spoof the timezone by default?
So far, I am fine with the general idea of adding better Tor integration to achieve feature parity with TBB. Before anyone submits a PR, I'd like to see a proposal of an implementation so we can work on a design we all agree on and minimize wasted developer work.
Maybe we could offload most of the logic to a special extension with access to a new private API (like the Webstore extension uses)?
Chromium allows you to spoof the timezone with an environment variable.
How do you do that?
Does TBB spoof the timezone by default?
According to about:config
the setting is privacy.use_utc_timezone=true
(which is the same I saw in the cookie when testing).
So far, I am fine with the general idea of adding better Tor integration to achieve feature parity with TBB.
Perhaps the best way to approach this is to open a discussion with the Tor developers themselves as there are surely additional factors we didn't look into here. Also bear in mind that TBB itself is not perfect at all. In fact I think UC has potential to be much better (as unlinke Firefox it doesn't connect to Mozilla's telemetry, Amazon, Akamai and all the rest of Mozilla's "privacy respecting" stuff).
According to about:config the setting is privacy.use_utc_timezone=true (which is the same I saw in the cookie when testing).
I see. I just set TZ='Etc/UTC'
whenever I need to spoof timezone to UTC.
as unlinke Firefox it doesn't connect to Mozilla's telemetry, Amazon, Akamai and all the rest of Mozilla's "privacy respecting" stuff
IMO it's all comes down to putting in the effort to implement something for Firefox like what ungoogled-chromium did for Chromium. Unless Firefox's design makes this significantly more difficult, I believe the potential in this area is equal to Chromium.
I see. I just set TZ='Etc/UTC' whenever I need to spoof timezone to UTC.
Thanks. But which other programs may be affected by this? Also is this documented somewhere? - If not - it would be good to be. Or maybe it would be best to have a flag for it?
Unless Firefox's design makes this significantly more difficult, I believe the potential in this area is equal to Chromium.
I am not so sure. Chromium connects only to Google hosts. It is probably easier to find and block these connections in which you have done an excellent job.
As Firefox piles up more and more "features" they can add new connections at any time with new Mozilla's partners and the about:config
flags for controlling all that are poorly documented (if at all). There are people who spend a lot of time to find info about that and reflect it in the multiple user.js
projects but so far I haven't found a project focused on eliminating completely the unrequested connections (TBB also doesn't seem to do it). My own attempts in that were successful to a point but I stopped keeping up to date the user.js
I created because following all that is a real nightmare - very time consuming and IMO unreliable. That's why I think UC is a much cleaner thing to start with.
IMO it's all comes down to putting in the effort to implement something for Firefox like what ungoogled-chromium did for Chromium. Unless Firefox's design makes this significantly more difficult, I believe the potential in this area is equal to Chromium.
here https://github.com/pyllyukko/user.js and here https://github.com/Eloston/ungoogled-chromium/issues/560#issuecomment-431713666 no need for patching... even if it could be better to completely remove the questionable code
As Firefox piles up more and more "features" they can add new connections at any time with new Mozilla's partners and the
about:config
flags for controlling all that are poorly documented (if at all). There are people who spend a lot of time to find info about that and reflect it in the multipleuser.js
projects but so far I haven't found a project focused on eliminating completely the unrequested connections (TBB also doesn't seem to do it). My own attempts in that were successful to a point but I stopped keeping up to date theuser.js
I created because following all that is a real nightmare - very time consuming and IMO unreliable. That's why I think UC is a much cleaner thing to start with.
Either way devs reviewing mozilla code and patching it or reviewing code to change something in about:config it takes all time... and still mozilla is reactive when someone ask to add a new flag in about:config to block this or that operation with a flag.
The advantage with chromium is that we dont need to deal with all the functions added in chrome as they are 2 different projects
Thanks. But which other programs may be affected by this?
@anchev At least with the popular shells on Linux, you can just place the value inline to have the variable set just for that process, e.g. TZ='Etc/UTC' chromium
. You can also use the env
command to do this. Furthermore with the Debian packages of ungoogled-chromium, you can add a file in /etc/chromium.d/
to set it by default (since chromium
on Debian is a shell script wrapper around the actual binary)
I created because following all that is a real nightmare - very time consuming and IMO unreliable. That's why I think UC is a much cleaner thing to start with.
The advantage with chromium is that we dont need to deal with all the functions added in chrome as they are 2 different projects
@anchev @intika I see, interesting insights. Thanks.
Thanks @Eloston. env
worked just fine.
@intika: pyllyukko's user.js is a nice project but the very existence of it and many similar is a proof that there is something is very crooked in Mozilla. In an old issue some of that was discussed.
A little off-topic but perhaps worth mentioning:
A post in Tor's blog from 2018-11-23 says:
The Tor Project has received $8,840 so far from AmazonSmile. If you buy from Amazon, please consider using smile.amazon.com and making the Tor Project your designated charity.
So now Amazon is financing Tor and Tor is advertising Amazon. And this article ends with "Join the fight for privacy, security, and freedom online." Hm...
Just another note in the context of Tor:
It is a good idea to disable expliclitly chrome://flags/#enable-quic
because QUIC is UDP and Tor socks proxy works only on TCP.
It is a good idea to disable expliclitly chrome://flags/#enable-quic because QUIC is UDP and Tor socks proxy works only on TCP.
No, it is not. Enabling QUIC does not conflict with TCP/SOCKS5, so it continues to work as usual.
Enabling QUIC does not conflict with TCP/SOCKS5, so it continues to work as usual.
The point is: When one uses Tor one doesn't want to "work as usual" (i.e. having non-torified connections).
The point is: When one uses Tor one doesn't want to "work as usual" (i.e. having non-torified connections).
So you are saying that if I happen to visit a QUIC-enabled server, it will bypass SOCKS5 and use QUIC as preferred protocol? If so, do you have a source?
My understanding is that it will simply won't use it - just like some of the UDP connections used in torrents (and the recommendation not to use Tor for torrents).
I haven't researched deeply into QUIC but I have read it is based on UDP, so logically the same should apply as long as Tor supports only TCP. In a quick search I found this (I still have not read it but you may be interested to).
@anchev Your link is discussing Tor over QUIC, not QUIC over Tor.
@ian-moone The Wikipedia page for QUIC says it is based on UDP. The overview page of Tor on Tor Project's website says it only supports TCP streams. Thus, QUIC should be ignored by Tor. I don't know if Tor has explicit QUIC support or not.
As I said I haven't read it. Just what searx returned.
Fingerprint will be radically different when compared to Tor Browser Bundle. I wouldn't add this feature. If you want to use Tor, use Tor Browser Bundle.
@theel0ja Could you clarify what you mean by "fingerprint"? I interpret your statement to imply that there is one "browser fingerprint", but I have seen that fingerprinting is really just a loose collection of methods of trying to identify a specific machine by manipulating various web APIs (technically, anything involving the client could be used, such as the communication protocols).
Also, could you explain why you believe ungoogled-chromium's fingerprint would be radically different from Tor Browser Bundle's? As we already know, ungoogled-chromium already has some fingerprinting deception features built-in (see docs/flags.md). Are there others that would make a significant impact?
@theel0ja Could you clarify what you mean by "fingerprint"? I interpret your statement to imply that there is one "browser fingerprint", but I have seen that fingerprinting is really just a loose collection of methods of trying to identify a specific machine by manipulating various web APIs (technically, anything involving the client could be used, such as the communication protocols).
Also, could you explain why you believe ungoogled-chromium's fingerprint would be radically different from Tor Browser Bundle's? As we already know, ungoogled-chromium already has some fingerprinting deception features built-in (see docs/flags.md). Are there others that would make a significant impact?
"radically different from Tor Browser Bundle's" 😂 Maybe because it's Google's Blink (WebKit Fork) instead of Firefox's Quantum Engine. By observing subtle differences you don't need the user agent to determine which browser a website is running inside.
@nsuchy Would you happen to know what these subtle differences are?
From what I see the main point of cloudflare and many other firewalls is to stop bots coming from tor network. Automated firefox is easy to detect because firefox injects webdriver
attribute to the html tag. If your main concern is to prevent malicious traffic you can easily check whether browser is automated and let pass everyone who is proven to use firefox and to be 'human'. There is no clear distinction between 'bot' and 'human' for chromium.
So while whatever version of firefox with tor works just fine it's impossible to use chromium with tor. Cloudflare and google block it completely, requiring to solve 7 captchas in a row and sometimes do not giving any captcha at all, forcing you to create new identity. Useragent mimicking is a joke, it seems like everything about chrome screams it is chrome. Panopticlick detects chrome just by using its plugins (i.e pdf preview). From my experience with chromedriver there must be hardcoded variables that reveal the engine you use. I have no idea how they do it but apparently nobody knows either.
@sertraline
Check #783
Something recent about fingerprinting:
Maybe even worth a separate issue?
You really should only Connect to TOR via the TOR browser. The reason for this is, the whole way that TOR manages to keep you anonymous is by making everyone look the same. By using a different browser, you're just making yourself look unique on the TOR network.
Using Tor with browsers other than Tor Browser compromises the Anonymity of using Tor, especially with Chromium based browsers which tend to have more vulnerabilities and entrypoints than Firefox based browsers. For this reason it's best to use the original Tor browser, brave obviously didn't get the memo.
Using Tor with browsers other than Tor Browser compromises the Anonymity of using Tor, especially with Chromium based browsers which tend to have more vulnerabilities and entrypoints than Firefox based browsers.
Do you have any reputable sources baking that claim?
This is an old issue, that didn't show much activity recently and probably lost its significance — closing. If you have any more information to add, let us know.
Recently Brave Browser added support to use Tor with private tabs. Would the developers consider adding something similar? Maybe even take to the next level and let you use Tor in all browsing not just private tabs. Thoughts?