Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2011-06-16T15:23:15Zhttps://gitlab.torproject.org/legacy/trac/-/issues/3324Mike Perry's Iteration Report 201106122011-06-16T15:23:15ZMike PerryMike Perry's Iteration Report 20110612# Goals
[[TicketQuery(keywords=~MikePerryIteration20110612,format=table,col=component|summary|points|actualpoints,order=component)]]
Interviews, emails, etc: 6 pts, Actual: 10 pts
# Fires
[[TicketQuery(keywords=~MikePerryIterationFires2...# Goals
[[TicketQuery(keywords=~MikePerryIteration20110612,format=table,col=component|summary|points|actualpoints,order=component)]]
Interviews, emails, etc: 6 pts, Actual: 10 pts
# Fires
[[TicketQuery(keywords=~MikePerryIterationFires20110612,format=table,col=component|summary|points|actualpoints,order=component)]]
# Metrics
Goal Points: 23
Goal Points Done: 5
Actual Goal Points Done: 35
Fires Done: 1
Actual Points Done: 36Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/3098Review other W3C-Identity Workshop submissions2011-05-15T05:49:38ZMike PerryReview other W3C-Identity Workshop submissionsI need to review 5 papers by Sunday as part of participation in the W3C-Identity workshop.I need to review 5 papers by Sunday as part of participation in the W3C-Identity workshop.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/3060Review JonDos Design + Profile2011-05-31T00:55:06ZMike PerryReview JonDos Design + ProfileWe need to review the JonDos Firefox profile and work with them towards a shared web fingerprint.We need to review the JonDos Firefox profile and work with them towards a shared web fingerprint.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/2743safelogging should cover hidden service name and intro-points too2020-06-13T14:09:26ZRoger Dingledinesafelogging should cover hidden service name and intro-points tooIn log messages about a hidden service we operate, we don't replace the hidden service name with [scrubbed].
Historically, this was considered fine, because you have your hostname and private_key files on disk already.
But if the user ...In log messages about a hidden service we operate, we don't replace the hidden service name with [scrubbed].
Historically, this was considered fine, because you have your hostname and private_key files on disk already.
But if the user puts his $datadir on encrypted storage, and the logs aren't on encrypted storage, then the logs could be the weak link.Tor: unspecifiedRobert RansomRobert Ransomhttps://gitlab.torproject.org/legacy/trac/-/issues/2681brainstorm ways to let Tor clients use yesterday's consensus more safely2022-03-22T13:28:40ZRoger Dingledinebrainstorm ways to let Tor clients use yesterday's consensus more safelyRight now Tor clients won't use a consensus that's 25 hours old. But if the directory authorities don't agree on a consensus for a day, things can go bad. We need to investigate other tradeoffs in this space than the one we've currently ...Right now Tor clients won't use a consensus that's 25 hours old. But if the directory authorities don't agree on a consensus for a day, things can go bad. We need to investigate other tradeoffs in this space than the one we've currently picked.
For instance: if you got your directory consensus info when it was valid, but you haven't been able to get any new consensus, perhaps you should be more forgiving about the timestamp on the consensus you have. That's a slightly different scenario than believing a new consensus that's 48 hours old.
Another option is just to change 24 to 48, which probably doesn't put clients at much greater harm, but gives us a lot more breathing room for mistakes.
The implementation side of this will be tricky, because we'll need to make sure that clients can handle descriptors that are 36 hours out of date too. We started implementing that feature several times, but I think we've never finished it.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/2544Report potential addon conflicts in a standard, observable way2018-03-27T13:44:43ZTracReport potential addon conflicts in a standard, observable wayi have installed foxyproxy recently in order to access i2p sites from firefox. by default foxyproxy provides a proxy configuration called 'Default' (no proxying) that's used when a given url doesn't match any patterns. this means that by...i have installed foxyproxy recently in order to access i2p sites from firefox. by default foxyproxy provides a proxy configuration called 'Default' (no proxying) that's used when a given url doesn't match any patterns. this means that by default all urls will be fetched directly without going through the tor network. at first it wasn't clear to me that proxy settings applied by foxyproxy override those specified in torbutton options. so i just added a proxy for the i2p network and some time later when i visited check.torproject.org i noticed that i'm not using tor anymore;) i think torbutton could somehow detect the presense of foxyproxy and at least warn user.
**Trac**:
**Username**: wooTorbutton: 1.2.5Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/1991Recognize poor guard performance and switch?2020-06-13T17:46:35ZRoger DingledineRecognize poor guard performance and switch?Ticket #1919 showed that the expected performance when using guards is comparable to the expected performance when picking the fastest guards. The penalty from using the slowest guards is especially noticeable in the 1MB and 5MB torperf ...Ticket #1919 showed that the expected performance when using guards is comparable to the expected performance when picking the fastest guards. The penalty from using the slowest guards is especially noticeable in the 1MB and 5MB torperf runs.
What property is it about the guards that lets us guess when we have the slow ones? Can we sum the bandwidth of our top three guards and realize that it's significantly below the average?
Ultimately I expect we'll want the Tor client to be able to recognize that it's chosen a poor set of guards and swap in a faster one so it's not in the bottom, say, 20%.https://gitlab.torproject.org/legacy/trac/-/issues/697Wrong DNS configuration could break navigation2020-06-13T14:00:00ZTracWrong DNS configuration could break navigationOn 0.2.0.26rc (add new version on reported version please),
Hello,
i've received one email who alert me.
One user have received OpenDNS pages when he is using tor.
OpenDNS is a company who resolve DNS for the others giving them filt...On 0.2.0.26rc (add new version on reported version please),
Hello,
i've received one email who alert me.
One user have received OpenDNS pages when he is using tor.
OpenDNS is a company who resolve DNS for the others giving them filtering, security, ads, but no privacy.
It appears that some nodes resolving DNS seems to have wrong DNS configured, blocking navigation.
If one router making dns resolution is misconfigured it could break navigation of others.
I think a DNS control need probably to be added making theses routers down.
Perhaps using a downloadable list for phishing.
---------- Forwarded message ----------
From: d
Date: 2008/6/10 04:22
Subject: Tor exit node policy
Hello,
I was browsing a phishing site using Tor recently and instead of the phish I saw an OpenDNS warning page (and apparently no way to bypass it). Yours was one of the exit nodes that was part of my Tor connection at the time.
I wasn't able to identify exactly which exit node it was.
Do you have Phish Filtering set up on your exit node, and if so is this a deliberate policy? I work in antiphishing and use Tor for some phish sites.
Thank you,
d
----------------------
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: amisTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/393hidden services resolve hosts only once2020-06-13T13:57:31Zweasel (Peter Palfrader)hidden services resolve hosts only onceI have a hidden service, configured with
HiddenServicePort 6666 irc.oftc.net:6666
Now irc.oftc.net is a rotation that changes quite frequently and for that
reason the TTL of the A records it returns is only 60.
The problem is that Tor ...I have a hidden service, configured with
HiddenServicePort 6666 irc.oftc.net:6666
Now irc.oftc.net is a rotation that changes quite frequently and for that
reason the TTL of the A records it returns is only 60.
The problem is that Tor resolves the hostname only once, when it configures
the hidden service, not everytime a user establishes a new connection. This
causes problems since by the time a client request comes the information Tor
has often is long obsolete.
Please resolve it on connects, and don't cache it in a broken way (caching it
for TTL is fine).
Thanks
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedRobert RansomRobert Ransom