Hi there,
I worked on a new update for globe. This update addresses some features that were missing or not possible in the current version of globe ( http://globe.rndm.de/ ).
These changes include: - fixed minification process to allow usage of the ember production build - removed unnecessary whitespace on top of the page - modified loading indicator - added subpages
Because this update includes some major ui changes, I would like to get some feedback on it. You find the latest version on http://globe.rndm.de/lab/
Cheers, Christian
The header's navigational tabs could be wider to take advantage of the available real estate and not squish "Top 10 relays" onto two lines.
See attached screenshot of it on my device.
Justin Bull me@justinbull.ca
E09D 38DE 8FB7 5745 2044 A0F4 1A2B DEAA 68FD B34C
On 2013-11-03, at 1:14 PM, me@rndm.de wrote:
Hi there,
I worked on a new update for globe. This update addresses some features that were missing or not possible in the current version of globe ( http://globe.rndm.de/ ).
These changes include:
- fixed minification process to allow usage of the ember production build
- removed unnecessary whitespace on top of the page
- modified loading indicator
- added subpages
Because this update includes some major ui changes, I would like to get some feedback on it. You find the latest version on http://globe.rndm.de/lab/
Cheers, Christian _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 2013-11-03, at 1:47 PM, me@rndm.de wrote:
Changed it and it should work now.
This may be more nit-pickery, but for each view: Top 10 relays, Help, and Code, have them apply an `.active` class of the same style as `:hover` when you're presently viewing it. In other words, it shows the tab in purple when its corresponding page is being displayed.
Feel free to ignore :-)
Justin Bull me@justinbull.ca
E09D 38DE 8FB7 5745 2044 A0F4 1A2B DEAA 68FD B34C
On 2013-11-03, at 1:47 PM, me@rndm.de wrote:
Changed it and it should work now.
Oh, and additionally, if a user clicks the search icon with no keywords the text at the top should read:
Showing all results: xx Relays yy Bridges
Instead of:
Search results for "": xx Relays yy Bridges
Justin Bull me@justinbull.ca
E09D 38DE 8FB7 5745 2044 A0F4 1A2B DEAA 68FD B34C
I worked on a new update for globe...
Damn this is awesome! I'm tempted to link to this from our front page (replacing Tor Browser in the project matrix on www.torproject.org, since TBB is already the featured item on the download page).
Mike, Roger, etc: Any objections?
Christian: Pity it doesn't have a valid cert. It would be nice if it defaulted to SSL.
Cheers! -Damian
I added the following based on Justin Bulls feedback:
- active style for navigation items - "Showing all results" for empty seach query
Damn this is awesome! I'm tempted to link to this from our front page (replacing Tor Browser in the project matrix on www.torproject.org, since TBB is already the featured item on the download page).
Mike, Roger, etc: Any objections?
Christian: Pity it doesn't have a valid cert. It would be nice if it defaulted to SSL.
Technically you could build globe and host it on your SSL enabled servers. The code and build process is available on github.
Cheers! -Damian _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Cheers, Christian
On Sun, Nov 03, 2013 at 11:23:18AM -0800, atagar@torproject.org wrote 0.5K bytes in 0 lines about: : Damn this is awesome! I'm tempted to link to this from our front page : (replacing Tor Browser in the project matrix on www.torproject.org, : since TBB is already the featured item on the download page). : : Mike, Roger, etc: Any objections?
TBB should stay where it is. Maybe feature this globe app from the metrics page.
: Christian: Pity it doesn't have a valid cert. It would be nice if it : defaulted to SSL.
Can we run the code somewhere rather than on a 3rd party server?
: Damn this is awesome! I'm tempted to link to this from our front page : (replacing Tor Browser in the project matrix on www.torproject.org, : since TBB is already the featured item on the download page). : : Mike, Roger, etc: Any objections?
TBB should stay where it is. Maybe feature this globe app from the metrics page.
Metrics is a site for researchers. Globe is a client application akin to Atlas. They're different audiences. I still like the idea of replacing TBB on the front page because, of the things we list, including it there offers no value to visitors (it's already the primary thing we vend). That said, this might be a moot discussion until we sort out the second bit...
: Christian: Pity it doesn't have a valid cert. It would be nice if it : defaulted to SSL.
Can we run the code somewhere rather than on a 3rd party server?
Christian suggested hosting it on TPO infrastructure elsewhere on this thread too. Sounds like a discussion that should move onto a ticket.
On Sun, Nov 03, 2013 at 11:23:18AM -0800, Damian Johnson wrote:
I worked on a new update for globe...
Damn this is awesome! I'm tempted to link to this from our front page (replacing Tor Browser in the project matrix on www.torproject.org, since TBB is already the featured item on the download page).
Actually, it should rather replace Atlas. It no longer has an active maintainer (Karsten and I are just trying to keep it alive and fix small bugs) and is still not able to display bridge information. Maybe it's time to retire Atlas in favour of Globe?
Cheers, Philipp
Philipp Winter:
On Sun, Nov 03, 2013 at 11:23:18AM -0800, Damian Johnson wrote:
I worked on a new update for globe...
Damn this is awesome! I'm tempted to link to this from our front page (replacing Tor Browser in the project matrix on www.torproject.org, since TBB is already the featured item on the download page).
Actually, it should rather replace Atlas. It no longer has an active maintainer (Karsten and I are just trying to keep it alive and fix small bugs) and is still not able to display bridge information. Maybe it's time to retire Atlas in favour of Globe?
Quoting Karsten last July: “However, I don't have plans to retire Atlas just yet. I think it's fine to have more than one website providing access to Onionoo data. Yay, diversity.” https://lists.torproject.org/pipermail/tor-dev/2013-July/005122.html
But the situation might have changed since then.
On Sun, Nov 03, 2013 at 01:14:26PM -0500, me@rndm.de wrote:
Hi there,
I worked on a new update for globe. This update addresses some features that were missing or not possible in the current version of globe ( http://globe.rndm.de/ ).
These changes include:
- fixed minification process to allow usage of the ember production
build
- removed unnecessary whitespace on top of the page
- modified loading indicator
- added subpages
Because this update includes some major ui changes, I would like to get some feedback on it. You find the latest version on http://globe.rndm.de/lab/
Sorting by "Advertised Bandwidth" appears to sort the column asciibetically rather than numerically (taking units into account): "9.22 MB/s" is sorted between "85.13 KB/s" and "97.38 KB/s".
Am 2013-11-04 04:17, schrieb Ian Goldberg:
On Sun, Nov 03, 2013 at 01:14:26PM -0500, me@rndm.de wrote:
Hi there,
I worked on a new update for globe. This update addresses some features that were missing or not possible in the current version of globe ( http://globe.rndm.de/ ).
These changes include:
- fixed minification process to allow usage of the ember production
build
- removed unnecessary whitespace on top of the page
- modified loading indicator
- added subpages
Because this update includes some major ui changes, I would like to get some feedback on it. You find the latest version on http://globe.rndm.de/lab/
Sorting by "Advertised Bandwidth" appears to sort the column asciibetically rather than numerically (taking units into account): "9.22 MB/s" is sorted between "85.13 KB/s" and "97.38 KB/s".
I fixed the datatables sorting functions. In addition i fixed the current tests to work with the new version and added a jshint task[1] in the build process.
The next task would be to add useful information about relays, bridges and all of their properties to the "Help" page.
If there isn't anything wrong, I will release it to the regular globe url.
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[1] - http://www.jshint.com/about/
Cheers, Christian
me@rndm.de:
In addition i fixed the current tests to work with the new version and added a jshint task[1] in the build process.
Please, please, please, don't depend on jshint. It is non-free software: https://github.com/jshint/jshint/issues/1234
Am 2013-11-05 13:20, schrieb Lunar:
me@rndm.de:
In addition i fixed the current tests to work with the new version and added a jshint task[1] in the build process.
Please, please, please, don't depend on jshint. It is non-free software: https://github.com/jshint/jshint/issues/1234
I removed jslint from the build process.
An alternative would be eslint[1] (via grunt-eslint[2]). Right now they have a dependency to jslint but it works without it. I wrote the author asking if there is a special reason for including jslint in the package dependency.
Until i find an alternative for jslint/jshint that doesn't depend on jslint/jshint i will skip the JavaScript code quality test.
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[1] https://github.com/nzakas/eslint [2] https://github.com/sindresorhus/grunt-eslint
If there isn't anything wrong, I will release it to the regular globe url.
I deployed the latest globe version on http://globe.rndm.de/ .
The jshint code quality check was replaced with latest eslint version that works without jshint. Aside from the already mentioned changes I fixed the bridge/relay detail page if no detail document was found.
I also added relay family links. While working on this feature I noticed that the onionoo family field can return fingerprints of bridges. I modified the way the relay details route works and now it checks if the api returns a valid relay. If this isn't the case it checks for a bridge and redirects to its detail page. (for example "TorLand2" has a bridge in its family members field and clicking on the fingerprint throws an error on atlas)
If this behavior is wrong or something is missing just tell me.
Cheers Christian
On Thu, Nov 07, 2013 at 03:33:23PM -0500, me@rndm.de wrote:
If there isn't anything wrong, I will release it to the regular globe url.
I deployed the latest globe version on http://globe.rndm.de/ .
The jshint code quality check was replaced with latest eslint version that works without jshint. Aside from the already mentioned changes I fixed the bridge/relay detail page if no detail document was found.
I also added relay family links. While working on this feature I noticed that the onionoo family field can return fingerprints of bridges. I modified the way the relay details route works and now it checks if the api returns a valid relay. If this isn't the case it checks for a bridge and redirects to its detail page. (for example "TorLand2" has a bridge in its family members field and clicking on the fingerprint throws an error on atlas)
If this behavior is wrong or something is missing just tell me.
Well, that's one place I didn't think to look for leaking bridge fingerprints. At this point there is no way to retrieve a bridge's IP address and port number using its fingerprint, right? And, considering the default torrc does say: "However, you should never include a bridge's fingerprint here, as it would break its concealability and potentionally reveal its IP/TCP address." I really don't know how else to prevent this. Onionoo could do extra processing to prevent leaking these bridges, but I'm not sure that's a good way to do it.
On another note, globe looks awesome! Thanks you!
On 11/8/13 2:59 AM, Matthew Finkel wrote:
On Thu, Nov 07, 2013 at 03:33:23PM -0500, me@rndm.de wrote:
I also added relay family links. While working on this feature I noticed that the onionoo family field can return fingerprints of bridges. I modified the way the relay details route works and now it checks if the api returns a valid relay. If this isn't the case it checks for a bridge and redirects to its detail page. (for example "TorLand2" has a bridge in its family members field and clicking on the fingerprint throws an error on atlas)
If this behavior is wrong or something is missing just tell me.
Well, that's one place I didn't think to look for leaking bridge fingerprints. At this point there is no way to retrieve a bridge's IP address and port number using its fingerprint, right? And, considering the default torrc does say: "However, you should never include a bridge's fingerprint here, as it would break its concealability and potentionally reveal its IP/TCP address." I really don't know how else to prevent this. Onionoo could do extra processing to prevent leaking these bridges, but I'm not sure that's a good way to do it.
Onionoo does not sanitize any information from relay or bridge descriptors. Onionoo processes publicly available information from metrics, so whatever is sensitive in there is already available to whoever wants to use it. Onionoo only makes it more convenient for people to use this information.
Metrics does not sanitize relay descriptors, only bridge descriptors. Whatever people put in their relay configuration and that goes into relay descriptors will be made public.
On another note, globe looks awesome! Thanks you!
Very true. Thanks, Christian!
All the best, Karsten