I saw https://trac.torproject.org/projects/tor/wiki/org/meetings/2015SummerDevMeet... and it notes "Create thread on tor-dev." I couldn't find that thread.
But since the below is relevant for this, I figured I'd forward it here.
He says not to be intimidated by the length of the document, but I am anyway. Unsurprisingly the tl;dr section was the most appealing to me: http://networkedsystemsethics.net/index.php?title=Networked_Systems_Ethics#S...
---------- Forwarded message ---------- From: Bendert Zevenbergen bendert.zevenbergen@oii.ox.ac.uk Date: 3 May 2016 at 10:08 Subject: [OTF-Talk] Launching Ethics Guidelines
Dear All,
Today I’m launching the outcome of my OTF information controls fellowship on the Ethics of Networked Systems Research: http://networkedsystemsethics.net. Here a short explanation:
These Networked System Ethics guidelines aim to underpin a meaningful cross-disciplinary conversation between gatekeepers of ethics standards and researchers about the ethical and social impact of technical Internet research projects.
At heart of this work is the iterative reflexivity methodology that guides stakeholders to identify and minimize risks and other burdens. These must be mitigated to the largest extent possible by adjusting the design of the project before data collection takes place.
The aim is thus to improve the ethical considerations of individual projects, but also to streamline the proceedings of ethical discussions in Internet research (or product development) generally.
The primary audience for these guidelines is technical researchers (e.g. computer science, network engineering, as well as social science) and gatekeepers of ethics standards at institutions, academic journals, conferences, and funding agencies. It would be great if these guidelines do get used beyond academic research in civil society, product development, or otherwise.
This is not just my work, but these guidelines were developed in cooperation with many great people who attended workshops worldwide. Here’s a workshop report and a case study that show how this work developed:
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2666934
http://bdes.datasociety.net/council-output/case-study-no-encore-for-encore/
I’m very interested to hear if you have applied these guidelines to your projects, or whether you have comments on this work! Feel free to forward this email..!
Many thanks to OTF for making this possible and their excellent support!
Ben
------------------------------------------------ Ben Zevenbergen DPhil (PhD) Candidate Oxford Internet Institute University of Oxford Senior Fellow Open Technology Fund
I've received conflicting accounts as to whether the ethics guidelines require onionsites are to be opt-in [no spec yet?] or the current opt-out [i.e., /robots.txt].
Any clarification on this point would be very helpful for the various tor2web services which currently use the current /robots.txt method.
FWIW, when Aaron and I designed tor2web, we chose the unusual subdomain URL format explicitly so that /robots.txt would work.
-V
On Thursday, 5 May 2016, Tom Ritter tom@ritter.vg wrote:
I saw https://trac.torproject.org/projects/tor/wiki/org/meetings/2015SummerDevMeet... and it notes "Create thread on tor-dev." I couldn't find that thread.
But since the below is relevant for this, I figured I'd forward it here.
He says not to be intimidated by the length of the document, but I am anyway. Unsurprisingly the tl;dr section was the most appealing to me:
http://networkedsystemsethics.net/index.php?title=Networked_Systems_Ethics#S...
---------- Forwarded message ---------- From: Bendert Zevenbergen <bendert.zevenbergen@oii.ox.ac.uk javascript:;
Date: 3 May 2016 at 10:08 Subject: [OTF-Talk] Launching Ethics Guidelines
Dear All,
Today I’m launching the outcome of my OTF information controls fellowship on the Ethics of Networked Systems Research: http://networkedsystemsethics.net. Here a short explanation:
These Networked System Ethics guidelines aim to underpin a meaningful cross-disciplinary conversation between gatekeepers of ethics standards and researchers about the ethical and social impact of technical Internet research projects.
At heart of this work is the iterative reflexivity methodology that guides stakeholders to identify and minimize risks and other burdens. These must be mitigated to the largest extent possible by adjusting the design of the project before data collection takes place.
The aim is thus to improve the ethical considerations of individual projects, but also to streamline the proceedings of ethical discussions in Internet research (or product development) generally.
The primary audience for these guidelines is technical researchers (e.g. computer science, network engineering, as well as social science) and gatekeepers of ethics standards at institutions, academic journals, conferences, and funding agencies. It would be great if these guidelines do get used beyond academic research in civil society, product development, or otherwise.
This is not just my work, but these guidelines were developed in cooperation with many great people who attended workshops worldwide. Here’s a workshop report and a case study that show how this work developed:
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2666934
http://bdes.datasociety.net/council-output/case-study-no-encore-for-encore/
I’m very interested to hear if you have applied these guidelines to your projects, or whether you have comments on this work! Feel free to forward this email..!
Many thanks to OTF for making this possible and their excellent support!
Ben
Ben Zevenbergen DPhil (PhD) Candidate Oxford Internet Institute University of Oxford Senior Fellow Open Technology Fund _______________________________________________ tor-project mailing list tor-project@lists.torproject.org javascript:; https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
On 6 May 2016, at 14:53, Virgil Griffith i@virgil.gr wrote:
I've received conflicting accounts as to whether the ethics guidelines require onionsites are to be opt-in [no spec yet?] or the current opt-out [i.e., /robots.txt].
Any clarification on this point would be very helpful for the various tor2web services which currently use the current /robots.txt method.
FWIW, when Aaron and I designed tor2web, we chose the unusual subdomain URL format explicitly so that /robots.txt would work.
Where is the current opt-out process specified? Im not familiar with it.
As with anything that's not explicitly spelt out in the ethics guidelines, I think that's an ongoing conversation we need to have, taking into account the principles in those guidelines.
It seems to me that access via Tor and access via tor2web should be equivalent by default. So I really can't see how opt-in would work, but I have yet to see a proposal for an opt-in method. (I don't like any design where tor2web needs to connect to an onion service to work out whether the service has opted-in. That adds to the load, and is bad if the number of connections or externally-triggered connections are part of the threat model.) Has there been anything said on a public mailing list about opt-ins for tor2web?
It also seems to me that any opt-in proposal would be more likely to work under prop224, when onion service addresses are harder to discover. Nevertheless, if a client has the address, it shouldn't matter if they access the service via Tor or tor2web. Any transition to opt-in would also be easier to manage as part of the prop224 transition.
There's one important exception to this general principle: Single Onion Services. To avoid creating one-hop proxies, tor2web should not allow access to a single onion service. We'e yet to arrive at a mechanism to make this happen, but I think we will end up adding a line to the onion service descriptor. We could make this a configuration parameter (AllowTor2Web?) that defaults to 1 for hidden services, and 0 for single onion services. https://trac.torproject.org/projects/tor/ticket/17945
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n
On 6 May 2016, at 19:30, Tim Wilson-Brown - teor teor2345@gmail.com wrote:
On 6 May 2016, at 14:53, Virgil Griffith i@virgil.gr wrote:
I've received conflicting accounts as to whether the ethics guidelines require onionsites are to be opt-in [no spec yet?] or the current opt-out [i.e., /robots.txt].
... There's one important exception to this general principle: Single Onion Services. To avoid creating one-hop proxies, tor2web should not allow access to a single onion service. We'e yet to arrive at a mechanism to make this happen, but I think we will end up adding a line to the onion service descriptor. We could make this a configuration parameter (AllowTor2Web?) that defaults to 1 for hidden services, and 0 for single onion services. https://trac.torproject.org/projects/tor/ticket/17945
After re-reading the ticket, there is another way to implement this feature without providing a generic method for onion services to block tor2web:
The rendezvous point (and possibly the introduction point) could terminate the connection if it has a single hop on both ends. However, this could result in false positives if the consensus gets out of sync.
Or is there a reliable way for a relay to detect non-relays without using the consensus?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n
Here's the line about unacceptability of crawling .onion:
"For example, it is not acceptable to run an HSDir, harvest onion addresses, and do a Web crawl of those onion services."
https://trac.torproject.org/projects/tor/wiki/org/meetings/2015SummerDevMeet...
So, this can indeed be an official policy. But it was the first I had heard of it. And currently at least 3-4 tor2web nodes in good-standing explicitly permit crawling of .onion .
----------------------
Teor: Apologies for being dumb, but can you explain why it's bad for tor2web-nodes to connect to single-onion services? Both Tor2web and Single-onion say IN BIG BOLD LETTERS that using these remove your anonymity. Given that these are intentionally meant to be "expert features" for people who know what they are doing, I don't immediately see a concern sufficiently large that it merits special handling. Can you enlighten me?
-V
On Fri, May 6, 2016 at 5:36 PM, Tim Wilson-Brown - teor teor2345@gmail.com wrote:
On 6 May 2016, at 19:30, Tim Wilson-Brown - teor teor2345@gmail.com wrote:
On 6 May 2016, at 14:53, Virgil Griffith i@virgil.gr wrote:
I've received conflicting accounts as to whether the ethics guidelines require onionsites are to be opt-in [no spec yet?] or the current opt-out [i.e., /robots.txt].
... There's one important exception to this general principle: Single Onion Services. To avoid creating one-hop proxies, tor2web should not allow access to a single onion service. We'e yet to arrive at a mechanism to make this happen, but I think we will end up adding a line to the onion service descriptor. We could make this a configuration parameter (AllowTor2Web?) that defaults to 1 for hidden services, and 0 for single onion services. https://trac.torproject.org/projects/tor/ticket/17945
After re-reading the ticket, there is another way to implement this feature without providing a generic method for onion services to block tor2web:
The rendezvous point (and possibly the introduction point) could terminate the connection if it has a single hop on both ends. However, this could result in false positives if the consensus gets out of sync.
Or is there a reliable way for a relay to detect non-relays without using the consensus?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n
tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
Virgil Griffith transcribed 2.7K bytes:
Here's the line about unacceptability of crawling .onion:
"For example, it is not acceptable to run an HSDir, harvest onion addresses, and do a Web crawl of those onion services."
https://trac.torproject.org/projects/tor/wiki/org/meetings/2015SummerDevMeet...
So, this can indeed be an official policy. But it was the first I had heard of it. And currently at least 3-4 tor2web nodes in good-standing explicitly permit crawling of .onion .
Perhaps, more explicitly, what we'd like to eliminate is people like you, Virgil. You've admitted publicly, in person, to several of our developers that you harvested HSDir data and then further attempted (unsuccessfully) to sell said data on users to INTERPOL and the Singaporean government.
We do not tolerate people within our community cooperating with any parties, including law enforcement and government agencies, to deanonymise real world users of the Tor network. Full stop.
Your previous behaviours were absolutely abhorent, unethical, unacceptable, and cowardly. They are now covered by the official ethical guidelines. Tor2web similarly should be killed with fire as being a blatant and disgusting workaround to the trust and expectations which onion service operators place in the network.
Have a nice day.
isis transcribed 3.6K bytes:
Virgil Griffith transcribed 2.7K bytes:
Here's the line about unacceptability of crawling .onion:
"For example, it is not acceptable to run an HSDir, harvest onion addresses, and do a Web crawl of those onion services."
https://trac.torproject.org/projects/tor/wiki/org/meetings/2015SummerDevMeet...
So, this can indeed be an official policy. But it was the first I had heard of it. And currently at least 3-4 tor2web nodes in good-standing explicitly permit crawling of .onion .
Tor2web similarly should be killed with fire as being a blatant and disgusting workaround to the trust and expectations which onion service operators place in the network.
Simply because a user, given an onion service address, naïvely decides to use one of your Tor2Web nodes, it is unacceptable that your Tor2Web node crawls said onion service simply because it didn't "opt out" of your historically malicious desires to harvest data on Tor users and operators. Consent is not the absence of saying "no" — it is explicitly saying "yes".
Wowsa. Hello everyone. Several issues brought up. Let us go one at a time. I apologize for the length. Forgive any typos.
Tor2web similarly should be killed with fire as being a blatant and disgusting workaround to the trust and expectations which onion service operators place in the network.
(1) When Aaron Swartz and I created Tor2web, we envisioned an anonymous publishing platform for world wide web. The quip was, "What good is an anonymously printed book if only your most technical, paranoid, patient friends can read it?" Our goal was for whistleblowers/etc to publish safely behind Tor and readers could link to and share the anonymously-published content over services as mundane as Facebook. Ergo Tor2web was born. Moving to the present, Shari explicitly prioritized make Tor usage more "mainstream". As Tor2web is many people's first exposure to onionsites and Tor, burning Tor2web would be counter-productive to Shari's stated goals as I currently understand them.
said onion service simply because it didn't "opt out" of your historically malicious desires to harvest data on Tor users and operators. Consent is not
(2) If a user requests a page from a never-before-seen .onion domain, and the response is HTTP 200, and that .onion domain doesn't have a disallow in its /robots.txt, the root of that domain is appended to https://onion.link/sitemap.xml for public search engines to crawl. I think it's a bit silly to forbid this, but after seeing this reaction I removed the sitemap until there's a policy on this.
Simply because a user, given an onion service address, naïvely decides to use one of your Tor2Web nodes, it is unacceptable that your Tor2Web node crawls said onion service simply because it didn't "opt out" of your historically malicious desires to harvest data on Tor users and operators. Consent is not the absence of saying "no" — it is explicitly saying "yes".
(3) I understand Isis's concern about search engines being opt-out, i.e., "Consent is not the absence of saying 'no' — it is explicitly saying 'yes'." When it come to sexual consent I wholly support this standard, and this same point was mentioned during the 90s in the creation of robots.txt. Without taking any side on robots.txt, the winning argument back then was roughly, "Search engines are very useful. We understand people like privacy, so we want a way for them to exclude themselves and make incredibly taboo to violate this exclusion. However, search engines are useful, so useful that it is worth making opt-in be the default." Isis disagrees with this precedent, and there exist others who support it. I support the community coming to a consensus on this issue and if it's widely agreed that previous robots.txt precedent was a mistake, I am down for adjusting.
FWIW, Aaron Swartz was the one who chose the somewhat-odd subdomain structure of tor2web URLs. He chose this structure for the *explicit purpose* of making /robots.txt "just work". So we can put Aaron down in the column for "supports the robots.txt precedent". I find it peculiar that the position of the person to whom Tor 0.2.4.x was dedicated, on one of his signature projects, is considered so out-of-the-norm to attract an analogy to rape.
Perhaps, more explicitly, what we'd like to eliminate is people like you, Virgil. You've admitted publicly, in person, to several of our developers that you harvested HSDir data and then further attempted (unsuccessfully) to sell said data on users to INTERPOL and the Singaporean government.
(4) There is substantial confusion on this. Let us clear the air.
(4.1) For me, Tor's speed and sustainable growth are front-and-center. For example, I wrote a Tor tech report on exactly this topic.
https://research.torproject.org/techreports/tor-growth-2014-10-04.pdf
We all know that .onion sites routinely disappear, and OnionLink has a lot of users who click repeatedly attempting to access long-gone .onion domains. I wanted two things: (a) tell users when a .onion domain no longer exists (so they'll stop refreshing); (b) given the substantial traffic OnionLink generates, minimize the burden we place on HSDirs. To achieve this, whenever there was an error, we used Donnache's python script to see whether the .onion domain existed in the DHT. If the domain didn't exist ("NXDOMAIN"), we cached that answer so we didn't burden the HSDirs with duplicate lookups for nonexistent domains. I felt, and feel, doing this was being a courteous citizen and the right thing to do, but my attempt at courteous behavior generated so much vitriol that OnionLink no longer caches non-existent domains, and correspondingly now burdens HSDirs more. I hope one day it will be politically acceptable to cache NXDOMAIN responses so we have a faster, more scalable Tor network.
(4.2) OnionLink is just too popular. As-is, OnionLink processes ~600 hits/sec and is projected to cross 1000 hits/sec before November. This is beyond my modest researcher's budget. And making OnionLink sustainable is an ongoing effort.
First, I tried the Bitcoin donations but no one donated.
Second I tried to make onion.link a paid-service---see our Google Toolbar experiment: https://chrome.google.com/webstore/detail/onionlink-onion-plugin/pgdmopepkim... But under the paid-service the traffic was so low that onion.link wasn't fulfilling its mission of serving the casual audiences Aaron and I intended.
This left me with the choice between displaying ads or selling minimized logs. There's a natural knee-jerk of *logs are bad*, and I thought it too. But after carefully weighing the each option, I felt, and continue to feel, that selling minimized logs is the lesser evil. Here's why:
With ads, which some Tor2web sites use (e.g., http://onion.nu/), the ad-networks gain access to the raw IP#s, which, for the exactly reasons Isis cited, should be zealously guarded. With minimized log files, onion.link greatly mitigates the risk of bad actors acquiring personally-identifying-information.
In my third attempt at sustainability, as Isis also mentioned, the market for logfiles without personally identifying information is exceedingly small---this is unfortunate. Because it forces onion.link into the option we're currently evaluating---ads.
We fought the good fight for greater privacy, but in the fourth attempt at sustainability, we are now begrudgingly experimenting with ads (something like the Forbes "thought of the day".) The leaking of IP addresses to an ad-network makes me uneasy, but when choosing between anonymous-publishing-platform-with-ads vs shutting-down, I choose platform-with-ads. If a market develops for minimized logs, I hope to return to better protecting user privacy by selling minimized logs and preventing ad-networks from seeing raw IP#s.
We do not tolerate people within our community cooperating with any parties, including law enforcement and government agencies, to deanonymise real world users of the Tor network. Full stop.
Wait what!? People believe I conspired with LEAs and governments to de-anonymize Tor users? OH! I thought people were upset that I thought "Fuck the police" was an unwise PR-strategy for mainstreaming Tor (I still think this). Many previously unexplained behaviors suddenly make a lot more sense.
That's a very black brush you got there. Careful whom you paint with that! Jeez.
*still a little be-wildered*
Okay... first reaction... Tor Project members assisting anyone (LEA or otherwise) in deanonymizing users is a palpable conflict of interest. Conflict of interest is terrible for user trust. Additionally, even the appearance of conflict-of-interest damages user-trust. Ergo yes I wholly support this rule. Thumbs up. +1. Anyone conspiring to subvert Tor's security should be banned.
As to Isis's suggestion that I have conspired to or was an accomplice in de-anonymizing Tor users. It is mistaken, against my values Moreover, and moreover lacks any evidence implying otherwise. The closest thing I do to this spurious charge is sell minimized logs (which, ironically, aims to protect user privacy from ad-networks). So here, let us concretize this---I emailed a day's worth of premium onion.link logs [249MB] to tor-assistants@ . I am totally fine going on record saying that this data is less damaging to privacy than Google Adsense or something similar.
Okay... I think that answers your concerns. Anything else?
-Virgil
Apparently tor-assistants@ no longer exists? Well, here's the logs. Share with whomever you think is appropriate.
============================================================ The earlier dates were on a different hard drive. Here's the oldest date I have on hand: Jan 25, 2016.
https://dl.dropboxusercontent.com/u/3308162/2016-01-25.log.gz
SHA1: f5eaab44c04e483ffe24c58ec558fdfaefb610b2
I forthrightly attest that:
(1) these logs are socially very interesting, but not actively dangerous.
(2) these logs are substantially less dangerous than running Google ads, which was the alternative.
Rebuttals are welcome on tor-project@ .
If you want to see the minimized logs for a specific day I can do that too. ============================================================
-V
On Thu, May 12, 2016 at 5:12 PM, Virgil Griffith i@virgil.gr wrote:
Wowsa. Hello everyone. Several issues brought up. Let us go one at a time. I apologize for the length. Forgive any typos.
Tor2web similarly should be killed with fire as being a blatant and disgusting workaround to the trust and expectations which onion service operators place in the network.
(1) When Aaron Swartz and I created Tor2web, we envisioned an anonymous publishing platform for world wide web. The quip was, "What good is an anonymously printed book if only your most technical, paranoid, patient friends can read it?" Our goal was for whistleblowers/etc to publish safely behind Tor and readers could link to and share the anonymously-published content over services as mundane as Facebook. Ergo Tor2web was born. Moving to the present, Shari explicitly prioritized make Tor usage more "mainstream". As Tor2web is many people's first exposure to onionsites and Tor, burning Tor2web would be counter-productive to Shari's stated goals as I currently understand them.
said onion service simply because it didn't "opt out" of your historically malicious desires to harvest data on Tor users and operators. Consent is not
(2) If a user requests a page from a never-before-seen .onion domain, and the response is HTTP 200, and that .onion domain doesn't have a disallow in its /robots.txt, the root of that domain is appended to https://onion.link/sitemap.xml for public search engines to crawl. I think it's a bit silly to forbid this, but after seeing this reaction I removed the sitemap until there's a policy on this.
Simply because a user, given an onion service address, naïvely decides to use one of your Tor2Web nodes, it is unacceptable that your Tor2Web node crawls said onion service simply because it didn't "opt out" of your historically malicious desires to harvest data on Tor users and operators. Consent is not the absence of saying "no" — it is explicitly saying "yes".
(3) I understand Isis's concern about search engines being opt-out, i.e., "Consent is not the absence of saying 'no' — it is explicitly saying 'yes'." When it come to sexual consent I wholly support this standard, and this same point was mentioned during the 90s in the creation of robots.txt. Without taking any side on robots.txt, the winning argument back then was roughly, "Search engines are very useful. We understand people like privacy, so we want a way for them to exclude themselves and make incredibly taboo to violate this exclusion. However, search engines are useful, so useful that it is worth making opt-in be the default." Isis disagrees with this precedent, and there exist others who support it. I support the community coming to a consensus on this issue and if it's widely agreed that previous robots.txt precedent was a mistake, I am down for adjusting.
FWIW, Aaron Swartz was the one who chose the somewhat-odd subdomain structure of tor2web URLs. He chose this structure for the *explicit purpose* of making /robots.txt "just work". So we can put Aaron down in the column for "supports the robots.txt precedent". I find it peculiar that the position of the person to whom Tor 0.2.4.x was dedicated, on one of his signature projects, is considered so out-of-the-norm to attract an analogy to rape.
Perhaps, more explicitly, what we'd like to eliminate is people like you, Virgil. You've admitted publicly, in person, to several of our developers that you harvested HSDir data and then further attempted (unsuccessfully) to sell said data on users to INTERPOL and the Singaporean government.
(4) There is substantial confusion on this. Let us clear the air.
(4.1) For me, Tor's speed and sustainable growth are front-and-center. For example, I wrote a Tor tech report on exactly this topic.
https://research.torproject.org/techreports/tor-growth-2014-10-04.pdf
We all know that .onion sites routinely disappear, and OnionLink has a lot of users who click repeatedly attempting to access long-gone .onion domains. I wanted two things: (a) tell users when a .onion domain no longer exists (so they'll stop refreshing); (b) given the substantial traffic OnionLink generates, minimize the burden we place on HSDirs. To achieve this, whenever there was an error, we used Donnache's python script to see whether the .onion domain existed in the DHT. If the domain didn't exist ("NXDOMAIN"), we cached that answer so we didn't burden the HSDirs with duplicate lookups for nonexistent domains. I felt, and feel, doing this was being a courteous citizen and the right thing to do, but my attempt at courteous behavior generated so much vitriol that OnionLink no longer caches non-existent domains, and correspondingly now burdens HSDirs more. I hope one day it will be politically acceptable to cache NXDOMAIN responses so we have a faster, more scalable Tor network.
(4.2) OnionLink is just too popular. As-is, OnionLink processes ~600 hits/sec and is projected to cross 1000 hits/sec before November. This is beyond my modest researcher's budget. And making OnionLink sustainable is an ongoing effort.
First, I tried the Bitcoin donations but no one donated.
Second I tried to make onion.link a paid-service---see our Google Toolbar experiment: https://chrome.google.com/webstore/detail/onionlink-onion-plugin/pgdmopepkim... But under the paid-service the traffic was so low that onion.link wasn't fulfilling its mission of serving the casual audiences Aaron and I intended.
This left me with the choice between displaying ads or selling minimized logs. There's a natural knee-jerk of *logs are bad*, and I thought it too. But after carefully weighing the each option, I felt, and continue to feel, that selling minimized logs is the lesser evil. Here's why:
With ads, which some Tor2web sites use (e.g., http://onion.nu/), the ad-networks gain access to the raw IP#s, which, for the exactly reasons Isis cited, should be zealously guarded. With minimized log files, onion.link greatly mitigates the risk of bad actors acquiring personally-identifying-information.
In my third attempt at sustainability, as Isis also mentioned, the market for logfiles without personally identifying information is exceedingly small---this is unfortunate. Because it forces onion.link into the option we're currently evaluating---ads.
We fought the good fight for greater privacy, but in the fourth attempt at sustainability, we are now begrudgingly experimenting with ads (something like the Forbes "thought of the day".) The leaking of IP addresses to an ad-network makes me uneasy, but when choosing between anonymous-publishing-platform-with-ads vs shutting-down, I choose platform-with-ads. If a market develops for minimized logs, I hope to return to better protecting user privacy by selling minimized logs and preventing ad-networks from seeing raw IP#s.
We do not tolerate people within our community cooperating with any parties, including law enforcement and government agencies, to deanonymise real world users of the Tor network. Full stop.
Wait what!? People believe I conspired with LEAs and governments to de-anonymize Tor users? OH! I thought people were upset that I thought "Fuck the police" was an unwise PR-strategy for mainstreaming Tor (I still think this). Many previously unexplained behaviors suddenly make a lot more sense.
That's a very black brush you got there. Careful whom you paint with that! Jeez.
*still a little be-wildered*
Okay... first reaction... Tor Project members assisting anyone (LEA or otherwise) in deanonymizing users is a palpable conflict of interest. Conflict of interest is terrible for user trust. Additionally, even the appearance of conflict-of-interest damages user-trust. Ergo yes I wholly support this rule. Thumbs up. +1. Anyone conspiring to subvert Tor's security should be banned.
As to Isis's suggestion that I have conspired to or was an accomplice in de-anonymizing Tor users. It is mistaken, against my values Moreover, and moreover lacks any evidence implying otherwise. The closest thing I do to this spurious charge is sell minimized logs (which, ironically, aims to protect user privacy from ad-networks). So here, let us concretize this---I emailed a day's worth of premium onion.link logs [249MB] to tor-assistants@ . I am totally fine going on record saying that this data is less damaging to privacy than Google Adsense or something similar.
Okay... I think that answers your concerns. Anything else?
-Virgil
On 12 May 2016, at 05:12, Virgil Griffith i@virgil.gr wrote:
Perhaps, more explicitly, what we'd like to eliminate is people like you, Virgil. You've admitted publicly, in person, to several of our developers that you harvested HSDir data and then further attempted (unsuccessfully) to sell said data on users to INTERPOL and the Singaporean government.
(4) There is substantial confusion on this. Let us clear the air.
(4.1) For me, Tor's speed and sustainable growth are front-and-center. For example, I wrote a Tor tech report on exactly this topic.
https://research.torproject.org/techreports/tor-growth-2014-10-04.pdf
...
(4.2) OnionLink is just too popular. As-is, OnionLink processes ~600 hits/sec and is projected to cross 1000 hits/sec before November. This is beyond my modest researcher's budget. And making OnionLink sustainable is an ongoing effort.
First, I tried the Bitcoin donations but no one donated.
Second I tried to make onion.link a paid-service---see our Google Toolbar experiment: https://chrome.google.com/webstore/detail/onionlink-onion-plugin/pgdmopepkim... But under the paid-service the traffic was so low that onion.link wasn't fulfilling its mission of serving the casual audiences Aaron and I intended.
This left me with the choice between displaying ads or selling minimized logs. There's a natural knee-jerk of *logs are bad*, and I thought it too. But after carefully weighing the each option, I felt, and continue to feel, that selling minimized logs is the lesser evil. Here's why:
With ads, which some Tor2web sites use (e.g., http://onion.nu/), the ad-networks gain access to the raw IP#s, which, for the exactly reasons Isis cited, should be zealously guarded. With minimized log files, onion.link greatly mitigates the risk of bad actors acquiring personally-identifying-information.
In my third attempt at sustainability, as Isis also mentioned, the market for logfiles without personally identifying information is exceedingly small---this is unfortunate. Because it forces onion.link into the option we're currently evaluating---ads.
We fought the good fight for greater privacy, but in the fourth attempt at sustainability, we are now begrudgingly experimenting with ads (something like the Forbes "thought of the day".) The leaking of IP addresses to an ad-network makes me uneasy, but when choosing between anonymous-publishing-platform-with-ads vs shutting-down, I choose platform-with-ads. If a market develops for minimized logs, I hope to return to better protecting user privacy by selling minimized logs and preventing ad-networks from seeing raw IP#s.
What I am hearing you saying is:
A. I can't afford to run this service without money. B. I have tried to get money by asking people for money. C. I have tried to get money by collecting user data myself. D. Now I am getting money by allowing others to collect user data.
If this is what you mean, I would suggest that having no service (or having no money), is better than allowing others to collect unknown quantities of data on users. (Isn't this precisely what Tor is trying to prevent?)
As for minimised logs, past experience shows that nominally de-identified user data can often be re-identified with very little effort, particularly when combined with other sources of data.
"Consider auxiliary data when assessing the risk of your research. For example, data from snooping exit traffic can be combined with entry traffic to deanonymize users." https://trac.torproject.org/projects/tor/wiki/org/meetings/2015SummerDevMeet...
I forthrightly attest that:
(1) these logs are socially very interesting, but not actively dangerous.
(2) these logs are substantially less dangerous than running Google ads, which was the alternative.
It seems unwise to release a days' worth of minimised user data on a public mailing list, when the collection of that data is itself under discussion. If the community guidelines are that people should not behave like this, and you've already publicly behaved like this, that puts you in a very awkward position.
Stepping back from your actions to tor2web design questions:
It seems unwise for the tor network to put a single node in a position where it can collect so much information about users. No other node in the network has the power to see both source and destination. Unfortunately, I don't believe there is any technical means of fixing this, because tor2web needs to know the destination address to proxy it, and it operates as a proxy on a network that inevitably leaks source addresses.
But, since tor2web knows more than a guard (which does not see destinations), and in some ways even more than an authority (which also does not see destinations), we must be very careful with how we use this knowledge. Selling logs and injecting advertising looks suspicious, even if done with the best of intentions, and while taking precautions.
I also wonder if tor2web should be considered an unnecessary vulnerability in the tor network, because it exposes too much information to a single node. It's similar to the position that exits and rendezvous points are in if they are one-hop proxies.
As I said:
Once a web header has been transmitted, it's too late: the introduction and/or rendezvous points already know both the tor client's and onion service's IP address, and traffic is flowing. This increases incentives for running malicious nodes or breaking into nodes or observing and correlating node traffic.
That said, onion.link being available over HTTP means that any internet router can see the onion sites people are accessing, and the return traffic. Even with HTTPS, the client still has to provide a domain to onion.link so it can proxy the traffic to the onion site. So tor2web is not in any way a unique position on the path between client and tor2web.
I also wonder if there are any technical means to prevent tor2web clients. If not, perhaps we have to accept it as a necessary evil, and encourage its responsible administration of tor2web via conversations like this. The alternative is the horror of blacklisting particular clients, or, perhaps less horrible, preventing network behaviours that are similar to what tor2web does.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n
What I am hearing you saying is:
A. I can't afford to run this service without money. B. I have tried to get money by asking people for money. C. I have tried to get money by collecting user data myself. D. Now I am getting money by allowing others to collect user data.
If this is what you mean, I would suggest that having no service (or having no money), is better than allowing others to collect unknown quantities of data on users. (Isn't this precisely what Tor is trying to prevent?)
Monetization is certainly an extremely tricky problem and a quagmire none of our other projects even attempt to wade into. News worthy controversies around Firefox and Ubuntu are just about always spawned by an attempt at monetization and with good reason: it puts users at odds with advertisers.
OnionLink is unique in trying to attempt this. All our other projects are either funded by grants or volunteer. I'm in the fortunate position that I have a good paying day job so my tor involvement can be completely voluntary. I don't need to figure out how to monetize Stem which is good, because I find the compromises that would require unacceptably distasteful.
I'm not gonna say "monetization is evil, shame on you". That's silly. Folks need to pay their rent and for a project to have full-time attention it needs some funding source source. But do be careful. As you've already seen the compromises this is forcing you to make go well past making you a pariah to many folks in this community.
Again, very difficult problem and one we're not accustomed to seeing tackled. It'll be interesting to see if you can find a solution that's viable while also having zero negative impacts to uses.
Cheers! -Damian
On May 12, 2016, at 12:29 PM, Damian Johnson atagar@torproject.org wrote:
<snip>
I'm not gonna say "monetization is evil, shame on you". That's silly. Folks need to pay their rent and for a project to have full-time attention it needs some funding source source. But do be careful. As you've already seen the compromises this is forcing you to make go well past making you a pariah to many folks in this community.
Thanks, atagar — you hit the nail on the head. A community member may not make compromises such as this on behalf of the community. When community work is involved, each contributor is expected to disclose plans such as this to peers within the community. Virgil clearly should have known this, and his refusal to recognize it even now places an exclamation point on the matter.
I really appreciate all your work at getting this right,
Tom
If this is what you mean, I would suggest that having no service (or having no money), is better than allowing others to collect unknown quantities of data on users. (Isn't this precisely what Tor is trying to prevent?)
Yes this is what I mean. See the bottom of this email for a presumably more palatable bitcoin-based solution.
It seems unwise to release a days' worth of minimised user data on a public mailing list, when the collection of that data is itself under discussion. If the community guidelines are that people should not behave like this, and you've already publicly behaved like this, that puts you in a very awkward position.
I accidentally posted the URL to the list. My error. I sent the updated URL to isis/matt. I have complete confidence in each of them to distribute the data as they see fit.
It's similar to the position that exits and rendezvous points are in if they are one-hop proxies.
Yes! I strongly support this analogy. Tor2web is a one-hop proxy. Ergo I discourage using Tor2web for anything but regular people linking and sharing onionsite content. Unfortunately, the demand for that solitary use-case is immense.
Stem which is good, because I find the compromises that would require unacceptably distasteful.
I don't like the compromises either, but I see no way around it while doing this at scale (1000+ hits/sec). The only comparable operation is torservers.net. I am immensely jealous of their stream of grants.
An aside, speaking of Torservers, onion.to also allows Google to crawl the onion-web, i.e., https://www.google.com/search?q=site%3Aonion.to&oq=site%3Aonion.to
Just yesterday this practice was compared to rape.
Thanks, atagar — you hit the nail on the head. A community member may not make compromises such as this on behalf of the community.
There was and does not exist any document or policy for what constitutes something worth checking-in about, or even whom to check-in with. Moreover, my previous impromptu check-in place, tor-assistants@, no longer exists. However, if the communtiy is simply asking to say aprised of any monetization/sustainability changes, sure. Can do. Just give me someone to do this with and they will be well-informed. I'll start a blog.
On the topic of monetization, there remains the unexplored strategy of doing top-up metering akin to SatoshiPay.io . The technology hasn't been attempted at this scale, but it would resolve the ad-network problem. So yes lets put that on front-and-center for onion.link development and see how that goes before being forced to choose ads.
Okay good. Yes, this is a step forward.
-V
On Fri, May 13, 2016 at 12:51 AM, Tom Leckrone semprephi@gmail.com wrote:
On May 12, 2016, at 12:29 PM, Damian Johnson atagar@torproject.org wrote:
<snip>
I'm not gonna say "monetization is evil, shame on you". That's silly. Folks need to pay their rent and for a project to have full-time attention it needs some funding source source. But do be careful. As you've already seen the compromises this is forcing you to make go well past making you a pariah to many folks in this community.
Thanks, atagar — you hit the nail on the head. A community member may not make compromises such as this on behalf of the community. When community work is involved, each contributor is expected to disclose plans such as this to peers within the community. Virgil clearly should have known this, and his refusal to recognize it even now places an exclamation point on the matter.
I really appreciate all your work at getting this right,
Tom _______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
On Fri, May 13, 2016 at 04:02:12AM +0800, Virgil Griffith wrote:
There was and does not exist any document or policy for what constitutes something worth checking-in about, or even whom to check-in with. Moreover, my previous impromptu check-in place, tor-assistants@, no longer exists.
tor-project@lists.torproject.org is a good place for this now. Alternatively, the community council may help. It is true there is not a public policy for this, but hopefully it will exist soon.
However, if the communtiy is simply asking to say aprised of any monetization/sustainability changes, sure. Can do. Just give me someone to do this with and they will be well-informed. I'll start a blog.
Not exactly. Monetization is an interesting topic but is quite different from the topic of selling information about users. Not only that, but these are potentially Tor users who could use Tor Browser instead if you taught them about it instead of proxying their requests. The situation has changed over the last 8 years, and using Tor Browser is now significantly easier and faster than it was previously. These are not good excuses anymore.
On the topic of monetization, there remains the unexplored strategy of doing top-up metering akin to SatoshiPay.io . The technology hasn't been attempted at this scale, but it would resolve the ad-network problem. So yes lets put that on front-and-center for onion.link development and see how that goes before being forced to choose ads.
Okay good. Yes, this is a step forward.
Unfortunately, no. We disapprove of how you are operating onion.link and onion.city. Logging client connections is not something the Tor community should accept, and the Tor Project certainly does not support it. As Andrew said in 2008 [0]:
Be aware that if tor2web logs IP addresses, they have yours; I don't believe they do log, however. I wonder if Google, Yahoo, and others will crawl tor2web and start indexing the content.
As far as we know, the other Tor2Web sites do not log client connections. Compromising on storing and selling user data so you can obtain some money for operating the website goes against users' and our expectations of Tor2web, and Tor's brand. Shutting down your Tor2web sites is the responsible decision if you can't find another way for funding it. You violated a fundamental, but unwritten, rule of the Tor community. There are consequences for this.
On 05/13/2016 07:53 AM, Matthew Finkel wrote:
As far as we know, the other Tor2Web sites do not log client connections. Compromising on storing and selling user data so you can obtain some money for operating the website goes against users' and our expectations of Tor2web, and Tor's brand. Shutting down your Tor2web sites is the responsible decision if you can't find another way for funding it.
I do not have the time and energy to really contribute to this thread right now, but some data points: At least for onion.to, that is right: We do not collect logs. We host it at two locations; the total costs of running it are less than 30€ per month, which we pay from our own pockets. Which is totally fine. Adding third party trackers or advertising is out of the question. If I did not have a way to sustain it (which, again, is really cheap) I would simply shut it down. Virgil, if you need 30€/month to operate them and it would buy us an ethical and privacy-friendly service, I'm happy to pay you. Mentioning costs here seem to be simply an excuse. You didn't even ask or tried to raise it in donations.
As far as I know, the other tor2web gateways (tor2web.org, blutmagie etc) do not log either.
Also, there seems to be some (deliberate?) commingling between running a tor2web gateway and putting the discovered sites into a sitemap (which we also don't; we do allow search engine indexing of the individual sites though), and actively harvesting onions at HSDirs. There is clearly a difference, it is not the same thing.
Using my old CDN, Fastly.com, my costs were ~$2000 per month. Under the new setup with 100TB.com (cheapest I could find) costs are $600 per month and climbing. It's unclear to me how you do it so cheaply. Are you metered by how much traffic you generate? If you have suggestions for a host i am interested---anything below $500 per month would be a godsend.
I have never harvested .onion addresses from a HSDir. All I've ever done is cache NXDOMAIN responses, which I've now stopped doing. I also stopped adding to the /sitemap.xml (which I was doing) because it made people upset.
I'm recognize that the logs angle as damaging the Tor brand. I will add a link to download TBB and disclaimer making it excruciatingly clear onion.link is not part of Tor.
Thus far I can commit to each of the above. Over the weekend I'll take a closer look at this.
-V
On Friday, 13 May 2016, Moritz Bartl moritz@torservers.net wrote:
On 05/13/2016 07:53 AM, Matthew Finkel wrote:
As far as we know, the other Tor2Web sites do not log client connections. Compromising on storing and selling user data so you can obtain some
money for
operating the website goes against users' and our expectations of
Tor2web, and
Tor's brand. Shutting down your Tor2web sites is the responsible
decision if
you can't find another way for funding it.
I do not have the time and energy to really contribute to this thread right now, but some data points: At least for onion.to, that is right: We do not collect logs. We host it at two locations; the total costs of running it are less than 30€ per month, which we pay from our own pockets. Which is totally fine. Adding third party trackers or advertising is out of the question. If I did not have a way to sustain it (which, again, is really cheap) I would simply shut it down. Virgil, if you need 30€/month to operate them and it would buy us an ethical and privacy-friendly service, I'm happy to pay you. Mentioning costs here seem to be simply an excuse. You didn't even ask or tried to raise it in donations.
As far as I know, the other tor2web gateways (tor2web.org, blutmagie etc) do not log either.
Also, there seems to be some (deliberate?) commingling between running a tor2web gateway and putting the discovered sites into a sitemap (which we also don't; we do allow search engine indexing of the individual sites though), and actively harvesting onions at HSDirs. There is clearly a difference, it is not the same thing.
-- Moritz Bartl https://www.torservers.net/ _______________________________________________ tor-project mailing list tor-project@lists.torproject.org javascript:; https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
To all:
I recognize that selling minimized log files, even if they could be minimized in a hypothetical way yielding high confidence that it didn't threaten Tor's security model, would still be contrary to the ethos of Tor Project. Towards that end, effective immediately, log files, aggressively minimized or otherwise, are not for sale.
Additionally, I commit to: * making a good faith effort to encouraging clearnet users to use TBB over OnionLink. Details TBD. * making a good faith effort to clearly conveying that OnionLink is not operated by, nor affiliated with, Tor Project. Details TBD. * not appending accessed domains to the /sitemap.xml * prioritizing development of top-up services such as SatoshiPay. With hope, ads will be obviated.
For now I am reserving the right to: * publishing aggregate statistics. Some will disapprove, but there is a dearth of data in this area to inform public policy. And Tor is too important to leave policy to the mercy of sophistry.
* obeying the /robots.txt precedent. From the very beginning, Aaron and I chose Tor2web's unusual URL structure for the explicit purpose of elegantly supporting robots.txt .
With that said, this has been emotionally draining and I'm taking a break from non-Roster Tor work for a few weeks.
-Virgil
On Friday, 13 May 2016, Virgil Griffith i@virgil.gr wrote:
Using my old CDN, Fastly.com, my costs were ~$2000 per month. Under the new setup with 100TB.com (cheapest I could find) costs are $600 per month and climbing. It's unclear to me how you do it so cheaply. Are you metered by how much traffic you generate? If you have suggestions for a host i am interested---anything below $500 per month would be a godsend.
I have never harvested .onion addresses from a HSDir. All I've ever done is cache NXDOMAIN responses, which I've now stopped doing. I also stopped adding to the /sitemap.xml (which I was doing) because it made people upset.
I'm recognize that the logs angle as damaging the Tor brand. I will add a link to download TBB and disclaimer making it excruciatingly clear onion.link is not part of Tor.
Thus far I can commit to each of the above. Over the weekend I'll take a closer look at this.
-V
On Friday, 13 May 2016, Moritz Bartl <moritz@torservers.net javascript:_e(%7B%7D,'cvml','moritz@torservers.net');> wrote:
On 05/13/2016 07:53 AM, Matthew Finkel wrote:
As far as we know, the other Tor2Web sites do not log client
connections.
Compromising on storing and selling user data so you can obtain some
money for
operating the website goes against users' and our expectations of
Tor2web, and
Tor's brand. Shutting down your Tor2web sites is the responsible
decision if
you can't find another way for funding it.
I do not have the time and energy to really contribute to this thread right now, but some data points: At least for onion.to, that is right: We do not collect logs. We host it at two locations; the total costs of running it are less than 30€ per month, which we pay from our own pockets. Which is totally fine. Adding third party trackers or advertising is out of the question. If I did not have a way to sustain it (which, again, is really cheap) I would simply shut it down. Virgil, if you need 30€/month to operate them and it would buy us an ethical and privacy-friendly service, I'm happy to pay you. Mentioning costs here seem to be simply an excuse. You didn't even ask or tried to raise it in donations.
As far as I know, the other tor2web gateways (tor2web.org, blutmagie etc) do not log either.
Also, there seems to be some (deliberate?) commingling between running a tor2web gateway and putting the discovered sites into a sitemap (which we also don't; we do allow search engine indexing of the individual sites though), and actively harvesting onions at HSDirs. There is clearly a difference, it is not the same thing.
-- Moritz Bartl https://www.torservers.net/ _______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
On 13 May 2016, at 07:50, Virgil Griffith i@virgil.gr wrote:
To all:
I recognize that selling minimized log files, even if they could be minimized in a hypothetical way yielding high confidence that it didn't threaten Tor's security model, would still be contrary to the ethos of Tor Project. Towards that end, effective immediately, log files, aggressively minimized or otherwise, are not for sale.
It really would be best if you didn't keep detailed logs at all. Now it is publicly known that you keep detailed logs, servers with access to those logs, and you yourself, become a target for bad actors.
Additionally, I commit to:
- making a good faith effort to encouraging clearnet users to use TBB over OnionLink. Details TBD.
I would also appreciate it if you would encourage TBB users to use onion sites directly, rather than over OnionLink.
On 13 May 2016, at 05:27, Virgil Griffith i@virgil.gr wrote:
Using my old CDN, Fastly.com, my costs were ~$2000 per month. Under the new setup with 100TB.com(cheapest I could find) costs are $600 per month and climbing. It's unclear to me how you do it so cheaply. Are you metered by how much traffic you generate? If you have suggestions for a host i am interested---anything below $500 per month would be a godsend.
I hear CloudFlare offers a free (as in beer) CDN plan that isn't volume-based. They will even let you block Tor Exit nodes (Tor Browser users) if you have a business-level paid plan. https://www.cloudflare.com/plans/
However, I recommend you first try to find a competitor of theirs which also offers feature-based pricing, but without the annoying CAPTCHAs for users with shared IP addresses, such as Tor Browser users.
On 13 May 2016, at 12:01, micah micah@riseup.net wrote:
However, you did not make any clear statement that you are not doing something else that people may similarly object to, but just dont know about it yet, or don't realize how it is being used in a way that may not be ethically ok for the community.
You said "All I've ever done", which is using the past tense, but that doesn't tell me that you are not doing something now, or will do so in the future.
Can you make such a statement now? Are there other things you are doing with Tor that the general community does not know about and cannot make an ethical evaluation?
Has OnionLink ever received a security or privacy review? I'd be interested in how much information about clients is logged and/or made available to hidden services, and vice versa.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n
Virgil Griffith i@virgil.gr writes:
I have never harvested .onion addresses from a HSDir. All I've ever done is cache NXDOMAIN responses, which I've now stopped doing. I also stopped adding to the /sitemap.xml (which I was doing) because it made people upset.
From what you write, it sounds like you didn't harvest .onions from
HSDirs, you did cache NXDOMAIN responses, but stopped, and you stopped adding to /sitemap.xml, that is all good.
However, you did not make any clear statement that you are not doing something else that people may similarly object to, but just dont know about it yet, or don't realize how it is being used in a way that may not be ethically ok for the community.
You said "All I've ever done", which is using the past tense, but that doesn't tell me that you are not doing something now, or will do so in the future.
Can you make such a statement now? Are there other things you are doing with Tor that the general community does not know about and cannot make an ethical evaluation?
isis:
Virgil Griffith transcribed 2.7K bytes:
Here's the line about unacceptability of crawling .onion:
"For example, it is not acceptable to run an HSDir, harvest onion addresses, and do a Web crawl of those onion services."
https://trac.torproject.org/projects/tor/wiki/org/meetings/2015SummerDevMeet...
So, this can indeed be an official policy. But it was the first I had heard of it. And currently at least 3-4 tor2web nodes in good-standing explicitly permit crawling of .onion .
Perhaps, more explicitly, what we'd like to eliminate is people like you, Virgil. You've admitted publicly, in person, to several of our developers that you harvested HSDir data and then further attempted (unsuccessfully) to sell said data on users to INTERPOL and the Singaporean government.
We do not tolerate people within our community cooperating with any parties, including law enforcement and government agencies, to deanonymise real world users of the Tor network. Full stop.
Your previous behaviours were absolutely abhorent, unethical, unacceptable, and cowardly. They are now covered by the official ethical guidelines. Tor2web similarly should be killed with fire as being a blatant and disgusting workaround to the trust and expectations which onion service operators place in the network.
Have a nice day.
MY EARS ARE RINGING FROM THE MAGNITUDE OF THIS MIC DROP
On Thu, May 12, 2016 at 01:08:36AM +0000, isis wrote:
Virgil Griffith transcribed 2.7K bytes:
Here's the line about unacceptability of crawling .onion:
"For example, it is not acceptable to run an HSDir, harvest onion addresses, and do a Web crawl of those onion services."
https://trac.torproject.org/projects/tor/wiki/org/meetings/2015SummerDevMeet...
So, this can indeed be an official policy. But it was the first I had heard of it. And currently at least 3-4 tor2web nodes in good-standing explicitly permit crawling of .onion .
Hi Virgil, I think it's time we have another conversation, privately.
Perhaps, more explicitly, what we'd like to eliminate is people like you, Virgil.
This is harsh, but sadly quite true based on what we've heard and were told. I'm sorry it's taken this long - and required Isis saying something.
You've admitted publicly, in person, to several of our developers
We do not tolerate people within our community cooperating with any parties, including law enforcement and government agencies, to deanonymise real world users of the Tor network. Full stop.
We shouldn't, but it seems like we do. We've significantly improved monitoring the Tor network for malicious relays and encouraging directory authorities reject them, but we're still struggling with how we handle people within our community who are potentially acting passively malicious. I hope we will act swiftly and decisively when we know a community members is actively acting malicious. That's to be determined, I suppose.
The easy and usually correct answer is "reject first and ask questions later". We started there but then stopped after some fruitful conversations. It's time we reassess this. However, that being said, it's difficult because we don't actually have a good method for kicking out a person from the community - if that is the chosen course of action. In addition, we don't have the resources available for mentoring or "rehabilitation" (or whatever that would be called), but still non-action is the worst possible default.
Your previous behaviours were absolutely abhorent, unethical, unacceptable, and cowardly. They are now covered by the official ethical guidelines.
Virgil, I hope this is clearly understandable for you. If not, and for anyone else reading this thread, then to the best of our abilities, we should not and must not implicitly allow someone to actively harm Tor users. If you are an active participant in this community, then it is implicitly assumed you are not malicious. Any actions by you that are contrary to this are not acceptable.
Tor2web similarly should be killed with fire as being a blatant and disgusting workaround to the trust and expectations which onion service operators place in the network.
Personally, I have varying opinions about Tor2Web's use, but at this point I do not support it. Despite it's inherent problems, I think it was a useful tool when it was initially designed and implemented. Now I believe it is actively harming (potential) Tor users. There is nothing we can do that will prevent people from using it, but the Tor2Web gateways are designed so they can easily be used instead of linking directly to an onion site. As a result, it provides websites with the privilege of both forcing the user to leak the onion service address to the Tor2Web gateway and (possibly) leaking the Tor user's IP address when they request the onion site, without the user's consent. If the Tor2Web gateways were not available then the user would either use Tor Browser or not visit the site - both are more preferable than leaking the client's IP address to the Tor2Web gateway.
I don't know how we can undo the damage from this. I'm open to suggestions for it.
Essentially, as I see it, we must take a strong stance against people who are harming Tor users. I don't care if the users are using Tor in TAILS, Tor Browser, ricochet, or they're connecting via a Tor2Web-backed website - these are all Tor users. There's something to be said for malicious Tor users and creepy/sick/crazy Tor users who are hurting other people, but those are edge cases they should be handled uniquely (and maybe not by the Tor community at all) without affecting the millions of people who use Tor for their own protection.
Thanks, Matt
On Wed, May 11, 2016 at 04:15:25PM +0800, Virgil Griffith wrote:
Here's the line about unacceptability of crawling .onion:
"For example, it is not acceptable to run an HSDir, harvest onion addresses, and do a Web crawl of those onion services."
https://trac.torproject.org/projects/tor/wiki/org/meetings/2015SummerDevMeet...
So, this can indeed be an official policy. But it was the first I had heard of it. And currently at least 3-4 tor2web nodes in good-standing explicitly permit crawling of .onion .
It is not crawling itself that is bad. If an onion service lets you fetch a lot of pages at once from it, or it decides to use rate limiting or require login or whatever to not let you do this rate of fetches, I think that's a policy decision on the part of the onion service.
What the above notes referred to is running a relay that gets the HSDir flag, and then writing down the onion addresses that you see on hidden service descriptors that get uploaded to your relay. People who run onion services have an expectation of privacy from the HSDir relays, and we'd like to follow through on it. In the long term that means the design changes in proposal 224. In the short term it (alas) means enforcing it via community ways.
Do the tor2web nodes you're talking about do this step? Or did you just mean "letting people load a lot of pages"?
For more context, see the ethics/safety section of the 32c3 onion services talk: https://media.ccc.de/v/32c3-7322-tor_onion_services_more_useful_than_you_thi... (starting around the 30 minute mark)
("Harvesting" onion addresses that people tell your tor2web website isn't either of these things, and I'm not sure what I think of it.)
Teor: Apologies for being dumb, but can you explain why it's bad for tor2web-nodes to connect to single-onion services? Both Tor2web and Single-onion say IN BIG BOLD LETTERS that using these remove your anonymity. Given that these are intentionally meant to be "expert features" for people who know what they are doing, I don't immediately see a concern sufficiently large that it merits special handling. Can you enlighten me?
It puts the relays at new risk. Right now breaking into a rendezvous point is not useful for linking users to the onion services they visit. If both sides are using short circuits, then the rendezvous point is acting as a single-hop proxy. And if we have a design where _sometimes_ the rendezvous point knows both sides, then it becomes a smart strategy to attack it, just in case this is one of those times.
--Roger
On Thu, May 12, 2016 at 9:26 AM, Roger Dingledine arma@mit.edu wrote:
It puts the relays at new risk. Right now breaking into a rendezvous point is not useful for linking users to the onion services they visit. If both sides are using short circuits, then the rendezvous point is acting as a single-hop proxy. And if we have a design where _sometimes_ the rendezvous point knows both sides, then it becomes a smart strategy to attack it, just in case this is one of those times.
Okay, That makes a lot of sense. Okay yes I support that. If a lot of users were using Tor2web and a lot of websites were on single-onion services, I totally understand how that makes the middle nodes juicier targets for intrusion. And we'd like to minimize their juiciness. So we need a way for (a) a tor2web user to detect if a domain is a single-onion service or (b) a single-onion service to detect whether someone is a tor2web user, and then put another hop in the middle.
I don't know of any way to detect (a). Maybe someone can enlighten me. For (b), tor2web requests always have a "x-tor2web: true" request header. So the single-onion service could detect that. It's possible that someone will modify their tor2web install to not have that header, but it seems sensible simply to forbid that behavior as "damaging Tor operators".
-V
On 12 May 2016, at 05:17, Virgil Griffith i@virgil.gr wrote:
On Thu, May 12, 2016 at 9:26 AM, Roger Dingledine arma@mit.edu wrote:
It puts the relays at new risk. Right now breaking into a rendezvous point is not useful for linking users to the onion services they visit. If both sides are using short circuits, then the rendezvous point is acting as a single-hop proxy. And if we have a design where _sometimes_ the rendezvous point knows both sides, then it becomes a smart strategy to attack it, just in case this is one of those times.
Okay, That makes a lot of sense. Okay yes I support that. If a lot of users were using Tor2web and a lot of websites were on single-onion services, I totally understand how that makes the middle nodes juicier targets for intrusion. And we'd like to minimize their juiciness. So we need a way for (a) a tor2web user to detect if a domain is a single-onion service or (b) a single-onion service to detect whether someone is a tor2web user, and then put another hop in the middle.
I don't know of any way to detect (a). Maybe someone can enlighten me. For (b), tor2web requests always have a "x-tor2web: true" request header. So the single-onion service could detect that. It's possible that someone will modify their tor2web install to not have that header, but it seems sensible simply to forbid that behavior as "damaging Tor operators".
I strongly recommend you read Trac ticket #17945 - if it's not clear, let's work on improving it. https://trac.torproject.org/projects/tor/ticket/17945
Web headers only work for websites, and not for other protocols that use similar mechanisms to tor2web. (Single onion services work for multiple protocols, not just websites.)
Once a web header has been transmitted, it's too late: the introduction and/or rendezvous points already know both the tor client's and onion service's IP address, and traffic is flowing. This increases incentives for running malicious nodes or breaking into nodes or observing and correlating node traffic.
Here's one way this can work:
Nodes can protect themselves from becoming one-hop proxies (exits already do something similar), by rejecting connections where neither side is in the consensus.
Single onion services can advertise their single-hop connections to introduction and rendezvous points in their descriptors.
Then, we can teach tor2web and other one-hop clients to avoid connection failures by creating multi-hop paths to single onion introduction and rendezvous points. (It's best if the client does this, because service connections to introduction points are used for multiple clients, and while clients could tell a service that they want a the service to connect multi-hop to the rendezvous, this would involve a call-based protocol change.)
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n
On Fri, May 06, 2016 at 07:36:25PM +1000, Tim Wilson-Brown - teor wrote:
The rendezvous point (and possibly the introduction point) could terminate the connection if it has a single hop on both ends. However, this could result in false positives if the consensus gets out of sync.
Yes, I think we should do this. It is to protect the relays, in just the same way as exits currently refuse to exit if the previous hop isn't a relay: https://trac.torproject.org/projects/tor/ticket/1751
Or is there a reliable way for a relay to detect non-relays without using the consensus?
Nope, the consensus is the best way we've got.
If we add this feature, we'll want to mod directory_fetches_from_authorities() like we did for #1751, to make sure potential rendezvous points aggressively keep up with new directory information (like exits do).
You're right that we also want a mechanism to avoid both sides innocently trying to do the 1-hop thing, and then finding that they failed because they both tried it. I think your notion of a line in the hsdesc is not a bad one.
It looks like https://trac.torproject.org/projects/tor/ticket/17945 is the place to move forward here.
--Roger
tor-project@lists.torproject.org
-
Alison -
Damian Johnson -
isis -
Matthew Finkel -
micah -
Moritz Bartl -
Roger Dingledine -
Tim Wilson-Brown - teor -
Tom Leckrone -
Tom Ritter -
Virgil Griffith