Comcast blocks ALL traffic with tor relays
I'd like to raise awareness of the Comcast blocking. As stated in subject, I believe Comcast blocks all traffic between its customers and public tor relay nodes. That is, the blocking is not limited to tor-related traffic, all other services / ports on the tor relay are blocked. Background: I am running a lightning node, lightning is a layer 2 protocol to scale Bitcoin. Lightning nodes need to be connected to each other ideally 24/7. I was contacted by the operator of another Lightning node, complaining that he cannot connect to my node. He is Comcast customer, I am not. I was also running a tor relay on the same public IPv4 address. I am pretty sure that the blocking is done by Comcast and is triggered by being in public list of tor relays. The blocking disappeared after I stopped my tor relay and restarted my router (thus getting a new external IPv4 address). After 1 day, I relaunched the tor relay, and the blocking reappeared a few hours later. It was also confirmed by the said operator of the lightning node, who said there were various rounds of blocking tor, customers complaining and Comcast lifting the block for some time, only to reinstate the blocking later. Comcast thus discourages me and similar people from running tor relays, or at least forces me to run tor in bridge mode. So this is an insidious attack on tor. Note that Bitcoin is not particularly relevant, Comcast is blocking tor nodes, not bitcoin nodes. So even if you hate Bitcoin, note that the same problem could arise even if Bitcoin never existed: e.g. a self-hosted web server, whose owner wants to donate his free capacity to tor by running tor relay. By doing this, he prevents any Comcast customers from accessing his web server, and this consequence is not obvious at all. Any ideas on how to combat this? I was thinking about including some false positives in tor relay list. Imagine including some Google servers' IP addresses - Comcast customers suddenly cannot connect to Google, unless Comcast stops this blocking... or simply whitelists Google. But those false positives sound ugly and a bit malicious, not sure it is a good idea. I already wrote about this publicly, and also wrote a mail to EFF. Hope I am not spamming, I feel this is quite important issue and am a bit frustrated by the lack of attention it gets.
xmrk2 via tor-relays wrote:
Any ideas on how to combat this? I was thinking about including some false positives in tor relay list. Imagine including some Google servers' IP addresses - Comcast customers suddenly cannot connect to Google, unless Comcast stops this blocking... or simply whitelists Google. But those false positives sound ugly and a bit malicious, not sure it is a good idea.
This sucks big time, if true. I am trying to ping Comcast from a middle relay IP address and it seams, to work, I guess you mean AS33651 - Comcast Cable LLC. Anyway, it could be, at latest consensus there is no single relay (middle or exit) hosted in AS33651. I am not sure about the false positive solution, I see only downsides, including but not limited to: - it's not ethical for Tor Project to do this, e.g. stating another company's infrastructure (say Google IP address space) is part of a network when in fact its not. I get it that the goal is privacy oriented and in good faith (freedom faith) but it seams rather inappropriate; - there is no evidence that a blocker might use a list of relays provided by Tor Project's metrics portal (I am confident nobody does it because it's less effective) - they can just run a Tor client and get a copy of a consensus and extract from there IP:PORT IPv6:PORT and do from there whatever they please; - if you include such false positives in the consensus you have to simulate dummy Tor relays on those "hot" IP addresses, like providing an onion key, RSA identity and ed25519 identity, thus looking like a relay, state some bandwidth for it, etc - in this case how will a Tor client know which relay is dummy and which not, in order not to try to establish circuits that fail, ultimately producing a terrible user experience for all users. Same applies for other relays, not just clients, that need to produce connections with the dummy relays. If we somehow mark them as "dummy", it will be pretty stupid and obvious and waste of effort as the blocker can simply understand the "dummy" marker and it's done, I guess it's pretty obvious.
I already wrote about this publicly, and also wrote a mail to EFF. Hope I am not spamming, I feel this is quite important issue and am a bit frustrated by the lack of attention it gets.
Not at all, this is very interesting and not spamming at all. I think it is unacceptable for this to happen, and I think all Comcast customers should quit if this is true - large internet corporations are trying to move on from "IP address identifications" as in only a beginner that discovered the internet one week ago still thinks of the IP address as "identification of a certain individual / entity", everybody is moving to advanced layers of authentication on per device basis, cryptographic public key, etc. Comcast if they do such a thing they set themselves 25 years behind the industry they operate in. And this can create many unwanted effects, someone should try to do something about this but I am not sure what we Tor volunteers *can* do to help with this, especially the ones that are not Comcast customers. EFF is the best start IMO.
If we could get EFF to announce a boycott of any corporation known to act maliciously against Tor or other privacy-friendly technology (such as VPNs), that would go a long way. I will also write to EFF. I have donated money to them, so maybe they will listen. If they won't support a boycott directly, maybe at least they will comment on the issue publicly, and that would help launch a boycott. If will also help to get an official communication from Comcast saying they are blocking Tor. If they won't admit this, it makes it that much harder to fight. I can't do this as I'm not a Comcast customer. Are there any Comcast customers that can get a Comcast rep to admit, in writing, that this is happening? On 6/12/23 10:50, s7r wrote:
xmrk2 via tor-relays wrote:
Any ideas on how to combat this? I was thinking about including some false positives in tor relay list. Imagine including some Google servers' IP addresses - Comcast customers suddenly cannot connect to Google, unless Comcast stops this blocking... or simply whitelists Google. But those false positives sound ugly and a bit malicious, not sure it is a good idea.
This sucks big time, if true. I am trying to ping Comcast from a middle relay IP address and it seams, to work, I guess you mean AS33651 - Comcast Cable LLC. Anyway, it could be, at latest consensus there is no single relay (middle or exit) hosted in AS33651.
I am not sure about the false positive solution, I see only downsides, including but not limited to:
- it's not ethical for Tor Project to do this, e.g. stating another company's infrastructure (say Google IP address space) is part of a network when in fact its not. I get it that the goal is privacy oriented and in good faith (freedom faith) but it seams rather inappropriate;
- there is no evidence that a blocker might use a list of relays provided by Tor Project's metrics portal (I am confident nobody does it because it's less effective) - they can just run a Tor client and get a copy of a consensus and extract from there IP:PORT IPv6:PORT and do from there whatever they please;
- if you include such false positives in the consensus you have to simulate dummy Tor relays on those "hot" IP addresses, like providing an onion key, RSA identity and ed25519 identity, thus looking like a relay, state some bandwidth for it, etc - in this case how will a Tor client know which relay is dummy and which not, in order not to try to establish circuits that fail, ultimately producing a terrible user experience for all users. Same applies for other relays, not just clients, that need to produce connections with the dummy relays. If we somehow mark them as "dummy", it will be pretty stupid and obvious and waste of effort as the blocker can simply understand the "dummy" marker and it's done, I guess it's pretty obvious.
I already wrote about this publicly, and also wrote a mail to EFF. Hope I am not spamming, I feel this is quite important issue and am a bit frustrated by the lack of attention it gets.
Not at all, this is very interesting and not spamming at all. I think it is unacceptable for this to happen, and I think all Comcast customers should quit if this is true - large internet corporations are trying to move on from "IP address identifications" as in only a beginner that discovered the internet one week ago still thinks of the IP address as "identification of a certain individual / entity", everybody is moving to advanced layers of authentication on per device basis, cryptographic public key, etc. Comcast if they do such a thing they set themselves 25 years behind the industry they operate in. And this can create many unwanted effects, someone should try to do something about this but I am not sure what we Tor volunteers *can* do to help with this, especially the ones that are not Comcast customers. EFF is the best start IMO.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
This sucks big time, if true. I am trying to ping Comcast from a middle relay IP address and it seams, to work, I guess you mean AS33651 - Comcast Cable LLC.
The peer's IP address is in ASN 7922, according to whatismyipaddress.com . Note that my test was always opening a TCP4 connection to him using socat. (I know on what port his lightning daemon listens. Obviously not feasible to do such test with a random Comcast customer.) In fact that node does not respond to pings. Perhaps those 2 differences explain different results. I will send that peer a link to this convo, he could do some tests from inside Comcast's network. He sounded a bit resigned though, so no guarantees obviously. And thanks for encouragement, up to now my efforts have fallen mostly to deaf ears.
FWIW I haven't ever experienced any issues using Tor on multiple Comcast residential and business lines. I use Tor as a client daily from a Comcast residential connection and have never been unable to connect to directories or relays. I also have a directory client running 24/7 on Comcast business and it hasn't had any Tor-related connectivity issues over the last 6+ years. I just spun up a new /relay/ on a Comcast residential connection and have no issues talking to other relays and I've confirmed the ORPort is reachable from multiple other AS's in the US and abroad. │ 09:11:35 [NOTICE] Self-testing indicates your ORPort 98.45.218.223:9001 is reachable from the outside. Excellent. Publishing server descriptor. │ https://metrics.torproject.org/rs.html#details/42BD1CC75EA01755D1F7DC8205C9E... If anyone wants to test reachability to this Comcast relay, I'll leave it up for the next 48 hours or so. I'm not necessarily a fan of Comcast or any of their practices and am only speaking for myself here but I haven't ever experienced any blocking or difficulty. Are you sure that port forwarding To your relay is reliably working and that some "security feature" in your Comcast modem/router isn't causing the problem? I haven't researched any reports of Comcast blocking so I can't speak to any other anecdotal reports of said blocking. I sure hope it isn't the case. If it is, I'll certainly drop them in a flash too. Regards, Drew On 6/11/23 04:46, xmrk2 via tor-relays wrote:
I'd like to raise awareness of the Comcast blocking.
As stated in subject, I believe Comcast blocks all traffic between its customers and public tor relay nodes. That is, the blocking is not limited to tor-related traffic, all other services / ports on the tor relay are blocked.
Background: I am running a lightning node, lightning is a layer 2 protocol to scale Bitcoin. Lightning nodes need to be connected to each other ideally 24/7. I was contacted by the operator of another Lightning node, complaining that he cannot connect to my node. He is Comcast customer, I am not. I was also running a tor relay on the same public IPv4 address.
I am pretty sure that the blocking is done by Comcast and is triggered by being in public list of tor relays. The blocking disappeared after I stopped my tor relay and restarted my router (thus getting a new external IPv4 address). After 1 day, I relaunched the tor relay, and the blocking reappeared a few hours later. It was also confirmed by the said operator of the lightning node, who said there were various rounds of blocking tor, customers complaining and Comcast lifting the block for some time, only to reinstate the blocking later.
Comcast thus discourages me and similar people from running tor relays, or at least forces me to run tor in bridge mode. So this is an insidious attack on tor. Note that Bitcoin is not particularly relevant, Comcast is blocking tor nodes, not bitcoin nodes. So even if you hate Bitcoin, note that the same problem could arise even if Bitcoin never existed: e.g. a self-hosted web server, whose owner wants to donate his free capacity to tor by running tor relay. By doing this, he prevents any Comcast customers from accessing his web server, and this consequence is not obvious at all.
Any ideas on how to combat this? I was thinking about including some false positives in tor relay list. Imagine including some Google servers' IP addresses - Comcast customers suddenly cannot connect to Google, unless Comcast stops this blocking... or simply whitelists Google. But those false positives sound ugly and a bit malicious, not sure it is a good idea.
I already wrote about this publicly, and also wrote a mail to EFF. Hope I am not spamming, I feel this is quite important issue and am a bit frustrated by the lack of attention it gets.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Okay, you planted some doubt. This is a quote what my peer wrote me about the issue, I hope it is ok to quote, contains no personal or sensitive info, emphasis added:
Comcast/Xfinity! has a bumpy past with tor. They periodically block it, get yelled out by their subscribers and the media, then unblock it. At this moment, outgoing tor is working. That is I am able to put the Brave browser in tor mode. But, because of the intermittent interruptions, I've given up on using tor when running behind my ISP.
Outgoing tor is working - so he has to be able to connect to some relay, not necessarily all of them. Or he configured a tor bridge because of past problems and forgot about it?
Are you sure that port forwarding To your relay is reliably working and that some "security feature" in your Comcast modem/router isn't causing the problem? I haven't researched any reports of Comcast blocking so I can't speak to any other anecdotal reports of said blocking. I sure hope it isn't the case. If it is, I'll certainly drop them in a flash too.
Well, I am not in the US, no Comcast here :), and running OpenWrt on my router. My peer is Comcast customer. I was connected to > 100 lighting nodes while not able to connect to my Comcast peer. I did not check specifically, my lightning node should be reachable by IPv4, IPv6 and tor/onion, so in theory there could have been no inbound IPv4 connection while having > 100 connections. But not likely. I think I either checked my fail2ban-client banned, or turned off fail2ban. Still, there could be some DDoS protection on my Comcast peer's end. To corroborate: lightning nodes need to be connected, they try to reconnect frequently to all their "neighbours". I myself see that when I take my lightning daemon offline for just 10 minutes, many IP addresses end in my fail2ban list. So my Comcast peer could have just taken his node offline, his router would see too many connection attempts from me and consider it DoS and ban me. Still, I would expected to be unbanned after some time, and this does not seem to happen, so this would be argument against DDoS protection. For reference, this is my fail2ban's jail.local, perhaps too aggressive: [lnd] enabled = true ports = 9735:9736 filter = lnd logpath = ... maxretry = 4 [lnd-repeat] enabled = true ports = 9735:9736 filter = lnd logpath = ... maxretry = 12 findtime = 1h bantime = 1h I'll test again by starting tor middle relay, and check inbound IPv4 connections, should bring some results in a few hours.
On Jun 11, 2023, at 04:46, xmrk2 via tor-relays <tor-relays@lists.torproject.org> wrote:
I believe Comcast blocks all traffic between its customers and public tor relay nodes
I'm a reluctant Comcast Business user. Here's my experience (briefly, as I'm typing with a newly-fractured wrist): Though during install I asked for "just pipes" with none of the extra services they offer, instead they silently signed me up for their "Security Edge" service. Many things broke. I finally discovered that they were intercepting all outbound UCP and TCP traffic to port 53 and re-directing it to their own, badly-broken DNS resolver which seems to be pretty arbitrary about what it blocks. When I contacted them, they said it couldn't be removed but gave me instructions for turning it off, but the switch to do so on their web site was disabled (grey and not responsive to clicking, using multiple browsers and platforms). After over TWENTY HOURS on chat, they finally disabled it from their end. I had pointed out that it was a direct and blatant violation of California's net neutrality law. Life was good for about a week, then it came back on. I think I next posted a complaint on Reddit (which seems to get more attention than contacting customer service directly) and they, again, turned it off. Around a year later, they started MITMing all my DNS queries again, wreaking havoc on my business. I, again, poked around their web site, and I found that the switch to disable blocking is now enabled (though hard to find) and for a couple of months now things have been okay. None of my difficulties were directly related to Tor, even though I run a relay on one of my IP addresses. However, the variable and arbitrary nature of the blocks they implemented make it seem likely that they could be blocking Tor relays some of the time.
On Sonntag, 11. Juni 2023 13:46:06 CEST xmrk2 via tor-relays wrote:
Background: I am running a lightning node, lightning is a layer 2 protocol to scale Bitcoin. Lightning nodes need to be connected to each other ideally 24/7. I was contacted by the operator of another Lightning node, complaining that he cannot connect to my node. He is Comcast customer, I am not. I was also running a tor relay on the same public IPv4 address.
Any ideas on how to combat this? It might help to configure Lightning node as a hidden service. I offer my Monero and Bitcoin RPC & P2P ports as a hidden service.
And have additionally SocksPort flag 'OnionTrafficOnly' on the client and hidden service side. SocksPort 9050 OnionTrafficOnly # Tell the tor client to only connect to .onion addresses in response to SOCKS5 requests on this connection. # This is equivalent to NoDNSRequest, NoIPv4Traffic, NoIPv6Traffic.
I was thinking about including some false positives in tor relay list. I wouldn't do that. I think you'll end up on the bad-relay list in no time. I would rather write to the Comcast network admins first. Give them good examples. E.g. in Germany the ISP's support Tor (NetCologne, Deutsche Telekom, ...)
Mirror: https://torproject.netcologne.de/dist/ Our Traffic sponsors: https://www.community-ix.net/sponsors/ -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
I was running a Tor Relay for a while from a Comcast residential, non-business account up until a couple of months ago with no issues from Comcast. I did, however start experiencing issues accessing other commercial websites from the same Internet address. When I accessed those sites from a different IP address I had no problem. Ultimately I determined our IP address was being blacklisted by certain hosting services who probably grabbed all Tor-related IP addresses and blocked them as a service to commercial websites. As this info is readily available it’s easy to deduce this. From this I’d say running any Tor components from a shared residential ISP probably isn’t a good recommendation.
On Jun 12, 2023, at 3:13 AM, xmrk2 via tor-relays <tor-relays@lists.torproject.org> wrote:
I'd like to raise awareness of the Comcast blocking.
As stated in subject, I believe Comcast blocks all traffic between its customers and public tor relay nodes. That is, the blocking is not limited to tor-related traffic, all other services / ports on the tor relay are blocked.
Background: I am running a lightning node, lightning is a layer 2 protocol to scale Bitcoin. Lightning nodes need to be connected to each other ideally 24/7. I was contacted by the operator of another Lightning node, complaining that he cannot connect to my node. He is Comcast customer, I am not. I was also running a tor relay on the same public IPv4 address.
I am pretty sure that the blocking is done by Comcast and is triggered by being in public list of tor relays. The blocking disappeared after I stopped my tor relay and restarted my router (thus getting a new external IPv4 address). After 1 day, I relaunched the tor relay, and the blocking reappeared a few hours later. It was also confirmed by the said operator of the lightning node, who said there were various rounds of blocking tor, customers complaining and Comcast lifting the block for some time, only to reinstate the blocking later.
Comcast thus discourages me and similar people from running tor relays, or at least forces me to run tor in bridge mode. So this is an insidious attack on tor. Note that Bitcoin is not particularly relevant, Comcast is blocking tor nodes, not bitcoin nodes. So even if you hate Bitcoin, note that the same problem could arise even if Bitcoin never existed: e.g. a self-hosted web server, whose owner wants to donate his free capacity to tor by running tor relay. By doing this, he prevents any Comcast customers from accessing his web server, and this consequence is not obvious at all.
Any ideas on how to combat this? I was thinking about including some false positives in tor relay list. Imagine including some Google servers' IP addresses - Comcast customers suddenly cannot connect to Google, unless Comcast stops this blocking... or simply whitelists Google. But those false positives sound ugly and a bit malicious, not sure it is a good idea.
I already wrote about this publicly, and also wrote a mail to EFF. Hope I am not spamming, I feel this is quite important issue and am a bit frustrated by the lack of attention it gets. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I have the same problem here in germany with also two sites. I'm running an non-exit relay. So far I can not access the sites "banking.ing-diba.de" and "www.elster.de" when the tor server is running after some time. The only thing which helps when I renew my public ip address. Then the access to the above mentioned sites is posible for some time. I'm not sure if the sites are blocking by themself or if they are using some service like cloudflare which does the blocking. Am 13.06.2023 um 23:18 schrieb securehell@gmail.com:
I was running a Tor Relay for a while from a Comcast residential, non-business account up until a couple of months ago with no issues from Comcast.
I did, however start experiencing issues accessing other commercial websites from the same Internet address. When I accessed those sites from a different IP address I had no problem.
Ultimately I determined our IP address was being blacklisted by certain hosting services who probably grabbed all Tor-related IP addresses and blocked them as a service to commercial websites. As this info is readily available it’s easy to deduce this.
From this I’d say running any Tor components from a shared residential ISP probably isn’t a good recommendation.
On Jun 12, 2023, at 3:13 AM, xmrk2 via tor-relays <tor-relays@lists.torproject.org> wrote:
I'd like to raise awareness of the Comcast blocking.
As stated in subject, I believe Comcast blocks all traffic between its customers and public tor relay nodes. That is, the blocking is not limited to tor-related traffic, all other services / ports on the tor relay are blocked.
Background: I am running a lightning node, lightning is a layer 2 protocol to scale Bitcoin. Lightning nodes need to be connected to each other ideally 24/7. I was contacted by the operator of another Lightning node, complaining that he cannot connect to my node. He is Comcast customer, I am not. I was also running a tor relay on the same public IPv4 address.
I am pretty sure that the blocking is done by Comcast and is triggered by being in public list of tor relays. The blocking disappeared after I stopped my tor relay and restarted my router (thus getting a new external IPv4 address). After 1 day, I relaunched the tor relay, and the blocking reappeared a few hours later. It was also confirmed by the said operator of the lightning node, who said there were various rounds of blocking tor, customers complaining and Comcast lifting the block for some time, only to reinstate the blocking later.
Comcast thus discourages me and similar people from running tor relays, or at least forces me to run tor in bridge mode. So this is an insidious attack on tor. Note that Bitcoin is not particularly relevant, Comcast is blocking tor nodes, not bitcoin nodes. So even if you hate Bitcoin, note that the same problem could arise even if Bitcoin never existed: e.g. a self-hosted web server, whose owner wants to donate his free capacity to tor by running tor relay. By doing this, he prevents any Comcast customers from accessing his web server, and this consequence is not obvious at all.
Any ideas on how to combat this? I was thinking about including some false positives in tor relay list. Imagine including some Google servers' IP addresses - Comcast customers suddenly cannot connect to Google, unless Comcast stops this blocking... or simply whitelists Google. But those false positives sound ugly and a bit malicious, not sure it is a good idea.
I already wrote about this publicly, and also wrote a mail to EFF. Hope I am not spamming, I feel this is quite important issue and am a bit frustrated by the lack of attention it gets. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I have only experienced similar problems while running tor exit node, even with very restricted exit policy. Allowing exit only to port X, and unable to initiate connections to port Y (typically Y=HTTPS=443, of course X =/= Y). Note that those problems are not Comcast's fault, although they do point to more general problem: that people (webmasters, cloud services, ISPs) sometimes block too much and misunderstand tor, they probably wanted to block just tor exits, but end up blocking anything tor-related. This leads me to following idea: Educational campaign to teach relevant people about difference between middle relays and exits. My proposal for title/slogan: "Tor relays are not a threat - no reason to block them". (Should it be "middle relays"? But it seems too long then.) EFF could be quite helpful there.
Regarding web-servers hosting Tor relays, it is much more likely for them to sit behind a CDN such as Cloudflare for DoS protection and delivery optimization. Other services of course, however.. ------- Original Message ------- xmrk2 via tor-relays <tor-relays@lists.torproject.org> schrieb am Sonntag, 11. Juni 2023 um 1:46 nachm.:
I'd like to raise awareness of the Comcast blocking.
As stated in subject, I believe Comcast blocks all traffic between its customers and public tor relay nodes. That is, the blocking is not limited to tor-related traffic, all other services / ports on the tor relay are blocked.
Background: I am running a lightning node, lightning is a layer 2 protocol to scale Bitcoin. Lightning nodes need to be connected to each other ideally 24/7. I was contacted by the operator of another Lightning node, complaining that he cannot connect to my node. He is Comcast customer, I am not. I was also running a tor relay on the same public IPv4 address.
I am pretty sure that the blocking is done by Comcast and is triggered by being in public list of tor relays. The blocking disappeared after I stopped my tor relay and restarted my router (thus getting a new external IPv4 address). After 1 day, I relaunched the tor relay, and the blocking reappeared a few hours later. It was also confirmed by the said operator of the lightning node, who said there were various rounds of blocking tor, customers complaining and Comcast lifting the block for some time, only to reinstate the blocking later.
Comcast thus discourages me and similar people from running tor relays, or at least forces me to run tor in bridge mode. So this is an insidious attack on tor. Note that Bitcoin is not particularly relevant, Comcast is blocking tor nodes, not bitcoin nodes. So even if you hate Bitcoin, note that the same problem could arise even if Bitcoin never existed: e.g. a self-hosted web server, whose owner wants to donate his free capacity to tor by running tor relay. By doing this, he prevents any Comcast customers from accessing his web server, and this consequence is not obvious at all.
Any ideas on how to combat this? I was thinking about including some false positives in tor relay list. Imagine including some Google servers' IP addresses - Comcast customers suddenly cannot connect to Google, unless Comcast stops this blocking... or simply whitelists Google. But those false positives sound ugly and a bit malicious, not sure it is a good idea.
I already wrote about this publicly, and also wrote a mail to EFF. Hope I am not spamming, I feel this is quite important issue and am a bit frustrated by the lack of attention it gets.
participants (9)
-
George Hartley -
lists＠for-privacy.net -
ronqtorrelays＠risley.net -
s7r -
securehell＠gmail.com -
sysop＠openinternet.io -
tor admin -
webmaster -
xmrk2