-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 02/07/15 10:59, Joshua Lee Tucker wrote:

Hi Karsten,

Hello Joshua,

I much prefer the design of the first logo (over the existing ones)

• I think it helps to retain ExoneraTor's affiliation with Tor, as

I think the other logos make it too difficult to recognise that Tor logo.

Sounds good, added to the mockup as pro argument for the first logo. Let's collect more arguments and maybe even alternatives. Note that these logos are very quickly drawn using the "paint equivalent on Mac OS X", just to capture the idea. It's easy to make more drafts. And once we have a candidate, we'll ask a real designer to re-draw the logo for us.

The designs look great!

I have one suggestion:

Would it not be better to use a date selection component for the user to select a data? I think the current method of having to manually input a date, formatted in the correct way, is a little clunky (I think this is demonstrated in the fact that there's a design page with a data formatting error).

I also added that one as open discussion point. Note that neither Julius nor I are web designers, so we just didn't know how to add such a date selector. I guess the tricky part might be that we wouldn't want to add a JavaScript requirement just for the date selection part. If you have any ideas or even patches, please send them here, and I'll include that in the mockup.

Keep up the great work!

Thanks for the feedback!

All the best, Karsten

Joshua Lee Tucker

On Thu, Jul 2, 2015 at 8:40 AM, Karsten Loesing karsten@torproject.org wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hello relay operators,

Julius and I have been working on a design mockup for the ExoneraTor service for the past few months and would want to hear what you think about this:

https://people.torproject.org/~karsten/volatile/exonerator-mockup/

The main idea behind this redesign was to simplify the existing ExoneraTor service by omitting technical details (e.g., Tor descriptor contents) and removing mostly unused features (e.g., parsing detailed exit policies).

Please take a look at the design mockup, maybe compare it to the existing ExoneraTor service, and let us know your thoughts.

Thanks!

All the best, Karsten

_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 02/07/15 11:15, Jens Kubieziel wrote:

• Karsten Loesing schrieb am 2015-07-02 um 09:40 Uhr:

...

Please take a look at the design mockup, maybe compare it to the existing ExoneraTor service, and let us know your thoughts.

• I find the logo 1 quite nice. - When a user enters the date

field, it might be helpful when some calendar-like thingie opens. So the user can jump to the right month, select the day and the correct date format is automatically inserted. This might help the user to insert the correct format.

Great. I think this pretty much matches what Joshua wrote and that I just replied to. If there's anything else to add, please let me know.

• Another approach for wrongly entered dates could be to guess the

correct date. I suspect that many will make a systematic error (exchanging day and month, forget to insert a leading 0 etc.). So instead of just saying: »The expected date format is "YYYY-MM-DD". Example: "2015-03-24"« it might be more helpful to say: »Did you mean 2015-03-24?« where the date is a link to https://exonerator.torproject.org/?ip=82.220.3.99%C3%97tamp=2015-03-24

I

like this idea. We can totally try out a few other date formats. Added to the mockup.

Thanks for the feedback!

All the best, Karsten

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 02/07/15 11:45, Joshua Lee Tucker wrote:

Hi Karsten,

I've made a patch to the page to add the HTML5 date components - it should work nicely across the majority of browsers (maybe even all with a plaintext fallback).

I wasn't sure exactly in which format you wanted the patch, so I've uploaded it to my server:

http://tucker.wales/tor/exonerator/index.html

So, it's as simple as changing type="text" to type="date"?

Turns out that Firefox (and hence Tor Browser) doesn't support this yet, but it falls back to plain text nicely.

I just made that change in the mockup.

Thanks!

All the best, Karsten

On 2 July 2015 at 10:45, Joshua Lee Tucker josh@tucker.wales wrote

Hash: SHA256

Hi Karsten,

I've made a patch to the page to add the HTML5 date components - it should work nicely across the majority of browsers (maybe even all with a plaintext fallback).

I wasn't sure exactly in which format you wanted the patch, so I've uploaded it to my server:

http://tucker.wales/tor/exonerator/index.html

Thanks,

Josh

Sorry for coming late in the discussion, any reason to default to no value? Defaulting to current date would all to just change the day in many cases and save a lot of clicks to set month/date

On 20 July 2015 at 15:12, Karsten Loesing karsten@torproject.org wrote:

On 20/07/15 11:40, Pascal Terjan wrote:

...

On 2 July 2015 at 10:45, Joshua Lee Tucker josh@tucker.wales wrote

...

Hash: SHA256

Hi Karsten,

I've made a patch to the page to add the HTML5 date components - it should work nicely across the majority of browsers (maybe even all with a plaintext fallback).

I wasn't sure exactly in which format you wanted the patch, so I've uploaded it to my server:

http://tucker.wales/tor/exonerator/index.html

Thanks,

Josh

Sorry for coming late in the discussion,

No worries, and thanks for joining the discussion.

...

any reason to default to no value? Defaulting to current date would all to just change the day in many cases and save a lot of clicks to set month/date

I'm not entirely sure that I understand. Do you mean accepting only an IP address as input and not also requiring a date?

The field does currently not have a default value, so the HTML 5 date selector in chrome shows me dd/mm/yyyy + some arrows to set each part of the date which I didn't find convenient as the month/year are likely to be current or previous one. But I have now noticed that the bigger arrow on the right shows a calendar displaying current month so it's only 2 clicks to get to a recent date :)

