Greetings to all developers! What do you think? BOINC - The Berkeley Open Infrastructure for Network Computing. https://boinc.berkeley.edu/ Technical wiki: https://boinc.berkeley.edu/trac/wiki/ProjectMain BOINC -> VirtualBox -> operating system with running Tor relay. Real working solutions? Yes: http://atlasathome.cern.ch/ http://lhcathome2.cern.ch/vLHCathome/ Platform diversity in Tor network may be solved by preparing images with different operating systems. The power of the Tor network may grow very quickly. Fastes reaction to Security vulnerabilities. All client will upgrade Tor images by administrator command. (all images should be signed ofcourse. It is the BOINC principle). You are doing a great job. Thank you! -- Best regards, Sergey
On 20 Jul 2015, at 06:30 , Serg <std.serg@gmail.com> wrote:
Greetings to all developers!
What do you think? BOINC - The Berkeley Open Infrastructure for Network Computing. https://boinc.berkeley.edu/ Technical wiki: https://boinc.berkeley.edu/trac/wiki/ProjectMain
BOINC -> VirtualBox -> operating system with running Tor relay.
Real working solutions? Yes: http://atlasathome.cern.ch/ http://lhcathome2.cern.ch/vLHCathome/
I think you may have confused VirtualBox with a "virtualisation layer" - or is VirtualBox how these projects implement virtualisation?
Platform diversity in Tor network may be solved by preparing images with different operating systems.
Well, this won't work for OS X or Windows for licensing reasons. (Not that many will care, I suspect.) But Linux/BSDs/... (even OpenDarwin) should be fine.
The power of the Tor network may grow very quickly. Fastes reaction to Security vulnerabilities. All client will upgrade Tor images by administrator command. (all images should be signed ofcourse. It is the BOINC principle).
None of the current projects on the BOINC website are network-based, instead, they use volunteers' spare CPU/GPU cycles. I remember there being a BOINC-based ping/download tester to map the internet at one point. Was it a success? Did people understand it would use network bandwidth? Were users happy with the outcomes? How do you plan to map ports on NAT devices? Eliminate relays with poor bandwidth? Support users? Teach people how to run a secure server? (This is the show-stopper for me.) Unfortunately, unlike Bitcoin Utopia, the Tor project really can't make much use of volunteer CPU cycles, in the absence of good network connectivity and secure server admin experience. http://www.bitcoinutopia.net/bitcoinutopia/ Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com pgp ABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
20.07.2015 2:06, teor wrote:
I think you may have confused VirtualBox with a "virtualisation layer" - or is VirtualBox how these projects implement virtualisation?
I mean Oracle virtual machine, its open source part. But, in general, any stable virtual machine may be suitable.
Platform diversity in Tor network may be solved by preparing images with different operating systems.
Well, this won't work for OS X or Windows for licensing reasons. (Not that many will care, I suspect.) But Linux/BSDs/... (even OpenDarwin) should be fine.
Yes, agree.
None of the current projects on the BOINC website are network-based, instead, they use volunteers' spare CPU/GPU cycles.
Non-CPU (or GPU) intensive project are not so popular probably, but they exist: Radioactive@Home, Quake Catcher Network, WUProp@Home. The Majestic-12 project is the internet traffic intensive web crawler.
I remember there being a BOINC-based ping/download tester to map the internet at one point. Was it a success? Did people understand it would use network bandwidth? Were users happy with the outcomes?
Yes, it called DIMES. I don't remember more, sory.
How do you plan to map ports on NAT devices?
If it can't be done automatically using UPnP, This must be done manually. No alternative cases.
Eliminate relays with poor bandwidth?
I guess that the strategy test bandwidth is already implemented in Tor relays. Available bandwidth can be different at different times, regardless of runing under BOINC. Any tests which can be automated, can be performed after the launch of the virtual machine, but before the relay software starts.
Support users?
Teach people how to run a secure server? (This is the show-stopper for me.)
The basic idea is that users running preconfigured secure server. BOINC downloads its as virtual machine image. Virtual machine gives secure sandbox to run relay. -- Best regards, Sergey
On 19 July 2015 at 20:11, Serg <std.serg@gmail.com> wrote:
The basic idea is that users running preconfigured secure server. BOINC downloads its as virtual machine image. Virtual machine gives secure sandbox to run relay.
I've set up and run BOINC tasks before. Unless something has fairly significantly changed, BOINC is really designed for discrete tasks. Get some data, do some processing/networking stuff, upload the result. Tor is designed as an always-running daemon - it never 'completes', and it doesn't chunk well. While relay capacity is always welcome, main forms of participation (Guards, HSDirs, being in stable circuits) require running for an extended period of time with very good uptime. -tom
20.07.2015 16:17, Tom Ritter wrote:
I've set up and run BOINC tasks before. Unless something has fairly significantly changed, BOINC is really designed for discrete tasks.
BOINC is used for discrete problems in many projects, but it has no limitations to run long tasks. It can be run as a daemon and work indefinitely. BOINC - standardized platform for all projects that attract A volunteer computing resources. There are no other restrictions on the type of project. Please look at CERN's BOINC-Projects. They run a virtual machine with the Linux and BOINC is only used as a wrapper to controll working and view a progress. Indeed, Tor relay does not need to BOINC technically, but BOINC provides hundreds of thousands of volunteers the opportunity to participate in the project by a simpliest way. -- Best regards, Sergey
On 20 Jul 2015, at 11:11 , Serg <std.serg@gmail.com> wrote:
How do you plan to map ports on NAT devices?
If it can't be done automatically using UPnP, This must be done manually. No alternative cases.
Our experience is that most routers' UPnP / NAT-PMP implementations don't work well with (our) automated tools. So this would have to be done manually, significantly reducing the pool of available volunteers.
Eliminate relays with poor bandwidth?
I guess that the strategy test bandwidth is already implemented in Tor relays. Available bandwidth can be different at different times, regardless of runing under BOINC. Any tests which can be automated, can be performed after the launch of the virtual machine, but before the relay software starts.
No, the Tor network does not currently eliminate relays with poor bandwidth or poor uptime from the consensus. (As far as I recall.) Therefore, a BOINC-based, or other widespread project, runs the risk of bloating the consensus with low-uptime, low-bandwidth, or asymmetrical-bandwidth relays.
Support users?
Teach people how to run a secure server? (This is the show-stopper for me.)
The basic idea is that users running preconfigured secure server. BOINC downloads its as virtual machine image. Virtual machine gives secure sandbox to run relay.
I don't think we're talking about the same kind of security here. Who will: * configure the relay bandwidth limits and various other options for the context? * fix the relay when it breaks? * monitor each virtual server for suspicious activity? I don't think the average BOINC volunteer has these skills. That said, a similar project deployed Tor bridges on Amazon EC2 using a preconfigured image. It was discontinued as it was unmaintained. Why not create a Tor bridge image, which tests for bandwidth and uptime (is this possible?), and then starts Tor once certain basic criteria are satisfied? The image could then be distributed via Amazon EC2, other VPSs, and maybe even BOINC. (And if a user has the bandwidth and uptime and skills to run a relay, they can edit the torrc to make it a relay.) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com pgp ABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
On Wed, 22 Jul 2015 01:06:41 +1000 teor <teor2345@gmail.com> wrote:
On 20 Jul 2015, at 11:11 , Serg <std.serg@gmail.com> wrote:
How do you plan to map ports on NAT devices?
If it can't be done automatically using UPnP, This must be done manually. No alternative cases.
Our experience is that most routers' UPnP / NAT-PMP implementations don't work well with (our) automated tools. So this would have to be done manually, significantly reducing the pool of available volunteers.
Just chiming in here. This may well work for a good number of users, but the support overhead for when it fails is utterly gigantic because certain brands of consumer routers have extremely poor UPnP/NAT-PMP implementations. The usual symptom of a poor implementation is "the router crashes" but certain other behaviors have been documented in the past by people trying to use UPnP in ways that are spec compliant such as "the router crashes and requires a NVRAM reset", "random port mappings get obliterated", "the UPnP/NAT-PMP stack on the router crashes" etc. A bigger issue is that a lot of consumer grade routers have a very limited amount of NAT session tracking space (in terms of absolute number of connections), which makes machines behind such devices extremely poor Tor relays (and even worse Guards)[0]. -- Yawning Angel [0]: In an ideal world every relay should be able to handle having a TCP connection open to any other relay simultaneously, plus connections from clients if they are guards, since relays do not get to choose their peers. Relays that fail to meet this criteria are (IMO) harmful to the health of the network.
participants (4)
-
Serg -
teor -
Tom Ritter -
Yawning Angel