doc: Add 5 privacy recommendations in tor.md #22316

ghost · 2021-06-23T00:29:54Z

Tor bridges
Disable listening for max privacy
Torsocks
onlynet=onion trade-offs
Deleting onion_v3_private_key is not one of the 'best practices'

I have divided #21157 in 3 parts (Alternative to PR 21157):

This PR for privacy recommendations
DNS requests: doc: Highlight DNS requests part in tor.md #22317
Will plan how to add examples in a better way later this week

fanquake · 2021-06-23T00:37:37Z

I have divided #21157 in 3 parts (Alternative to PR 21157):

Why?

ghost · 2021-06-23T00:48:24Z

Why?

It will be easier to review and get merged soon IMO if enough people agree on changes
Earlier PR had a bigger scope with title as "Improve Tor docs", was difficult to add every suggestion and made no sense in keeping basic doc improvements pending for months.
Few reviewers had issues with the "examples" part and "DNS requests" thing in previous PR. Keeping things separate and specific to one type of changes in a PR should help.
Lot of comments in previous PR. It's difficult for anyone trying to review and read all the conversation however I don't want the contribution by everyone in the previous PR to be wasted so proposing a better alternative with changes in separate PRs.

DrahtBot · 2021-06-23T00:53:38Z

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

No conflicts as of last run.

jarolrod · 2021-06-23T01:03:09Z

my opinion is don't split up #21157. Splitting up #21157 adds greater burden on reviewers and burden on you with required rebases.

While #21157 has required a lot of review attention, I don't think that splitting it up will make it easier to merge. If there is discussion to be had and reviewers still have feedback, seems suboptimal to split up this discussion over three PR's which all have the same purpose: to improve the tor docs.

If you have made the decision to split up #21157, then you should close it in favor of the three separate PR's.

ghost · 2021-06-23T01:19:02Z

three PR's which all have the same purpose: to improve the tor docs.

'Improving docs' is a bigger scoping of PR which is not helping in any way. Changes to docs that are specific get merged or rejected soon.

If you have made the decision to split up #21157, then you should close it in favor of the three separate PR's.

Done

Rspigler · 2021-06-23T04:56:23Z

ACK commit b7d465aa6d14b46c96870930679d6d5cb0b3b6f0

I think splitting the PR up how you have is beneficial (I had issues with the examples you added, but like this change and the DNS change in 22317).

Rspigler · 2021-06-23T05:01:58Z

Please tag when examples PR is added

doc/tor.md

RiccardoMasutti

ACK 2c18e7f

lsilva01

ACK 2c18e7f

Rspigler · 2021-06-25T08:17:56Z

Good changes. ACK 2c18e7f6614d665f4eb9891f83391a5317e7d113
Apologies for missing the onlynet=onion/tor mistake

ghost · 2021-06-25T11:36:12Z

I think there is grammatical error but not sure:

--- a/doc/tor.md
+++ b/doc/tor.md
@@ -245,7 +245,7 @@ for normal IPv4/IPv6 communication, use:
   As Tor addresses may be created at no cost, an attacker can potentially flood the network with many Tor
   nodes and receive all of the outbound Tor connections an `onlynet=onion` node makes.

