On 7/24/10 1:04 PM, Greg Troxel wrote: > > I was very surprised to see requests to > > http://chart.apis.google.com/chart > > From the web UI. It seems that while one can argue that sending the > hash of a serverid is not tha big a deal, it still reveals the IP > address of a tahoe client to google.
Hm, yeah, I see what you mean. The chart API is only used on the "recent uploads and downloads" portion of the human-facing webapi, specifically the "map-update" phase of a mutable-file publish or retrieve. It reveals three things to google: * a truncated version of the serverids that were used for a given mapupdate (as labels for certain graph rows) * the number of mapupdate operations this node has performed since boot (in the Referrer URL) * the internet-visible IP address of the web browser you're using to view that page (possibly the exterior address of a NAT box) In return, we get an easier-to-view timeline of how servers responded during the map-update operation, which only took me a day to implement. I looked around briefly for a python-side way to build those sorts of graphs (PIL comes to mind, but pure-python would be easier, as our dependency set is already getting out of hand), but it looked like it'd be harder to get running then the google chart api. > By default, I think the web UI should not generate any off-machine > traffic (other than what's necessary to do the tahoe ops requested). Yeah, I'd be happy to see that graph generated by something else. I'd also like to see graphs like that on all of our upload/download-status pages, not just mutable mapupdate. In particular, I've been putting off some #798 new-downloader work (the "OVERDUE" state machine, and the slow/fast-server selection code) until I've got better visualization tools to guide the changes. I've been experimenting with a javascript library called SIMILE[1] which provides a zoomable scrollable timeline widget, but I had some problems making it work correctly. A library like that would require Tahoe web clients to enable JS (which I've been avoiding for years now), but it wouldn't involve any external servers. cheers, -Brian [1]: http://www.simile-widgets.org/timeline/ _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
