[tor-talk] TorBirdy doesn't work with Gmail?

Mike Hearn hearn at google.com
Mon Sep 9 17:26:43 UTC 2013


Actually, re-reading this thread I recall that tagnaq suggested just
disabling the risk analysis entirely once we see a successful Tor login.
I've CCd Daniel Margolis who still works on this system (I moved on to
other things).

Daniel, what do you think?

(note that you may have to sign up to the public tor-talk list to reply-all
successfully)


On Mon, Sep 9, 2013 at 7:11 PM, Mike Hearn <hearn at google.com> wrote:

> Yes, but then people who run relays would end up having to deal with the
> suddenly changed security model. There were people complaining about
> getting blocked by random websites just because they ran relays elsewhere
> on this list. I don't think Google wants to actively discourage people from
> contributing to the Tor network by challenging their logins more harshly.
> Especially as our list of tor nodes might get used for more stuff in future.
>
> It'd be better to find out why nodes that are exiting traffic don't get
> marked as exits. Looking at that relay, it seems it doesn't allow web
> traffic, but some ports are allowed. Perhaps the suspicious sign-in in
> question wasn't a web signin?
>
> What would be really useful not just for Google but I suppose the entire
> internet community, would be a simple runnable tool that would take a set
> of host/port-range pairs and identify any node with a compatible exit
> policy. Then we could find any node that could potentially exit traffic
> towards our servers.
>
>
>
> On Mon, Sep 9, 2013 at 6:32 PM, Griffin Boyce <griffin at cryptolab.net>wrote:
>
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 09/09/2013 12:19 PM, Mike Hearn wrote:
>> > For a real fix we need to be able to identify Tor nodes that exit
>> traffic.
>> > The fact that some nodes exit traffic but aren't marked as exits would
>> > appear to be a design issue with Tor itself. I don't think we can
>> justify a
>> > whole lot of engineering time to building a complicated system to
>> identify
>> > every possible exit - the only obvious alternative is to simply select
>> > every Tor node which would be annoying for people who run relays but not
>> > exits.
>>
>>   Blutmagie runs a quite in-depth listing of tor nodes (exit and
>> otherwise): http://torstatus.blutmagie.de/
>>
>>   There are CSVs that can be polled to output just the IP addresses,
>> which should cut down on any programming time significantly.  Is it
>> possible to just consider all nodes "potential exits"?  There are only a
>> few thousand IPs in the entire network at any given moment, so it
>> shouldn't be a large undertaking.
>>
>> best,
>> Griffin
>>
>> - --
>> "Cypherpunks write code not flame wars." --Jurre van Bergen
>> #Foucault / PGP: 0xAE792C97 / OTR: saint at jabber.ccc.de
>>
>> My posts are my own, not my employer's.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>>
>> iQIcBAEBAgAGBQJSLfgoAAoJEOMx/SmueSyX0mMP/0S+VW/IT8V4L//XblKyuAcU
>> KAEU+KVrFh7F9OE4NyiQcgkA1ac8G07HdrVPCwPCvceUGDYQsTUKVBVIireiGZ3i
>> dO7hsfcVWX6p+kfHu5+CkCXGo0UHyqtiyZT3cNwwkeLe/EH1+R7qdhUkh5KxD1o8
>> FUQ3M7ThB4Rv7V2PjtFrugS3u+BBhJv7rnoK7I4JIHeFLuBo3JVKT1Eeu5tef2th
>> 5owkGEQ/LKdnS4I+2sVHvkj7nSnziQ+a7no6MLHRvyiWEqPAYUQrI8IVggc+2Y6K
>> xU8LxM6r/K0spB9Sl4grFrCWq3mb4nDlZld4r6AfKV16WLPjxCKfWbni4BkOWJWI
>> Ps9gHgmU9qQXE8eSZLOO/zZPQZ2lR2LZL50KB3eyL7nT/VP6BW+Ke5LcBFhmhpfZ
>> fkSD/Gv2QAAcgdOi9LrMZb59Vr9pBBDhCKm3YPa+spyphcrR81QcMimCXh10Ku4v
>> K2a+2EUcVxOtggck6AhnPn8fD07i+hIbHoVhTR1DUmV+vREVAY1Re1DPGVfF4k86
>> etlrBwsav2scJq4ctEEephUqPLn6eY6kpJDKX8nRmKWm5mN+kbMjvLdTCpemIsTf
>> 5lzKR9RWumiu8us07yvQ/v9nCIqCQzhSEhUxRL0EwhEVnzPdM3WiR+PDqtxKmRXz
>> L7C5Yq0QPAgi3oMbr/m2
>> =kA9V
>> -----END PGP SIGNATURE-----
>>
>> --
>> tor-talk mailing list - tor-talk at lists.torproject.org
>> To unsusbscribe or change other settings go to
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>>
>
>


More information about the tor-talk mailing list