My understanding is that users are typically not interested in whether there's a relay with a given IP address right now but weeks or even months back in the past.

A big downside of not requiring a date is that people may only put in an address, because that's much more convenient than also looking up the date, obtain a positive or negative result, and implicitly assume that the result for a few weeks back would have been the same. That can be quite unfortunate for people on dynamic IP addresses or those who have recently stopped running a relay.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 04/07/15 10:55, David Serrano wrote:

On 2015-07-02 09:40:31 (+0200), Karsten Loesing wrote:

...

Julius and I have been working on a design mockup for the ExoneraTor service for the past few months and would want to hear what you think about this:

https://people.torproject.org/~karsten/volatile/exonerator-mockup/

...

Good job! This new page looks a lot fresher.

Glad you like it!

Logo: I'd like a version of the third one in which the fingerprints were more or less aligned to the onion layers on the original Tor logo, keeping the correct perspective and all that.

Added as *quickly* drawn logo suggestion number 4.

Dates: I was going to suggest 3 separate comboboxes to prevent users from entering wrong formats, but if Joshua's solution works without javascript, then it's a killer. Would be nice that the fallback on older browsers were those 3 combos.

I'm not sure if that's possible, but I added it to the open discussion points for when we work on implementing the new web design.

Results: do we really need the "Exit: yes" column? Seems pretty redundant to me.

I think this is answered later in this thread. We should probably keep that column. Not sure if exiting to at least one of the two ports 80 and 443 justifies having that column set to yes. But assuming we can figure out good criteria there, having this information might be useful.

Also, there seems to be 24 rows with white background, then 24 with light grey bg. If the search returns eg. 30 results, then only the last 6 would be in grey, and users could potentially think there's something special about those. I'd use a much smaller number, eg. 5 at most, so it's obvious that the background is just there for aesthetic reasons.

Ah, the highlighted rows contain results for the searched date, whereas the other rows are for the previous and next date. The idea is to always search +/- 1 day in order not to rely on users figuring out timezones correctly. Maybe the highlighting is too implicit though. I'll leave it out. It's not worth explaining to users what the highlighting is about, and it's particularly not worth confusing users with it.

...

The main idea behind this redesign was to simplify the existing ExoneraTor service by omitting technical details (e.g., Tor descriptor contents) and removing mostly unused features (e.g., parsing detailed exit policies).

Maybe a link to a "Technical details" could still be kept for the most weirdos among us :), containing some more details. Not the full gore we have now, but something like platform, bandwidth, exit policy... things that could be explained to your sister in 5 minutes.

I guess you'd rather use Globe or Atlas to explain such details to your sister. (Note that it's not possible to link to those services from ExoneraTor, because they only display relay details for relays running in the past 7 days.)

The ExoneraTor service has a specific set of users in mind that want to investigate whether or prove that a given IP address was a relay at a certain time weeks or months ago. If this task requires looking at raw Tor descriptors we should provide them, together with tools to verify cryptographic signatures and a probably long FAQ. But my understanding is that it's easier to process these descriptors internally and provide them in a table view that can be consumed by humans. I think the typical use case is to look up an address and print out (to PDF, hopefully) the result.

Another reason for leaving out technical details is that they're making the database behind ExoneraTor huge. I'd like to kick out all raw descriptors unless we really need them.

