chris-barry / darkweb-everywhere

HTTPS Everywhere rulesets for hidden services and eepsites.
http://onion.im
Other
168 stars 32 forks source link

Rule suggestions #8

Open jutozex opened 10 years ago

jutozex commented 10 years ago

I will post any rule suggestions here in future. Anyone else could use here too.

bitmessage.ch -> bitmessage.i2p

colinmahns commented 10 years ago

Thanks for the post, can't believe I didn't catch bitmessage's eepsite earlier!

If you find anymore suggestions, please feel free to add them here or make a pull request :)

jutozex commented 10 years ago

I think it was added recently.

According to the admin, it is still experimental, I have found that after sending an email it tries to request from bitmessage.ch instead of bitmessage.i2p. So this rule should fix such problems too

jutozex commented 10 years ago

So I also think that it's not even necessary that the hidden service's owner is the same as the original website. Such situations are generally people supporting the content by mirroring it as hidden service.

colinmahns commented 10 years ago

kognitionskyrkan.xml proof http://kognitionskyrkan.nu/1.0/

bitcoincigs.xml proof https://bitcointalk.org/index.php?topic=193243.0

Thanks for finding these. Kognitionskyrkan has been a tough one to find,

.darktor.com and .onion.cab as a tor2web alternative (tor2web.xml)

wtfismyip.com -> tmkloc6vhxos3nde.onion

I'll look into these two later today when I get the time.

Also, did you edit out two adult links from this post? The email from github had two hidden services you labeled as "adult". Anyway, I wanted to add that I don't think we (Chris and myself) should be in the business of barring rules based on a site's content. We aren't trying to be the morality police, rather just supplying a way to try and keep anonymity for all users. There are sites that we have rules to that I don't think people should go to, but I'm not going to try and make it difficult for them.

Bitmessage i2p proof is the link from the onion (which requires another proof-check), better change it to main domain

projectpm.xml has a typo: "http://http://projpmcxufvim7be.onion/"

projectpm.xml: wiki.echelon2.org is forgotten. add the <target and replace (www.)? with (www.|wiki.)?

Wow, thanks for pointing those out. It's a good thing we have you around, I clearly shouldn't be trusted behind a keyboard ;) Good catch on projectpm not redirecting wiki.* too.

I think the rules under the unverified-rules folder shouldn't be off by default, if the user installs them, accepts the responsibility and it would be hard to turn them on one by one. And I don't think most rules need verification, I believe general/information websites should be on by default without need of verification (as long as the content is same), but if any kind of risk is involved, for example the keyserver rule, some marketplace (bitcoincigs) or some other bitcoin service, then it should be separated. The unverified but included rules should be listed under documentation.

I created the unverified rules just as an incubator of sorts for rules that haven't been verified. Removing the default_off on them is a good idea since a user now has to go out of their way to add those rules, however I don't like the idea that we should just add unverified rules because the "content" is the same or because they aren't that "risky". I think we should strive to only include rules that meet our criteria in the default install rather than rules that might be okay.

So I also think that it's not even necessary that the hidden service's owner is the same as the original website. Such situations are generally people supporting the content by mirroring it as hidden service.

As a good example I'm suggesting a rule to redirect geohot.com -> wdnqg3ehh3hvalpe.onion

I personally don't like this, since it will alter the content the user expects vs what they receive. In that example you cited, what if Geohot changes his personal site and has something a user might want to see? If we link to a mirror (especially the mirror cited in that example) we will be receiving whatever the owner of that hidden service wants to serve, rather than what the user is expecting. Also, what if that hidden service mirror is malicious in any way? I think it's safer to hardline this.

Please keep the contributions coming by the way!

jutozex commented 10 years ago

About the adult links, I've by chance found another very similar site with a hidden service, clearly from the same owners, which had sets of almost naked underage children, so I thought better not even add the previous two as to not support them

chris-barry commented 10 years ago

That was a good call. As long as it doesn't feature obviously underage children it shouldn't be an issue adding anything.

Chris Barry

On Jun 13, 2014, at 13:46, jutozex notifications@github.com wrote:

About the adult links, I've by chance found another very similar site with a hidden service, clearly from the same owners, which had sets of almost naked underage children, so I thought better not even add the previous two as to not support them

— Reply to this email directly or view it on GitHub https://github.com/chris-barry/darkweb-everywhere/issues/8#issuecomment-46039872 .

jutozex commented 10 years ago

As an improvement, the proof links could be archived and linked to protect for future.

Some services: http://webcitation.org/ https://archive.today/ https://archive.org/web/

jutozex commented 10 years ago

http://pastebin.com/BF7yJKtY is a 2 year old paste, not technically but logically it is a proof of wtfismyip.xml.

Other than that, for current or future rules we can try to get a proof by using the contact options. Maybe they will add a link to the website, or send a gpg signed message to be used as proof of ownership.

colinmahns commented 10 years ago

I'd rather rely on a primary source as proof rather than something like a pastebin.

I'll be happy to send an email out to the guys at WTF Is My IP. I've reached out to several of the sites already, but only a handful have responded. Hopefully they respond.

jutozex commented 10 years ago

proof of bbseyes: https://twitter.com/bbseyes/status/422416817659707392

But I cannot reach the hidden site.

colinmahns commented 10 years ago

If I recall correctly, they were one of the sites that hasn't responded to me... But at least we can verify their site :)

jutozex commented 10 years ago

http://maximaculpa.me/sin/365/ proof of maximaculpa. But the correct address is nsmgu2mglfj7za6s.onion. Actually the first two characters of the address on the rule is missing

colinmahns commented 10 years ago

Ah this was a good find, I just pushed it. Thanks!

I think I got the current one from one of the hidden wikis. Not that it matters now of course.

jutozex commented 10 years ago

I think the searx addresses are just independent instances of the software, like https://github.com/asciimoo/searx/wiki/Searx-instances

colinmahns commented 10 years ago

Heard back from WTF Is My IP, it's confirmed that they host that hidden service, but the site creators expressed that the hidden service is more of a joke. I've attatched the email.

As a result of this, I think it's safe to say it should be default off to preserve the intended functionality.

That's a good fine about searx, I guess if we can verify that each instance has a hidden service run by the same guys/girls, it's okay to add to the main set of rules. I think I saw one or two that meet our criteria, so I'll add them in a little bit.

jutozex commented 10 years ago

https://searx.gliderswirley.org/ -> qfz67iw4xz7qwfab.onion

colinmahns commented 10 years ago

Added, thanks.

jutozex commented 10 years ago

Despite the fact that it is usable as an anonymous mail provider, if their real intention is to rob people's bitcoins, should we delete the newly added Mailtor rule?

When I was testing it, I saw the so called wallet functionality but I felt it was a scam.

And today I found this reddit: https://www.reddit.com/r/TOR/comments/28hyyj/mailtor_onion_email_and_bitcoin_wallet_scam_2000/

chris-barry commented 10 years ago

As far as I see it, these rules are only here to provide a mapping from clear->hidden service. It's each user's responsibility to make sure they're using services which don't rob them (assuming that reddit poster is not lying).

colinmahns commented 10 years ago

Glad you posted that link. I probably wouldn't have seen it until much later, if at all.

The possible inclusion of scams is something I've thought about, but haven't written anything about it yet. I think that we should apply the same rules we already have for rulesets, with the addition that if we find confirmation that the site is a scam, we give it a default_off="$REASON" and throw a link to the scam confirmation in EVIDENCE.md.

Or we can just leave default_off to continue being what it is, for dead rules and leave scam sites mixed in with regular rules. We aren't out to tell people what we think they should do, even as indirectly as to keep them away from a bad site. This project exists more to catalog as many clear > hidden sites as possible.

TL;DR - If Chris likes either of my proposals for how to handle, we'll go down that route.

chris-barry commented 10 years ago

Colin: we seem to be agreeing, kinda. I don't really have an opinion about on/off. I just feel it shouldn't be excluded.

chris-barry commented 10 years ago

jutozex: how should I cite you in AUTHORS.md ?

colinmahns commented 10 years ago

Chris: I don't think they should be excluded either, I am just wondering how we should include them in the default install. There's decent arguments for both sides.

I'm leaning more to keeping them default on, since we shouldn't be the ones responsible for the user's actions while using the rules, or responsible for keeping them "protected" from scams and the like.

jutozex commented 10 years ago

No need for citing, this is just a randomly created nickname. But if you want the file to look more crowded :) just add jutozex

jutozex commented 10 years ago

I think we can move the 3 unverified rules to the rules folder (and indymediakeyserver to dead-rules, at least temporarily), I think nobody would oppose this.

Considering the content, there is no motivation for anyone to host the hidden service with bad intent for a long time without any warning anywhere on the main website or anywhere else.

And I think, including mailtor.xml means we should also move these unverified rules to rules folder. They couldn't make more harm

jutozex commented 10 years ago

By the way, my answer on stackexchange made its way into the Tor Blog :)

https://blog.torproject.org/

colinmahns commented 10 years ago

I think we can move the 3 unverified rules to the rules folder (and indymediakeyserver to dead-rules, at least temporarily), I think nobody would oppose this.

I'm not crazy about moving unverified rules into the main mix, since I really do like having that buffer. Verified doesn't mean "safe to use", but "confirmed to not be a bad actor/actress". Remember, Donald Trump has a "verified" twitter account ;)

I understand the point you are making with these three specific services however. I won't stand in the way of these three making it back into the main rules directory.

Indymedia's key server is unique because not only is it dead, but it can't be verified thanks to it being dead. So yeah, I think putting it in dead-rules/ is acceptable.

By the way, my answer on stackexchange made its way into the Tor Blog :)

Warning, Youtube link of my reaction

This is so cool.

justsomeguyyouknow commented 10 years ago

Hi, I have some questions. I already have a website with .onion support (can connect both clearnet and darknet).

My questions are:

For Evidence

In order to make sure all of the clearnet to hidden mappings are correct, proper evidence is required. Proper evidence can consist of:

A link on the clearnet site.
A tag in the HTML similar to <link rel="x-tor-hidden-service" href="sweetsite.onion">.
A signed email from the owner of the site saying it is real.
A link on Twitter by the verified site owner saying so.

A link on the clearnet site. OK.

A tag in the HTML similar to . So I'll add this tag to top page.

A signed email from the owner of the site saying it is real. What is this? "Email body" or "Email address"? I don't want any spam, so I don't want to make my mail address public.

A link on Twitter You know, NSA is watching. I don't use Twitter. (If you believe I'm a paranoid, you're wrong. http://prism-break.org)

jutozex commented 10 years ago

If there's a link on the clearnet site, that's enough. What's the address, I will quickly add it.

chris-barry commented 10 years ago

You don't have to use all three. Any will be convincing enough

Chris Barry

On Jun 19, 2014, at 1:00, justsomeguyyouknow notifications@github.com wrote:

Hi, I have some questions. I already have a website with .onion support (can connect both clearnet and darknet).

My questions are:

For Evidence

In order to make sure all of the clearnet to hidden mappings are correct, proper evidence is required. Proper evidence can consist of:

A link on the clearnet site. A tag in the HTML similar to <link rel="x-tor-hidden-service" href="sweetsite.onion">. A signed email from the owner of the site saying it is real. A link on Twitter by the verified site owner saying so.

A link on the clearnet site. OK.

A tag in the HTML similar to . So I'll add this tag to top page.

A signed email from the owner of the site saying it is real. What is this? "Email body" or "Email address"? I don't want any spam, so I don't want to make my mail address public.

A link on Twitter You know, NSA is watching. I don't use Twitter. (If you believe I'm a paranoid, you're wrong. http://prism-break.org)

— Reply to this email directly or view it on GitHub https://github.com/chris-barry/darkweb-everywhere/issues/8#issuecomment-46523793 .

jutozex commented 10 years ago

similar to geohot, exposed.su/exposed.re is dead due to suppression and probably up as hidden service by the owners on http://exposed36mq3ns23.onion. I think this is where the real benefit of this project could be. Keeping information alive. What do you think?

colinmahns commented 10 years ago

If it's run by the owners or if the owners verify, I don't see a problem. I think it might've been buggedplanet or one of the Telecomix sites where we had a similar situation to this.

If it's like the Geohot case, where a third party is mirroring, then it's best to treat it as such, IMO.

On June 19, 2014 12:45:37 PM EDT, jutozex notifications@github.com wrote:

similar to geohot, exposed.su/exposed.re is dead due to suppression and probably up as hidden service by the owners on http://exposed36mq3ns23.onion. I think this is where the real benefit of this project could be. Keeping information alive. What do you think?


Reply to this email directly or view it on GitHub: https://github.com/chris-barry/darkweb-everywhere/issues/8#issuecomment-46585809

Sent from my Android device with K-9 Mail. Please excuse my brevity.

jutozex commented 10 years ago

What do you think having these websites under unverified-rules, including geohot, I've seen other similar websites in past which could be added

colinmahns commented 10 years ago

I actually like having a dedicated mirrors folder, leaving the unverified rules folder available for rules that need to be proven.

On June 19, 2014 1:07:16 PM EDT, jutozex notifications@github.com wrote:

Or alternatively having a folder named mirror or mirrors which wouldn't require ownership


Reply to this email directly or view it on GitHub: https://github.com/chris-barry/darkweb-everywhere/issues/8#issuecomment-46588437

