21–30 of 67 posts
To me this just seems pointless because an implementation in Rust is going to have similar features to one in C, Java, Python, or any of the handful of languages where Tor already exists... I want to rep another project that I think would be more relevant to Tor's goals. It is unfunded yet should it exist: would have the potential to transform privacy on the web. The project is https://github.com/Ayms/node-Tor It's a…
Very cool, I fully support this and I plan to experiment with it. The developers should be proud of making such exciting progress. But doesn’t “ready for production use” sound like hyperbole when the blog post describes a partially completed implementation? It can’t even connect to onion services yet. Similarly, “improved security” is a suspect claim to make when comparing brand new software to a battle-tested codeba…
Earlier quoted context omitted.
Their goal was to increase security more than speed.
Yup, the core part of Tor is written in C so it can't get much speedier. Rewriting it in rust is almost is entirely to reduce the footguns you get in C
It's interesting that the funding for this came from the Zcash Community Grants. There's a lot of money involved with cryptocurrency and a lot of it gets invested into the software involved. It's interesting that in this case, serious money got invested into some software that isn't strictly cryptocurrency-related and is useful outside of cryptocurrency. It makes me wonder if there are other software projects that ar…
react-grid-layout is written and maintained by cofounder of bitmex.
uWebSockets, one of the fastest ws servers, is mainly makelt afloat by crypto exchanges who make use of the author‘s consultancy service.
This project has come a long way, very fast. Great work to all involved. The biggest security holes in Tor are most likely going to be from the browser going forward. Hardening the browser is tough, but that's a win for everyone (including those not using Tor). This sentiment was one that I shared in my Rust work: > the pickiness of the compiler has been a great boon. Generally speaking, if our Rust code compiles and…
I have a question, can I use tor as a middleware? for example, can I build a social network with Tor embedded into the client as the network layer?
This is the most interesting part of this announcement for me:
>> You can test Arti ... as an embeddable library (if you don't mind a little API instability).
My first thought was adding Tor as a transport for TCP DNS resolution for an existing recursive resolver like unbound. Or, a TOR proxy for DoH public recursive resolvers. Either would result in better privacy than directly using a centralized public resolver with DoH. For the former, you would need to send the query through multiple circuits to have confidence that a guard or an exit node wasn't modifying the query/result (with all exits for a particular query in the same country to minimize geo DNS load balancing causing different results-- this level of control would be easier with a library than a separate daemon communicated through via socks. For the latter, using a socks proxy would work, but the library would make for a simpler setup for the user.
Too bad rust doesn't really do dynamic linking. 'libtor' as a distribution maintained library that is automatically kept patched for security vulnerabilities would add piece of mind when running applications that embed Tor.
Using a unix domain socket for a client in a private network namespace with no network interfaces is a nice extra layer to ensure no IP leaks. The regular Tor daemon has supported this for a few years now.
To me this just seems pointless because an implementation in Rust is going to have similar features to one in C, Java, Python, or any of the handful of languages where Tor already exists... I want to rep another project that I think would be more relevant to Tor's goals. It is unfunded yet should it exist: would have the potential to transform privacy on the web. The project is https://github.com/Ayms/node-Tor It's a…
Sometimes it's better to have no security software and fully understand the implications than to have a security software with bugs unknown to you, which are tacitly exploited by your adversary.
It seems the Rust people are especially prone to re implementing things. Nothing is really created, just reimplemented.
It seems the Rust people are especially prone to re implementing things. Nothing is really created, just reimplemented.
I am happy for most software to move from C into almost anything else. Something unlikely to have memory exploits, or with standardized tooling for dependency management and compilation.
- There are no dynamic binaries. Everything it's static. But binaries and the userland are tiny and usable.
- Cross compile it's dumb easy. [0-9]c, one number per arch.
- Every OS comes with compilers, libraries and sources for every arch.
- Security it's handled by separated modules, a password/login daemon/server and namespaces. Totally different. That will be the future in 10 years, and not Rust.
> Development of comparable features has gone way faster, even considering that we're building most things for the second time
> Portability has been far easier than C
> We've found that Arti has attracted volunteer contributions in greater volume and with less friction than C Tor
Wow