What to do about false positives that are found?

[Ryman]

Perhaps add a wiki page to list false positives at specific times to see if we can track down causes?

I just exited from 199.48.147.41 @ 00.34 GMT+1 27/09/2013 and got a 'You're not connected to Tor' message but I've verified I can connect to onions and such, so I'm pretty sure it's wrong. This is likely due to missing an ip from TorDNSEL but I can't check it right this moment so I'm leaving it here to investigate later! Which reminds me, we should probably add investigation instructions to the docs?

I guess this is really a false negative. Regular check.tpo gets it right.

[arlolra]

Had a discussion with @armadev re: this issue on Monday. Here's the IRC logs: http://pastebin.com/32ztF4jk

The just of it is that clients can continue to use a consensus for up to 24hrs. I exited from a relay that currently was not part of the consensus but had been recently and came back online.

The reason that the regular check.tpo gets it right is that it considers relays from the past 16hrs or so. This is #9.

The plan is as follows,

• Have scripts/cpexits.sh copy over the consensus with an hourly timestamp.
• Have scripts/exitips.py read in multiple consensuses marking the relays with t-minus.
• The / path will use relays from the past n hours (the 16 from above, most likely)
• Bulk exit list will get a new query parameter for hours to consider.

Haven't had the time to implement this yet. If you care to or can think of something better, please do :)

[arlolra]

Also, the json output from those scripts should key by relay fingerprint, not exit ip. I think I've seen several relays with conflicting exit ips, which may have different exit policies.

[arlolra]

The above is implemented. The initial load now pulls in data from the past 72 hours, or whatever metrics recent has, and the cron job keeps it up-to-date.

To answer the initial question,

Perhaps add a wiki page to list false positives at specific times to see if we can track down causes?

A wiki could be good but I don't want to force people to join GitHub. Is there a cypherpunks account? I think people will just post issues to Trac, with Torcheck component.

[Ryman]

Didn't mean to imply a github wiki, I think making a page on trac's wiki makes more sense as you've said. I'd agree that this was definitely part of #9 after checking the irc logs. (so yeah, closed... but here's some words!)

I had a think about the issue after reading them earlier, would it make sense to show the user a probability, or a graph of their exit node's uptime instead of just assuming yes if in consensus within last 72hours? Perhaps that would scare/confuse users overall.

Also regarding the trac vs github thing, the bulk exit list's text points to this repo, perhaps for future proofing it should be hosted canonically on gitweb?

[arlolra]

I had a think about the issue after reading them earlier, would it make sense to show the user a probability, or a graph of their exit node's uptime instead of just assuming yes if in consensus within last 72hours? Perhaps that would scare/confuse users overall.

IsTor checks the past 16 hrs. I think that's reasonable for a yes/no answer. Anything more would probably be more confusing than it is worth. However, I like the idea of the graph or, rather, linking to atlas based on the fingerprint of a relay, like: https://atlas.torproject.org/#details/62F33A4D76124F8297BBA7752B0C712385CB865B

Also regarding the trac vs github thing, the bulk exit list's text points to this repo, perhaps for future proofing it should be hosted canonically on gitweb?

True, I'll raise that with people in #tor-dev.

[arlolra]

https://trac.torproject.org/projects/tor/ticket/9857