-  This is significantly less a concern with if you make `-addnode` connections to trusted peers
+  This is significantly less a concern if you make `-addnode` connections to trusted peers
   (even if they're onion addresses). It's also alleviated with IPv4/IPv6 (especially when using the -asmap
   configuration option) due to the cost of obtaining IPs in many networks.

Rspigler · 2021-06-25T22:08:22Z

Yes, that change should be made, thanks!

doc/tor.md

Rspigler · 2021-06-28T19:10:27Z

tiny nit

- Tor bridges - Disable listening for max privacy - Torsocks - `onlynet=onion` trade-offs - Deleting `onion_v3_private_key` not best practice

luke-jr · 2021-06-30T05:55:51Z

doc/tor.md

+  If you are in an environment that does not permit direct Tor connections or the use
+  of Tor bridges, then considering the trade-offs, it may not be safe to use Tor.
+
+- For maximum privacy, it is preferable to disable accepting incoming connections.


This seems like bad advice. Incoming connections should be encouraged, and any potential privacy risks addressed.

Bitcoin Core behind a tor proxy with no incoming connections is better for privacy in comparison to listening over Tor IMO. It was suggested by @gmaxwell and reviewers(Sipa and Jonatack) in previous PR had no issues with it:

#17491 (comment)
#21157 (comment)

Both of these appear to be talking about security, not privacy. And not as general advice, but as super-paranoia.

This comment by Sipa specifically mentioned privacy: #21157 (comment)

re: not encouraging this setting; I think the section on Sybil Attacks and Network Partitioning covers that, right?

I think many users will read this and go "oh good, I want maximal privacy, so I'll disable listening." IMO the statement as it is, and placed where it is, lacks nuance and context. Privacy is a slippery and multifaceted thing with a number of tradeoffs; I'm not sure that discussion should be in this doc, but it probably should be if advice like this is given in the repository, as any such advice here might be seen as a reference.

Also, some of the thoughts here may also pertain to other privacy networks, e.g. I2P and perhaps others at some point like CJDNS. Should there be privacy recommendations in each doc, or rather in one place (doc/privacy.md?) that interrelates between the networks.

IMO the statement as it is, and placed where it is, lacks nuance and context

Agree

I'm not sure that discussion should be in this doc

This doc had a section for privacy recommendations

I am trying to share few things that I learnt during different conversations about privacy, relevant to this doc and can help others

as any such advice here might be seen as a reference

They should be used as reference. I had two options when I started researching about these things:

Share my thoughts and discuss on social media about it. Few people will read it and forget it.

Create a pull request with basic things that can be added, discuss with PR reviewers and help more users know about it in a better way.

I think 2 works better.

Example: Deleting onion_private_key is mentioned on multiple websites: Bitcoin Wiki, Bisq Wiki etc. Editing every wiki, commenting on each social media post, etc. will take lot of time and people will still believe what they read in docs and not me.

Should there be privacy recommendations in each doc, or rather in one place (doc/privacy.md?) that interrelates between the networks.

I think i2p and Tor have few similarities and differences. It's better we have separate docs and maintain privacy recommendations separately but have no issues with doc/privacy.md suggestion. I have added few things in a different repository used by lot of people to learn Bitcoin from command line:

Differences: https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/15_0_Using_i2p.md

Trade-offs: https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/15_1_i2p_service.md

luke-jr · 2021-06-30T05:57:42Z

doc/tor.md

+  The `onlynet=onion` configuration option can potentially ensure the node attempts to only
+  connect over Tor. It is more private when you combine it with no reachable IPv4/IPv6 address,
+  in particular if you want to broadcast transactions without them being correlatable with your IP.


This is bad advice. Tor is a centralised network, and using it as your only network puts the user at risk for no benefit. It isn't more private, as it doesn't do anything to stop the "cookies" (UTXO/address relationships) Bitcoin wallets need to work.

I think 'more private' here is a comparison between onlynet=onion and onlynet=onion + bind=onion. This was suggested by @sipa in #21157 (comment)

I relate to Luke's feedback and am a bit uncomfortable with the lines of advice he points out; maybe they could use more nuance and context. Otherwise, they seem likely to be misinterpreted or followed somewhat blindly.

maybe they could use more nuance and context

Agree

ghost · 2021-07-12T19:50:29Z

@jonatack @luke-jr write your own recommendations when you feel like that everyone agree to

86a4a15 Highlight DNS request part (Prayank) Pull request description: _What?_ Highlight DNS requests part in Proxy section _Why?_ 1. DNS requests are very important while considering privacy 2. Lot of users might skip reading it because of the way it is mixed with everything else in the doc right now 3. I have seen lot of users ignoring DNS requests or unaware of such things while using privacy tools _How?_ Initially I had tried keeping these lines separate from code block but [Jonatack didn't agree with the changes](bitcoin/bitcoin#21157 (comment)). Harding suggested using [bold/italic in `<pre></pre>`](bitcoin/bitcoin#21157 (comment)). I have used the suggestions from previous PR and added `---` This is a part of alternative described in bitcoin/bitcoin#22316 ACKs for top commit: jonatack: ACK 86a4a15 Rspigler: ACK 86a4a15 achow101: ACK 86a4a15 RiccardoMasutti: ACK 86a4a15 lsilva01: ACK bitcoin/bitcoin@86a4a15 kristapsk: ACK 86a4a15 theStack: ACK 86a4a15 Tree-SHA512: a4fe0e8c08df330e5ca78ce19ce74be7034c653f4374469d928908847a6debf385283e3a6da66de600566c7bab6290ccd35df26864aef94cbb3f294123391437

86a4a15 Highlight DNS request part (Prayank) Pull request description: _What?_ Highlight DNS requests part in Proxy section _Why?_ 1. DNS requests are very important while considering privacy 2. Lot of users might skip reading it because of the way it is mixed with everything else in the doc right now 3. I have seen lot of users ignoring DNS requests or unaware of such things while using privacy tools _How?_ Initially I had tried keeping these lines separate from code block but [Jonatack didn't agree with the changes](bitcoin#21157 (comment)). Harding suggested using [bold/italic in `<pre></pre>`](bitcoin#21157 (comment)). I have used the suggestions from previous PR and added `---` This is a part of alternative described in bitcoin#22316 ACKs for top commit: jonatack: ACK 86a4a15 Rspigler: ACK 86a4a15 achow101: ACK 86a4a15 RiccardoMasutti: ACK 86a4a15 lsilva01: ACK bitcoin@86a4a15 kristapsk: ACK 86a4a15 theStack: ACK 86a4a15 Tree-SHA512: a4fe0e8c08df330e5ca78ce19ce74be7034c653f4374469d928908847a6debf385283e3a6da66de600566c7bab6290ccd35df26864aef94cbb3f294123391437

ghost mentioned this pull request Jun 23, 2021

doc: Highlight DNS requests part in tor.md #22317

Merged

DrahtBot added the Docs label Jun 23, 2021

DrahtBot mentioned this pull request Jun 23, 2021

doc: Improve Tor docs #21157

Closed

kristapsk suggested changes Jun 23, 2021

View reviewed changes

doc/tor.md Outdated Show resolved Hide resolved

jonatack reviewed Jun 23, 2021

View reviewed changes

doc/tor.md Outdated Show resolved Hide resolved

jonatack reviewed Jun 23, 2021

View reviewed changes

doc/tor.md Outdated Show resolved Hide resolved

RiccardoMasutti approved these changes Jun 23, 2021

View reviewed changes

lsilva01 approved these changes Jun 23, 2021

View reviewed changes

Rspigler reviewed Jun 28, 2021

View reviewed changes

doc/tor.md Outdated Show resolved Hide resolved

Add 5 privacy recommendations

45c1bfa

- Tor bridges - Disable listening for max privacy - Torsocks - `onlynet=onion` trade-offs - Deleting `onion_v3_private_key` not best practice

luke-jr suggested changes Jun 30, 2021

View reviewed changes

ghost closed this Jul 12, 2021

bitcoin locked as resolved and limited conversation to collaborators Aug 16, 2022

This pull request was closed.

doc: Add 5 privacy recommendations in tor.md #22316

doc: Add 5 privacy recommendations in tor.md #22316

Uh oh!

Conversation

ghost commented Jun 23, 2021 • edited by ghost Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fanquake commented Jun 23, 2021

Uh oh!

ghost commented Jun 23, 2021 • edited by ghost Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DrahtBot commented Jun 23, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Conflicts

Uh oh!

jarolrod commented Jun 23, 2021

Uh oh!

ghost commented Jun 23, 2021 • edited by ghost Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Rspigler commented Jun 23, 2021

Uh oh!

Rspigler commented Jun 23, 2021

Uh oh!

Uh oh!

Uh oh!

Uh oh!

RiccardoMasutti left a comment

Choose a reason for hiding this comment

Uh oh!

lsilva01 left a comment

Choose a reason for hiding this comment

Uh oh!

Rspigler commented Jun 25, 2021

Uh oh!

ghost commented Jun 25, 2021

Uh oh!

Rspigler commented Jun 25, 2021

Uh oh!

Uh oh!

Rspigler commented Jun 28, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ghost Jul 1, 2021 • edited by ghost Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ghost commented Jul 12, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

ghost commented Jun 23, 2021 •

edited by ghost

Loading

ghost commented Jun 23, 2021 •

edited by ghost

Loading

DrahtBot commented Jun 23, 2021 •

edited

Loading

ghost commented Jun 23, 2021 •

edited by ghost

Loading

ghost Jul 1, 2021 •

edited by ghost

Loading