#29624: New version of exit list format -------------------------------------+-------------------------------- Reporter: irl | Owner: irl Type: task | Status: needs_revision Priority: Medium | Milestone: Component: Metrics/Exit Scanner | Version: Severity: Normal | Resolution: Keywords: metrics-roadmap-2019-q2 | Actual Points: Parent ID: #29650 | Points: Reviewer: irl | Sponsor: -------------------------------------+-------------------------------- Changes (by karsten):
* status: needs_review => needs_revision Comment: Nice blog post! It's indeed interesting to see what fraction of IP addresses is only available in exit lists. If I may nitpick: - It's slightly confusing (to me) that the red and green line show single set sizes whereas the blue line shows one set minus the other one. I wonder if the lines would work better (for me) if they were: Found only in consensus, Found in consensus and exit list, and Found only in exit list. That way it would be possible to add up all three lines and obtain the total number of addresses. - Maybe this graph would work as a stacked area plot like [https://metrics.torproject.org/bandwidth-flags.html our bandwidth flags graph], just with three stacked areas rather than four. If you look at that linked bandwidth flags graph, yellow would be "Found only in consensus", green would be "Found in consensus and exit list" and blue would be "Found only in exit list". That would show pretty quickly what fraction someone is missing when only looking at consensuses: the blue part at the top. - If you like, I can help you with making that graph. Just give me the raw data, and I'll make a quick graph out of it. Also as an experience to learn more about the tidyverse. And for the next funding proposal, of course. Anyway, I think you wanted a review of the exit list spec! Here's what I found: - "[the identity-ed25519 line] MUST appear as the first or second element in the router descriptor": Why the first? In version 2 or later the first element is always "exit-list", so it can only be the second element. And why router descriptor? You mean exit list? - Sometimes we're using two spaces between sentences. Let's be consistent and either use one or two. - In the "location" line, should we write the AS number as AS12345 rather than just 12345? Technically, it's correct to just use an integer there, but if we think of humans reading the format, we might want to include the "AS" part anyway. - Should the "platform" line suggest a possible format for exit list scanner software version, Tor software version, and operating system? Something like "ExitScanner 55.5 using Tor 1.0.0 on Windows 10"? - There are at least two places where you write "[XXX: Informational: ...]". Can we just include those informational parts without the XXX stuff? - A bit below that you refer to the "created" timestamp, which is now called the "published" timestamp. - I wonder if the "address" part of "exit-address4" and "exit-address6" lines should be unique (with respect to the exit list entry, not the whole exit list, of course). This has implications on how somebody parsing an exit list entry can store and retrieve parsed addresses. Of course, if we think it's useful to include an address several times with different scan times, we'll have to say that the address is not necessarily unique. In any case, we should say what people can expect there, or they'll make assumptions. - The "exit-scanner-sig-ed25519" should probably specify where to expect the signature part. Is it going to be part of the line, separated by SP from the keyword? Or is it going to be an object in the next line? In the latter case the subsequent description would have to say "including the newline character after" rather than "including the first space after". Other than these comments, the plan to build it see if it works sounds reasonable to me. Thanks! -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29624#comment:18> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs