subject:"\[tor\-bugs\] #18361 \[Tor Browser\]\: Issues with corporate censorship and mass surveillance"

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by jgrahamc):

 Replying to [comment:225 lunar]:
 > Replying to [comment:223 jgrahamc]:
 > > Every web property of significant size uses some sort of IP-based
 reputation. It's one way web sites deal with abuse (sometimes it's super-
 manual: web site admins look at logs and restrict certain IPs). No plan to
 ditch IP reputation, but CloudFlare likes to make continuous improvements
 and I think this is an area where we can do that.
 >
 > I think this is very short-sighted. The future is Carrier-grade NAT and
 IPv6. Both makes IP reputation highly impractical. Or maybe you have a
 fancy solution. I'd be curious to hear about it!

 The future is IPv6 not CGN. Really major ISPs are making a massive push to
 IPv6 as are mobile carriers.

 We do have a fancy solution that we are working on, but I don't want to
 make a specific promise yet.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by lunar):

 Replying to [comment:223 jgrahamc]:
 > Every web property of significant size uses some sort of IP-based
 reputation. It's one way web sites deal with abuse (sometimes it's super-
 manual: web site admins look at logs and restrict certain IPs). No plan to
 ditch IP reputation, but CloudFlare likes to make continuous improvements
 and I think this is an area where we can do that.

 I think this is very short-sighted. The future is Carrier-grade NAT and
 IPv6. Both makes IP reputation highly impractical. Or maybe you have a
 fancy solution. I'd be curious to hear about it!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by tne):

 Replying to [comment:223 jgrahamc]:
 > I need to think about it. I don't have a ready answer to whether that
 would work. Will do some internal investigation.

 Greatly appreciated.

 > It's more a question of how you mix this stuff. Suppose you have a bad
 IP reputation for some IP, plus you look at the request and it looks it
 might be SQLi then you impede that, but if you see a request and it's
 clean then you downplay the IP reputation and let the request through.
 Equally you have a good IP and it's certain it's a known exploit, you
 block that.

 That is more nuanced. We're now on the same wavelength; thank you for your
 patience.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by jgrahamc):

 Replying to [comment:222 tne]:
 > Exactly; it's "part of" your solution. In and of itself, it isn't
 sufficient. This means you'll continue to rely on IP rep. Nobody likes
 that, not even you I reckon, but it's the best you have right now.

 Every web property of significant size uses some sort of IP-based
 reputation. It's one way web sites deal with abuse (sometimes it's super-
 manual: web site admins look at logs and restrict certain IPs). No plan to
 ditch IP reputation, but CloudFlare likes to make continuous improvements
 and I think this is an area where we can do that.

 > Dealing with that reality, I think there are ways to reduce the pain in
 specific areas (e.g. sites that are not being "actively abused") and that
 are worth exploring. Would you comment on that?

 I need to think about it. I don't have a ready answer to whether that
 would work. Will do some internal investigation.

 > I know, I've been following the discussion. I probably should have
 thanked you and your team for that beforehand. As I said, I even benefit
 from some of those changes, and that's great.

 Good, I'm glad to hear the changes we are making are helping.

 > Assumption: By "''It's better to think at an individual request level
 and ask "Does this request indicate abuse?" and then decide what to do. Of
 course, we can take into account other things as well, but [...]''" you
 didn't really mean that you were aiming to do that exclusively, as that
 would prevent you from using an IP reputation system (which uses data
 besides the isolated request, i.e. reputation scores gathered via other
 customer sites). I interpreted it like that however, and we might have
 talked past each other. If that's correct, what I said will make more
 sense.

 It's more a question of how you mix this stuff. Suppose you have a bad IP
 reputation for some IP, plus you look at the request and it looks it might
 be SQLi then you impede that, but if you see a request and it's clean then
 you downplay the IP reputation and let the request through. Equally you
 have a good IP and it's certain it's a known exploit, you block that.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by tne):

 Replying to [comment:221 jgrahamc]:
 > Replying to [comment:220 tne]:
 > > I agree wholeheartedly with your mention of focusing on individual
 requests instead (who wouldn't?). The problem is, it's just a promise at
 this point. If you could really do it efficiently and reliably, this
 entire discussion would be moot -- you could drop IP rep altogether.
 However, you don't, so evidently you can't (yet) do it efficiently and
 reliably, and timing matters.
 >
 > We already do examine individual requests to look for abuse. That's part
 of the layers of defense we give web sites.

 Exactly; it's "part of" your solution. In and of itself, it isn't
 sufficient. This means you'll continue to rely on IP rep. Nobody likes
 that, not even you I reckon, but it's the best you have right now. Dealing
 with that reality, I think there are ways to reduce the pain in specific
 areas (e.g. sites that are not being "actively abused") and that are worth
 exploring. Would you comment on that?

 > > Whatever long-term plans CF might have regarding a strictly request-
 level approach, any short-term compromises will help.
 >
 > I'm working short and medium on this not long. Short term we've
 introduced the ability for sites to whitelist Tor, we changed our
 clearance cookie so that it applies across circuit changes, and we've
 recently made changes to the CAPTCHAs which should stop people getting
 stuck in loops of CAPTCHAs. I'm also working on a slightly less short term
 project to apply other technologies (non-CAPTCHA) to Tor. The important
 thing there is that I need to measure their effectiveness in this
 situation and will do so.

 I know, I've been following the discussion. I probably should have thanked
 you and your team for that beforehand. As I said, I even benefit from some
 of those changes, and that's great.

 I'm looking forward to those non-CAPTCHA approaches. It's good to hear
 they're planned for the "short to medium term", since for many people
 those are the ones that matter most.

 (Note that this is orthogonal to the point I was making; but that's OK.)

 > > Attempting to reduce CF's reliance on it is a noble goal that I
 support, I'm just afraid it is a mirage that will only perpetuate the
 status quo (which, in my view and that of many others, is hardly tenable).
 Hopefully I don't come across as a defeatist, I'm just trying to be
 realistic (hence the more nuanced suggestion).
 >
 > I'm not spending my time here as some sort of mirage or PR exercise.

 Given the whole thread above I understand the tone, but I'd like not to be
 caught in the crossfire. I'm referring to a technical mirage (I think it's
 fair to say at this point that dropping IP reputation is not a goal you
 can set a date for right now, and maybe you'll never be able to). I have
 yet to see anything that would suggest CF is trying to mislead anyone
 deliberately, and I'm not trying to imply it myself.

 Assumption: By "''It's better to think at an individual request level and
 ask "Does this request indicate abuse?" and then decide what to do. Of
 course, we can take into account other things as well, but [...]''" you
 didn't really mean that you were aiming to do that exclusively, as that
 would prevent you from using an IP reputation system (which uses data
 besides the isolated request, i.e. reputation scores gathered via other
 customer sites). I interpreted it like that however, and we might have
 talked past each other. If that's correct, what I said will make more
 sense.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by jgrahamc):

 Replying to [comment:220 tne]:
 > I agree wholeheartedly with your mention of focusing on individual
 requests instead (who wouldn't?). The problem is, it's just a promise at
 this point. If you could really do it efficiently and reliably, this
 entire discussion would be moot -- you could drop IP rep altogether.
 However, you don't, so evidently you can't (yet) do it efficiently and
 reliably, and timing matters.

 We already do examine individual requests to look for abuse. That's part
 of the layers of defense we give web sites.

 > Whatever long-term plans CF might have regarding a strictly request-
 level approach, any short-term compromises will help.

 I'm working short and medium on this not long. Short term we've introduced
 the ability for sites to whitelist Tor, we changed our clearance cookie so
 that it applies across circuit changes, and we've recently made changes to
 the CAPTCHAs which should stop people getting stuck in loops of CAPTCHAs.
 I'm also working on a slightly less short term project to apply other
 technologies (non-CAPTCHA) to Tor. The important thing there is that I
 need to measure their effectiveness in this situation and will do so.

 > Attempting to reduce CF's reliance on it is a noble goal that I support,
 I'm just afraid it is a mirage that will only perpetuate the status quo
 (which, in my view and that of many others, is hardly tenable). Hopefully
 I don't come across as a defeatist, I'm just trying to be realistic (hence
 the more nuanced suggestion).

 I'm not spending my time here as some sort of mirage or PR exercise.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by tne):

 Replying to [comment:219 jgrahamc]:
 > I'm not sure that totally makes sense. It's better to think at an
 individual request level and ask "Does this request indicate abuse?" and
 then decide what to do. Of course, we can take into account other things
 as well, but we wouldn't want to wait around and measure abuse and then
 say "OK, now we'll start blocking it" because it might be too late (i.e.
 the customer may have been hacked/attacked in some way). I think both Tor
 users and our customers will be happy with a solution like that.

 The delay issue was my guess. I don't think the answer is as clear-cut
 however; it's a trade-off. Many sites will be fine with a few misses
 before your countermeasures kick in if that means they can still handle
 them easily without losing their own users/visitors whenever another
 random site at the other side of the planet is attacked from a shared IP.
 This is especially the case with spam abuse for example, which is not as
 dramatic as a breach and yet is probably the number one reason you assign
 bad rep scores (any published data on this?).

 It's not like you can catch everything all the time even now anyway, it's
 defense in depth and it's all in the numbers. Only you will know if it
 really makes sense (you have the data) and I appreciate your replies and
 the time you take to consider this suggestion. It is not for me to say of
 course, but I like to believe the suggestion is worth your time (from my
 admittedly limited perspective, I see potential to calm many people down
 this way -- it is not mine although it is an obvious one, many people are
 asking here and elsewhere).

 I agree wholeheartedly with your mention of focusing on individual
 requests instead (who wouldn't?). The problem is, it's just a promise at
 this point. If you could really do it efficiently and reliably, this
 entire discussion would be moot -- you could drop IP rep altogether.
 However, you don't, so evidently you can't (yet) do it efficiently and
 reliably, and timing matters. Whatever long-term plans CF might have
 regarding a strictly request-level approach, any short-term compromises
 will help. Also, can we honestly believe strictly-request-level solutions
 will someday be completely satisfactory? Data correlation is extremely
 powerful and the temptation (or even pressure from your customers, direct
 or indirect) will always remain to leverage it (as evidenced by your
 apparently very successful IP reputation system). Attempting to reduce
 CF's reliance on it is a noble goal that I support, I'm just afraid it is
 only a mirage that will only perpetuate the status quo (which, in my view
 and that of many others, is hardly tenable). Hopefully I don't come across
 as a defeatist, I'm just trying to be realistic (hence the more nuanced
 suggestion).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by jgrahamc):

 Replying to [comment:218 tne]:
 > Replying to [comment:217 jgrahamc]:
 > Sure, I think we all understand that; the decision to block using a
 CAPTCHA is based on the reputation of the origin IP only. Can you, in
 addition, take into account the status of the destination site? (Similar
 to what you do in DDoS situations when you classify sites as "Under
 attack" in order to, as I understand it, deploy different
 countermeasures.)

 We will throw CAPTCHAs in other situations not just for IP reputation.
 CAPTCHA is one of a number of countermeasures we have and is used in
 different ways.

 > So: if the site is "actively observing abuse" and the IP has bad
 reputation, block using a CAPTCHA as usual. If the site is not "actively
 observing abuse" or the IP reputation is good, let the request go through.
 >
 > My question (hopefully clarified now) is: How hard would it be to
 establish (and remove) this "observing abuse" status (if it makes sense at
 all)?

 I'm not sure that totally makes sense. It's better to think at an
 individual request level and ask "Does this request indicate abuse?" and
 then decide what to do. Of course, we can take into account other things
 as well, but we wouldn't want to wait around and measure abuse and then
 say "OK, now we'll start blocking it" because it might be too late (i.e.
 the customer may have been hacked/attacked in some way). I think both Tor
 users and our customers will be happy with a solution like that.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by tne):

 Replying to [comment:217 jgrahamc]:
 > Yes. We have all sorts of different systems for dealing with different
 types of abuse because they are quite different. The IP reputation part,
 which is the source of the CAPTCHAs that Tor users are seeing, is a small
 part.

 Sure, I think we all understand that; the decision to block using a
 CAPTCHA is based on the reputation of the origin IP only. Can you, in
 addition, take into account the status of the destination site? (Similar
 to what you do in DDoS situations when you classify sites as "Under
 attack" in order to, as I understand it, deploy different
 countermeasures.)

 Of course, as you say, we're not talking about DDoS situations -- the
 "Under attack" terminology might not be appropriate. Say "Observing abuse"
 instead if that helps.

 So: if the site is "actively observing abuse" and the IP has bad
 reputation, block using a CAPTCHA as usual. If the site is not "actively
 observing abuse" or the IP reputation is good, let the request go through.

 My question (hopefully clarified now) is: How hard would it be to
 establish (and remove) this "observing abuse" status (if it makes sense at
 all)?

 The obvious assumption here is that a non-trivial amount of sites are not
 being actively abused and so it doesn't make sense to put the walls up
 around them, since it unfortunately prevents many legitimate users from
 reaching them painlessly as well (or at all, depending on their patience).
 Barring evidence to the contrary, I believe this assumption to be true.
 Intuitively, it wouldn't help the most popular sites, which are
 undoubtedly under *constant* abuse, but it would alleviate a big chunk of
 the pain expressed in this whole debate.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by jgrahamc):

 Replying to [comment:216 tne]:
 > Replying to [comment:215 jgrahamc]:
 > Indeed, that's actually the source of my question. I imagine the
 classification of requests that are participating in a DDoS is somehow
 different from that of requests participating in other kinds of abuse. If
 you could shed some light on how it is so, I would be very grateful.

 Yes. We have all sorts of different systems for dealing with different
 types of abuse because they are quite different. The IP reputation part,
 which is the source of the CAPTCHAs that Tor users are seeing, is a small
 part.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by tne):

 Replying to [comment:215 jgrahamc]:
 > CloudFlare already does that for sites that are under DDoS (under some
 circumstances) but it doesn't really make sense here. The Tor network
 isn't a source of DDoS for us, it's a source of all sorts of other abuse
 (see above).

 Indeed, that's actually the source of my question. I imagine the
 classification of requests that are participating in a DDoS is somehow
 different from that of requests participating in other kinds of abuse. If
 you could shed some light on how it is so, I would be very grateful.

 (I have a few guesses, but obviously I'd love to avoid speculating if I
 can avoid it.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by jgrahamc):

 Replying to [comment:214 tne]:
 > Replying to [comment:213 jgrahamc]:
 > > Do you mean could we only show a CAPTCHA to sites that we already know
 are under attack?
 >
 > Yes. I can only assume this was on the table at some point, but I feel I
 don't have a full understanding of the problem.

 CloudFlare already does that for sites that are under DDoS (under some
 circumstances) but it doesn't really make sense here. The Tor network
 isn't a source of DDoS for us, it's a source of all sorts of other abuse
 (see above).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by tne):

 Replying to [comment:213 jgrahamc]:
 > Do you mean could we only show a CAPTCHA to sites that we already know
 are under attack?

 Yes. I can only assume this was on the table at some point, but I feel I
 don't have a full understanding of the problem.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by jgrahamc):

 Replying to [comment:212 tne]:
 > Replying to [comment:211 jgrahamc]:
 > > Are Tor users seeing easier to pass CAPTCHAs now?
 >
 > I believe for the first time ever I got through one in a single pass a
 few minutes ago, where it used to take me two passes at a minimum before
 (~past year, probably since forever). Small datapoint, but it sounds
 related.

 Good to hear. Hoping that others will have the same experience.

 > Side question: Would you mind pointing me to some clarifications
 regarding the difficulties around shielding only the sites that are under
 attack and leaving the rest open?

 Do you mean could we only show a CAPTCHA to sites that we already know are
 under attack?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by tne):

 Replying to [comment:211 jgrahamc]:
 > Are Tor users seeing easier to pass CAPTCHAs now?

 I believe for the first time ever I got through one in a single pass a few
 minutes ago, where it used to take me two passes at a minimum before
 (~past year, probably since forever). Small datapoint, but it sounds
 related.

 Side question: Would you mind pointing me to some clarifications regarding
 the difficulties around shielding only the sites that are under attack and
 leaving the rest open? I've went through this thread, two HN threads and
 CF's blog -- given the large amount of discussion I feel like I might have
 missed it. If not, would you elaborate a little bit on that here or
 elsewhere? I saw the question pop up quite a few times and I'm interested
 myself.

 Thank you.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by jgrahamc):

 Are Tor users seeing easier to pass CAPTCHAs now?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by jgrahamc):

 Replying to [comment:201 frustrated]:
 > Since there are Cloudflare people on this thread, I have a number of
 questions.
 >
 > 1. Why is it that the images on the captcha load individually, slowly?
 >
 > 2. Why is it that the captchas usually fail, and you have to do it over
 and over again?
 >
 > I'm serious. I went to look up a Bible passage, REPEATEDLY solved
 captchas for OVER A HALF HOUR, and gave up and grabbed the bible on my
 shelf. I was so angry I wanted to break something.

 I would be interested to know if this situation is now resolved.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-04-01 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--