Oh, and if a technical person really cares about raw descriptors, they're all available on https://collector.torproject.org/. But those people don't need the ExoneraTor service anyway.

Just my 2sat,

Very helpful. Thanks for your feedback!

All the best, Karsten

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 05/07/15 14:20, teor wrote:

...

On 5 Jul 2015, at 19:37 , Karsten Loesing karsten@torproject.org wrote:

...

Results: do we really need the "Exit: yes" column? Seems pretty redundant to me.

I think this is answered later in this thread. We should probably keep that column. Not sure if exiting to at least one of the two ports 80 and 443 justifies having that column set to yes. But assuming we can figure out good criteria there, having this information might be useful.

If we don't use the same definition as the Exit flag or the policy summary in microdescriptors (which can, in fact, be different), can we please document it somewhere?

For the purposes of ExoneraTor, it makes sense to use a broad(er) definition of Exit, as those using it will likely be answering the question: "Could a client have possibly used this relay as an exit?" Rather than: "Is this a relay which Exits to most places on some ports?" (microdescriptors) "Is this a relay which Exits to some places on common ports?" (consensus flag)

The differences between the consensus Exit flag and microdescriptor policy summaries are already a source of some confusion: https://trac.torproject.org/projects/tor/ticket/11264 https://trac.torproject.org/projects/tor/ticket/11624

Actually, how about we use the same definition as for the Exit flag?

Even if a relay without the Exit flag could have possibly been used as an exit, the probability for clients to choose it is quite low.

I'd say let's make this as simple and least confusing as possible. Re-using the existing definition of the Exit flag makes a lot of sense to me.

Updated the mockup.

...

...

Also, there seems to be 24 rows with white background, then 24 with light grey bg. If the search returns eg. 30 results, then only the last 6 would be in grey, and users could potentially think there's something special about those. I'd use a much smaller number, eg. 5 at most, so it's obvious that the background is just there for aesthetic reasons.

Ah, the highlighted rows contain results for the searched date, whereas the other rows are for the previous and next date. The idea is to always search +/- 1 day in order not to rely on users figuring out timezones correctly. Maybe the highlighting is too implicit though. I'll leave it out. It's not worth explaining to users what the highlighting is about, and it's particularly not worth confusing users with it.

"The two extreme time zones on Earth (both in the mid Pacific) differ by 26 hours." https://en.wikipedia.org/wiki/List_of_UTC_time_offsets

So can we possibly change this to +/- 26 hours? (or, perhaps, 30 hours, just in case some region adjusts its timezone another hour or two out?)

For the sake of those in Kiribati, Samoa, Tonga and the eastern New Zealand islands on one side, and the US Minor Outlying Islands on the other.

But no timezone can be more than -12 or +14 hours away from UTC, so I think we're good by including the previous and next 24 hours of any given date. That being said, I'm not good at timezones, so it's quite possible that my math is wrong.

Tim

Tim Wilson-Brown (teor)

Thanks for your feedback!

All the best, Karsten

teor2345 at gmail dot com pgp ABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5

teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

On Sun, Jul 5, 2015, at 02:26 PM, Karsten Loesing wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 05/07/15 14:20, teor wrote:

...

...

On 5 Jul 2015, at 19:37 , Karsten Loesing karsten@torproject.org wrote:

Actually, how about we use the same definition as for the Exit flag?

Even if a relay without the Exit flag could have possibly been used as an exit, the probability for clients to choose it is quite low.

Is that probability the same for a malicious actor though (who may have set up the relay themselves)? GD

Karsten wrote:

Anyway, I guess what I'm trying to say is that this is not an exact science and there's no clearly right way to say that a relay is an exit or not. We should pick a definition that's plausible to mere mortals, and that could be:

a) whether the relay has the Exit flag, b) whether the relay permitted exiting to "web ports" 80 or 443, c) whether the relay permitted exiting to any port at all, etc.

I think a) is better than b). But do you think c) would be even better than that?

From the perspective of someone investigating abuse, I think it's important that 'not an exit relay' means 'not capable of exiting on any port at all'. Ergo I think your option c) is the way to go. Regards, Geoff

On 7 Jul 2015, at 09:46 , josh@tucker.wales wrote:

...

