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.

For example, hidden services are currently used by activists and journalists to publish blogs--in anonymity and free from retaliation. They are used by NGOs to securely receive information on government corruption and injustice from concerned citizens. Newspapers such as the Washington Post, and human rights groups such as Amnesty International use them to receive leaked information. They are used by people looking for the latest cat facts, companies that want to secure the path of their clients or by people chatting securely and anonymously -- including at-risk journalists talking to sources.

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

  • Fast-but-not-hidden services
  • A way to set up public hidden services with improved performance but reduced server-side anonymity. Basically, hidden services that don't care about anonymity but still want to protect their clients with Tor's cryptography and anonymity, will be able to run faster since they don't need to protect their own anonymity. This is an optional feature that suits the needs of large sites like Facebook and reddit, and will make their hidden services faster while also reducing the traffic they cause to the network. Also by optimizing for performance in this specialized feature, we can optimize for security even more in the default hidden services configuration.

  • Next Generation Hidden Services
  • 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.
  • Feel free to use the comments of this blog, or contact us directly at tor-assistants@torproject.org. Also see our wiki page with more information!

    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!

    Anonymous

    April 01, 2015

    Permalink

    We know that the enemy has attempted to "herd" target Tor user populations, by influencing how circuits are chosen so that they wind up using entry and exit nodes both controlled by the enemy. I am not sure how much of a concern this is with current Tor, but if it is still a credible threat, I wonder whether working towards making all websites activists might want to visit into "unhidden sites" might help.

    Regarding hiding metadata: Riseup is experimenting with something which might help here, but an even easier step which I think could help a lot in keeping their new "black" accounts anonymous from all but the most determined enemies would be add a capability to the web mail where the user can request a random delay on the order of (1 hour, 1 day) before the email leaves the server.

    Anonymous

    April 01, 2015

    Permalink

    Another area where hidden services might help: bug reports.

    Thanks to Snowden, we know that the enemy monitors unencrypted bug reports and uses the information gleaned to attack specific users who report their system configuration in a bug report. Tails has an interesting response, which I don't think I really understand, but I believe one component of their "Whisperback" system uses a hidden service so that a user can send an end-to-end strongly encrypted bug report to the Tails developers. This would be very useful if

    * it were audited independently
    * the documentation were sufficiently clear that users have confidence they are using it correctly to obtain strong end-to-end encryption

    I think this system even when used correctly (which might not happen by default) might still be vulnerable to easy traffic analysis by the enemy (who can probably tell that a specific IP is using Tails and just sent an encrypted bug report). If not used correctly it can potentially reveal your identity and a lot of information about your system. I welcome correction from Tails developers if I got anything wrong (I probably did).

    I'd like to see Tor adopt a strongly end-to-end bug report system along those lines, possibly using hidden services and OTR chat connection instead of email, similar to the Tails preconfigured chat accounts but available in Tor Browser Bundle. It would be very useful to help the user generate strong keys (usual entropy source problem applies) for use one-time-only. This situation cries out for ECC (elliptic curve cryptography) using a non-NSA-weakened elliptic curve.

    Anonymous

    April 01, 2015

    Permalink

    For "making all websites" please read "make all websites into hidden services".

    Anonymous

    April 01, 2015

    Permalink

    Memorable addressses is a big game changer for hidden service usability. I hope there are plans to look into it as part of your next gen facelift.

    Anonymous

    April 01, 2015

    Permalink

    Hello! Thank you for a great technology! It saves my family members lifes for last 5 years (gangs are chasing us all that time, and Tor help us to hide). I want not only to get you some money, but also provide idea that can make Tor more secure.

    Multiple network connections
    In my opinion, one of the most dangerous attacks on the Tor network and hidden services is a data correlation attacks made by global observer. Today all the governments try to spy on internet communications. Sometimes same things can do botnet owners. So "global observer" is not a virtual thing anymore, and we can't simply close our eyes to that problem, and say "there are no protection form global observer, and nobody can do anything with it, but there are no global observers, so there are no reasons to fear". We need to have some additional protection.
    There are no solutions that can totally solve that problem for low-latency networks, but we can make such attacks much more harder and expensive. Widely discussed solution is to send garbage traffic to hide actual amount of transmitted data, but it dramatically increase network load. My idea is to split traffic and send it throw several independent internet connections, so MiM can't to know not only the message contents and destination, but also a total message size. There are several use cases:

    1. Advanced Tor user

    If observer controls exit relay or web-service (web-service hoster or hosters data-center is also a good choice), and can spy on user ISP traffic, he can easily correlate transmitted packets by size and time (and how many hops between user and service doesn't really matters). It's not a theoretical issue - Caché based spy equipment used in many countries can store all traffic of a whole town for hours, and easily process queries like "who transmit such amount of data at that time with such headers". If Tor will support multiple ISP connections, advanced users could prevent this type of attacks:

    1. <br />
    2. user<br />
    3. ISP-1 (e.g. Ethernet) - tor-node-1 - tor-node-4<br />
    4. ISP-2 (e.g. ADSL) - tor-node-2 - tor-node-4<br />
    5. ISP-3 (e.g. 3G) - tor-node-3 - tor-node-4 - tor-node-5<br />
    6. web-service<br />

    tor-node-4 in this case is not only a simple relay, but also a mixer/splitter, that construct requests coming from several connections, and split responses. So data packets size between tor-node-5 and web-service will not correlate to packets size between user and any of entry nodes.

    2. Hardened Hidden Service

    If observer controls hosting companies network connections (or data-centers), he can periodically send requests to hidden service from any computer, and check where packets of that size appears. Hardened Hidden Service can prevent it by using multiple internet connections:

    1. <br />
    2. hidden-service<br />
    3. WAN-1 - tor-node-1 - tor-node-4<br />
    4. WAN-2 - tor-node-2 - tor-node-4<br />
    5. LAN - another-server - WAN - tor-node-3 - tor-node-4 - tor-node-5<br />
    6. rendezvous-point<br />

    user requests and hidden service responses are splits by tor-node-4 and transfer throw several connections, so observer couldn't determine what server receive requests for hidden service and send a responses.

    3. 1+2

    1. <br />
    2. hidden-service<br />
    3. WAN-1 - tor-node-1 - tor-node-3<br />
    4. WAN-2 - tor-node-2 - tor-node-3<br />
    5. tor-node-4<br />
    6. rendezvous-point<br />
    7. tor-node-5<br />
    8. tor-node-6 - tor-node-7 - ISP-1<br />
    9. tor-node-6 - tor-node-8 - ISP-2<br />
    10. user<br />

    tor-node-3 and tor-node-6 are mixers/splitters.

    Summary: by providing ability to use multiple internet connections on clients and servers and mix/split traffic on relays, we can make data correlation attacks on Tor network much more difficult, so make it more protected against global observer.

    This basically is the concept of multi path tcp over Tor. A solution like this I tested successfully but depreciated it because it presents a major anonymity risk if used by some individuals only. But if implemented for everybody it will present a major breakthrough for Tor.

    Would "rubberhose" work for this allowing anyone to split up traffic into parts without accessing the message or knowing if the part of the message was even the whole message?

    Anonymous

    April 01, 2015

    Permalink

    I would like to see effort spent working on:
    1) Developing an RFC for DNS lookups of onion service addresses. Just like I request "A blockchain.info", I should be able to do "AONION blockchain.info"; just like I request "MX riseup.net" I should be able to do "MXONION riseup.net". This is not secure, no, but it's important (there should also be an easy way to manually specify onion service addresses, so security of DNS is less of a concern).
    2) Working on popular MTAs like sendmail, Postfix, Exim, qmail, etc. to add automatic delivery to an onion service, if the domain has one available.
    2.1) Working on popular MTAs to automatically generate an onion service address for receiving submissions from other MTAs (complementary to 2)

    Email is a surveillance goldmine. Even STARTTLS still gives up lots of metadata. It's time to pull the rug out from under these fuckers.

    Anonymous

    April 02, 2015

    Permalink

    I think TorProject should setup their own hidden service for the blog and main website. It would allow you to track issues for hidden services much easily. I would personally love to browse TorProject.org using hidden service.

    Show an example to the world guys. Torproject.org is more known than any hidden service.

    Hope to see this implemented.

    torproject.org actually DID have a hidden service, once upon a time. Alas, they decided to discontinue it for some reason.

    I miss the old hidden service. It was arguably the most secure way to get access to tor downloads, once you already had tor installed. SSL's promise of end-to-end security is too easily compromised by compromise of a CA; onion addresses do not suffer from this problem, assuming you can initially confirm the correct onion address.

    Running your own hidden services is also a good way to get some "eat your own dog food" cred, and to gain familiarity with some of the challenges of their actual use.

    unfortunately, I think the problem here is the lack of sysadmin time we have, and the effort required for maintaining the service. These are both crappy reasons and hopefully we will make a hidden service for the website and blog soon. A plethora of tickets have been created over time for this task (see #13829 and its comments).

    Anonymous

    April 02, 2015

    Permalink

    Funding might be simple if there were a torrency used for virtural payment. It would allow anyone to generate it. It could be donated to tor. It would also become valuable. It could be stored in distributed onionland.
    Or the user could print it out on paper.

    Anonymous

    April 02, 2015

    Permalink

    "In fact, anything you can build on the internet, you can build on hidden services."

    AFAIK, you can't build P2P (e.g. BitTorrent) on Tor, can you?

    Anonymous

    April 02, 2015

    Permalink

    Priority for needed project:
    a Secure Browser.

    Simple, secure by default, no addons, no "Firefox forces us to upgrade" nonsense by ARMA.

    In short, give all users the option of using the secure TBB you created for the US government and military.

    Anonymous

    April 03, 2015

    Permalink

    POSTNOTE Number 488 (March 2015), "The darknet and online anonymity", while generally favorable to our community, does contain one potentially alarming sentence:

    "The Executive Director of Tor Project Inc., Andrew Lewman, says he would like to intensify collaborations with LEAs and policy makers in the UK."

    I assume this means training LEAs not to just kick down doors to seize Exit nodes, but can Andrew please confirm it certainly does not mean "implant backdoors"?

    Are Roger and/or Andrew available to speak to US/UK lawmakers and their staffs?

    > In short, give all users the option of using the secure TBB you created for the US government and military.

    I for one don't know what you are talking about... unless... could you be thinking of Blackphone? That is a commercial product sold by a company, Silent Circle, which AFAIK is not affiliated with Tor (but Phil Zimmerman is a cofounder, so good for them!). Blackphones have been sold to the US DOD, which has also bought large numbers of a distinct phone made by Boeing, called simply "Black". See

    http://arstechnica.com/security/2014/06/exclusive-a-review-of-the-black…

    I hope key Tor Project people use Black phones, and lawmakers should use them too. The reasons why might be worth mentioning if Tor people speak to lawmakers.

    > Simple, secure by default, no addons, no "Firefox forces us to upgrade" nonsense by ARMA.

    Alas, security and anonymity issues tend to be very complex, and despite intense effort by many very smart people, any product which offers "complete security by default" is surely a scam.

    As Bruce Schneier likes to say, "security is a process, not a destination you can reach". The same could be said about achieving anonymity: it's something to work towards, and it's an arms race where sometimes the good guys have an edge and sometimes the bad guys get ahead.

    Because of the technical complexities, TBB developers leverage an existing and well-tested open source browser, Mozilla's Firefox, rather than trying to build something entirely from scratch.

    It indeed certainly does not mean 'implant backdoors'.

    Also, there is no separate "TBB we created for the government/military". There's only one Tor Browser, and it's on our download page.

    (I don't use a Blackphone, but then, I don't use a smartphone.)

    Anonymous

    April 05, 2015

    Permalink

    From the perspective of running and managing a Hidden Service I think giving us a channel that is scalable for managing authenticated users/groups would be a HUGE plus.

    HiddenServiceAuth combined with a Flat or SQLcipher database for user management.
    On signup to access my sites services/documents client receives HSauth address and can also "log in". If my server detects an attack coming from a specific client it can "de-authorize" or pause that specific user's or groups access. This would mitigate some types of DOS attacks and allow my server to "heal" or ban/delete users via script.

    Mainly we would need a way to API HSA or at least allow that feature to be pulled from a database versus the present method of implanting and generating them in the .torcc file. This has the added benefit of not being listed in the HS directory if I understand correctly.

    ====

    Second. It would be great to be able to use a Multi Signature Key like bitcoin as an option complimenting or extending a Hardware Key Manager HSM. What I am trying to get is a way to minimize server compromise or at least an easier way to deploy and distribute security via multiple Load balancers and servers which don't hold the privatekeys or at least all of the private key. This would leave a possibly .onion cloud hosted server with no key to compromise and blind only routing traffic to more deeply hidden servers over its own HSA channel.

    ====
    Tor Server Bundle!

    A hardened Hidden Service bundle similar to TBB or Whonix packaged with SQLcipher, PHP, specific cryptography libraries deterministic and contained. Easy Modes of operation such as Blog, Service/Market/Members, LoadBalance, TorVPN/SelfHosted Gateway, PrivateRelay/Bridges, OnionStorage, etc. With easy VPN attaching as well as pluggin to systems like Tails, Qubes, Whonix.

    The server should have a means to backup/store/serve easily via remote file hosting sites in darknet or clearnet (if held encrypted, provider has no knowledge). Bundle should also include BitID, SQRL, or a process like walletauthenticator for remote management access as well as possibly client signup and access. Self hosted 2-factor that is pretty easy and dummy proof.

    =======
    Knuckles
    BM-2cV8wSTcNZ76dPPTQNoCxNpSNi9hAfV6i5

    Thanks for the feedback.

    For what it's worth, we indeed have plans to improve the UI of hidden service authorization both on the server-side and on the client-side. We have already started doing some work on TBB for the client-side: https://trac.torproject.org/projects/tor/ticket/14389

    But we still haven't started specifying server-side improvements like the ones you suggested.

    Anonymous

    April 05, 2015

    Permalink

    Another way to probably get money for further development could be to integrate a blockchain namecoin type mechanism into Tor for HS easy name space allocation.

    A hidden service .onion or .tunion where users can do a traditional 16 bit or new base 32 bit address for free, but "register" shorter names for a small fee (towards Torproject and hosts of tor namechain) which acts as a DNS system in Tor. This should allow for drudgereport.onion/tunoin or any such name space association. Keeping Torproject out of the loop directly would keep them from getting sued when apple.onion goes live.

    Alternatively, a small fee and or proof of Relay/Bandwidth/Bridge/Exitnode could be used to purchase "names".

    Anonymous

    April 07, 2015

    Permalink

    Idea of useful feature for hidden services:

    Currently there's no functionality for indexing of existing hidden services

    Desirable functionality:
    When user decides to make hidden service, he/she decides whether to index his hidden service in search engines for hidden services.

    If user doesn't want to index his/her hidden service, then it leaves configuration option untouched, cause it's disabled by default.

    But if user decides to index his hidden service he/she enables it and puts next information in configuration file:

    [index_service]
    enable=on

    hidden_service_description="Short description of your site here"

    hidden_service_kewords="some, keywords, here, describing, your, site, and, what,is, for"

    index_services_addr="indexserver1.onion, indexserver2.onion"

    index_services_resend_interval=12 hour

    So, user's hidden service sends this information to given "index_services_addr" servers through Tor, which put this infomation into their DB and make this record available to users who search info.

    For this to be uniform, there must be uniform HTTP REST API on "index_service" part. It can be embedded in Tor or it can be application written on any language and which waits for REST API call on HTTP.

    Idea to think about is:

    How to determine/authenticate , that request for adding/updating record for "somehost1.onion" goes from "somehost1.onion" owner and not from some other malicious person, which is not the owner of the hidden service.

    What are you talking about? Imagine how fast anyone would D-DOS such index from his own localhost, anonymously, simply by restarting tor in such manner:

    1. <br />
    2. # while sleep $[5*60];do rm /usr/local/var/lib/tor/hidden_service/private_key; service tor restart; done<br />

    Anonymous

    April 07, 2015

    Permalink

    "TOR HIDDEN SERVICES SHOULD BE DISCONTINUED NOT CROWD-FUNDED"

    The Onion Router at its core and original intent is a "networking technology"...not a "hosting technology". TOR Hidden Services are scope creep and have failed repeatedly when attacked by "powerful" adversaries. Development and support should be discontinued for the following reasons:

    - The single node model is fail! Any realistic model of hidden services has to be multi-node, distributed, and load balanced...like I2P and Freenet. Whether you agree or disagree with darknet market places, Evolution's performance and uptime was outstanding and had to be the result of cleverly leveraging some cloud or distributed hosting platform.

    - The right tool for the right task, let TOR be TOR and I2P be I2P, being a responsible actor and discontinuing a flawed model/service allows...nay "forces" hidden services to migrate to I2P or a successor...I2P will get more attention and support...vetting! Java is a ridiculous choice for use in the darknet threat model.

    - TOR should focus its resources on improving "onion routing" increasing distribution, acceptance, bandwidth, and security...for anonymous clearnet access...so Google/Cloudflare captchas, de-anonymizing talks, and browser exploits are a historical road bump for nostalgia.

    Anonymous

    April 08, 2015

    Permalink

    Very recently there has been another report of malware being bundled with software downloaded using bittorent.

    Some users have previously asked whether i2p might be a suitable method for safely obtaining the latest ISO image for Tails.

    But is i2p really safer than bit torrent? Certainly (unless something has changed drastically) our enemies know who is using i2p, just perhaps not precisely what they are downloading. In some ways that could be the worst of all possible worlds, in that it appears to invite FBI to assume the user is downloading something illegal (which in the case of Tails, if the FBI gets its way, may soon be literally true in FEY countries).

    So what is the current security status of i2p?

    Last I heard (a few years ago) it had badly failed an independent audit. I hope all the flaws discovered then were promptly fixed, but is there a new audit in the works?

    I'm not at all saying I2P is without flaws, anyone that claims anything is flawless, you should smile and walk away.

    What I was trying to articulate TOR, Tails, whatever its better at hiding the client than the server because that was the original design intent, spies in another country interacting with the clearnet.

    But from the server side you want people to find your site...so there can never be such a thing as a "hidden service". Someone is going to know something about your site like an onion address and attack it, so you don't put your site in one place you put it in lots of places or everyplace. My understanding is this is what I2P and Freenet attempt to do...like a torrent your site is split up and shared across everyone who has the client install.

    I'm saying focus on what you do best. TOR leaves a traffic fingerprint as well and thats why its best to run both I2P or TOR over a VPN connection.

    Anonymous

    April 08, 2015

    Permalink

    > Development and support should be discontinued for the following reasons:

    Your points do not lack validity, and I'd add another: the Tor Project is experiencing pressures to grow, which is good but which also carries the danger that the developer community may not be able to maintain its tightly focused and close-knit status. Our most dangerous enemies (NSA/GCHQ/CSE) will not hesitate to try to encourage and then exploit too-rapid growth, in order to harm Tor.

    But IMO these points are outweighed by other considerations:

    o So long as Tor Project leaders bear in mind the sociological tactics used by our enemies to disrupt groups like ours, we can probably avoid becoming fragmented,

    o HS have not been very safe so far, but there seems to be reason to hope they can made much safer,

    o There appear to be many reasons why safe HS would be a boon to the freedom-seeking peoples of the world,

    o Anything FBI/NSA fervently desires to kill, such as HS, must be a very good thing for every citizen of the Internet; the features of the Tor network which our enemies hate most are precisely those we should insist upon retaining, improving, and growing.

    Anonymous

    April 08, 2015

    Permalink

    Some unfair comments in tor-talk recently drew irritated responses from two founding members of our community. Just wanted to remind everyone to consider two Snowden-confirmed facts before responding to "trollbait":

    o The Tor Community is a major target of GCHQ,

    o GCHQ targets its enemies with a variety of "effects" which can include disinformation and trolling campaigns.

    Several Snowden leaked presentations from GCHQ sketch their rationale for attempting to destroy the cohesiveness and effectiveness of targeted communities, for example by trying to

    o discredit leadership figures,

    o turn influential members of the community against each other.

    Nasty. And very much in the spirit of "Gamergate". Let us all resolve not to fall for such dirty tricks.

    I'm going to say this and everyone is going to crap their pants. NSA/GCHQ/FBI/CIA are not trying to kill TOR, nor do they care about anything not large enough to get them a promotion. DOD funded it and CIA uses it for their assets in enemy nations. If western agencies wanted it dead, it would be dead. Why do you think unpublished bridges are a requirement in countries like China and Iran? Because that is what trying to kill TOR really look like. It blows my mind how many smart people have been brainwashed and bamboozled by Russia's spy Snowden because they are so paranoid their porn habits are being scrutinized. Would they love to have a backdoor? Sure, because that's what voters and tax payers asked them to do by supporting politicians who wrote and voted for the Patriot Act, and all the legislation supporting the MIC and IIC. The only people we have to blame in the West are ourselves because we weren't paying attention and still haven't done anything to change it.

    Anonymous

    April 09, 2015

    Permalink

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

    o defenses for protestors targeted with chemical weapon assault drones

    http://arstechnica.com/tech-policy/2015/04/pepper-spraying-drones-will-…
    Pepper-spraying drones will be used on Indian protesters
    Daniel Culpan
    9 Apr 2015

    o visual identification service ("what IS this thing (image of mystery device noticed on a pole, embedded in the road, found inside telecom gear?")

    o tamper detection for hardware sent by mail/courier

    Anonymous

    April 15, 2015

    Permalink

    > If western agencies wanted [Tor] dead, it would be dead. Why do you think unpublished bridges are a requirement in countries like China and Iran? Because that is what trying to kill TOR really look like.

    The trouble with your argument is that in their response to Tor the FVEY nations increasingly look more and more like China and Iran. Take a look at the language in anti-democratic laws which have been enacted in recent years in Spain, Russia, Australia, China, UAE, etc., and then compare with repressive bills likely to soon become law in USA, Canada, etc. See hrw.org for analysis.

    > It blows my mind how many smart people have been brainwashed and bamboozled by Russia's spy Snowden

    Someone, presumably you, has occasionally made similar claims on tor-talk, and no one can understand why you believe something ("Russia's spy") which seems so obviously contra-factual.

    Many who offer critical comments on CIA (some of them even work there) say that James Jesus Angleton did more damage to CIA than any of the moles he was hunting. And you'd have to look long and hard to find anyone inside FBI who has anything good to say about J. Edgar Hoover.

    But more to the point, anti-communist paranoia seems out of place in the modern world. I agree that Putinism is a serious threat (especially to Russians and to people living in neighboring countries), but it is a minor threat to the world, compared to NSA, CIA, SOCCOM, etc.

    We do agree on one thing, I think: governmental reprisals against the Tor Project are a measure of its success in accomplishing its pro-democracy purpose.

    IMO, the greatest problem for human rights workers today is that the USG is transforming from being a nation which officially guarantees human rights at home and supports them abroad into the world's most lethal oppressor nation. That leaves human rights workers, Tor developers, etc., with no "safe haven" they can use as a base while working to develop democratic government in countries like Bahrain, Vietnam, North Korea, etc.

    Anonymous

    April 16, 2015

    Permalink

    Please, read my Advice !!!!

    There are prev. generation of hidden network, called FreeNet. There is another method of hidden services.

    It is much better for operator, do n't you see?

    The point of failure in current version of Tor's Hidden Service - is a point of operator, point of owner. It is bad, bad,bad, and again very bad way.

    I don't know, is it possible to wrap two hidden-networks FreeNet and Tor into one bunch for such new version of hidden-service.

    Is there any researchs?

    Anonymous

    April 18, 2015

    Permalink

    Please avoid going "off topic" into politics. This is a talk about crowdfunding hidden services and improvement suggestions. If it is not about that then lets assume it it s TROLL comment to keep us off of subject.

    Anymore IMPROVEMENT suggestions for HS?

    Anonymous

    April 23, 2015

    Permalink

    Forum software analogous to VBulletin, but written specifically for use with HS with anonymity protections in mind from the ground up, as far as possible.

    The same, for blogging software.

    I'd love to hear creative ideas on how HS might be leveraged to replace email (stmp is hopelessly dragnet-friendly).

    Anonymous

    April 27, 2015

    Permalink

    Recently the crucial role currently played by GPG in the pro-privacy infrastructure received some long-overdue media attention.

    One of the most worrisome issues surrounding current usages of PGP/GPG is the difficulty for many users of obtaining trustworthy copies of keys, including signing keys for iso images. The special purpose key distribution protocol used by PGP/GPG is unfortunately not encrypted, which is a serious limitation in the current environment. Even worse, few if any http-based key servers use https. This would appear to practically invite our most lethal enemy to trojan or alter keys in transit between the key server and the user's computer. Please note that this concern is independent of the Web of Trust model.

    Would it be possible to use HS to help improve the chances that downloaded PGP/GPG public keys have not been tampered with? Perhaps by providing hidden key-servers protected (sort of) by https?

    I am aware that "conventional wisdom" holds that downloading keys via Tails (for example) using either the purpose-built protocol or an http connection to a key-server which supports http is even more likely (for the average user) to attract governmental interference than downloading via a direct connection. Worst of all, perhaps, would be a direct connection from an IP address which shows up in NSA's database of IPs which have been seen connecting to a Tor directory authority.