> "After a lot of back-and-forth technical discussions, the Tor Project's representative wrote, "I'm a bit lost with all this info in this ticket. I feel like lots of the discussion here is fruitful but they are more brainstormy and researchy and less fitting to a bug bounty ticket." They concluded with: "Is there a particular bug you want to submit for bug bounty?" In my opinion, describing a vulnerability and mitigation options is not "brainstormy and researchy". To me, it sounds like they were either not competent enough to fix the bug, or they were not interested. In any case, they were just wasting time."
This plus the other descriptions/responses from the project in his post makes me think the project has attracted a lot of people that aren't programmers or can't actually do the valuable work of fixing the thing (though I'd be interested in seeing the specific ticket).
I'd guess that projects like Tor that interest people outside of strict programmer types have this as a bigger issue.
The result is you end up with a lot of people filing tickets and writing emails, but very few actually doing work to fix things because they don't know how. The few that could figure it out, are probably over extended. Having non-programmers interested in helping isn't necessarily a bad thing since good support people help make it easier to fix issues, but it can become bad if support people bias to closing issues because they can't fix them and closing them becomes the goal.
Tor does have some obfuscation proxies (called pluggable transports) to try and disguise the traffic to make it harder to block (there were videos a few years ago when I looked into how Tor worked that talked about this, the traffic is disguised as VOIP among other things). I know China blocks Tor by blocking all the bridge nodes it can find (both public and private) and by using the tricks he describes to slow or stop identified traffic. I think the head of the project cares about these issues.
Not an easy problem to fix, they probably need more programmers. Maybe a direct focus on these issues would help, but it could be they're focused on problems of similar or worse severity (hard to know).
I think the author’s problem is that he finds vulnerabilities thinking outside the box. Traditionaly vulnerabilities exist when you can inject payloads, get access to somewhere you don’t have access to.
His points are valid, and these are vulnerabilities. However they seem like feature requests, rather than being focused on a technical vulnerability (for example use after free).
This plus the other descriptions/responses from the project in his post makes me think the project has attracted a lot of people that aren't programmers or can't actually do the valuable work of fixing the thing (though I'd be interested in seeing the specific ticket).
I'd guess that projects like Tor that interest people outside of strict programmer types have this as a bigger issue.
The result is you end up with a lot of people filing tickets and writing emails, but very few actually doing work to fix things because they don't know how. The few that could figure it out, are probably over extended. Having non-programmers interested in helping isn't necessarily a bad thing since good support people help make it easier to fix issues, but it can become bad if support people bias to closing issues because they can't fix them and closing them becomes the goal.
Tor does have some obfuscation proxies (called pluggable transports) to try and disguise the traffic to make it harder to block (there were videos a few years ago when I looked into how Tor worked that talked about this, the traffic is disguised as VOIP among other things). I know China blocks Tor by blocking all the bridge nodes it can find (both public and private) and by using the tricks he describes to slow or stop identified traffic. I think the head of the project cares about these issues.
Not an easy problem to fix, they probably need more programmers. Maybe a direct focus on these issues would help, but it could be they're focused on problems of similar or worse severity (hard to know).