From the perspective of someone investigating abuse, I think it's important that 'not an exit relay' means 'not capable of exiting on any port at all'. Ergo I think your option c) is the way to go.

I also think this (c) is the best option. I agree that it's important to be able to determine, from an investigatory perspective, whether or not a relay was capable of exiting on any port.

And, if we are going to implement "Exit" as any port, it should also be *any* IP, not just an IPv4 /8 as in the Ext flag definition.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com pgp ABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5

teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

On 7 Jul 2015, at 07:48, Karsten Loesing karsten@torproject.org wrote:

...

On 07/07/15 03:45, teor wrote:

...

...

On 7 Jul 2015, at 09:46 , josh@tucker.wales wrote:

From the perspective of someone investigating abuse, I think it's important that 'not an exit relay' means 'not capable of exiting on any port at all'. Ergo I think your option c) is the way to go.

I also think this (c) is the best option. I agree that it's important to be able to determine, from an investigatory perspective, whether or not a relay was capable of exiting on any port.

Okay, let's do c).

...

And, if we are going to implement "Exit" as any port, it should also be *any* IP, not just an IPv4 /8 as in the Ext flag definition.

For c), we'd just check if there's a "p reject 1-65535" line or not.

I think this is a perfectly OK way of doing this considering the use case.

Here's the updated design mockup:

https://people.torproject.org/~karsten/volatile/exonerator-mockup/

Looks great Karsten, good job!

Regards,

Joshua Lee Tucker @tuckerwales

...

...

For c), we'd just check if there's a "p reject 1-65535" line or not.

I think this is a perfectly OK way of doing this considering the use case.

I agree, as long as we document what "Exit" means, and that there are edge cases where a relay could be used to exit to a small number of IPs, yet not have "yes" in the "Exit" column. (A false negative.)

It may be worth documenting the false positives as well, that is, that there are many ways a packet could appear to be from an IP, yet not have come via Tor.

Are we going to provide a list of exit ports, or does Exonerator not go into that level of detail?

I'm also a little concerned by this, but I think the acceptable solution is:

If a relay can exit on any port at all, it should have "Exit: Yes", because from an investigatory point of view, it CAN act as an exit.

However, I'm a little worried that this will lead people to think that the relay can act as a general exit to the web (80, 443). I think it's important that we specify the ports that existed in the exit policy for that relay at that point in time.

What's your opinion on this Karsten, Tim?

Thanks,

Joshua Lee Tucker @tuckerwales

On 7/7/15, teor teor2345@gmail.com wrote:

Organisation X experiences an attack on their website via an IP address, and they want to identify the origin of the attack. Exonerator tells them that the IP was used by a Tor Exit that permitted port 80. (This is a very likely scenario.)

Organisation X experiences a SSH login/password scan via an IP address, and they want to identify the origin of the attack. Exonerator tells them that the IP was used by a Tor Exit that permitted port 22. (This is perhaps a less likely scenario, but still well worth knowing about.)

We could split the Exit column in two (web ports, other ports), but I'd prefer to provide the list of ports in a detail page, and let the analyst do their own triage. But if we only have one page, perhaps the split is worthwhile.

I personally don't like displaying the ports in the overview page - I would also much rather have this information displayed in a detail page. (Maybe make the "Exit: Yes" clickable?)

I think this improves not just readibility, but also keeps the main page as simple as possible.

Regards,

Joshua Lee Tucker @tuckerwales

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 07/07/15 17:40, Zack Weinberg wrote:

On Tue, Jul 7, 2015 at 10:19 AM, Joshua Lee Tucker josh@tucker.wales wrote:

...

I personally don't like displaying the ports in the overview page

• I would also much rather have this information displayed in a

detail page. (Maybe make the "Exit: Yes" clickable?)

How about "Exit: [Never/Unrestricted/Restricted/Unlikely/Former] (details...)"

Yes, I could imagine adding more states than just Yes and No.

where: "Never" means the relay has never allowed exiting to any port or IP;

Well, the table already contains a timestamp, so this is probably not necessary. Also, keeping a history whether a relay permitted exiting up to a given time is quite expensive, because we'd have to re-import the whole descriptor archives for this.

"Unrestricted" means the relay currently allows exiting to all ports and IPs;

Plausible, though there are hardly any relays permitting all ports.

"Restricted" means the relay currently allows exiting to some ports and IPs, enough to get the exit flag;

I'd simply call this "Yes". All relays with the Exit flag would have this state.

"Unlikely" means the relay currently allows exiting to some ports and IPs, *not* enough to get the exit flag;

This is probably what I'd call "Restricted" or "Limited". That's for all relays which don't have reject 1-65535 and which also don't have the Exit flag.

"Former" means the relay allowed exiting to something at some time in the past, but doesn't anymore.

This has the same issues as "Never".

We'd also need "No" for the reject 1-65535 case.

And in all cases you can click for more details. (The '(details...)' is literal.)

See my earlier response about more details. We can probably explain three or four possible states in easy-to-understand terms.

So, yes, this seems plausible, if we can keep it simple. What states should we use, and how should we document those in user language?

All the best, Karsten

On Tue, Jul 7, 2015 at 12:21 PM, Karsten Loesing karsten@torproject.org wrote:

On 07/07/15 17:40, Zack Weinberg wrote:

...

where: "Never" means the relay has never allowed exiting to any port or IP;

Well, the table already contains a timestamp, so this is probably not necessary. Also, keeping a history whether a relay permitted exiting up to a given time is quite expensive, because we'd have to re-import the whole descriptor archives for this.

The thing is, putting myself in the shoes of someone trying to investigate an incident, I think the distinction among "this relay has _never_ allowed any sort of exiting", "this relay _does_ allow exiting right now", and "this relay _did_ allow exiting at some point in the past but doesn't right now" is critical. More important than whatever its current policy is wrt any given port or IP address. Re-importing the entire descriptor archive therefore strikes me as "yeah, if that's what it takes, you should do that."

Moreover, when digging deeper, I would want to be able to know the exact exit policy at a specific time in the past, which I believe would entail having the entire descriptor history available anyway?

...

"Unrestricted" means the relay currently allows exiting to all ports and IPs;

Plausible, though there are hardly any relays permitting all ports.

Maybe the right distinction is between relays that allow more than the common "reduced exit policy", and those that allow no more than that?

I'd simply call this "Yes". All relays with the Exit flag would have this state.

I do not think using "Yes" as a member of an N-way distinction (N>2) is good design.

...

"Unlikely" means the relay currently allows exiting to some ports and IPs, *not* enough to get the exit flag;

This is probably what I'd call "Restricted" or "Limited". That's for all relays which don't have reject 1-65535 and which also don't have the Exit flag.

I hesitate to use "Restricted" or "Limited" because people might think it referred to the reduced exit policy.

I wanted a single word which expressed "technically an exit, but a client would have had to override the default circuit generation policy to have used it as an exit". I'm not happy with "Unlikely" but I can't think of anything better.

If five states is too many, I'd drop the unrestricted/restricted distinction first (i.e. now/former/never/now but only with special circuit generation).

zw

On Tue, Jul 7, 2015 at 4:50 PM, Geoff Down geoffdown@fastmail.net wrote:

On Tue, Jul 7, 2015, at 07:47 PM, Zack Weinberg wrote:

...

The thing is, putting myself in the shoes of someone trying to investigate an incident, I think the distinction among "this relay has _never_ allowed any sort of exiting", "this relay _does_ allow exiting right now", and "this relay _did_ allow exiting at some point in the past but doesn't right now" is critical. More important than whatever its current policy is wrt any given port or IP address. Re-importing the entire descriptor archive therefore strikes me as "yeah, if that's what it takes, you should do that."

If someone only has an IP address for an incident but no exact time, they barely have the basis for a complaint, let alone something more formal like a prosecution. What is the relevance of the relay's status at any time other than that of the incident?

That's just the point I'm trying to make. If the relay's status at the (past) time of the incident was different from the relay's status at the (present) time of the investigation, that should be immediately obvious when you look at its page; it should not be a thing buried in a details screen.

zw

On Tue, Jul 7, 2015 at 6:12 PM, Geoff Down geoffdown@fastmail.net wrote:

On Tue, Jul 7, 2015, at 10:12 PM, Zack Weinberg wrote:

...

On Tue, Jul 7, 2015 at 4:50 PM, Geoff Down geoffdown@fastmail.net wrote:

...

What is the relevance of the relay's status at any time other than that of the incident?

That's just the point I'm trying to make. If the relay's status at the (past) time of the incident was different from the relay's status at the (present) time of the investigation, that should be immediately obvious when you look at its page; it should not be a thing buried in a details screen.