Changes (by tne):

 * cc: tne (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-30 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by jgrahamc):

 As promised the CEO has written about Tor including information on how to
 whitelist Tor exit nodes on CloudFlare: https://blog.cloudflare.com/the-
 trouble-with-tor/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-27 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by cypherpunks):

 Replying to [comment:206 jgrahamc]:
 > I'm here, not posting unless I have something useful to say.
 Agree. For my part, I liked best when you educated the Tor community that
 the exit nodes fluctuate.
 https://trac.torproject.org/projects/tor/ticket/18361#comment:159
 Must have been a novelty to many.

 madD

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-25 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by jgrahamc):

 Replying to [comment:205 cypherpunks]:

 > Since CF manages whitelisting as a hidden feature

 Not a hidden feature. CEO plans to blog about Tor and this will be
 included.

 > we're gonna have to contact their customers directly. And inform them
 politely about whitelisting, or better, onionizing their service.

 CEO wants us to issue .onions automatically for sites on CloudFlare to
 make things easier all round:
 https://twitter.com/eastdakota/status/710357574579650560

 > @jgrahamc stopped posting 3 weeks ago, the number of daily captchas does
 not sink, at least in my experience, and I don't believe in miraculous
 tesseracts, they only work until next generation of gropeware is released.
 CF and Google conduct a digital form of TSA's groping.

 I'm here, not posting unless I have something useful to say.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-25 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by cypherpunks):

 Replying to [comment:204 cypherpunks]:
 > I don't know if its coincidental or if Cloudflare is taking its
 douchebagery to new levels but now accessing some pages even with
 archive.is is still blocked.
 >
 > https://www.aei.org/publication/gen-michael-hayden-on-apple-the-fbi-and-
 data-encryption/
 >
 > https://archive.is/7u5P8
 >
 >
 > This whole "enagagement with Tor" is looking like a damage control
 tactic instead of saying they block us outright and having customers
 leave. Fuck you Cloudflare.

 Since CF manages whitelisting as a hidden feature, we're gonna have to
 contact their customers directly. And inform them politely about
 whitelisting, or better, onionizing their service. I see no other option
 at this point. @jgrahamc stopped posting 3 weeks ago, the number of daily
 captchas does not sink, at least in my experience, and I don't believe in
 miraculous tesseracts, they only work until next generation of gropeware
 is released. CF and Google conduct a digital form of TSA's groping.

 The problem is how to deliver thousands of CF customers our informing
 email without getting that email globaly blacklisted within one
 microsecond :)

 madD

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-25 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by cypherpunks):

 I don't know if its coincidental or if Cloudflare is taking its
 douchebagery to new levels but now accessing some pages even with
 archive.is is still blocked.

 https://www.aei.org/publication/gen-michael-hayden-on-apple-the-fbi-and-
 data-encryption/

 https://archive.is/7u5P8


 This whole "enagagement with Tor" is looking like a damage control tactic
 instead of saying they block us outright and having customers leave. Fuck
 you Cloudflare.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-24 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by cypherpunks):

 Replying to [comment:87 jgrahamc]:
 > > I'll wrap up with a question.  ''How'' are you intending on rolling
 out this new feature?  Is it going to be opt-in, opt-out, will there be an
 email sent to your customers about using it?  I think that this is
 something that the community is greatly interested in.
 >
 > Almost everything we announce goes on our blog so I imagine we'll do it
 that way. It gets emailed to people who subscribe to the blog. I don't
 know if it'll be emailed to all customers (mostly because we don't tend to
 send them a lot of email and it's the marketin group that decides). The
 current plan is for this to be opt-in.

 1) Whitelisitng was NOT announced on blog.cloudflare.com, can you fix
 that?
 2) nor did customers get any email
 3) The chosen firewall identifier is confusingly "T1", entering "Tor"
 leads to error without hint:

 [[Image(http://3j3j5hyf44hgggod.onion/bbo8ui6i.png)]]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-23 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--
Changes (by saint):

 * cc: saint (added)


Comment:

 Replying to [comment:173 polyclef]:
 > Cloudflare is using recaptcha.  Recaptcha has been broken for years.
 >
 > http://bitland.net/captcha.pdf describes how to defeat captchas in
 general and a prior version of recaptcha in particular.
 >
 > Many challenges are overly simple and can be broken with existing tools
 that require no further modification.


 In the thread someone mentions that it's possible to derive the answer for
 the old-style street number captchas using tesseract [1]. Interestingly,
 there is a version of tesseract in javascript [1]. This is probably not
 especially useful for the current "select all boxes that contain one pixel
 of street sign" Recaptcha system, but if there were a way to trigger the
 old behavior, these techniques could be used together.

 [1] http://tesseract.projectnaptha.com/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-21 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by frustrated):

 Since there are Cloudflare people on this thread, I have a number of
 questions.

 1. Why is it that the images on the captcha load individually, slowly?

 2. Why is it that the captchas usually fail, and you have to do it over
 and over again?

 I'm serious. I went to look up a Bible passage, REPEATEDLY solved captchas
 for OVER A HALF HOUR, and gave up and grabbed the bible on my shelf. I was
 so angry I wanted to break something.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-19 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--
Changes (by jeffburdges):

 * sponsor:   => None


Comment:

 A partial fix similar to Yawning's CFC extension might be an extension to
 provide a mailto: link to contact the website's operator based upon whois
 information.  A mailto: link goes through the user's own email program, so
 it's likely to be read and allow discussion.

 Also, mailto: links can provide initial text that explains the problem.
 This could mention that CloudFlare's upmarket competitors like Akamai see
 no problem with Tor users.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-19 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--

Comment (by paradox):

 It is getting worse.

 Got a Google captcha. Clicked on audio challenge. Instead of a series of
 numbers the message was:
 "Your computer or network maybe sending automated queries.
 To protect our users, we cannot process your request right now."
 (Here the full message:
 http://wikisend.com/download/403898/dos_captcha_audio.mp3)

 Subsequently right after the audio message clicked on "Get a visual
 challenge".
 Solved the warped image correctly. Got the content.

 This happened repeatedly over the course of several hours. Each time with
 different content, requested from different exit node located in different
 countries.
 Each time the same pattern, audio message denies, visual challenge carries
 on.

 I think we should determine the responsibilities in the Google-Cloudflare
 mishmash for indiscriminately denying a minority group of privacy
 conscious users access to web content.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-11 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Well something needs to be done for the humans.  Non-human user agents can
 presumably tell that a missing image has been individually captcha'd but
 nothing makes this apparent to humans browsing a site.  If you know you're
 serving an image at least serve an error image instead of serving the
 captcha page in place of an image.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-09 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 @jgrahamc

 Have you checked if Orfox support is happening? The user experience is
 still terrible with 0% success.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-07 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by jgrahamc):

 Replying to [comment:194 samlanning]:
 > (I've written this up in more detail as a blog post over at
 https://samlanning.com/blog/the_tor_cloudflare_problem/ that I'd love
 critique on).

 I don't think this improves the situation. It doesn't help for non-human
 User-Agent (such as legitimate bots, apps and anything calling an API).
 The right solution is for us to start applying our attack detection
 technologies to Tor traffic and not make the first layer of defence the
 CAPTCHA.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-06 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by yawning):

 Replying to [comment:192 cypherpunks]:
 > Replying to [comment:190 yawning]:
 > > Proof of concept, if you actually use this for anything other than
 "testing said proof of concept" you get what you deserve.  The README.md
 has dire warnings about reduction in anonymity, and I will point and laugh
 at people that have bad things happen to them.
 > >
 > > https://git.schwanenlied.me/yawning/cfc
 >
 > archive.li (which is what archive.is serves all the images from) is
 using cloudflare now :(

 Proof of concept is a proof of concept.  Switching the archive service
 used is a one line change (Suggestions accepted, though `archive.is` seems
 to have the least suck privacy/takedown policies).

 Maybe someone should contact them to see if they are willing to whitelist
 Tor access.

 I felt inspired and wrote the code for "scrape the DOM to see if it
 actually is a captcha page, and inject a unblock me now button"
 (https://imgur.com/MW71d3g).  Not in git, I want to get some more things
 done before I push.

 The button works even with NoScript set to paranoid values.

 When I have time I'll finalize the UI.  I'm leaning towards mirroring the
 NoScript UX with "Allow CloudFlare globally (Dangerous)" (Switches between
 the fast reject behavior and the new DOMscraping/injection based
 unblocking), and some menu items that allow manipulating the internal non-
 persistent white/blacklist.

 (nb: I still would rather prefer clever crypto and I promised someone
 feedback about such.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-06 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by samlanning):

 I've been thinking over this problem for a number of days now, and think I
 may have come to a solution that is somewhat of a Compromise.

 (I've written this up in more detail as a blog post over at
 https://samlanning.com/blog/the_tor_cloudflare_problem/ that I'd love
 critique on).

 But here's the important bit:

 This idea requires work from both the Tor developers (specifically those
 who work on TBB), and the CloudFlare developers.

 == The User Experience ==

 For non Tor users, or Tor users using an older TBB, the experience is
 unchanged. Older Tor users will still have to use a Captcha, which will
 grant them full access to a website as is currently done now. For users
 using the latest TBB, upon landing on a website protected by CloudFlare,
 they will see something like this:

 [[Image(https://i.imgur.com/zWhSuTg.png)]]

 ''Note: the wording in this screenshot is by no means final.''

 Now the user can choose to either ignore the warning, dismiss it, or click
 "Prove You're Human". Ignoring the warning will allow the user to continue
 using the site in a Read Only mode; here I think the most appropriate
 Implementation would be to use Cached-Only pages (not sending any requests
 on to the server). For any cache misses it can display the Captcha.

 Now when a user submits a form, the page will remain in a "loading" state
 while a new tab is opened and focused for the user to complete a Captcha.
 (We could optionally have the same warning displayed on this page, but
 without the button or dismiss icon). Once the user has completed the
 captcha, the tab will close and the existing (paused) tab will continue
 (actually make the request).

 A similar thing would happen for any AJAX or WebSocket requests, the
 request would be paused until a Captcha is completed in a separate tab or
 window.

 This would allows for, I think, the minimum amount of friction for
 performing any particular task on a website, requiring a Captcha only when
 necessary, and indicating to a user that they are viewing a reduced-
 functionality version of a website.

 == A Technical Implementation ==

 On the TBB side, the browser would need to indicate that it supports this
 "prove human" functionality by way of either User-Agent, or by specifying
 a particular header. For example, along with the request, it could send `X
 -Human-Proof: Available`.

 The CloudFlare server, upon receiving a request, if:

 * The threat level has been determined as "CAPTCHA"
 * The user agent supports the "Human Proof" feature (i.e. has the
 appropriate `X-Human-Proof` header).
 * There is no cookie set for the Captcha (no existing proof-of-human).
 * The request is a `GET`.
 * The requested URL is cached.

 Then return the cached contents, along with a header like `X-Human-Proof-
 Required: `. In any other situation, behave
 as normal. ''(Note: the URL will need to be for the same domain as the
 request, so site-relative probably will make most sense, i.e. starting
 with `/`)''

 The TBB, upon seeing a response with the header `X-Human-Proof-Required`,
 will mark any domains that return this as "requiring human proof" (for the
 given session), and for any pages whose URL contains a domain in this
 list, display the bar shown in the screenshot (unless it's already been
 dismissed).

 Now when any non-`GET` request is made to a domain marked as "requiring
 human proof" (whether AJAX, WebSocket or otherwise), pause the request,
 and open a new tab to the URL required (given in the `X-Human-Proof-
 Required` header). Wait for a response from the given domain that '''does
 not''' contain the `X-Human-Proof-Required` header, then continue the
 paused request (actually send the request to the server).

 == Future Improvements ==

 This would give us a good foundation for building on iterative UX
 improvements, and improving mechanisms for how user agents prove to
 servers that they are being operated by humans. From here we could:

 * Submit an RFC for these headers, and try and make an official spec for
 the behaviour.
 * Make these changes in the client (handling of headers, pausing requests,
 opening challenge in new tab etc...) upstream, and across other browsers.
 * Iteratively improve the UI, such as displaying a blocking-dialog on any
 pages that

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-04 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 Replying to [comment:189 jgrahamc]:
 > The feature to whitelist the Tor network has been shipped and is
 documented here: https://support.cloudflare.com/hc/en-
 us/articles/203306930

 Thanks! Will you enable this feature for support.cloudflare.com,
 cloudflare.com, etc?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-04 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 Replying to [comment:190 yawning]:
 > Proof of concept, if you actually use this for anything other than
 "testing said proof of concept" you get what you deserve.  The README.md
 has dire warnings about reduction in anonymity, and I will point and laugh
 at people that have bad things happen to them.
 >
 > https://git.schwanenlied.me/yawning/cfc

 archive.li (which is what archive.is serves all the images from) is using
 cloudflare now :(

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-02 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 Replying to [comment:189 jgrahamc]:
 > The feature to whitelist the Tor network has been shipped and is
 documented here: https://support.cloudflare.com/hc/en-
 us/articles/203306930

 Captcha'd trying to access this page.  Try enabling the whitelist?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-02 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by yawning):

 Proof of concept, if you actually use this for anything other than
 "testing said proof of concept" you get what you deserve.  The README.md
 has dire warnings about reduction in anonymity, and I will point and laugh
 at people that have bad things happen to them.

 https://git.schwanenlied.me/yawning/cfc

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

2016-03-02 Thread Tor Bug Tracker & Wiki

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by jgrahamc):

 The feature to whitelist the Tor network has been shipped and is
 documented here: https://support.cloudflare.com/hc/en-
 us/articles/203306930

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 I have noticed several times that one of the many Google resources
 required for recaptcha will get blocked by a Google captcha.  There is no
 indication of this on the Cloudflare captcha page, I have to try all the
 urls to see which one is getting blocked.  In the short term Cloudflare
 could improve reliability by either detecting this or by getting Google
 not to throttle their captcha resources.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by madD):

 Replying to [comment:181 SatoshiNakamoto]:
 > madD : whatever script you just ran to make that pretty graph, either
 > a) would you be interested in running it on https://pad.okfn.org/p
 /cloudflare-tor periodically
 > b) or providing the world with the source code so we can?
 > thanks.
 I'm not the author, never claimed so. Below the image was a link to the
 source, @sheetal57, now it's above.
 It's a good idea, that script should run periodically. However, I'd not
 disclose the code in order to avoid fingerpriting by CloudFlare. If the
 target list & sequence & timing are fixed in the code, it'd be easy for CF
 to make false positives, i.e. pass no captchas to script bot + a few tor
 users who happen to access target domain in the same timeslot as the
 script. It'd need proper randomization first. If you write to @sheetal57,
 tell her please.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by wwaites):

 Replying to [comment:185 jgrahamc]:

 > This idea just kicks the ball down the line. The right solution is to
 allow
 > Tor users who are not behaving in a malicious manner 'normal' access to
 the
 > web.

 Well no not really. Cloudflare is fundamentally the *wrong* solution for
 security, because it is about putting a bubble around broken and
 vulnerable
 web sites. This is easier than fixing the actual problems so it is
 attractive.

 This is quite apart from what might be the *right* use of Cloudflare or
 other
 CDNs (modulo surveillance) which is efficiently delivering data from as
 close
 to the edge as possible, and coincidentally being able to sink volumetric
 DDoS attacks.

 The problems with Tor arise, near as I can tell, almost exclusive from the
 former. It's just bad architecture.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by jgrahamc):

 Replying to [comment:184 cypherpunks]:
 > Replying to [comment:182 jgrahamc]:
 > > I'm not sure how you come up with the 5% number but I think you
 underestimate how complicated deciding what R/O is in the web. Plenty of
 attacks come through GET requests. Doing the R/O mode seems like a nasty
 hack.
 >
 > To me R/O would be delivering the cache that you have. The request would
 never see the actual website. This would also discourage adversaries that
 repeatedly pull websites to have an automated advantage at idk ticket
 sales as the cache does not have to be the most recent.

 There are a lot of assumptions here. For example, this assumes that we
 have all the pages in cache and all the assets. It assumes that web pages
 can be displayed without any POSTs happening (so nothing dynamic at all).

 In addition it ignores what happens if a Tor user comes to CloudFlare and
 we don't have the item in cache, or the item is outdated.

 This idea just kicks the ball down the line. The right solution is to
 allow Tor users who are not behaving in a malicious manner 'normal' access
 to the web.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 Replying to [comment:182 jgrahamc]:
 > I'm not sure how you come up with the 5% number but I think you
 underestimate how complicated deciding what R/O is in the web. Plenty of
 attacks come through GET requests. Doing the R/O mode seems like a nasty
 hack.

 To me R/O would be delivering the cache that you have. The request would
 never see the actual website. This would also discourage adversaries that
 repeatedly pull websites to have an automated advantage at idk ticket
 sales as the cache does not have to be the most recent.

 I mean seriously. How hard can it be to deliver the cache instead of a
 captcha? I can't imagine that this takes one of your junior software
 engineers more than two hours to implement and then a day to deploy. But
 please give us better estimates, so we have an idea of what we are
 actually demanding here.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 How nice it is for CloudFlare to work with us, thank you very much. It's
 nice to have a global active adversary that listens to us. One has to
 wonder for how long this will last, perhaps a few years, perhaps a decade?
 How long will it be until CloudFlare is eaten by the bigger fish, or
 bought out by a company like Google? Money trading hands decides our fate
 here, we'd be fools to think we can fix this.

 The facts are that online we have authorities like Wikipedia, Gutenberg,
 CloudFlare, Google that decide what we can read or write based on what
 information we give. How did we even get to this point? We need to
 drastically change this structure, and we need to do it before things get
 worse. Not by asking, but by doing with or without permission.

 To throw an idea out, let's mirror popular sites (Wikipedia, Gutenberg,
 news sites behind CloudFlare) using scraping tools and integrate our own
 GET cache using Tor Browser using IPFS or something similar.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by jgrahamc):

 Replying to [comment:180 cypherpunks]:
 > Of course we all want the perfect solution in happy rainbow land, but
 let's face it, allowing read-only of the cache will take about 5% of the
 resources that the "proper" solution would take and make 95% of users
 happy. I would consider this a good first step in the right direction. It
 would also take a lot of pressure from the recaptcha issues, and might
 rather increase the elasticity in your resource planning instead of
 occupying more resources.

 I'm not sure how you come up with the 5% number but I think you
 underestimate how complicated deciding what R/O is in the web. Plenty of
 attacks come through GET requests. Doing the R/O mode seems like a nasty
 hack.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 Replying to [comment:166 jgrahamc]:
 > Replying to [comment:163 cypherpunks]:
 > > Thank you for the new possibility to whitelist Tor, jgrahamc.
 > >
 > > An argument I have often seen raised, acknowledged, but then silently
 dropped over the last year was the one of the read only option, though.
 The arguments made for delivering the contents via onion services were
 sound as well. If Facebook can do it why shouldn't you?
 >
 > On the R/O mode I'm mostly opposed to working on it because I've got X
 engineering resources and I'd rather spend them on a solution that allows
 legitimate Tor users 'normal' access to the web and not some special mode.
 I think Tor users are better off and CloudFlare a stronger company if I do
 that.

 Of course we all want the perfect solution in happy rainbow land, but
 let's face it, allowing read-only of the cache will take about 5% of the
 resources that the "proper" solution would take and make 95% of users
 happy. I would consider this a good first step in the right direction. It
 would also take a lot of pressure from the recaptcha issues, and might
 rather increase the elasticity in your resource planning instead of
 occupying more resources.


 > We've debating internally offering .onion addresses to our customers
 and/or running exit nodes just for our customer base. Currently there's no
 work happening on this but neither are out of the question (they've just
 tended to get prioritized far down the list).

 That sounds promising. Maybe a collaboration with Tor developers is an
 option here? They also have priority lists, but I guess the Cloudflare
 issues are rather higher on their list than the Tor issues on yours.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by jgrahamc):

 Replying to [comment:171 aperture]:
 > @jgrahamc: I'm glad to see the whitelist tor option. This has certainly
 made me consider re-subscribing to Cloudflare Business for one of my
 sites.

 Glad to hear it.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by jgrahamc):

 Replying to [comment:174 cypherpunks]:
 > @jgrahamc
 >
 > Has anyone at CF looked at the captcha bugs when browsing with Orfox
 yet? Still broken :(

 Not sure. I need to check in with the SF office on that.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 Replying to [comment:176 aperture]:
 > @polyclef: It's well known that the "simple reCAPTCHAs" like image
 classification and street number OCR relies on being logged into a Google
 Account and accessing from an IP with high reputation.
 No, that's wrong. Why comment if you're clueless?

 > As many faults as reCAPTCHA has, there's no alternative. Rolling your
 own CAPTCHA takes years of effort and can have a high risk initially.
 WTF? Both of those statements are outrageously false. What gives?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by aperture):

 @polyclef: It's well known that the "simple reCAPTCHAs" like image
 classification and street number OCR relies on being logged into a Google
 Account and accessing from an IP with high reputation.

 reCAPTCHA isn't broken; it has been a behavioural based system for ages.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by madD):

 @jgrahamc
 WHO say that ''there are estimated 285 million people visually impaired
 worldwide: 39 million are blind and 246 million have low vision''. If they
 want to enjoy the privacy of VPN or Tor, they are forced to take an Audio
 challenge (javascript only), in order to decrypt crappy telephone
 recordings of numbers (English only).

 Furthermore, people with motorics handicap, like Stephen Hawking, can't
 provide human-like mouse movements for reCAPTCHA v2, but don't know that
 they should turn off JS to get static challenge.

 What will CloudFlare advise to all of them?

 #ttp://www.who.int/mediacentre/factsheets/fs282/en/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 @jgrahamc

 Has anyone at CF looked at the captcha bugs when browsing with Orfox yet?
 Still broken :(

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by polyclef):

 Cloudflare is using recaptcha.  Recaptcha has been broken for years.

 http://bitland.net/captcha.pdf describes how to defeat captchas in general
 and a prior version of recaptcha in particular.


 Many challenges are overly simple and can be broken with existing tools
 that require no further modification.

 Example:

 [[Image(http://bitland.net/recaptcha-001.jpg)]]

 can be solved with tesseract

 {{{% tesseract recaptcha-001.jpg stdout -psm 4}}}
 outputs
 {{{1307}}}

 Other challenges may require simple processing such as erode/dilate, etc

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by aperture):

 FYI, I encountered a 8 recaptcha loop while signing up here! I entered the
 wrong captcha initially, and I think the "redirect on success page" got
 set to `/projects/tor/captcha`. When I successfully completed the CAPTCHA,
 I still got redirected to the captcha page.

 While I'm talking about reCAPTCHA, it is pretty much an open secret that
 No CAPTCHA works by collecting as much information correlated to 'bot or
 not' as possible, and feeding it to a neural network. Google has a nice
 source for 'bot or not' by looking at deactivations of the Google account
 registration flow.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by aperture):

 As a website owner, I had to take the somewhat difficult decision to block
 Tor on some services in order to minimize disruption. Creating a special
 read-only or restricted mode for Tor users were not feasible as I have
 engineering time constraints. I suspect this is fairly common.

 Fundamentally, site owners typically rely on identifiers like IP, email,
 CAPTCHA, etc to weakly identify users. Each of these resources have a
 small cost, and hence blocking abuse is a possibility as there is a cost
 to abuse. Tor removes these identification vectors, making individual
 blocking unfeasible.

 This is not a question of humanness or the turning test. It's about
 introducing a progressive cost to privileged actions (whether that's
 creating an account, posting on a forum, etc) that has zero monetary cost
 for the user.

 To resolve this problem, there needs to be an easy way (both from a site
 owner, and a user's perspective) of applying a cost to privileged actions,
 when conventional identification methods do not work. One option is
 bitcoin micropayments, which is already being done on many bitcoin-related
 sites with good success. Bitcoin isn't accessible to the vast majority of
 people though.

 Another more promising option is proof of work. Unfortunately PoW heavily
 tilts in the favor of botnets, spammers running a Xeon, etc. Decentralized
 and possibly zero knowledge identity '''is''' what appears to the most
 promising solution.

 In the interim, I think resolving CAPTCHA loop issues on Tor is a good
 fix. 1 CAPTCHA per site is too much, but it's better than nothing.

 As for the read only concept, I just don't think it'd work. Many modern
 web sites submit data with AJAX post requests or websockets; you can't
 intercept that and return a CAPTCHA. `` for POST is getting rarer
 and rarer, and whatever cloudflare does needs to work for almost every
 site; not just "some sites" or even "a majority of sites".

 @jgrahamc: I'm glad to see the whitelist tor option. This has certainly
 made me consider re-subscribing to Cloudflare Business for one of my
 sites.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by strcat):

 Some irony: Trac decided my comment was probably spam and had me fill out
 a recaptcha.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by strcat):

 Hi jgrahamc,

 As a CloudFlare user, I've noticed that there are many users encountering
 the captchas without the events appearing in the traffic log. I don't
 think sites have any idea how aggressive the feature is by default because
 it seems that only 1/100 events ends up in the traffic log. I think you
 should consider shipping it as Essentially Off by default and allowing
 sites to opt-in to more aggressive checking if they really have anti-spam
 or anti-DoS problems. Most sites do not have those problems. They don't
 allow anonymous comments and already have captchas for registration. They
 may encounter spikes in spam or a DoS attack, in which case it makes sense
 to crank up that setting. If your customers realized how many users they
 were losing, they would be upset.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 The most poisonous thing about those graphical captchas is having to
 interpret a constant barrage of ontological corner cases from the
 viewpoint of some silly machine learning algorithm

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by madD):

 Cloudflare now blocks 60-80% of the exits
 research by Berkeley University
 [[Image(https://pbs.twimg.com/media/CcGst-OUkAA0qxc.jpg:large)]]
 https://twitter.com/sheetal57/media

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by jgrahamc):

 Replying to [comment:163 cypherpunks]:
 > Thank you for the new possibility to whitelist Tor, jgrahamc.
 >
 > An argument I have often seen raised, acknowledged, but then silently
 dropped over the last year was the one of the read only option, though.
 The arguments made for delivering the contents via onion services were
 sound as well. If Facebook can do it why shouldn't you?

 On the R/O mode I'm mostly opposed to working on it because I've got X
 engineering resources and I'd rather spend them on a solution that allows
 legitimate Tor users 'normal' access to the web and not some special mode.
 I think Tor users are better off and CloudFlare a stronger company if I do
 that.

 We've debating internally offering .onion addresses to our customers
 and/or running exit nodes just for our customer base. Currently there's no
 work happening on this but neither are out of the question (they've just
 tended to get prioritized far down the list).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 Replying to [comment:148 cypherpunks]:
 > Is CloudFlare trying to protect against anything besides these 4
 categories of unwanted traffic?

 @jgrahamc can you enlighten us?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 Replying to [comment:162 cypherpunks]:
 > Replying to [comment:119 jgrahamc]:
 > > Sorry for the double post there. Got stuck in a loop of CAPTCHAs on
 this site and was unable to submit.
 >
 > Is this a joke? There are no captchas here.
 Regrettably there are and they don't work very well. The 'trac' software
 uses google captchas in some situations (for example when one of its
 cranky filters trips on a word it doesn't like and logically concludes
 your comment is 'spam'). There are a number of tickets about this.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 Thank you for the new possibility to whitelist Tor, jgrahamc.

 An argument I have often seen raised, acknowledged, but then silently
 dropped over the last year was the one of the read only option, though.
 The arguments made for delivering the contents via onion services were
 sound as well. If Facebook can do it why shouldn't you?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 Replying to [comment:119 jgrahamc]:
 > Sorry for the double post there. Got stuck in a loop of CAPTCHAs on this
 site and was unable to submit.

 Is this a joke? There are no captchas here.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 Replying to [comment:41 ioerror]:
 > Replying to [comment:37 jgrahamc]:
 > > I'm not convinced about the R/O solution. Seems to me that Tor users
 would likely be more upset the moment they got stale information or
 couldn't POST to a forum or similar. I'd much rather solve the abuse
 problem and make this go away completely.
 >
 > Are you convinced that it is strictly worse than the current situation?
 I'm convinced that it is strictly better to only toss up a captcha that
 loads a Google research when a user is about to interact with the website
 in a major way.


 +1000

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

Comment (by madD):

Webmasters who use Google's reCaptcha are reporting since 24th February
unannounced changes of server response messages, and disruptions in
service. Needless to say, Google does not react on their complaints in
support forum.

groups.google.com/forum/?_escaped_fragment_=topic/recaptcha/5zlo4DpqhWI#!topic/recaptcha/5zlo4DpqhWI
CloudFlare with their millions of users do not complain into that forum at
all, isn't it strange?

Neither FAQ for reCaptcha / Google Privacy / Google Terms contain
information about biometrics capture by reCaptcha v2. If this is the case,
Google knows that it does so illegaly. Implicitly, CloudFlare could
publicly deny knowing it, to shrug off accusations. However, they don't
deny it. Why? Non disclosure agreement of some kind?

While CloudFlare are willing to discuss the reCaptcha trigger conditions,
they won't talk about the actual reCaptcha v2 code. Non the less there
must be some exchange with Google, because of the unannounced reCaptcha v2
changes ever since this ticket got attention.

--
Ticket URL:
Tor Bug Tracker & Wiki
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by jgrahamc):

 Also, I was looking at how often we update our exit node list and wrote a
 little program to visualize the coming and going of nodes. The code is
 here: https://github.com/jgrahamc/torexit and I've been running a cron job
 that does this every 15 minutes:

 {{{
 curl -s -o $HOME/torhoneydata/exitlist_`date --utc +%s`
 https://check.torproject.org/exit-addresses
 }}}
 Here are 24 hours of that data (columns are exit nodes, rows are 15 minute
 increments). White means that the exit node did not appear in the exit
 node list when that 15 minute cron job ran. So you can see the coming and
 going of nodes.

 [[Image(https://i.imgur.com/qQH09pz.png)]]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by jgrahamc):

 The ability to whitelist Tor exit nodes has been rolled out but not
 announced yet (the marketing/support folks need to write up the
 documentation etc.) but I've enabled it on one of my domains and not on
 another so that people can test.

 http://plan28.org: Tor exit nodes are whitelisted

 http://jgc.org: Tor exit nodes are not whitelisted (CloudFlare default
 handling).

 So, you should see no CAPTCHAs on plan28.org but CAPTCHAs on jgc.org. You
 should only get a CAPTCHA the first time you visit jgc.org unless you use
 a new Tor identity. Appreciate bug reports; I've been testing using the
 TorBrowser and repeatedly switching to a new circuit and it seems OK but
 this is very beta right now.

 If you do see a CAPTCHA when switching circuits it would be handy to know
 the IP address of the exit node and the UTC time so I can see if it's
 caused by a bug or us not having an up to date list of exit nodes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by ioerror):

 Replying to [comment:154 jgrahamc]:
 > Replying to [comment:153 ioerror]:
 > > Thanks for continuing to engage jgrahamc. Many of us, myself included,
 would really like to see the list or the general issued raised in
 comment:144 addressed. I'm especially keen to see how Tor exits compare
 with the XFF proxy IP addresses; are any of those IP addresses being
 treated specially?
 >
 > Plan to keep engaging, but I'm concentrating most of my effort on
 solving the problem (i.e. keeping our customers safe while making life
 better for Tor users). Working on statistics.

 Thank you very much for the update.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by SatoshiNakamoto):

 The *immediate* problem, at least in my particular case( palemoon ( 26.0.1
 )), with javascript *disabled* appears to have been resolved, at least
 momentarily.  *With* javascript enabled,

 "the page at http://www.google.com says:
 Cannot contact reCAPTCHA. Check your connection and try again."

 After spinning the CPU up for awhile.  This means I can get away with
 disabling javascript, but others who don't know to do that will be
 effectively blocked at that poinnt.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by freetheinternet):

 Blocked by the Great Cloudwall when going to the new Register article (I
 have JavaScript enabled).
 [http://www.theregister.co.uk/2016/02/25/tor_users_discriminated_against/]
 [[Image(http://s30.postimg.org/qli4oqn0x/cloud0.png)]]
 [[Image(http://s30.postimg.org/5afz6qfip/cloud1.png)]]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by jgrahamc):

 Replying to [comment:153 ioerror]:
 > Thanks for continuing to engage jgrahamc. Many of us, myself included,
 would really like to see the list or the general issued raised in
 comment:144 addressed. I'm especially keen to see how Tor exits compare
 with the XFF proxy IP addresses; are any of those IP addresses being
 treated specially?

 Plan to keep engaging, but I'm concentrating most of my effort on solving
 the problem (i.e. keeping our customers safe while making life better for
 Tor users). Working on statistics.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by ioerror):

 Thanks for continuing to engage jgrahamc. Many of us, myself included,
 would really like to see the list or the general issued raised in
 comment:144 addressed. I'm especially keen to see how Tor exits compare
 with the XFF proxy IP addresses; are any of those IP addresses being
 treated specially?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by jgrahamc):

 Replying to [comment:150 cypherpunks]:
 > Replying to [comment:82 jgrahamc]:
 > > 1. We'll roll out the ability for any CloudFlare web site to whitelist
 Tor so that Tor users will not see CAPTCHAs within days.
 >
 > For the free tier too? Someone told me recently that they have fewer
 controls, which would make sense, but if that means that they're stuck
 with the default tor-blocking policy then that is obviously a big problem.

 It is true that free customers have fewer controls, but they will be able
 to whitelist Tor.

 > Also, another repeated question which I haven't seen CloudFlare answer
 yet so I'll restate it here: are you or are you not selling or otherwise
 sharing the very valuable analytics data you're in an ideal position to
 collect? Specific clickstream data, perhaps? Or maybe something derived
 from it, like "people who go to this website also go to this other
 website"?

 We are not.

 We've written about our logging in the past (https://blog.cloudflare.com
 /what-cloudflare-logs/) and I gave a talk about that
 (http://www.thedotpost.com/2015/06/john-graham-cumming-i-got-10-trillion-
 problems-but-logging-aint-one). Also here's our transparency report:
 https://www.cloudflare.com/transparency/

 Tor users may notice changes starting today as I altered the speed with
 which we download the Tor exit node list to make sure that it's more up to
 date and we are rolling out fix for a caching bug that was identified (see
 earlier) and affected identifying an IP as a Tor exit node.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 Replying to [comment:148 cypherpunks]:
 > Can any CloudFlare person explain if there are more than these 4
 categories of unwanted traffic?

 Following up on this question, what specific type of unwanted traffic is
 CloudFlare attempting to protect *itself* against when it just served me a
 captcha in response to a `GET /` request to https://cloudflare.com/ ?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 Replying to [comment:82 jgrahamc]:
 > 1. We'll roll out the ability for any CloudFlare web site to whitelist
 Tor so that Tor users will not see CAPTCHAs within days.

 For the free tier too? Someone told me recently that they have fewer
 controls, which would make sense, but if that means that they're stuck
 with the default tor-blocking policy then that is obviously a big problem.

 Also, another repeated question which I haven't seen CloudFlare answer yet
 so I'll restate it here: are you or are you not selling or otherwise
 sharing the very valuable analytics data you're in an ideal position to
 collect? Specific clickstream data, perhaps? Or maybe something derived
 from it, like "people who go to this website also go to this other
 website"?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by jgrahamc):

 Replying to [comment:142 SatoshiNakamoto]:
 > It would be nice if there was somewhere on *cloudflare*'s side to report
 specific tor-related client issues that wasn't behind the great cloudwall.
 That would be one way for Cloudfare to work together with the tor network,
 beyond having one thread on tor's side, wouldn't it?

 There's CloudFlare's regular support, but, to be honest, there are lots of
 people (including me) reading this thread and suggestions made in it (and
 the complaints) and working internally to address them. I'm happy for
 folks to add specific problems they've seen (e.g. on the "Banana Wumpus
 4.2 Mobile Browser the CAPTCHA wasn't rendered") so I can get them into
 our bug system. I've received a few reports like that already.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 Is CloudFlare trying to protect against anything besides these 4
 categories of unwanted traffic?

 1. Comment Spam
 2. DDOS
 3. Vulnerability scanning
 4. Crawling

 Of course different customers probably have different priorities, but it
 seems to me like captchas on GET requests are mostly useful for stopping
 crawling. (Comment spam is POST, DDOS over Tor would be stupid as botnets
 are cheap and more effective, and for vuln scanning it should be pretty
 easy to have high confidence that typical requests are legit using simple
 heuristics.)

 So whats up?

 Can any CloudFlare person explain if there are more than these 4
 categories of unwanted traffic?

 And what portion of CloudFlare customers are anti-web-crawling?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by madD):

 BIOMETRICS ALERT
 An eye-opening article by a data mining researcher, Igor Savinkin,
 http://scraping.pro/no-captcha-recaptcha-challenge/
 says:
 "For this new type of CAPTCHA the main evidence will be browser behaviour,
 rather than check box value.
 '''mouse movement, its slightness and straightness
 page scrolls
 time intervals between browser events
 keystrokes
 click location history tied to user fingerprint'''
 All these criteria, are stored in the browser’s cookie. These criteria are
 processed by Google’s server"

 He also states that the communication between the user and Google server
 is encrypted.

 It should be emphasized, that there is a DARPA '''technology to identify
 people by mouse movements and typing''' http://www.itnews.com.au/news
 /users-ided-through-typing-mouse-movements-365221. In 2013 this technology
 was "being extended to capture mouse movements and touch inputs from
 mobile devices".

 CloudFlare highly probably is an accomplice in a mass biometrics
 collection and deanonymization service. There is no wonder that we got
 GLOMARed by their CTO on most occasions before he went silent completely.
 This program surely violates privacy laws, at least in Europe, because the
 users get no warning that their bodily movements are recorded and sent for
 analysis in the USA.
 I wonder under which legal frame conducts CloudFlare this intelligence
 operation in the EU, is it under never-to-be-defunct Safe Harbor
 agreement? Or does CF have a special agreement, does anybody know?

 CAPTCHA must be understood as '''CAPTURE you bloody data-slaves!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 bring it on ioerror, smash the surveillance capitalists!

 
[[Image(http://www.wired.com/images_blogs/photos/uncategorized/2007/10/06/img_5561.jpg)]]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by lunar):

 Replying to [comment:141 torhp]:
 > To summarise:
 >
 > Starhub 1(Singapore): 40
 > Starhub 2(Singapore): 26
 > Vietnam: 57
 > Thailand: 30
 >
 > Tor Fast Exit 1: 50
 > Tor Fast Exit 2: 42
 > Tor Fast Exit 3: 40
 > Tor Fast Exit 4: 41
 >
 > Limited samples not withstanding, the results are pretty interesting.

 Indeed. Thanks a lot for your research!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by paxxa2):

 Here is a summary of some unaddressed points CloudFlare could come back
 to, if they are wondering how to continue to engage with this ticket:

  1. What kind of per browser session tracking is actually happening?
  1. What would a reasonable solution look like for a company like
 Cloudflare?
  1. What is reasonable for a user to do? (~17 CAPTCHAs for one site == not
 reasonable)
  1. Would "Warning this site is under surveillance by Cloudflare" be a
 reasonable warning or should we make it more general?
  1. What is the difference between one super cookie and ~1m cookies on a
 per site basis? The anonymity set appears to be *strictly* worse. Or do
 you guys not do any stats on the backend? Do you claim that you can't and
 don't link these things?
  1. Cloudflare asks: “Is it possible to prove that a visitor is indeed
 human, once, but not allow the CDN/DDoS company to deanonymize / correlate
 the traffic across many domains?” Answer and follow-up question: Here is a
 non-cryptographic, non-cookie based solution: Never prompt for a CAPTCHA
 on GET requests. For such a user - how will you protect any information
 you've collected from them? Will that information be of higher value or
 richer technical information if there is a cookie (super, regular,
 whatever) tied to that data?
  1. Let's be clear on one point: humans do not request web pages. User-
 Agents request web pages ... It might be true that there is some kind of
 elaborate ZKP protocol that would allow a user to prove to CloudFlare that
 their User-Agent behaves the way CloudFlare demands, without revealing all
 of the user's browsing history to CloudFlare and Google. Among other
 things, this would require CloudFlare to explicitly and precisely describe
 both their threat model and their definition of 'good behaviour', which as
 far as I know they have never done.
  1. How many people are actively testing with Tor Browser on a daily basis
 for regressions? Does anyone use it full-time?
  1. If I was logged into Google (as they use a Google Captcha...), could
 they vouch for my account and auto solve it? Effectively creating an ID
 system for the entire web where Cloudflare is the MITM for all the users
 visiting users cached/terminated by them?
  1. Regarding “What sort of data would qualify as an 'i'm a human' bit?
 Let's start with something not-worse than now: a captcha solved in last
  minutes.” – Is this something that CloudFlare has actually found
 effective? Are there metrics on how many challenged requests that
 successfully solved a CAPTCHA turned out to actually be malicious?
  1. I'd really like it if it was CAPTCHA free entirely until there is a
 POST request, for example. A read only version of the website, rather than
 a CAPTCHA prompt just to read would be better wouldn't it?
  1. CloudFlare is in a position to inject JavaScript into sites. Why not
 hook requests that would result in a POST and challenge after say,
 clicking the submit button? It seems reasonable in many cases to redirect
 them on pages where this is a relevant concern? POST fails, failure page
 asks for a captcha solution, etc.
  1. Actually, a censorship page with specific information ala HTTP 451
 would be a nearly in spec answer to this problem. Why not use that?
  1. Why not just serve them an older cached copy?
  1. Do you have any open data on (“unfortunately many Tor exit IP's have
 bad IP reputation, because they _ARE_ often used for unwanted activity”)?
  1. CF asks: “What do we do to implement zero-knowledge proofs both on
 ddos protection side and on TBB side?” My first order proposition would be
 to solve a cached copy of the site in "read only" mode with no changes on
 the TBB side. We can get this from other third parties if CF doesn't want
 to serve it directly - that was part of my initial suggestion. Why not
 just serve that data directly?
  1. What about slowing down recurrent requests? it's really not something
 that can be solved on the Tor side.
  1. What kind of DoS can you guys possibly see through Tor? The network in
 total capacity has to be less than a tiny fraction of the capacity at
 *one* of your PoPs. Could you please give us actual data here? I've seen
 some basic CF API data - what is exposed seems to be quite minimal. As far
 as I can

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by ioerror):

 Replying to [comment:139 jgrahamc]:
 > Replying to [comment:137 ioerror]:
 > > Replying to [comment:135 jgrahamc]:
 > > > We are not just using Project Honeypot but it's an input. I'm using
 it here because all of us can look at their data and draw conclusions
 about any IP address or group of IP addresses.
 > >
 > > It is hard to address abuse if we cannot understand what that word
 means.
 >
 > I've said a few times what abuse means. It means things like SQL
 injection, comment spamming, harvesting email addresses and HTTP DoS that
 exploits slowness on a web server to knock it over.
 >

 What is the p value as asked above?

 > > I think Project Honeypot data is more of an art than a just process or
 even a fully explained science.
 >
 > They publish all their data and you can look up any IP to see what
 they've seen from that IP.  I'm not sure how to make progress on this
 then. Do you have an alternative source of information that would help
 measure abuse coming through Tor?
 >

 Please reply to the analysis of the XFF dataset: Does CloudFlare censor
 the entire country of Vietnam as hard as it does to many Tor exit nodes?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by SatoshiNakamoto):

 1) There's some metrics above about the % of tor nodes that abuse is
 coming from, but unless I missed it, there's no details of % of *all
 traffic* that is abuse.  Lunar made the point that we should be comparing
 these numbers to the abuse numbers for carrier-grade NAT but we should
 also compare to the baseline of a typical IP.  We should expect some kind
 of relationship like tor  carrier-nat  otherwise, but is this
 actually what we see?  Even granting the technically infeasible goal of
 stopping this abuse, it's gotta be in context.  What is p(abuse | tor) /
 p(abuse | non-tor) ?

 2) The register article is also behind cloudfare, so if you're expecting
 us to read it and get any information from it, you may be sorely
 disappointed.  I'm batting like 3 for 250+ today for loading pages through
 cloudfare.

 3) Not sure if this is the right ticket or not(there's a lot going wrong
 here for one ticket), but in my particular case until today there seems to
 be 2 situations that you can get into depending who you allow javascript
 for.

  i)  Google and website :

   palemoon (  26.0.1 ) presents user with :

   [ ] I'm not a robot reCAPTCHA
 selecting this:
 results in 100% cpu for awhile and then
 "Cannot contact reCAPTCHA. Check your connection and try again."
 100% of the time.

  ii)  Neither google *nor* website.

   palemoon presents user with:

 http://0bin.net/paste/uCUCp72l6EYqvVNA#6E+2Hi3izY37X+nQ-
 lNLzqZ5Jx9HukKLkjl/hrj3+Py
 as you can see it's all garbled to hell.  This wasn't the case
 ever before today.  Until today we could get away with disabling
 javascript, and select the particular pictures, at least on my setup.  The
 check boxes might be associated with boxes in order, but sometimes only 6
 boxes show up, and as of yet I haven't been able to solve one since they
 started looking that way, though one page just happened to load without
 the CAPTCHA page just recently(?).

 so really if you're fixing issues as they come up on your side, there are
 two broken use cases right there.

 It would be nice if there was somewhere on *cloudflare*'s side to report
 specific tor-related client issues that wasn't behind the great cloudwall.
 That would be one way for Cloudfare to work together with the tor network,
 beyond having one thread on tor's side, wouldn't it?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by torhp):

 I looked into the project honey pot data and I don't find it to be very
 supportive of the "Tor is a source of abuse" hypothesis.  Certainly not in
 the sense that it can be used to justify blocking Tor users.

 So I looked at the list of XFF proxies someone linked to above and
 coincidentally I found Singapore's number one ISP near the top of the list
 which piqued my curiosity.

 I used to live in Singapore and at that time I was using Tor pretty much
 daily.  I can tell you that as a residential clearnet internet user, I
 don't remember once coming across the cloudflare captcha problem.  As a
 Tor users of course I did get locked out of websites by cloudflare though,
 so comparing honeypot numbers for Tor versus Singapore ISP's NAT hardware
 is interesting to me.  Let's get down to it.

 First of all, the ISP alluded to above is Singtel, but I was actually a
 customer of Starhub (Singapore's number 2 ISP), but I found them in the
 honeypot data too and checked their scores.  Their two listed IPs have
 threat scores of 40 and 26.

 Two IP addresses isn't a huge amount though, so I checked out a couple
 more - I found an IP listed as being the outbound proxy for Vietnam's
 state owned ISP.  They only have one IP listed so it may be a single
 carrier grade NAT device for the whole country - Vietnam I believe has a
 national firewall so that seems possible.  Their score was 57.  I checked
 one more IP which was one belonging to an ISP in Thailand.   Its score was
 30.

 I then pseudo randomly selected (scroll, point and click) four Tor fast
 exit nodes from torstatus.blutmagie.de  Their scores were 50, 42, 40 & 41.

 To summarise:

 Starhub 1(Singapore): 40
 Starhub 2(Singapore): 26
 Vietnam: 57
 Thailand: 30

 Tor Fast Exit 1: 50
 Tor Fast Exit 2: 42
 Tor Fast Exit 3: 40
 Tor Fast Exit 4: 41

 Limited samples not withstanding, the results are pretty interesting.
 Vietnam which apparently has one public IP address for the whole country
 has a worse threat score than the Tor exits.  Is anyone under the
 impression that Cloudflare breaks the internet for the whole of Vietnam in
 the same way they do for Tor users?  It is news to me if so.  The other
 inference is that public shared IP addresses are prone to having high
 threat scores in general, which seems obvious.

 I would like to get greater clarity from Cloudflare on how they interpret
 these threat numbers, and they have done a good job of engaging so far so
 hopefully we might get something.  We have heard that Tor is not singled
 out specifically, but rather that it is treated as a source of abuse as
 per these threat scores.  So how?  If a whole country is behind a carrier
 grade NAT with a higher threat score than typical Tor exit nodes, is that
 country being treated as a threat / abuse source similar to Tor?  Do they
 get unsolvable Captchas with a similar frequency as Tor users?  What else
 feeds into this heuristic?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by madD):

 Replying to [comment:116 jgrahamc]:
 > Replying to [comment:100 madD]:
 > > Replying to [comment:82 jgrahamc]:
 > >  > 0. We fixed the bug that caused a new CAPTCHA to be served for a
 site when the circuit changes.
 > > Does this fixed CAPTCHA record users' reaction time, order of clicks,
 or mouse movements?
 >
 > The fix I am talking about does not involve JavaScript or any of those
 things at all.
 But I was not asking about the particular bug fix, you realize. The
 subject of my repeated question is the ability of CF CAPTCHA to capture
 response of users such as mouse movements, reaction time, order of
 checkbox selection. Is this kind of information transferred out of users
 device by submitting a CF CAPTCHA?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by jgrahamc):

 Replying to [comment:137 ioerror]:
 > Replying to [comment:135 jgrahamc]:
 > > We are not just using Project Honeypot but it's an input. I'm using it
 here because all of us can look at their data and draw conclusions about
 any IP address or group of IP addresses.
 >
 > It is hard to address abuse if we cannot understand what that word
 means.

 I've said a few times what abuse means. It means things like SQL
 injection, comment spamming, harvesting email addresses and HTTP DoS that
 exploits slowness on a web server to knock it over.

 > I think Project Honeypot data is more of an art than a just process or
 even a fully explained science.

 They publish all their data and you can look up any IP to see what they've
 seen from that IP.  I'm not sure how to make progress on this then. Do you
 have an alternative source of information that would help measure abuse
 coming through Tor?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by lunar):

 Replying to [comment:136 jgrahamc]:
 > Replying to [comment:134 lunar]:
 > > If I understood correctly, this chart show individual Tor exit nodes
 who have been spotted doing at least one of the “abuse” you describe
 earlier. If that's correct, then it's just totally meaningless data. Tor
 users can control which exit node they use. So this could just be a
 **single** Tor user doing a **single** attempt at SQL injection repeatedly
 over **different exit nodes**.
 >
 > No, this data is only for Tor exit nodes that are comment spamming. It's
 not "one person did a bad thing once on an exit node".

 Same thing. It could be just one person using all Tor exit nodes in turns
 to attempt comment spamming. It is not a good metric to reflect about Tor
 users and Tor traffic.

 > > Please stop framing this as “''Tor traffic is 90% abuse''”. This is
 not what these numbers are telling us.
 >
 > I never said that. Don't put words in my mouth.

 According to The Register article, your boss did: ''According to Prince,
 third-party figures have suggested than more than 90 per cent of Tor
 traffic […] is traffic that is actively trying to hurt the websites it is
 visiting.'' Please read my comment as addressed to all readers of your
 graph.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by ioerror):

 Replying to [comment:135 jgrahamc]:
 > Replying to [comment:133 ioerror]:
 > > You don't have other threat scores for other IP addresses? You could
 look at the country wide proxy list that Wikipedia keeps for X-Forwarded-
 For style proxies - for example. Though I'm surprised - you don't have
 *any* data on carrier grade NAT IP ranges?
 >
 > Nope. We do not have special treatment for groups of IP addresses other
 than Tor and only for Tor because of widespread complaints from Tor users.
 We have scores and data for individual IP addresses.

 OK - but for example - VPN services - or the Wikipedia X-Forwarded-For IP
 ranges - what data do you have on those? Do you see a threat score that is
 higher than really large Tor exit nodes used by millions of people
 (machines, bots, actual people, etc) daily?

 >
 > > We publish a great deal of data in a privacy preserving manner:
 https://metrics.torproject.org
 >
 > Thanks
 >

 Sure, you're welcome - you can probably do neat metrics data comparisons
 too. Especially during censorship events, I expect you'll see interesting
 data.

 > > Could you please make some comparisons of the abuse in question? Is
 CloudFlare really just using Project Honeynet data here?
 >
 > We are not just using Project Honeypot but it's an input. I'm using it
 here because all of us can look at their data and draw conclusions about
 any IP address or group of IP addresses.

 It is hard to address abuse if we cannot understand what that word means.
 I think Project Honeypot data is more of an art than a just process or
 even a fully explained science. If that is the only bit of data we'll see,
 I'm quite unhappy as it is effectively "trust us" as an answer.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by jgrahamc):

 Replying to [comment:134 lunar]:
 > If I understood correctly, this chart show individual Tor exit nodes who
 have been spotted doing at least one of the “abuse” you describe earlier.
 If that's correct, then it's just totally meaningless data. Tor users can
 control which exit node they use. So this could just be a **single** Tor
 user doing a **single** attempt at SQL injection repeatedly over
 **different exit nodes**.

 No, this data is only for Tor exit nodes that are comment spamming. It's
 not "one person did a bad thing once on an exit node".

 > Please stop framing this as “''Tor traffic is 90% abuse''”. This is not
 what these numbers are telling us.

 I never said that. Don't put words in my mouth.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by jgrahamc):

 Replying to [comment:133 ioerror]:
 > You don't have other threat scores for other IP addresses? You could
 look at the country wide proxy list that Wikipedia keeps for X-Forwarded-
 For style proxies - for example. Though I'm surprised - you don't have
 *any* data on carrier grade NAT IP ranges?

 Nope. We do not have special treatment for groups of IP addresses other
 than Tor and only for Tor because of widespread complaints from Tor users.
 We have scores and data for individual IP addresses.

 > We publish a great deal of data in a privacy preserving manner:
 https://metrics.torproject.org

 Thanks

 > Could you please make some comparisons of the abuse in question? Is
 CloudFlare really just using Project Honeynet data here?

 We are not just using Project Honeypot but it's an input. I'm using it
 here because all of us can look at their data and draw conclusions about
 any IP address or group of IP addresses.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by lunar):

 Replying to [comment:124 jgrahamc]:
 > Replying to [comment:123 ioerror]:
 > > Could you give us some actual absolute numbers here? This chart is
 without context or even absolute numbers where we may compare with some
 other sources of information.
 >
 > That's the percentage of Tor exit nodes.

 If I understood correctly, this chart show individual Tor exit nodes who
 have been spotted doing at least one of the “abuse” you describe earlier.
 If that's correct, then it's just totally meaningful data. Tor users can
 control which exit node they use. So this could just be a **single** Tor
 user doing a **single** attempt at SQL injection repeatedly over
 **different exit nodes**.

 Please stop framing this as “*Tor traffic is 90% abuse*”. This is not what
 your numbers are telling us.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by ioerror):

 Replying to [comment:128 jgrahamc]:
 > Replying to [comment:125 ioerror]:
 > > It would be nice, if you could show us data that compares carrier
 grade NAT for a similar quantity of users, and then to back up the data
 beyond "project honeynet" offered "threat scores" for us to understand it
 in detail.
 >
 > I don't have that data because it's not something we monitor.

 You don't have other threat scores for other IP addresses? You could look
 at the country wide proxy list that Wikipedia keeps for X-Forwarded-For
 style proxies - for example. Though I'm surprised - you don't have *any*
 data on carrier grade NAT IP ranges?

 Here is a list of ip addresses of major proxies - such as say, all users
 of Opera Mini which is probably more users than Tor Browser hitting
 CloudFlare:

   https://meta.wikimedia.org/w/extensions/TrustedXFF/trusted-hosts.txt

 One can read about those proxies here:

   https://meta.wikimedia.org/wiki/XFF_project


 >
 > I only have data on Tor because there's a public list of exit nodes and
 because I wrote code to pull information on Tor (see github above) because
 the Tor community was upset at CAPTCHAs. I also don't know how large the
 Tor user base is so even if I did have the data I couldn't make the
 comparison.

 We publish a great deal of data in a privacy preserving manner:
 https://metrics.torproject.org

 Could you please make some comparisons of the abuse in question? Is
 CloudFlare really just using Project Honeynet data here?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by mmarco):

 Addendum: of course, that comes at the prize of leaking some extra bit of
 information: the fact that they have their browser configured to request a
 specific language.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by mmarco):

 Replying to [comment:126 ioerror]:
 > Another comment about the broken CloudFlare captchas is that they're
 always in English for me. Is that always the case? For those who don't
 speak English, they're even more confused when they are censored with a
 looping and thus broken captcha security solution...?


 I would jsay it deppends on the language that TBB is configured to request
 the content. By changing it to spanish, I get the "One more step..." web
 page in english, but the captcha question is in spanish.

 So yes, users that don't speak english would get some extra confussion,
 but at least they can read the captcha challenge.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by jgrahamc):

 Replying to [comment:114 jgrahamc]:
 > Replying to [comment:101 garrettr]:
 > > Replying to [comment:82 jgrahamc]:
 > > For what it's worth, at least of right now, this is still an issue. To
 demonstrate, I recorded a video of myself using Tor Browser to access
 https://cloudflare.com, which is naturally behind Cloudflare.
 >
 > Le sigh.
 >
 > You are correct. I've reproduced myself here using TorBrowser 5.5.2
 (JavaScript enabled; not that that matters as we don't use JavaScript to
 decide on the CAPTCHA serving). Raising this internally to figure out why.

 Replying to myself, but... this looks like it's a caching bug where the
 fact that an IP is currently a Tor exit node is not being cached
 correctly. Fix is in and should be pushed to production today.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by naif):

 My point on that is:

 a) Tor should enable Tor Relay Operators to reduce portscan and web
 attacks (see #18142 and #17975)

 b) Cloudflare must implement a Dynamic Proof of Work and Dynamic attack
 threshold detection system for traffic coming from Tor (see
 https://lists.torproject.org/pipermail/tor-talk/2016-January/040011.html)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance