Custom Query (15 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (1 - 5 of 15)

1 2 3
Ticket Summary Owner
#19057 Prohibit modifications of doc/EmailProvider
Description

Someone have created doc/EmailProvider and constantly removes my notes from there. Creating such a list, especially on torproject official website, can be harmful, because it reduces the cost of discovering such services to law enforcement. The fact users are not identified are flaws in a state, and states will fix them. Those unfixed services are really rare. Creating such a public list will allow law enforcement to fix them all. All the law enforcement will have to do is to monitor such lists and enforce services` owners.

So I propose to lock the page to prevent addition of services and make an official statement about it.

#23565 document signs of client clock skew to ease troubleshooting
Description

Ticket #23508 describes some ways that clock skews during client bootstrapping can often cause stalls without any useful user feedback. Document some signs of this behavior (e.g., specific message patterns in log files, Tor Launcher messages when stalled) so we can better help users who aren't running a modern enough release to mitigate these issues.

#5553 prevent protocol leaks; Tor client connection API or protocol review howto phoul
Description

I am unhappy with the current Torify instructions.

The big bittorrent leak may happen to any application, which has not been explicitly designed for Tor or reviewed by someone. That's why safe use of Tor is at the moment somewhat limited to the few applications designed over Tor (Tor Browser) or reviewed for use over Tor.

Two ideas will follow how to solve this problem. One or another may work as solution. Feel free to propose other/better/easier/faster solutions.

Proposal 1: Write a howto, how to review an application and protocol for leak free use over Tor. "The protocol/application has to be reviewed." - That is much to vague, even for the application's developer.

For example, would the xchat developers answer "xchat over Tor: do not use dcc/ctcp... it leaks your IP/timezone..."?

What we easily could do for many applications, would be asking the application's developers. But even them could be confused by the question. The paper should define, what a protocol leak is, how to look out for them, how to prevent them.

This would hopefully enable the application developers to answer to the question regarding the protocol leak status. And if they don't want to review their own application, third party contributors could review the protocol.

Proposal 2: Provide an alternate interface for applications. An alternative to socks. Either an API or libery for developers. i2p does also provide one and loads of applications are build on top of i2p. Why there are not so many applications designed for Tor? Because there is neither an API nor an libery.

#8518 Document the new support workflow phoul
Description

The support workflow is changing, the team is growing, I should document it.

#10966 Define a process on how new support assistants can be accepted in the team phoul
Description

The switch from having a single person handling all support request to a team was made through recruiting support assistants as a contracting position. It would be good to define a process on how new people can get accepted in the team. It's mostly a question of trust and probably we need to define a vouching process and a set of people that need to ack the decision.

1 2 3
Note: See TracQuery for help on using queries.