But Exonerator at present (and as proposed) requires a datestamp to produce any output at all. An investigator will input the datestamp of the incident.

I may have gotten this project mixed up with the one that is replacing Atlas/Onionoo, for which a "dashboard" showing the relay's status at the present time is the entry point. Still, I think that an investigator might indeed want to know whether the behavior of the relay is different now than it was at the time of the incident. For instance, there would be no point to complaining about exit traffic emanating from a relay that *was* an exit, but isn't anymore. And a relay that was only an exit for a brief window of time, that happens to coincide with an incident, should be suspected to have been hacked.

zw

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 08/07/15 08:56, josh@tucker.wales wrote:

...

On 8 Jul 2015, at 04:56, Zack Weinberg zackw@cmu.edu wrote: I may have gotten this project mixed up with the one that is replacing Atlas/Onionoo, for which a "dashboard" showing the relay's status at the present time is the entry point. Still, I think that an investigator might indeed want to know whether the behavior of the relay is different now than it was at the time of the incident. For instance, there would be no point to complaining about exit traffic emanating from a relay that *was* an exit, but isn't anymore. And a relay that was only an exit for a brief window of time, that happens to coincide with an incident, should be suspected to have been hacked.

I don't think this is information ExoneraTor should provide.

I agree that the investigator might need to know the differences in the configuration of the relay between "now" and "then", but ExoneraTor isn't a config diff utility. There are tools available to confirm the current status of a relay, and I don't feel we should be duplicating this functionality again in ExoneraTor.

I'm with Joshua here. ExoneraTor specifically asks for a date and an IP address and returns details about relays running on that address on or within a day of that date. Since then, relays could have switched from exit to non-exit or back and they could have changed IP addresses.

However, I'm still unclear what states the Exit column should contain. States like "Never" or "Former" shouldn't be part of those for the reason above, but it's plausible that more than just "Yes" and "No" would help. The goal here is to simplify, but not to oversimplify. Thoughts?

All the best, Karsten

Short answer: Keep away from any myLoc company. They are Tor unfriendly and will shut down your server as soon as you run Tor. And of course they will keep the money.

They kicked us even before we installed anything. Just because of our domain name torservers.net

So please don't use them!

Juris Vetra https://www.torservers.net/

Am 12.07.2015 um 18:46 schrieb fatal:

Hello list,

hopefully a (preferably german) lawyer is subscribed to this list.

I was thinking of starting an exit-relay on a dedicated machine. The german company servdiscount offers very cheap machines with 1 gbit connection (500 mbit guaranteed). They don't mention tor in their terms and conditions but § 10 worries me a bit (myLoc is the mother company of servdiscount):

"The customer is obligated, to refrain from sending e-mails to third parties who have not consented to receipt beforehand or whose consent to receive cannot be inferred from other means. This likewise applies to sending postings in chats and/or forums. The customer promises to pay myLoc a contractual penalty in the amount of 5,100.00 Euro per incident in the event of culpable breach of this obligation under exclusion of the assumption of repeated offence."

https://servdiscount.com/en/about-us/terms-and-conditions.html

or in german:

"10. Der Kunde ist verpflichtet, keine E-Mails an Dritte zu versenden, die dem Empfang nicht zuvor zugestimmt haben oder deren Einverständnis zum Empfang nicht anderweitig vermutet werden kann. Dies gilt ebenfalls für das Versenden von Postings in Chats und/oder Foren. Der Kunde verspricht für jeden Einzelfall ein er schuldhaften Zuwiderhandlung gegen diese Verpflichtung unter Ausschluss der Annahme eines Fortsetzungszusammenhangs die Zahlung einer Vertragsstrafe in Höhe von 5.100,00 Euro an myLoc. Die Geltendmachung weiterer Ansprüche bleibt vorbehalten."

https://servdiscount.com/ueber-uns/agb.html

Would this condition apply in case a tor user would e. g. rant around in a forum? Or would beeing a provider keep me from paying 5.100,00 Euro (!) to myLoc?

thanks! _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 07/07/15 16:19, Joshua Lee Tucker wrote:

On 7/7/15, teor teor2345@gmail.com wrote:

...

