Main menu

Crowdfunding the Future (of Hidden Services)

Hidden Services have received a lot of attention in 2015, and Tor is at the center of this conversation. Hidden Services are a Tor technology that allows users to connect to services (blogs, chats, and many other things) with neither the user nor the site giving up identifying information.

In fact, anything you can build on the internet, you can build on hidden services. But they're better--they give users things that normal networking doesn't authentication and confidentiality are built in; anonymity is built in. An internet based on hidden services would be an internet with Tor built in--a feature that users could take for granted. Think of what this might mean to millions of users in countries like China, Iran, or the UK. Yet currently, only about 4% of Tor's traffic comes from hidden services.

So we at Tor have been considering how we might meet the challenge of making them more widely available. In this post, we will briefly discuss the role of hidden services before we explore the idea of using crowdfunding to pay for bold, long-term tech initiatives that will begin to fulfill the promise of this technology.

Hidden Services are a critical part of Tor's ecosystem

Hidden Services provide a means for Tor users to create sites and services that are accessible exclusively within the Tor network, with privacy and security features that make them useful and appealing for a wide variety of applications.

In addition, developers use hidden services as a building block to incorporate Tor's security and anonymity features into totally separate products. The potential of hidden services is huge, and much of it is yet to be explored.

Next Steps for Hidden Services

We want to make this technology available to the wider public as these services will play a key role in the future of secure communications. This means that we must increase the uses for hidden services, bring them to mobile platforms for anonymous mobile apps, and vastly increase the number of people who use them.

Since our goal is wider use, it is imperative that we build them to be more secure, easier to set up, better performing, and more usable. Clearly, the questions that we answer in early deployment efforts will inform how we answer the deeper questions pertaining to massive worldwide deployment.

We must engage a large number of people to bring hidden services to the next level. Until now, hidden services development largely relied on the volunteer work of developers in their spare time. This will not be sufficient if we are to make the leap to transformative hidden services.

We are currently evaluating funding strategies that will support our Hidden Service initiatives in the short-, intermediate- and long-term. In order to fit the requirements more conservative large funders have, so we can fully sponsor the Next Generation Hidden Services, we must put preliminary pieces in place. And for that we will reach out to crowdfunding. To do this right, we need your feedback.

Why Crowdfunding?

Crowdfunding allows us to engage the broader community in grasping the opportunity that this new technology promises. We are confident that we can deliver significant advancements in the hidden services field in the short-term, and that many small donors who understand their context will be eager to contribute. We intend to begin by prioritizing the improvement of the security, usability, and performance of the current hidden services system.

Further, we want to make sure we support the efforts of community projects and that the community is participating in shaping the evolution of hidden services. For example, it would be important to assist and improve the Tor integration of projects such as SecureDrop, Pond, Ahmia and Ricochet. We are in the unique position to be able to shape the Tor protocol to make these projects easier to use and better performing, and we would like to identify ways to promote broader deployment of these projects.

Identifying, prioritizing and meeting future challenges will require engagement throughout the greater community. For instance, as changes and enhancements are introduced, we hope to speak with the best bug hunters, cryptographers and privacy experts and ask them to audit our code and designs. Non-technical users could help us evaluate the usability of our improvements.

For this crowdfunding campaign we have identified a few possible ideas-- but the point of this post is to ask you for yours. Here are three projects that we have come up with so far:

Information Panel for Hidden Service Operators

An application that Hidden Service operators could use to learn more about the activity of their Hidden Service. The operator would have access to information on user activity, security information, etc., and will receive important system-generated updates, including log messages

Tor has been at the center of hidden services from the beginning. We have big lists of changes we need to do to the Tor protocol to increase the security of hidden services against cryptanalysis, DoS and deanonymization attacks. We also want to improve guard security, allow operators to store their cryptographic keys offline and enable scaling of hidden services to new levels. This is a big project but we hope to start crunching through it as part of this crowdfunding campaign.

Your Idea for Hidden Services?

Long story short, we are looking for feedback!

What hidden services projects would you like to see us crowdfund?

How do you use hidden services; what makes them important to you? How you want to see them evolve?