Sent from my Android device with K-9 Mail. Please excuse my brevity.

chris-barry commented 10 years ago

I'd feel more comfortable with them in another folder. I don't want to accidentally redirect the wrong resource...

In other news, I am considering forking HTTPSEverywhere this weekend to try and make this into a real plugin. Any thoughts on this?

On Jun 19, 2014, at 13:07, jutozex notifications@github.com wrote:

Or alternatively having a folder named mirror or mirrors which wouldn't require ownership

— Reply to this email directly or view it on GitHub https://github.com/chris-barry/darkweb-everywhere/issues/8#issuecomment-46588437 .

colinmahns commented 10 years ago

I'll share my thoughts on the idea that I've had with you in private.

I like the idea since it will make this much easier for all users to install, especially for those that use that one unnamed proprietary operating system. It's much easier to say to someone to "install this extension into the Tor Browser Bundle" than "drag all these files into this specific folder".

jutozex commented 10 years ago

we.riseup.net rule is invalid because it redirects to same address as the hidden mail service.

colinmahns commented 10 years ago

I see that now actually. Looks like the riseup site has a typo. I'll try to get in touch with someone from there, only problem is that for some reason I'm banned from their IRC channel, despite having never connected to it...

colinmahns commented 10 years ago

Finally got a response from the riseup guys! Turns out their IRC room doesn't like using their hidden service, or something.

Anyway, was able to find we.riseup.net's hidden service and confirm thanks to them. Another one down!

jutozex commented 10 years ago

Encyclopedia Dramatica alive

jutozex commented 10 years ago

indymedia keyserver alive and verified: https://archive.today/Uy5jQ (old content of keys.indymedia.org) - (Page 201 of https://linksunten.indymedia.org/es/system/files/data/2013/06/1814659631.pdf - https://archive.today/yZdgd or http://web.archive.org/web/20140627184946/https://linksunten.indymedia.org/es/system/files/data/2013/06/1814659631.pdf)

colinmahns commented 10 years ago

Just pushed. Thanks!

jutozex commented 10 years ago

I tend to add mirror addresses to redirection like in thepiratebay.xml

Should I/we add whonix.org.nyud.net and www.whonix.org.nyud.net for whonix.xml

I'm asking because maybe it is unnecessary, it doesn't show up on search engines, but it also doesn't make any harm either

ckanth1 commented 10 years ago

I'm using "Easylist NoMercy" via .onion (darknet). It is providing .onion access, but it also require you to add Auth Key (easy to understand though)

Source: https://bitbucket.org/adstomper/adblockedge/issue/78

2 Tor Hidden Service[Recommend] | Are you using Tor to protect your privacy? Then I recommend this one.

colinmahns commented 10 years ago

Hey ckanth1, welcome to the project! :)

That's pretty cool that Easylist has .onion access in Adblock. I'm not quite sure if it would integrate well into this project however. The way the rules (and the extension we are planning on) work, is it redirects you from an HTTP or HTTPS site to the hidden service when typed in the browser. I have no idea of making a rule out of this would get us anywhere

chris-barry commented 10 years ago

Where do you see the onion? I can't see it on mobile. :(

There's a good chance it will work. IIRC HTTPSEverywhere also redirects links that are embedded in pages. It would be worth it to give it a try.

On Jun 30, 2014, at 22:51, Colin Mahns notifications@github.com wrote:

Hey ckanth1, welcome to the project! :)

That's pretty cool that Easylist has .onion access in Adblock. I'm not quite sure if it would integrate well into this project however. The way the rules (and the extension we are planning on) work, is it redirects you from an HTTP or HTTPS site to the hidden service when typed in the browser. I have no idea of making a rule out of this would get us anywhere

— Reply to this email directly or view it on GitHub https://github.com/chris-barry/darkweb-everywhere/issues/8#issuecomment-47611695 .

colinmahns commented 10 years ago

Thanks for linking those to clear things up, your earlier link did not seem to have them.

If you want to submit a pull request for this rule, it makes merging changes go much quicker. That said, I'm not sure if this rule exactly fits in with the project for two reasons. It's depending on an external plugin not included with the TBB, along with the fact that it's not a clear -> hidden web page.

colinmahns commented 10 years ago

So the only way to view this hidden service is to modify your .torrc? I think that this might be a bit much for end users to deal with.

jutozex commented 10 years ago

http://www.kavkazcenter.com/eng/content/2012/06/20/16355.shtml

colinmahns commented 10 years ago

Added. Thanks :)