root/tags/REL4_0/CHANGES

Revision 13232, 42.3 kB (checked in by kasimir, 8 months ago)

Data only dump from old repository - all commits by kasimir

  • Property svn:executable set to *
Line 
1Portions Copyright (c) 2006-2007, Joseph B. Kowalski
2Portions Copyright (c) 2007 Kasimir Gabert
3See LICENSE for licensing information
4
5TorStatus - Tor Network Status Changes
6
7===============================================================================
8Version 4 Changes {{{
9===============================================================================
10--Version 4.0--
11* (ticket 56) The DNSEL database no longer is left in memory
12* (ticket 58) Read-write history now works through extra-info/digest
13* (ticket 8) A logo was created for TorStatus
14* (ticket 53) Graphs have been moved to a Perl based framework
15* (ticket 64) The interface was greatly modified-includes JS now, but works
16  equally well without it
17* (ticket 65) tns_update.pl now just needs to be run
18* (ticket 66) The HSDir flag was added
19* (ticket 68) tns_update will no longer break if there are multiple router
20  names that are the same as the nickname for the opinion source
21* (ticket 43 49) Up and down arrows were fixed to work with more browsers
22* (ticket 52) A search option is now at the top for ease of use
23* (ticket 47) Names of countries are now used intead of just the country code
24
25===============================================================================
26}}}
27===============================================================================
28
29===============================================================================
30Version 3 Changes {{{
31===============================================================================
32--Version 3.6--
33* Will no longer crash with an error if the database is not populated
34* An interface has been added to the WHOIS data
35* The guard image is now a shield
36* (ticket 40) It will now work with modern versions of Tor
37* A Debian agent daemon has been created
38
39--Version 3.5--
40* Complete interface redesign
41* Integrated operating system detection in by default
42* Bandwidth change to have a progress bar
43* Legend created
44* WHOIS query integrated for IP addresses
45* Background colors for different router status
46* Overall softer colors
47* Added notifications for Asc or Desc sort orders
48
49--Version 3.4.2--
50
51* (ticket 12) Fixed error with server IP detection for non-Squid servers
52* (ticket 12) Added config option for Squid server
53
54--Version 3.4.1--                             (changes made by Kasimir Gabert)
55
56* Fixed bottom headers for new domain
57* Updated IP detection so it works through Squid
58* Added known mirrors bar
59
60TODO:
61* Move the two changes into configuration items
62* Centralize the known mirrors and make it dynamic
63
64--Version 3.4--                            (end of changes by Joseph Kowalski)
65Rename of the DNSBL server to DNSEL (DNS Exit List) server. This was by
66recommendation of Roger Dingledine of the Tor project. All filenames, variable
67names, etc, have been adjusted to reflect the rename.
68
69Added basic hit counting functionality to the DNSEL server. Now, every five
70minutes, the DNSEL server will write a record to the "DNSEL_LOG" table with a
71timestamp, a TotalResponses counter, and counters of how many "NOERROR",
72"SERVFAIL", "NXDOMAIN", and "NOTIMP" responses it has sent out since it was
73started. This procedure runs in it's own thread, and so should not have any
74measurable effect on performance.
75
76Improved the code that detects whether a user is accessing the site via a Tor
77hidden service. Previously, I checked to see if the user was coming from
78127.0.0.1. Now, I check to see if the "HOST" header provided by the client
79upon access exists in the "$Hidden_Service_URL" from the config file. If so,
80we tell them they are accessing the site as a hidden service. If not, we
81proceed on to the normal checks to see if they are accessing through the Tor
82network.
83
84Modified the DNSEL server to return SERVFAIL instead of NXDOMAIN for requests
85which are outside of the zone the DNSEL server is authoritative for.
86
87Modified the DNSEL server to return NXDOMAIN instead of NOTIMP for requests
88other than type 'A' and 'ANY' when the request is in the authoritative zone.
89
90Modified the documentation / default variables for the DNSEL server to use the
91"ip-port.torhosts.example.com" domain, rather than "tor.dnsel.example.com".
92This encourages users to setup servers that are consistent with the
93"torel-design.txt" document maintained by the Tor project.
94
95--Version 3.3--
96Complete rewrite of the DNSBL server in Java. This provided a performance
97increase on the order of approximately 5x over the old Perl version of the
98server. On a Pentium 2.4 GHz machine with 2 GBs of RAM, I was able to
99consistently obtain load test results of 200 queries/sec or more. These tests
100were conducted across the internet, and not on the local machine.
101
102Addition of the "dnsbl_server.php" page. This page provides usage instructions
103for the DNSBL server, and informs users of it's domain name. Note that the
104link to "dnsbl_server.php" from the main page will only display if you
105set the "$DNSBL_Domain" variable in the "config.php" file, so you can leave
106this variable set to 'null' if you are not running a DNSBL server, or do not
107wish to advertise it on the web site.
108
109Addition of the "$Hidden_Service_URL" variable to the "config.php" file. If
110you are also making the TorNetworkStatus site available through a Tor Hidden
111Service, you can enter the URL here, and a link will be added to the main page.
112If you are not making the site available as a Hidden Service, or do not wish
113to advertise it on the web site, you can leave this variable set to 'null'.
114
115Removal of the "tor_exit_status" page. This functionality is already provided
116by the main page (Tells a user if they are accessing the site through the Tor
117network or not), and the user already has two options to do custom exit
118queries if desired: The "tor_exit_query" page, and the DNSBL server. Both are
119linked to from the main page.
120
121Modifications to the "tns_update.php" file and the database create script to
122accommodate the re-write of the DNSBL server.
123
124--Version 3.2--
125Removed the first type of query that the DNSBL server could perform, which
126was to simply lookup if a provided IP address was an active Tor server or not.
127This was causing confusion amongst some users, and causing people to focus on
128whether or not an IP is a Tor server at all, which is exactly what we are
129trying to get away from by providing an answer to the more granular question
130"Is this IP address a Tor server that is capable of exiting to my destination
131IP and port?", which is precisely what the second (and now only) query type
132does. This had the added benefit or making the server a little faster, since
133a bit of logic was removed. Please see the "README_DNSBL" file in the source
134distribution for full setup and usage information.
135
136--Version 3.1--
137Nearly a complete redesign of the DNSBL server added in the last version to
138improve performance. Major changes:
139
1401) Previously, there was a Perl script which performed the actual listening
141for DNS requests, and when one was received, the script passed on the details
142of the request to a PHP script, which is where the main processing happened.
143The PHP script would then return a value to the Perl script indicating success
144or failure of the request. This had the horrible performance penalty of
145needing to invoke PHP every time a new request was received. Now, the entire
146process is handled within the same Perl script -- All of the PHP code to
147process the DNSBL request has been ported over to Perl -- So there is no
148calling an external executable again and again. Additionally, Perl runs faster
149than PHP with all other factors being equal.
150
1512) With the old PHP script, since it had to be invoked anew from within the
152Perl script with each request, this also meant that a new database connection
153had to be setup with each request. This also caused a performance penalty.
154Now, since everything is handled from within a single script, a single
155database connection can be maintained the entire time the script is running.
156
1573) Previously, when the DNSBL script did it's database queries to pull the
158IP addresses and exit policies of Tor routers, it did it the same way that the
159main application does, which means joining two large tables together on the
160router fingerprint key. While this works fine for the main application and
161it's very large queries, it did not suit the performance needs of a DNS
162server. Now, I have added two new in-memory database tables specifically for
163the DNSBL functionality. These two tables are populated during the update
164cycle, and contain only the necessary information (prejoined) required by the
165DNSBL server. The fact that they are in memory and are a lot smaller than the
166other tables should help the DNSBL server to return queries much quicker.
167These two tables act just like the set of NetworkStatus and Descriptor tables
168in that only one is ever active at a given time. The update cycle will always
169be updating the non-active table in the background while requests can continue
170being served by the active table. When the update is done successfully, a flag
171in the Status table is toggled to tell the application to begin using the
172other table as the active one, and the process repeats -- No downtime for
173updates.
174
175Fixed a bug that would cause the DNSBL server to only return "NXDOMAIN"
176responses if the database connection was lost until the script was restarted,
177even if the database connection came back up later. Now, the server will
178return "SERVFAIL" responses while the database server is down, but it will
179resume correct operation once the database server comes back up.
180
181Various other minor bug fixes, mainly relating to the "Tor Exit Status" and
182"Tor Exit Query" functionality that was added in the last release.
183
184--Version 3.0--
185Complete redesign of the way that the application determines if you are
186accessing the site through the Tor network or not, or if the provided IP
187belongs to a Tor server capable of exiting to the specified IP and port (See
188section on "Tor Exit Query" page, below). Previously, we would simply check to
189see if the IP address that the user was coming from was a Tor server with the
190'Exit' flag set to true, and tell them they were coming through the Tor
191network if so. Now, we check if the user is coming from the IP address of a
192Tor server, regardless of it's 'Exit' flag status. If so, we pull the Exit
193Policy for the matching Tor server(s), look at what IP and Port the client is
194accessing us on, and parse the exit policy to determine if the Tor server(s)
195would allow or deny such an access. We then give the user information on each
196Tor server that matches their exit IP, letting them know if it would allow
197access to us or not considering it's exit policy. Finally, we also tell the
198user if it appears that they are coming to the site via a Tor Hidden Service
199or from the local machine directly. This is determined by checking if the user
200is coming to the site from the '127.0.0.1' IP address. Note that the
201application now handles situations where there are multiple Tor servers with
202IP's that match where the user is coming from (Or the IP provided, in the case
203of the "Tor Exit Query" page, see below). In these cases, it will cycle through
204each applicable Tor server to provide Exit Policy match information.
205
206Addition of "Tor Exit Status" page. This page provides the same information
207about whether a user is accessing the site through the Tor network as is
208available on the main page, but without all the other information. This may be
209easier for someone who just wants a simple answer for "Is my Tor installation
210working?", and should serve as a good entry point for such situations. This
211page also contains a link to the main Tor documentation page.
212
213Addition of "Tor Exit Query" page. This page allows a user to enter in an IP
214to check if it matches that of one or more Tor servers, and, if it does,
215checks to see if those Tor servers are capable of exiting to the destination
216IP address and port that the user provides.
217
218Addition of a DNSBL server. This allows a standard, non-web interface method
219for clients to query whether or not an IP address belongs to an active Tor
220server, and whether or not an IP address belongs to an active Tor server that
221would allow exiting to a specified destination IP address and port. Please
222see the "README_DNSBL" file in the source distribution for full setup and
223usage information.
224===============================================================================
225}}}
226===============================================================================
227
228===============================================================================
229Version 2 Changes {{{
230===============================================================================
231--Version 2.0--
232
233Small performance enhancement to background update process. When clearing old
234data from the descriptor and network status tables, we now use the "truncate
235table" command rather than the "delete from" command. This is faster because
236"truncate table" deletes all records from the table at once, while "delete
237from" deletes records one row at a time.
238
239Enhancement of "Require Flags" custom query option so that the user now has
240three options available for each flag: "Off", "Yes", and "No". "Off" means
241the status of the flag is not a factor in the search. "Yes" means a router
242must have flag set in order to show up in result set. "No" means that a router
243must not have flag set in order to show up in result set. Previously, a user
244only had the equivalent of the "Off" and "Yes" options. Also, when a flag is
245set to "Off", it's column header in the result list will have a blue
246background, "Yes" will have a green background, and "No" will have a red
247background. This further increases the level of flexibility with searches.
248
249Addition of "Country Code" field to "Tor Server Providing Network Status
250Opinion" section. 
251
252Addition of background color to drop-down lists and edit box in advanced
253search section.
254
255Minor changes to text in custom query section to facilitate clarity.
256
257
258--Version 2.1--
259
260Addition of "Aggregate Network Statistic Graphs / Details" page. This page
261contains four graphs of network-wide aggregate information: Number of Routers
262by Country Code, Number of Routers by Observed Bandwidth, Number of Routers
263by Time Running, and an aggregate summary of various criteria including router
264flags.
265
266Addition of "EventDNS" and "Hibernating" statistics to newly renamed
267"Aggregate Network Statistics Summary" section on main page.
268
269Improvement to the way that the "Aggregate Network Statistics Summary" section
270of the main page gets it's data. Previously, each piece of information used
271was collected by a separate SQL query. Now, all of this has been joined into
272one large query to cut out the overhead of multiple SQL calls.
273
274Change to CSS which affects the highlight color of links which are on a white
275background, for increased readability.
276
277
278--Version 2.2--
279
280Fixed a bug in the code that detects whether or not the user is connecting to
281the server through the Tor network. Previously, it would tell a user they were
282connecting through the Tor network if their IP address matched the IP address
283of any Tor server. Now, it will only tell the user they are connecting through
284the Tor network if their IP address matches the IP address of a Tor server AND
285that Tor server is an exit node.
286
287Addition of exit node only CSV file download, for those who don't want the
288IP's of all Tor servers.
289
290Addition of graph of exit routers by country code to Network Detail page. This
291is useful for letting us see where we are most likely to exit the Tor network.
292
293Addition of "BadDirectory" flag information everywhere we make use of flags.
294The "BadDirectory" flag was added in Tor version 0.1.2.5-alpha.
295
296Minor cleanups to documentation to enhance readability.
297
298Fixed minor bug in SQL database create script.
299
300
301--Version 2.3--
302
303Redesign of the "Custom / Advanced Query Options" box on the main page. I am
304now using drop-down lists for the sort request, sort order, and address mode
305parameters instead of radio buttons, which takes up a lot less screen real-
306estate and also makes adding new options for these parameters in the future
307more practical.
308
309Slight changes to the "Application Server Details" (Previously "Application
310Server Information") box on the main page to enhance readability.
311
312Addition of the "Number of Descriptors In Cache" field to the "Application
313Server Details" box.
314
315Movement of the "Application Server Details" box to the bottom of the page.
316This has the dual purpose of improving page readability as well as making the
317"Approximate Page Generation Time" figure more accurate, since it is now
318calculated closer to the bottom of the page. Previously, the PHP code which
319generates the "Custom / Advanced Query Options" box still ran after this time
320was calculated.
321
322Update of source URL at bottom of page to new domain.
323
324
325--Version 2.4--
326Modified "Aggregate Network Statistic Summary" box to also show "percent of
327total network" values for each statistic listed. This allows you to easily see
328what percent of Tor routers are exit nodes, what percent are mirroring the
329directory, what percent of the total network your current result set makes up,
330etc.
331
332Modified "Network Status Opinion Source" box to allow clicking on the nickname
333of the router to jump directly to its router detail page. This makes it easy
334for a user to get detailed information about the source of the network data
335that they are seeing.
336
337Modified code that detects whether a user is accessing the site through the
338Tor network or not. Now, if the user is accessing through the Tor network, the
339name of their exit node is displayed in addition to the IP address. Also, the
340user can click on the name of the exit node to jump directly to its router
341detail page. This makes it easy for a user to get detailed information about
342the exit node they are currently coming through.
343
344Modified page footer to also include a link to the change history and license
345of the application.
346
347Removed the "$MinRouterThreshold" variable from the config file, and all code
348that made use of the variable. This really became obsolete when version 1.4 of
349the application was released and we started using two sets of tables in the
350database for storing router information instead of one. Since that time, a
351user will always have their page generated from the active set of router
352tables in the database, while the next refresh operation is being performed on
353the inactive set. This makes this variable, which was used to see if a
354database refresh was in progress and display an error to the user back when we
355used a single set of tables, obsolete.
356
357Fixed a bug in the generation of the Comma Separated Value (CSV) list of exit
358nodes. A comma was incorrectly being added after the last entry in the file,
359which might have caused problems for parsers.
360
361Added "Number of Routers by Platform" graph to network detail page. This lets
362us easily see how popular different operating systems are for running Tor
363routers.
364
365Modified "Number of Routers by Time Running (Weeks)" graph on network detail
366page to be full page width. This makes this graph easier to read since it
367usually has a lot of items along the x axis.
368
369
370--Version 2.5--
371Fixed lots of minor HTML and CSS errors. All pages now validate as "CSS
372version 2.1" and "HTML 4.01 Transitional".
373
374Modified the handling of all SQL queries which return a result set so that the
375result set populates into an associative array rather than a numerically
376indexed array. This allows items in the result set to be referred to by column
377name rather than a numerical array index. This is a significant step towards
378being able to offer the user the ability to do things such as select which
379columns they want displayed on the page, etc, as it is much more flexible
380than using numerical indexes because your entire result set handling code is
381no longer affected by re-arranging the order of items in your query, or adding
382and removing items on the fly. It is also generally considered a database
383programming best practice, as a lot of confusion and potential for bugs is
384eliminated by being able to use easily recognizable column names as opposed to
385numerical indexes.
386
387Modified the "Address Display Mode" in the "Custom / Advanced Query Options"
388so that users now have a third choice -- "Hostname + IP Address". Previously,
389the user could only choose one at a time, and had no way to view both
390simultaneously. "IP Address Only" mode is still the default as the "Hostname +
391IP Address" mode can result in a much larger amount of data being returned,
392but now the option is there for those who want it.
393
394
395--Version 2.6--
396Added the ability for users to select which columns they want displayed in the
397main router table. This should be good for ensuring that the page does not
398grow larger and larger as new informational items about Tor routers become
399available, since we can just maintain reasonable default settings and leave
400the obscure stuff off unless a user intentionally turns it on. Also, the SQL
401query for obtaining the main router list has been made dynamic so that it will
402only request columns from the database if the user will actually be displaying
403them.
404
405Added "Fingerprint" as a column display option.
406
407Removed "Address Mode" from "Custom / Advanced Query Options" since it is made
408obsolete by the users ability to select which columns they want displayed,
409which offers more granularity.
410
411Efficiency improvement in the way that it is determined if a given flag
412column for a given router should display the red "x" or green check mark.
413Previously, there was an "If" statement that set the appropriate CSS class for
414the table data cell based on whether a flag variable for that router was '0'
415or '1'. Now, there is a CSS class that ends in '0' and '1', and the variable
416value is just dumped directly into the class statement in the appropriate
417place. This saves up to '$NumberOfDifferentFlags X $NumberOfRoutersInResultSet'
418'If' statements from being executed on each page load, normally many thousand.
419
420Fixed a bug in the generation of CSV files that was causing a comma to be
421added after the last column in a row. According to RFC 4180, this is incorrect.
422Also, added a newline character (\n) to the end of files.
423
424Added "Comma Separated Value (CSV) List of Current Result Set" option. This
425lets a user get a comma separated value (CSV) file of their current search
426result set, exactly as displayed on screen (Including sort preferences, column
427display preferences, and any other custom query parameters that may be
428applied). The first record (row) in the generated CSV file will contain the
429column names for reference. This should be very useful for users wishing to
430export the data from a custom query into an external data source.
431
432
433--Version 2.7--
434Moved the column display options to their own page, rather than having them on
435the main page in the "Custom / Advanced Query Options" box. You can get to the
436column display options by following the "Custom / Advanced Display Options"
437link from the top of the page and then clicking on the "Column Display
438Preferences" link. This should provide a much more comfortable interface for
439customizing column display options.
440
441Added the ability for users to re-configure the order that columns display in.
442Previously, users could only add and remove columns. This should allow much
443more flexibility to users wishing to customize the look of the page.
444
445Updated "Comma Separated Value (CSV) List of Current Result Set" functionality
446to support the newly added ability of users to re-configure column display
447order. This way, the CSV file of the current result set benefits from the same
448level of flexibility as the main page display.
449
450
451--Version 2.8--
452Added the ability for users to display four additional columns on the main
453page: "Platform", "Contact", "EventDNS", & "Hibernating". Users can sort by
454the new columns and, in the case of the "EventDNS" and "Hibernating" items,
455filter query results based on whether they are true or false, as they are
456treated as "Flags" by the application. All four of the newly added columns are
457set to "Off" by default.
458
459Updated the "Comma Separated Value (CSV) List of Current Result Set" script to
460support the addition of the new columns.
461
462Bug fix to the "Comma Separated Value (CSV) List of Current Result Set" script:
463Commas (,) and double-quotes (") are now replaced with a dash (-) and a single-
464quote ('), respectively, when they occur in a field to be written to the CSV
465file, as these characters would cause problems for automatic parsers.
466
467Modified the "Router Detail" page to display information on the "EventDNS" and
468"Hibernating" items alongside the other flags, since it has now been
469determined that the application will be treating these items like any other
470flag. Previously, these two items were displayed in the "General Information"
471section of the page, not the "Router Flags" section.
472
473Modified the order in which some items display in the "Aggregate Network
474Statistic Summary" section of the main page and the "Aggregate Summary --
475Number of Routers Matching Specified Criteria" graph on the "Network Detail"
476page to enhance consistency throughout the application.
477
478Minor source code cleanups to enhance consistency between scripts.
479
480
481--Version 2.9--
482Various application-wide code cleanups to fix all known situations that would
483generate PHP warnings.
484
485Fixed a rare division by zero bug that could occur during the generation of
486the bandwidth history graphs on the router detail page.
487
488Updates to the way "Uptime" information is presented. Previously, the "Router
489Detail" page would calculate the real-time uptime of the router (By looking
490at the difference between the current time and when the router descriptor was
491last published, and adding this value to the published "Uptime" value in the
492descriptor, compensating for time zone differences), but the other places that
493made use of the "Uptime" value did not, such as the main page, the "Network
494Detail" page, and the "Comma Separated Value (CSV) List of Current Result Set"
495functionality. These places would simply use the static "Uptime" value from
496the latest descriptor, and would not perform any real-time calculations on it.
497Now, all places that make use of the "Uptime" value perform the real-time
498calculations on it. This eliminates discrepancies between what the "Router
499Detail" page shows and what is shown everywhere else. Additionally, code to
500gracefully deal with situations where a certain descriptors publish time is
501obviously wrong, such as when it's in the future, was added to all places
502doing the "Uptime" calculations.
503
504Modified all places that display a "DirPort" value to say "None" rather than
505"0" for routers that do not mirror the directory. This is less confusing.
506
507Modified all places that display a "CountryCode" value to say "N/A" rather than
508nothing for routers where country code information could not be retrieved.
509Again, less confusing.
510
511Made the "Tor Network Status" text at the top and bottom of each page a link
512to get back to the main page. This should be more user-friendly than having to
513hit "back" to get to the main page when on the "Network Detail" and "Router
514Detail" pages. The links also exist on the main page itself, which will just
515refresh the page with the user's current settings.
516
517Added two new array variables to the config file to allow the default column
518display options to be set on a global scale. These options are what will be
519used when the user has not yet performed any customization on their display
520preferences. Both the active/inactive columns and their display order can be
521specified.
522
523Changed default column display preferences -- Added "Hostname" and removed
524"Bad Dir" and "Bad Exit".
525
526Removed support for the "EventDNS" descriptor flag entirely. The logic for this
527functionality was faulty, and since all new Tor versions have EventDNS enabled
528by default, and the Tor developers plan to remove the old DNS logic entirely
529at some time in the future (According to the "dir-spec" document), I decided
530to just go ahead and remove this now since it is becoming irrelevant.
531
532Removed "IRIX" as a listed operating system on the "Platform Graph", as it
533seems there have been no Tor servers running on this OS for some time now.
534
535Other minor fixes/enhancements.
536===============================================================================
537}}}
538===============================================================================
539
540===============================================================================
541Version 1 Changes {{{
542===============================================================================
543--Version 1.0--
544
545Initial release.
546
547
548--Version 1.1--
549
550Addition of router detail page.
551
552Addition of real-time-calculated router uptime to router detail page.
553
554Addition of bandwidth graphs to router detail page. This functionality makes
555use of the free 'JPGraph' PHP libraries.
556
557Addition of country code data to main and router detail pages. This
558functionality makes use of the free 'GeoIP' PHP API and country database.
559
560Separation of database refresh operation from main page render operation. The
561database refresh operation has been moved out of the web root into it's own
562script, 'tns_update.php'. This greatly increases page render speed in
563situations where the local-cache is expired.
564
565Addition of 'tns_agent.php' script to handle background scheduled database
566refresh operations.
567
568Movement of the SQL database creation script out of the web root.
569
570Addition of ability to click on a column header on main page to sort. Multiple
571clicks alternate sort direction.
572
573Addition of code to handle situations where a user attempts to load a page
574while a background database refresh is in progress. In these situations, the
575user will be notified of the database refresh being in progress, and the page
576will automatically reload in 10 seconds, retaining any sort or search criteria
577that was initially passed by the user.
578
579Various performance improvements during main page render, some major. Code
580cleanups. Implementation of CSS / HTML restructuring to greatly reduce the
581size of page.
582
583
584--Version 1.2--
585
586Application-wide security fixes.
587
588Multiple XSS vulnerabilities fixed.
589
590Possible SQL injection vulnerability fixed.
591
592Code cleanups, further performance enhancements.
593                                               
594
595--Version 1.3--
596                       
597Major changes to the way the application gets it's network status information
598and router descriptors.
599
600Previously, for network status information, the application would cycle
601through the local Tor server's "cached-status" documents of Authority servers
602you explicitly allowed in the application config file, using a different one
603for each local-cache refresh. This had two problems. First, it meant that you
604would get a different number of routers listed, and oftentimes different
605properties listed for a specific router depending on which Authority server's
606cached-status doc had been used. Second, and this is the bigger of the two
607problems, is that this is not the way the Tor network works. The Tor network
608leaves it up to each client/server to calculate what it believes to be the
609correct view of the network based on the multiple sources of network status
610information it has available. This is important for security reasons, and
611plays a significant role in making it harder for someone to play some bad
612tricks on network users. So, now network status information is obtained by
613asking the local Tor server's control port to list all routers it has an
614opinion about. This ensures the data being presented has been through the
615proper "voting" process done by the Tor software, and is what the local Tor
616server believes to be correct.
617
618Previously, for individual router descriptors, the application would do one
619of two things. One, the default, was to directly ask whichever Authority
620server was used for the last local-cache refresh. This was bad, as it
621basically meant that for the duration of the current cache life, every
622visitor going to the "router_detail" page was causing a request for a
623descriptor to be sent to that Authority server. Not what we want for the
624Authority servers, I'm sure. Two, a user could specify that they always wanted
625to use a certain Tor server for descriptor requests. This fixed the issue with
626hammering the Authority servers, but only if people used the option. Now,
627router descriptors are also obtained through the local Tor server's control
628port. Also, router descriptors are no longer written to files on the hard
629drive. This was unnecessary and slow.
630
631These changes allowed a lot of clean-up to be done in the config file. There
632are a lot less variables in there now.
633
634 
635--Version 1.4--
636
637Addition of an option to export the IP Addresses of all current Tor routers to
638a CSV (Comma Separated Value) file. This may be of some use for people looking
639to get a quick, current list of Tor router IP's, whether to formulate block
640lists, or to assist with other Tor network status apps / pages.
641
642Addition of "Bandwidth" and "Uptime" columns to main page. The bandwidth
643reading is obtained from the "Bandwidth Observed" parameter of the router
644descriptor and is displayed in KB/s. The uptime reading is obtained from the
645"Uptime" parameter of the router descriptor and is displayed in days. Both of
646these columns are sortable.
647
648Back end changes to make the addition of the "Bandwidth" and "Uptime" columns
649to the main page, described above, possible. These changes consisted of making
650the scheduled background update process request and parse the descriptors of
651every router that the local Tor server has an opinion about, as identified by
652it's network status request response, so that the bandwidth and uptime
653information (and everything else in the descriptor) could be inserted into the
654database at this stage to be available for use on the main page. Previously,
655descriptors were only requested and parsed on an as-needed basis when a user
656loaded the "router_detail.php" page, and the data parsed from them was not
657stored. Now, it's all inserted into the database during the main update
658process which opens up the possibilities for all kinds on new stuff. The
659downside to doing it this way is that the main update process CAN take
660considerably longer (especially when the local Tor server is very busy), which
661led to the second major back end change: Using two router (local-cache) tables
662instead of one. Basically, only one table is marked as active at any given
663time, and all page loads use the active table. When the update process runs,
664it runs on the non-active table, and marks it as the active table upon
665successful completion. This prevents users from seeing the "Database refresh in
666progress" error message, as they will instead just be seeing the old data
667until the new data is ready. I was quite serious about not causing a
668performance hit to page load times due to the new functionality, and this was
669the solution implemented to avoid that.
670         
671
672--Version 1.5--
673
674Major performance enhancements to both the background update process and the
675main page load process.
676
677First, for the update process, we are now obtaining the full network status
678opinion document and the full recent descriptor document from the control port
679of the Tor server. Previously, we were obtaining the full network status
680opinion document, and then, as we parsed out this file, we requested server
681descriptors of the Tor server's control port individually. This tended to
682sometimes cause somewhat of a load on the Tor server and cause the descriptors
683to be fed back very slowly, sometimes taking up to a half hour for a full
684refresh. Now, since we grab both full documents all at once, it only takes the
685Tor server a few seconds to provide them. Second, we are now writing the
686parsed network status information and the parsed descriptor information into
687two separate database tables (NetworkStatus & Descriptor). This makes for
688cleaner design and tables with less columns. And, in keeping with the spirit
689of the updates made in Version 1.4, there is two of each of these tables
690(NetworkStatus & Descriptor) so that one set can be updated while the other
691set can continue to be used by folks loading the page and running queries,
692etc., until the new set is ready.
693
694Performance improvements to the load time of the main page were obtained by
695switching to the MySQL MyISAM storage engine, instead of the InnoDB engine we
696had been using previously. MyISAM is significantly faster than InnoDB, and,
697since we currently don't make use of transactions, there is no reason not to
698use it. Also, indexes were added to the NetworkStatus and Descriptor tables
699on the "Fingerprint" column, since this is what is used for the join of these
700two tables during page load. This further increased the query speed.
701
702Some other small performance improvements were implemented, especially on the
703"router_detail.php" page.
704
705The update process now has more robust error handling.
706
707Addition of "Count" column to main page.
708
709Addition of green check marks and red x's to indicate whether a flag is "Yes"
710or "No". Previously, it would just print "Yes" or "No".
711
712Modifications of font selections and background images to hopefully achieve
713two things: Fit more in a smaller space, and make the page easier to read.
714
715
716--Version 1.6--     
717
718The application now performs reverse-DNS lookups during the update process and
719stores this information in the database. This enables a user to choose whether
720they would like addresses displayed as IP or Hostname. Of course, whichever
721display they choose, it is sortable.
722
723Added Hostname information to the router detail page as well.
724
725Added "Last Update Elapsed Time" field to main page. Good way to see if your
726system is experiencing problems during the background updates.
727
728Added "Current Descriptor Signature" field to the main page for the Network
729Status Source router information section.
730
731Minor CSS changes to improve layout and formatting in certain situations. 
732
733
734--Version 1.7--
735
736Changes to the way variable handling is done. I moved all state maintaining
737variables into PHP session, such as all of the "Flags" variables and the
738Address Display Mode, SortRequest, and SortOrder variables. Also, wherever
739possible because of addition to session, variables were removed from the URL's
740in the anchor tags of the generated page. The only ones that were left in
741URL's were variables that need to be manipulated by clicking on a link, namely
742the SortRequest and SortOrder variables. This makes the URL's in the anchor
743tags of the generated page much shorter and cleaner, since a whole lot less is
744being passed around via GET. This in turn reduces the generated page size,
745sometimes considerably depending on the custom query options in effect.
746Another nice benefit to doing things this way is that if a user has custom
747options set, completely browses away from the site, and later comes back
748within their same browser session, all of their options will be configured as
749they were when they left.
750
751Also, variables that needed to remain in URL's have shorter names to further
752reduce the amount of data being passed around via GET, and hence the length
753of the URL's in the generated page.
754
755Further cleanups to HTML formatting and CSS on both the main page and the
756router detail page.
757
758Addition of timer to bottom of main page to indicate how long page generation
759took on the server.
760
761 
762--Version 1.8-- 
763
764Changes / cleanup to CSS. All CSS information is now defined in one external
765style sheet which resides in the "web/css" directory, and the different parts
766of the code that need the style sheet simply reference it rather than defining
767everything at the top of every HTML page output to the browser.
768
769Addition of row highlighting for Mozilla Firefox / Opera. This makes it easier
770to visually track which row you are currently moused over. This feature does
771not currently work in Internet Explorer since that would require JavaScript,
772and I'm trying to keep this app JavaScript free for those who browse with it
773disabled.
774
775When sorting by IP Addresses, they are now sorted naturally, rather than as
776strings. This should make the IP Address search quite a bit more meaningful.
777This change also applies to the CSV (Comma Separated Value) file list of IP's.
778
779
780--Version 1.9-- 
781
782Added proper escaping of problem characters to all strings that get populated
783from data parsed from router descriptors and network status documents before
784database inserts are performed. This should prevent the update process from
785dying when these characters are encountered, which would sometimes happen.
786
787Now using the standard "gethostbyaddr" PHP function to do hostname lookups.
788Previously, I was doing some custom parsing on the output of the Unix "host"
789command, as I thought it would be faster, but, after comparing the two, I see
790no speed degradation with using "gethostbyaddr". The advantage of using
791"gethostbyaddr" over "host" is that we are not using a platform-specific
792command which limits where the application can run without modification.
793
794Addition of Advanced Search functionality, which lets you perform free-text
795searches on the following data: Fingerprint, Router Name, Country Code,
796Bandwidth, Uptime, Last Descriptor Published, IP Address, Hostname, Onion
797Router Port, Directory Server Port, Platform, & Contact. You can apply the
798following modifiers when searching the above data: Equals, Contains, Is Less
799Than, or Is Greater Than. The Advanced Search works in conjunction with the
800other Custom Query options (Sort By, Sort Order, Address Display Mode, and
801Require Flags), allowing a great deal of flexibility to customize the result
802set as desired.
803
804Addition of indexes where necessary in the database to better facilitate
805speedy free-text searches.
806
807Addition of "Hostname" field to "Tor Server Providing Network Status Opinion"
808section.
809
810Addition of feature to tell user if they are accessing the page through the
811Tor network or not, color coded.
812
813Additional escaping of potentially troublesome HTML characters before
814displaying on page for "Contact" field on main page and router detail page.
815===============================================================================
816}}}
817===============================================================================
818
819NOTE: This product includes GeoLite data created by MaxMind, available from
820http://www.maxmind.com/.
821
Note: See TracBrowser for help on using the browser.