We'd love to hear your ideas on picking crowdfunding rewards and stretch goals.
Also, we are curious about which crowdfunding platforms you prefer and why.

In the following weeks, we will update you on our progress, incorporating feedback we receive from the community. We hope to make this process as transparent and public as possible!

Thanks!

EDIT: The "Unhidden Services" paragraph was expanded and changed to "Fast-but-not-hidden Services". The previous name was too scary and the description not sufficient to show the potential of the project. Please send us better names for this feature!

We meant services like Facebook or reddit, who don't care to hide their servers, but they would still like to offer high security to their clients. If Reddit had an unhidden service, it could ensure that clients who reach the Activism subreddit are always protected by Tor (and hence they are anonymous, and have server authentication without relying on SSL CAs).

I'm not sure how that would open the door to further network/traffic analysis. Please expand further?

I dont really see this happening the unhidden services. These site block tor for a reason and allowing users to use tor wouldn't it just create spam and people to post Child porn and other illegal things?

Child porn is just your government's way of telling it is good to look at your business and see if someone put stuff on your machine that violates their laws and arrest you if true. This makes child porn a way to violate all the laws restraining your government from prying into your business and framing its citizens for "crimes" against humanity (called PORN) while ignoring their own.

Their solution is more obscene and kills more children than the problem they purport to solve by removing your freedoms to prevent you from viewing porn.

If you wish to really impact children's lives I suggest you campaign against slave child labour in products like chocolate, sugar, coffee and the like sourced from countries like the Ivory Coast or simply not purchase these where not ethically sourced.

Porn is an easy 'take down' but usually involves repression of everyone's Rights, Liberties ETC. These types of regimes are usually so corrupt that child sex slavery including porn becomes rampant.

Personally, I preferred the older "G" rated tele with enforced standards and clean messages. It seems to be something that we may never go back to again. Tragic.

Anyway, freedom from Big Brother is the reason many choose to keep their lives free from observation, even if they have "nothing to hide" as I tend to think to be my own case.

To answer your question directly: Yes some perhaps many pedophiles will hide behind TOR. I hope TOR PREVAILS OVER BIG BROTHER, EVERY TIME!
With drugs science has proven that the attempt to ban drugs has the paradoxical effect of greatly increasing usage. I am sure that this is likely true of photo pedophilia as well.

The article is really not clear on the distinction between anonymity of the operator and anonymity for the end user. EG under "fast but not hidden services" - "hidden services that don't care about anonymity but still want to protect their clients with Tor's cryptography and anonymity" is confusing.

We updated that paragraph to make it clearer what that feature is about. It's an optional feature that hidden services have to enable explicitly, and it's only suited for hidden services like Facebook or reddit who don't care about anonymity.

While those services might not care about their own anonymity, they care about the anonymity of their clients and that's preserved with that feature. Please let us know if you have more questions about this feature and how we can make it clearer.