Organisation X experiences an attack on their website via an IP address, and they want to identify the origin of the attack. Exonerator tells them that the IP was used by a Tor Exit that permitted port 80. (This is a very likely scenario.)

Organisation X experiences a SSH login/password scan via an IP address, and they want to identify the origin of the attack. Exonerator tells them that the IP was used by a Tor Exit that permitted port 22. (This is perhaps a less likely scenario, but still well worth knowing about.)

We could split the Exit column in two (web ports, other ports), but I'd prefer to provide the list of ports in a detail page, and let the analyst do their own triage. But if we only have one page, perhaps the split is worthwhile.

I personally don't like displaying the ports in the overview page - I would also much rather have this information displayed in a detail page. (Maybe make the "Exit: Yes" clickable?)

I think this improves not just readibility, but also keeps the main page as simple as possible.

Well, I'd like to keep the main page as simple as possible, and I'd also prefer not to add a details page at all. The only output that users should see is a single page that they can print out and file to close a case (in favor of having more time for the 9 other open cases where ExoneraTor returned a negative result). Adding more details, even on a separate page, would only confuse users and not help much.

Regarding documentation, it's already there on the same page, so that it will be printed out on the same page as lookup results. If we can phrase things better, please let's do that. But let's not add another page with explanations.

Does that make sense?

All the best, Karsten

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On Tue, Jul 7, 2015 at 7:27 PM, David Serrano tor@dserrano5.es wrote: Throwing this idea out there instead of keeping it to myself: what about modifying the form to ask also for the destination port? So the investigator would enter source IP, dest port and date. Can be somewhat confusing due to the source/dest mix, but the "Exit" column in this case would be pretty clear because it would refer only to the required port.

I actually quite like this idea, I think that could work.

Anyone else have an opinion on this?

Joshua Lee Tucker @tuckerwales

On Tue, Jul 7, 2015 at 7:27 PM, David Serrano tor@dserrano5.es wrote:

On 2015-07-07 15:19:18 (+0100), Joshua Lee Tucker wrote:

...

On 7/7/15, teor teor2345@gmail.com wrote:

...

Organisation X experiences an attack on their website via an IP address

Organisation X experiences a SSH login/password scan via an IP address

We could split the Exit column in two (web ports, other ports)

I personally don't like displaying the ports in the overview page - I would also much rather have this information displayed in a detail page. (Maybe make the "Exit: Yes" clickable?)

Throwing this idea out there instead of keeping it to myself: what about modifying the form to ask also for the destination port? So the investigator would enter source IP, dest port and date. Can be somewhat confusing due to the source/dest mix, but the "Exit" column in this case would be pretty clear because it would refer only to the required port.

-- David Serrano PGP: 1BCC1A1F280A01F9

---

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 14/07/15 23:32, Geoff Down wrote:

On Tue, Jul 14, 2015, at 03:05 PM, Karsten Loesing wrote:

...

I implemented most of the changes that Julius and I suggested plus the feedback we received on this list. Please find the updated ExoneraTor service here:

https://exonerator.torproject.org/

Please give it a try, including the tricky edge cases where you expect it to break. And if you have any further feedback, please post it here.

Thanks!

Broke it straight away - 'summary.invalidparams.invalidtimestamp.body ' . What date format are you wanting? No placeholders in HTML4...

Oops, fixed. The error message now also explains the expected date format. If you have suggestions for making it work better in HTML 4 while still working nicely in 5, please let me know. Thanks!

All the best, Karsten

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 14/07/15 23:44, Jens Kubieziel wrote:

• Karsten Loesing schrieb am 2015-07-14 um 16:05 Uhr:

...

https://exonerator.torproject.org/

• Could give a better explanation than

"summary.invalidparams.invalidip.body" when a non-IP address was entered? same for "summary.invalidparams.invalidtimestamp.body".

Both are fixed now.

• "Es wurde kein Tor-Relay mit IP-Adresse". Please add "der" after

"mit".

Changed. If you want to tweak the German translation more, feel free to fetch these files and send me new ones:

https://gitweb.torproject.org/exonerator.git/plain/res/ExoneraTor.properties

https://gitweb.torproject.org/exonerator.git/plain/res/ExoneraTor_de.propert...

• Maybe it is useful to trim() the input IP address. So an

accidentally entered space doesn't result in a invalid query. You seem to do it with the date.

Good idea, changed.

Thanks!

All the best, Karsten