teor2345 at gmail.com
Mon Nov 14 09:34:38 UTC 2016
> On 14 Nov. 2016, at 02:54, Karsten Loesing <karsten at torproject.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> Hi everyone,
> I'm moving this (old but recently continued) thread from an internal
> mailing list to this list as suggested by Roger. Any feedback would
> be most useful by Wednesday, November 16. Thanks!
> All the best,
> On 07/12/15 14:09, Karsten Loesing wrote:
>> Hi everyone,
>> we're discussing changing the graphing engine on Tor Metrics from
>> generating static images on the server using R/ggplot2 towards
>> As a result, Tor Metrics will require Tor Browser users to switch
>> to Medium-High Security or lower.
>> This switch has some potential with respect to visualizations, and
>> the visualization people in the metrics team want to do it. It
>> allows producing more graphs like Lunar's bubble graph:
>> In fact, it would allow all kinds of visualizations like the ones
>> seen in the D3 gallery:
>> So, my question is: can you all live with this change?
>> The next step will be to ask users on tor-talk@, but I figured I
>> should ask here first. If I don't hear any strong objections by
>> Thursday, I'll go ask on tor-talk at .
>> All the best, Karsten
> On 07/12/15 15:22, somebody else wrote:
>> fallbacks, correct?
>> Likewise, I assume it would be too difficult (for now (?)) to try
>> server and serve them as images in that case? 
>>  I'm hand-waving about whether or not this is possible, but it
>> seems like it in theory, and at least one person has tried:
> On 08/12/15 00:34, somebody wrote:
>> I don't understand why you would want Tor users to lower their
>> security in order to get prettier graphs. Is there some obvious
>> thing I am missing?
>> web sites I access (via NoScript), and with third party "included"
>> sometimes RequestPolicy). Having web sites run their own choice
>> of programs in my computer seems like a really stupid idea. I can
>> only assume that its prevalence as a technique reflects how little
>> respect the average web site has for the security of its users.
> On 09/12/15 08:45, another person wrote:
>> I'd like to know how much work it would be.
> On 09/12/15 13:59, Karsten Loesing wrote:
>> fallbacks written in a different language would be infeasible. But
>> I could imagine that we render D3.js graphs on the server using
>> Node.js and return images to the client.
>> I'm mostly worried about the lack of interactivity. I'd really
>> want to get away from requiring a full round-trip from client to
>> server and back just to change something in the displayed graph.
>> Maybe we can keep them somewhat interactive, or at least add
>> tooltips, by using SVG as image format.
>> But please understand that while I'm doing okay at processing
>> large amounts of data, I don't know much about web development. If
>> people here have ideas, please let me know!
>> Note that investigating these options may take a while, mostly
>> because people in the metrics team are busy. But we won't switch
>> Thanks for the feedback. This is very helpful!
>> All the best, Karsten
> On 12/11/16 16:37, Karsten Loesing wrote:
>> Hello everyone,
>> apologies for digging out such an old thread, but after almost
>> starting a new thread on the exact same topic I remembered that we
>> had this discussion almost a year ago. I figured it's better to
>> continue this thread to avoid discussing the exact same things
>> again and instead add new thoughts below.
>> So, on Thursday, Linda, iwakeh, and I met in Berlin to talk about
>> making the Tor Metrics website more usable. We came up with some
>> pretty good ideas to better address the various user types---from
>> journalists to data scientists---coming to the Tor Metrics website
>> to learn interesting things about the deployed Tor network. We'll
>> share results with you in a few weeks from now when there's
>> something to see and click on.
>> once more.
>> To be clear, our immediate plans---including reorganizing
>> information and displaying sparklines as quick entry points into
>> customizable graphs and even a dashboard with user-selected
>> will be a stretch.
>> The question is: do we have to keep stretching by avoiding a web
>> techology that would make our lives and the lives of our users so
>> much easier?
>> This isn't really something that we can work around by generating
>> switch to another graphing framework such as R Shiny (which I used
>> for the webstats prototype) or D3.js (which we currently use on Tor
>> Metrics just for the bubbles graph, though not in the most
>> efficient way).
>> - From a development perspective this switch would make a lot of
>> sense, because we'd have to write a lot less code for new graphs
>> and because there'd be potential contributors out there who'd
>> appreciate working with a known framework. Our current graphing
>> engine doesn't scale much longer, and this does slow us down.
>> because we can. I'm in favor of keeping all the parts of Tor
>> Metrics where we provide textual or static information entirely
>> But the parts of Tor Metrics where we're providing visualizations
>> would include all graphs and tables, because we shouldn't be
>> maintaining two graphing engines.
Are there any privacy or security advantages to having client-side
For example, if we download data from the server, and then render it
the client is requesting and visualising.
improve client privacy in this way?
(Or does it cost too much effort or too much bandwidth to pull down
larger datasets just to hide what the client is looking at?)
>> So, how do we decide this? I believe that this should be a
>> Tor-wide decision. My main worry is that we're sinking weeks and
>> weeks of development effort into this switch without many Tor
>> people noticing, and then once we publish and they get aware, we
>> need to roll back, wasting all the effort.
>> But to be honest, we're wasting effort right now by keeping the
>> workarounds and implementing hacks with dynamically generated HTML
>> forms and potentially dozens of parameters just to avoid the devil
>> Here's my suggestion: unless somebody raises a valid concern how
>> Wednesday, November 16, we're putting this on the hold again.
>> (That's the day before the next metrics team meeting and Vegas
>> meeting, and it should be enough time to raise your voice.)
>> Otherwise we'll switch.
>> Oh, and if you're in favor of switching, please consider saying
>> that, too. Thanks.
>> All the best, Karsten
> On 13/11/16 05:04, Roger Dingledine wrote:
>> Does this mean that we'd be breaking the "download a static version
>> of the graph" feature too? I use that feature a lot for grabbing
>> snapshots to put into presentations, and we also want to use it for
>> pulling in metrics graphs in blog posts, e.g.
> as well as for external journalists.
>> Oh, I should also say this would be a great topic for the
>> tor-project list, since it doesn't need to be sekrit (and since
>> then other people could know that it's a topic we're considering,
>> and maybe even help us make the right decision).
> On 13/11/16 10:08, Karsten Loesing wrote:
>> It's quite easy to implement that feature using Shiny, for
>> example. Either Shiny would produce a .png file that you can
>> download using your browser's "Save Image As..." feature, or there
>> would be a "Download Graph" button. It would be just a few lines
>> of code.
>> And we'd be able to provide features like a "Download graph data"
>> button with just a few more lines of code, which would require a
>> lot more effort right now.
"Download Graph" or "Download graph data" buttons?
Would it be possible to give others a URL for a specific graph,
without having to save the graph on some other site?
If we can't do this, it would be bad for how I and many others
typically use Tor Metrics on mailing lists.
(And if we do allow this feature, I'm not sure how that's any
different from server-side rendering of graphs for clients that
I'm also not sure what you mean by "tables" or "Download graph
data" - will there still be CSV data downloads available?
Is it the aggregated data that would be in the
In general, I would prefer to be able to use the Tor Metrics
we provide Tor Browser, where we recommend(?) people turn
to turn it on. But if the advantages outweigh the security and
consistency considerations, I'd be ok with it.
(Just like I use Atlas, and the Metrics Bubble graphs.)
have some level of basic functionality, even if it's only static
images and tables (which I think should be available for offline
use as well).
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
xmpp: teor at torproject dot org
More information about the tor-project