I am very interested in seeing Hidden Services developed as a replacement for SSL. The Certifying Authority system for SSL is both a significant barrier to use (i.e. needing to pay and/or meet certain requirements for cert issuing) and ironically a security problem (compromise of any one of hundreds of CA's can break the entire system).

While higher-performance hidden services would help towards this goal, the main issues I'm, personally, most immediately concerned about are availability (i.e. being able to host a single service on multiple machines with some kind of failover) and security (i.e. using more than 80 bits of an antiquated RSA key as the means of authenticating the server).

That's really a separate problem: tying keys to names. You might want to do that with or without Tor.

But I do agree that it would be nice to have Tor do it in a generally useful way. Maybe Tor could adopt one of the decentralized naming schemes that get proposed periodically, or create a system that was also useful outside the Tor network. People propose things like that from time to time, but there's no critical mass behind them. Tor could help, especially if other projects could be gotten on board as well.

There've been several proposals to add a DNS TLD where the next level names were just key hashes, similar to .onion addresses. That's the decentralized-secure edge of Zooko's triangle for global naming systems. The DNS servers for such a zone could even just be front ends to a DHT... and something like Tor could go around DNS entirely, and find data in something like the existing hidden service lookup system, or directly in the same DHT that also served DNS.

You could imagine a future world where a TLS layer knew to check the peer's key directly in the name, or where the DNS layer knew to check DNSSEC keys (and thence DANE and thereby TLS keys) against that name.

There are also decentralized FCFS systems like Namecoin that are a little hard to put on the perimeter of the triangle; they sort of trade off human meaningfulness against strong assurance that the "Joe" you're talking to is really the one that everybody else calls "Joe".

Or I guess you could just punt to local nicknames like I2P... but I2P's names aren't so "local" or decentralized in practice...

I actually really like tor's naming system as it is right now. It's currently the only decentralized-secure naming system at the moment that I'm aware of for general low-latency use, such as web hosting or running an SSH server; others like bitcoin, bitmessage, and PGP are more specialized. I wouldn't be against adding another naming system as an overlay, but I'd really like to leave the existing decentralized-secure option in place.

It might not be bad to offer an option to clients to choose from a few different levels of security. For instance, onion addresses could be expanded to 32 characters (160 bits), but only the first 16 would be required; a truncated address would just be compared against the equivalent number of characters from the "real" address. To do this, the 80-bit prefix would be still be the way that onion services are identified, but the client could do additional validation based on the longer address after the circuit is established.

It would also be nice, if we lengthen the service addresses to accomodate more security, to allow hyphens or some other divider character in the name that will be ignored. This would allow names to be more memorable, even in their current form. These characters should probably be stripped off in the TBB from any Host: headers, at least, to resist using them as a client fingerprinting side-channel. There is precendent for this sort of thing: gmail ignores periods (.) in the "username" portion of its email addresses.

One of the tricks I use to make a decentralized-secure address a little more human-memorable is using a vanity address generator like shallot. Specifically, rather than just choose a name prefix (leaving users to painstakingly memorize the suffix), the regex I use is a global heuristic to try to make the address into a pronounceable "nonsense word" for speakers of a particular language (English, in my case). Depending on how your memory works (i.e. "visual" thinkers vs. "auditory" ones), these may be easier to memorize.

A hidden service aimed at cyber dissidents would be interesting. But I am not sure what features would really be useful. What do cyber dissidents need? I guess, a way to get their message out safely and securely.

What I know, which is not very much, is that wordpress over tor is the recommended way to publish anonymously online. Putting a blog on a hidden service itself is not useful since so few people would actually be able to read it... Similarly I suppose if someone has a message to get out, they would probably want to be active on social media, FB, twitter etc. They would use tor to protect their identity but publish their message publicly.

So what would be useful for this? All those tools are usable through tor, but we still have the usual pattern of life, and traffic correlation problems. Particularly in small countries with government owned ISPs, sending lots of packets out over tor at the same time that dissident X is posting to facebook is dangerous. A Bharaini dissident who always posts at certain hours of the day may also be determined to be an exile living overseas in timezone Y based on when they post.

This got me thinking about tools that can solve pattern of live and traffic correlation. There are social media tools like hootsuite (works over tor) which let you post asycnronously and on a delayed schedule. But this is only a partial solution for cyber dissidents. The traffic going to hootsuite over the clear net is presumably still vulnerable to traffic correlation for example. Using it to compose and publish blog posts for wordpress is hard / impossible based on a few small experiments that I did.

So what I think would be nice is a hidden service with some basic functionality like hootsuite - posting to twitter, wordpress, facebook etc, from a hidden service on schedule or with delays built in. If tor people can convince hootsuite to run a basic hidden service themselves then great. Otherwise someone might like to build one. Facebook as a hidden service is an obvious nod to the usefulness of this. Whether or not twitter, wordpress etc would like to recieve API calls from a hidden service is a potential issue, but since people can use their services over tor, perhaps not. (I know there have been some reports about tor users being blocked from registering for twitter without a phone number but my own testing indicates that this is false).

Hidden Service made easy in default Tor Browser for all platforms would be quite useful! Provide share a specific folder as simple file share over onion to more complex auto-port mappings to local and LAN resources.

I would also like to see ORCHID v2 style IPv6 tun style access via onions. An entity identifier overlay like ORCHID would also ease a transition from current hidden service key lengths to newer schemes by providing consistent network semantics to users and applications.

Obviously, many devils in these details; the above would greatly soothe my druthers :P

A great security problem is that private key must be on machine where hidden service is running. Would be nice if this was fixed without having to port forward. Each client could be assigned a guid and hidden service operator could sign the hidden service packet and allow this guid to receive data from its hidden service address.

John Locke and other writers hallowed in the tradition of enlightenment moral philosophy on which "Western" legal traditions are based would advise us, under such conditions, to use any means necessary to defend ourselves against such lethal enemies. I am not yet prepared to go quite as far as Locke was, but I certainly think all dissidents urgently need various defensive tools, by which term I mean to include

* knowledge
* techniques
* software
* hardware

> What do cyber dissidents need? I guess, a way to get their message out safely and securely.

And many more "specialist items", such as

* tools to detect possible IMSI catchers in use
* tools to detect possible attacks on WiFi networks (e.g. replay attacks, attacks gathering ivs for offline cryptanalysis)
* tools leveraging COTS items to detect suspicious RF transmissions (see the ANT catalog for how NSA uses of retro-reflectors) and other evidence of buggery
* tools to provide defenses against stylometry
* more and better stenographic tools (for example, modify the brush pass so that two people on a commuter train can unobtrusively pass a deniable encrypted message using their smart phones, without saying a word, perhaps using existing NFC capabilities)
* cheap reliable clandestine GPS bugs activists can attach to the undercarriage of police surveillance vehicles; they track us, why shouldn't we track back?)
* tools to detect (and maybe to disable/hijack) surveillance drones; this could include a project as "simple" as the equivalent of a bird guide for visual observation
* tools to detect WiFi mesh nodes being used to inventory all WiFi capable devices in urban areas
* tutorials on defensive measures against various threats
* tutorials on counter-surveillance in the 21st century
* advice from psychologists on detecting and resisting techniques used by GCHQ to "disrupt" the social functioning of dissident groups
* the same, for techniques used by trained infiltrators (beyond such obvious things as: don't go out drinking with other activists)
* the same, for foiling "predictive analysis" behavioral modeling (US agencies run supercomputer models including every person in entire countries, plus their interactions with government, NSA, and economic forces, in order to decide who to harass/arrest/kidnap/kill).

Plus items we all need, such as

* more secure COTS routers, printers
* upgradeable cryptographically signed firmware for Linux
* more and better encryption (alternatives to AES vital in case we learn that NSA has cracked AES by exploiting its unique algebraic structure; see Bruce Schneier's comments)
* more and better Tor
* more Tails for smart phones
* more secure DNS, TLS
* more intensive and extensive auditing of privacy/anonymity tools
* more and better theory relevant to anonymity

Specifically hidden service related ideas:

* hidden services acting as honeypots for agencies tasked with infiltrating dissident groups, implemented with the specific aim of capturing "watering hole" type malware planted by global intelligence agencies like FBI, with the intent of passing samples to groups like Citizen Lab for reverse engineering and publication

* hidden services masquerading as fun websites where people exchange innocuous computer art (unique and metadataless so our enemies have nothing to compare with) which contain short steganographic messages

* lots and lots of truly innocuous websites briefly put up as hidden services, to make a point and also to make things harder for global intelligence agencies seeking to hack all the worlds hidden services

* tools allowing people to temporarily create hidden services to share info with a very small number of persons who each receive a share of a secret (via Shamir's secret sharing scheme based on polynomials for example)

* hidden services offering current Tor and citizen cryptography to people who have an older version and want to get the latest, for dissidents who live in nations where Tor and unbackdoored crypto is effectively illegal; Tor users need to prepare now for how to obtain these items essential for life in case they become illegal where they live.

Please note that France, UK, USA are all very close to joining Belarus as nations where Tor and unbackdoored crypto is effectively outlawed. (See for example proposed changes to Rule 41(b) of the Federal Code of Criminal Procedure in the US, which will explicitly allow FBI to hack into any computer anywhere in the world, unless the US Congress takes action to stop it.)

Police and intelligence agencies all over the world are treating all of us like terrorists or spies. Please note that just because you live in Brazil (say) does not mean that US agencies are not spying on you at every turn. So it is all of them against all of us.

It seems reasonable, in the spirit of John Locke, to conclude that such treatment forces us all to damn well behave like (genuine) highly trained professional espionage agents. When everyone behaves like a trained espionage agent (in terms of evasion, deception, and communication techniques, not in terms of violent acts), the surveillance state will collapse under its own weight. Only then will governments acknowledge the painful necessity of seeking political solutions, rather than simply "managing" dissidents by spying, stealing, harassing, and killing them.

A good historical perspective on the global nature of the epic struggle between the forces of freedom and the forces of oppression in which we are all immersed (whether we choose to acknowledge this or not): Jay Winik, The Great Upheaval, Harper, 2007.

The sad irony is that we rebels actually believe in the Rule of Law and in the notion of government of the People, by the People, for the People.

Dr. Franklin, Col. Washington, and others wouldn't give the time of day to anyone who talked rebellion in 1770. By 1775 their minds had been changed, by the foul and foolish actions of the "legal" government in America. Jay Winik's book is well worth reading.

I'm still thinking about a YouTube/Twitch clone that can't be taken down as a HiddenService.. Preferable with P2P load balancing(once WebRTC works without leaking) and short lived automatic 48h take down to avoid legal trouble (*but with the HTML5 download/save option intact).

The idea would be to make any video available to anyone, regardless of the political situation/censors and integrate it with Android to upload/steam live Video without immediately reveling the source(*keep in mind: if they film you they can always see your camera or triangulate your filming position later, they are only limited by not censoring you).

However there are still so many technical obstacles in the way of this, last time i checked, that just i guess just doing some more research and fixing WebRTC through Tor would be enough for now.

Another very important subject was not mentioned yet: even if hs will be secure and stable - what will run securely ON it? We stay with good old HTML and maybe dare to use some PHP? I am thinking here not only about the well known risks like using Java platforms or JS and its countless frameworks, but also about the serious concerns regarding HTML5 and other new standards and protocols. In my opinion securing hs is only a solution for half of the problem, to protect the hs visitor remains a huge challenge.

Since more than three years I am testing various tor based solutions in order to find a reliable hs platform, together with some open source site packages on it that offer still some acceptable usability with JS turned off - the available choice goes down to close to zero.

To bring up hs to a secure level is an urgent task and an absolute must. Tor may not become just a network fore safe communication - it has to become also a platform for safe publication of information and access to it.

Think OpenBazaar but builtin to Tor. Relays could have a data-store element that much like freenet that allows a service operator to offload processing and storage to relay operators who opted-in. This would in effect completely take the crosshairs and bottlenecks off a single server and move it across the network, albiet perhaps with a slight delay. Given that any info a relay would hold would be encrypted to prevent tampering a service operator could safely store any info across the network, and as its distributed things like ddosing and relays going offline would not bring a service to its knees as we are seeing now.

Im reading in these comments the idea of distributed hidden services being brought up, however the larger implications of "how" this would realistically work given the limited resources of Tor must be considered. Granted by and large relay operators pay for both bandwidth and storage space as part of the package deal that comes with renting a server but only use the bandwidth element as there is no storage consumption with Tor currently, the potential storage capacity of a Tor-relay datastore is immense, but how would this work?

Lets say we adopt freenets model, where there needs to be some redundancy to ensure data is not loss should relays go down. This now sets the total storage capacity from 1-50% of the total storage on hand at any one moment depending on the level of redundancy mandated by the network, this already limits the network greatly.

An attacker wants to knock a large hidden service offline, or at the very least cause dataloss. They proceed to ddos the network not with connection attempts to the hidden service as with traditional ddos, but instead to setup their own hidden service and fill it up with junk data that would in turn flood the network of redunant relays knocking everything else into the trash bin. Stop me here if freenet has already found a solution to this, im sure they have but lets say their solution doesnt work for Tor (freenet is horrendously slow for a reason...)

Perhaps a wholly distributed model isnt the best approach for a low-latency network. A better approach would be a "money-where-your-mouth-is" model, whereby a HS would still operate as a singular server, whose datastore would be in turn mirrored by various relays that would in turn syncronize with the server based on most frequently accessed data. So in this way a HS could be "distributed" in its ability to field requests for data while remaining centralized so that there would be no chance of dataloss or loss of service due to a reliance on the network itself.

This would in effect act like a temporary distributed datastore, whereby relays would mirror and serve an HS's data by frequency of requests, dataload, in effect popularity. The bigger question however is how exactly is a relay supposed to know a request is destined for a HS given the design of Tor? Could the HS itself forward its excess requests to a relay who would be handling mirros of its most recently requested data? Could this be done in a way that keeps the traffic encrypted so as to ensure its integrity? Does this solve the problems of a HS being DDOS'd (that is its ability to handle a number of requests) or just the issue of it hitting its bandwidth cap?

Mixing low latency with high latency anonymity is something that we've also been looking into. We understand that low latency anonymity has certain limits and we are curious to see if we can also offer higher latency options to users who are interested in more advanced security models. It would be interesting to explore such avenues through crowdfunding, but I'm afraid that the topic is too researchy to be crowdpleasing

I'm interested in using hidden services to hide my metadata. Specifically, I want a easy to use voice and text program such as TextSecure and Redphone, but with untraceable metadata so nobody can map my inner circle of family and friends.

By easy to use, I don't mean setting up SIP account username and passwords. Perhaps have the chat program automatically assign a hidden service address for each user, but somehow map the hidden service address to something more human readable/memorable.

The program would have to work on mobile phones, because the only thing people carry with them everywhere they go is mobile phones. Not Desktops or laptops. Otherwise the chat program would be near useless because your friends and family won't be reachable 24/7.

in my opinion and experience, I want to emphatically state that the most sensible uses for hidden services, especially if the future looks like an even grimmer version of today, are ANYTHING but web servers.

There is no good reason at all why static content, or content that is updated slowly and asynchronously, should have to be linkable to, or fully dependent upon (except for local mirrors), the up-times of a specific computer. I think the future of plain old web content lies in distributed, peer-to-peer structured storage systems where you, as a publisher, can periodically push signed updates. A concept for making that a fully practical replacement will have to be developed, though.

I tend to view hidden services as a logical replacement for a static IPv4 address or domain name, so one can regain the end-to-end principle even in a centralized, censored and balkanized internet. OnionCat, which probably many posters here know, makes this vision concrete by converting hidden service keys to IPv6 addresses.

I find short-lived HS a most convenient way for creating one-off synchronous communication channels with another party, such as onionshare, or telephony (for which no really user-friendly application exists yet, but which certainly works reasonably well in my experience). Long-lived ones are extremely useful for other things that can't be done asynchronously, such as accessing a machine via SSH and possibly tunneling some traffic through it.

So I'd say, less emphasis on the web hosting aspect, which is also the PR-wise most reviled aspect (but I'll gladly eat my words when the suggested load-balancing makes the next generation hidden services more attractive for this purpose again, and more interesting websites will move into onionspace :-) I'm in two minds about this really).

Re: Cheap off the shelf (COTS)
I am working with a Raspberry PI model 2B+. It costs $35.00. It comes with a quad arm7 processor and an awesome GPU, 1GB ram, 4 USB (which seems to be the main limitation of this platform), HDMI and PAL/ NTSC (with a special plug also not simultaneously), uses an micro SD card for OS.

I need a TOR BROSWER BUNDLE that makes the ABOVE SUGGESTIONS work for my Pi2. I would not mind a TOR replacement for a NOOBS that would not give up any info without the distributed password confirmation or perhaps not keep any at all.

Otherwise, I need tails that works for arm 7 quad core... ....

I also need details on how to compile from source TOR Browser Bundle and or TAILS. Alternatively perhaps someone could put it up as an alpha build.

It would also be wonderful for a tool that generated checks on builds as part of the building process for all to observe. I am referring to the hash (SIG/ signature(s)) that tells me that I have the genuine product(s). This would make everyone much more secure.

I need security to work like a toaster (push the button and it works) as much as possible otherwise it overwhelms me.

(Overwhelming those who use tor is an intentional goal of our governments. The idea seems to be that if security is at all difficult nobody will use it. ( They seem to be at least largely right.))

It seems that at least part of the TOR stream should reaffirm our rights to security in our private effects Declaring rights to freedoms as part of the communication streams. Declaring copyright. Declaring freedom of speech. Declaring freedom of association. Declaring freedom of... ....

Then if someone comes up in court they can ask if those who read/ wiretapped/ decoded the contents had considered the freedoms that were being trampled/ ignored.
It could be used to change the lengths of messages.

Allowing message path splitting could also be a function of TBB.

I would gladly give some pi computation time to a distributed tor service node(s) maybe 3 cores or several Pi2's. It is bandwidth pay for not computation.

How about distributed onion dns.

There is no reason I can think of for tor not to become the source of Certificate Authority in the onion realm. If we did a good enough job of it people might want ours more than the others.

I suppose a bounty on fixes (perhaps on tickets) which could be accepted/ declined by the solver(s) with the donor defining what happens to his bounty. In the example below ( A true statement of my needs),I would love to be able to offer a declining bounty by say 10% per month with the unused portion going to torproject and otherwise shared equally by all solvers. I would love to have others be able to join in with other amounts and payouts.

True Example:
I Can get Tor on my rpi 2 but cannot get my rpi 2 to use TBB ( the TOR Browser Bundle.)

While i am certain it is easy to do, I would gladly put up a bounty of say $50.00 for a simple command like
sudo apt-get install torbrowser
to work on my Pi2's. I suppose a bounty on tickets is what i am requesting.

It would have to work in Raspbian or be addable to NOOBS or have an image that could be burned to an micro SD. I am good with almost anything that tells me line by line what I must do. However, what i really want is a package that works in an efficient OS on my Pi2, that I do not have to particularly understand how it works while still keeping the adversary from peeping in to my business.
To this end, I need a browser and an anonymous email, with an rejection similar to the way I understand NOMOROBO.com works with calls in the US. However, I would pay out for just the browser bundle for now.

Since these RPI2's are very cheap and there seem to be about 2 million RPi2's out of the 5 million RPi's ( Total of all kinds)made to date i am sure that this should be a very quick fix. With 200k / Month being made there should be 2.4 million more made before Moores law requires an upgrade.

I like the comment on "decentralized publication system" which brings to mind the global need for Alternative Media and the tools to feed it (internal and external sourcing) and a structure to distribute.

Hi! There's a new alpha release available for download. If you build Tor from source, you can download the source code for 0.3.3.2-alpha from the usual place on the website. Packages should be available over the coming weeks, with a new alpha Tor Browser release some time in February.

Remember, this is an alpha release: you should only run this if you'd like to find and report more bugs than usual.

Tor 0.3.3.2-alpha is the second alpha in the 0.3.3.x series. It introduces a mechanism to handle the high loads that many relay operators have been reporting recently. It also fixes several bugs in older releases. If this new code proves reliable, we plan to backport it to older supported release series.

Changes in version 0.3.3.2-alpha - 2018-02-10

Major features (denial-of-service mitigation):

Give relays some defenses against the recent network overload. We start with three defenses (default parameters in parentheses). First: if a single client address makes too many concurrent connections (>100), hang up on further connections. Second: if a single client address makes circuits too quickly (more than 3 per second, with an allowed burst of 90) while also having too many connections open (3), refuse new create cells for the next while (1-2 hours). Third: if a client asks to establish a rendezvous point to you directly, ignore the request. These defenses can be manually controlled by new torrc options, but relays will also take guidance from consensus parameters, so there's no need to configure anything manually. Implements ticket 24902.

Major bugfixes (netflow padding):

Stop adding unneeded channel padding right after we finish flushing to a connection that has been trying to flush for many seconds. Instead, treat all partial or complete flushes as activity on the channel, which will defer the time until we need to add padding. This fix should resolve confusing and scary log messages like "Channel padding timeout scheduled 221453ms in the past." Fixes bug 22212; bugfix on 0.3.1.1-alpha.