Re: [tor-bugs] #9199 [BridgeDB]: Rethink the logging of BridgeDB

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#9199: Rethink the logging of BridgeDB
----------------------+-----------------------------------------------------
 Reporter:  asn       |          Owner:                   
     Type:  task      |         Status:  needs_information
 Priority:  normal    |      Milestone:                   
Component:  BridgeDB  |        Version:                   
 Keywords:            |         Parent:                   
   Points:            |   Actualpoints:                   
----------------------+-----------------------------------------------------

Comment(by sysrqb):

 Replying to [comment:3 asn]:
 > Replying to [comment:2 sysrqb]:
 > > a) Should we scrub the bridge's fingerprint when safe logging is not
 disabled? It can easily be used to retrieve the IP addr via Atlas, etc.
 Maybe we should hash the fingerprint by default so various aspects of the
 log file are linkable?
 >
 > Hm, do we even care about scrubbing the IP addresses of bridges? I was
 mostly worrying about clients IPs.

 I don't know, do we? My thought was "what happens if an adversary obtains
 a log file?", but maybe this isn't something we should worry about.
 Currently we don't log client IP addresses (only the /24 "area", but that
 still maybe too much info). We also log email addresses, which I think we
 should scrub. My current branch scrubs these last two cases.

 > > c) I think providing a heartbeat is a nice idea. How do you feel about
 displaying uptime, user GEOIP stats, OS stats (based on user-agent) over
 the past n hours? This won't be trivial, but it shouldn't be too
 difficult. I think we should push this to v2 also.
 >
 > Yeah, I also like heartbeats.

 It was your idea :)

 >
 > BTW, be aware that if you want a "X unique IPs asked for bridges during
 the last N hours" dialog, you also need to keep client IPs in memory. We
 should probably not do that.
 >

 For GEOIP stats, I was thinking we would analyze the information in real-
 time and only need to keep counters in a dict for the various values, but
 this would not show unique queries. If we want unique IPs stats, we can
 hash the IP and store it in the DB only for the time period, very similar
 to what we do for email addresses. We absolutely should not store IP
 addresses, agreed.

 > > d) If we're auditing the logging, do we want to consider switching to
 [https://twistedmatrix.com/documents/12.2.0/core/howto/logging.html
 twisted.python.log]? Isis brought this up a few weeks ago. If we're going
 to make a decision on it, now is a fine
 time.[https://twistedmatrix.com/trac/wiki/TwistedLogging 0]
 > >
 >
 > Hm. How hard would it be to switch to twisted.logging?  What are the
 advantages of using Twisted logging? Do we care about them?  If the
 advantages are not too great, I'd rate this as low-priority and probably
 do something more important if it takes more than 2 hours of
 coding/thinking.
 >
 > It's up to you :)
 >

 Deferring to Isis' answer above :)

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9199#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs