I'm reading Max Hillebrand's Praxeology of Privacy #1489281 and would very much enjoy the Stackers' opinions about the things inside. Your commentary is welcome even if you don't have time to read the book. Part I - #1501602;, Part II - #1507762;, Part III - #1515488;, Part IV - #1519389;, Part V - #1523102
This is the last part of The Praxeology of Privacy was full of interesting tools and a number of interesting discussions about actually implementing privacy practices in real life. While Hillebrand clearly knows his stuff, I think I would have been happier with a less broad survey and more specific approach. As Hillebrand points out at the beginning of this part:
Security is always relative to a specific adversary. Defensive measures are arbitrary until the actor knows whom the defense is meant to resist.
Threat modelling is essential, and in trying to write a broad survey it felt like Hillebrand missed the opportunity to make a more useful and appealing work -- Praxeology of Privacy feels like a book aimed at the privacy-curious, but it also attempts to address corporate privacy and resisting state-actors pursuing targeted attacks. I think I would have enjoyed a more conversational book that focused on just one category of threats.
Nevertheless, this part contains a number of very helpful observations:
Perfect privacy is unachievable. Pursuing perfection leads to paralysis or burnout. The practical goal is continuous improvement: making your position better today than yesterday, better this year than last year.
This requires accepting imperfection, since every system has vulnerabilities and every practice has limitations; the question is not whether vulnerabilities exist but whether your position is improving. Prioritize high-impact changes: some modifications provide large privacy improvements with minimal effort, while others require significant effort for marginal improvement. Build sustainable habits, because practices that require constant vigilance fail when vigilance lapses; sustainable privacy comes from habits that become automatic, not heroic efforts that cannot be maintained. Avoid all-or-nothing thinking: partial implementation provides partial protection.
Before selecting implementation steps, apply the threat modeling.
Diminishing returns apply to OPSEC. Early measures provide large benefits: using encrypted messaging instead of plaintext provides massive security improvement. Later measures provide smaller benefits: using three layers of VPNs instead of two provides marginal improvement. Excessive measures create new risks, as complexity increases the chance of misconfiguration.
These sorts of observations are very useful and I am tempted to make a bullet point list of them that I keep on a sticky note somewhere as a reminder. Privacy feels like a castle made of building blocks and it easy to get caught up messing about with the detail work when your foundational blocks are precarious or even missing.
Hillebrand has a very useful discussion about privacy practices in the context of one's community. I know just how difficult it is to get family members to use privacy preserving tech -- I haven't been in the family group chat for years because they refuse to get off WhatsApp and I refuse to use the app. My wife doesn't feel anywhere near as strongly about privacy as me and her devices are major privacy holes...navigating privacy in this context is important to keep in mind.
Households need shared rules. One person posting family schedules publicly can undo another person’s careful location discipline. One spouse using exchange-linked coins for sensitive purchases can expose the other. One child using the family tablet with real-name accounts can collapse identity separation for everyone who shares the device
Community can assist our privacy goals as well. Trading partners on peer-to-peer exchanges, merchants who accept bitcoin, coinjoins and payjoins all require the participation of other people.
Privacy is often framed as individual practice, but community expands what individuals can achieve.
Hillebrand includes a three-tier list of actions one can take to increase privacy. This list is presented in narrative paragraphs, but I've distilled it to bullet-points. It's supposed to start with the easiest to achieve privacy practices and move on to progressively more involved and difficult practices. I don't think he got the list quite right, but there are great suggestions here and this is the sort of thing that can be really handy:
Beginner level
- Avoid password resuse
- Use two-factor authtentication apps
- Use encrypted communication
- Use privacy browsers like Mullvad Browser or LibreWolf
- Use an email aliasing service
- Encrypt your hard drive
Intermediate level
- Use peer-to-peer exchanges to buy bitcoin
- Use lightning for spending bitcoin
- Use a VPN
- Practice identity separation and security awareness
Advanced level
- Requires a high level of self-discipline
- Use Nym for network anonymity
- Use Tor browser
- Use Tails or Qubes OS
- Use GrapheneOS
- Consider using separate devices for separate identities
- Consider using separate network paths for separate identities
This list is helpful in organizing your mind around tasks you might choose to pursue to preserve your own privacy and I'd be interested to hear the stackers' opinions about which practices are most beneficial to the average bitcoiner.
The book's penultimate chapter contains a very interesting discussion of the role of trust in privacy.
The same continuity that lets others trust you also lets others track you: pseudonymity is workable because it carries history, and that same history can expose patterns and counterparties to anyone who watches long enough.
While not entirely at odds, there is a tension between reputation and webs of trust and privacy -- but this tension is resolved in the famous cypherpunk definition of privacy: the ability to selectively reveal oneself to the world. Technology can work wonders in helping individuals maintain their privacy -- and therefore their sovereignty -- but it ultimately serves the purpose of allowing us to get to know each other (whether commercially or personally).
The footnotes sections for all the chapters have consistently been goldmines of interesting reading for further exploration. All along, I've tried to list a selection of items that caught my eye, but if you wanted the short version of Praxeology of Privacy you could just read the footnotes and be well-served.
- Michael Bazzell, Extreme Privacy: What It Takes to Disappear, 5th ed. (2023)
- Frans Osinga, Science, Strategy and War: The Strategic Theory of John Boyd (Routledge, 2007)
- Boyd’s own briefing documents, including “Destruction and Creation” (1976) and the “Patterns of Conflict” slide deck, are archived at https://www.dnipogo.org/john-r-boyd/
- Robert Coram, Boyd: The Fighter Pilot Who Changed the Art of War (Little, Brown, 2002)
- Kyle Rearden and Shane Radliff, Just Below the Surface: A Guide to Security Culture (Independently Published, 2019)
- Andy Greenberg, “How the Feds Took Down the Dread Pirate Roberts,” Wired, November 18, 2013
- Parmy Olson, We Are Anonymous: Inside the Hacker World of LulzSec, Anonymous, and the Global Cyber Insurgency (New York: Little, Brown, 2012)
- On Reality Winner and printer steganography, see the FBI affidavit in United States v. Reality Leigh Winner, 1:17-MJ-590 (S.D. Ga. 2017)
- Graham Cluley, “Fugitive John McAfee’s location revealed by photo meta-data screw-up,” December 3, 2012
- Moxie Marlinspike, “The Network in Motion” (2016)
- Micah Lee, “A DIY Guide to Feminist Cybersecurity,” The Intercept, November 12, 2017, https://theintercept.com/2017/11/12/a-diy-guide-to-f
eminist-cybersecurity/ - Martin Shelton maintains current step-by-step recommendations at https://martinshelton.medium.com.
- The Electronic Frontier Foundation’s Surveillance Self-Defense guide at https://ssd.eff.org
- the Electronic Frontier Foundation’s Surveillance Self-Defense guide on password managers at https://ssd.eff.org/en/module/animated-overview-using-password-managers-stay-safe-online
- https://transactionfee.info covers chain-analysis techniques and defenses.
- Sparrow Wallet’s documentation at https://sparrowwallet.com/docs covers coin control, label hygiene, and PayJoin integration
- https://github.com/awesome-selfhosted/awesome-selfhosted.
- Paul Resnick and Richard Zeckhauser, “Trust Among Strangers in Internet Transactions: Empirical Analysis of eBay’s Reputation System,” in The Economics of the Internet and E-Commerce, ed. Michael Baye (Elsevier, 2002)
- Timothy May, “Crypto Anarchy and Virtual Communities” (1994)
- Edward Stringham, Private Governance (Oxford, 2015)
-David Friedman, The Machinery of Freedom, 3rd ed. (2014) - Nick Szabo, “Formalizing and Securing Relationships on Public Networks” (1997)
- Nick Szabo, “Negative Reputations” (1996)
- Stephan Kinsella, “Defamation as a Type of Intellectual Property,” in A Life in Liberty (Mises Institute, 2024)
- Nick Szabo, “Rights, Remedies, and Security Models” (2004)
Great post because it includes a practical todo list. Modern tech companies are all the extension of the state. As the state gets more oppressive year to year, so does software. It may be scary to trust your secrets to anonymous developers behind Graphene, but you don't have to go all-in. It may also seem like a company like Apple would be more trustworthy because you know who is in charge, but realistically, you have very little leverage over such a big company, while Graphene developers have a reputation to lose, so there is no reason to trust Graphene less compared to a traditional company.
You can review Graphene (the non secure version) so with some skills, a good eye, great analytic capacity and a superb system to track your patches in trust is diminished.
What you cannot review is pixel firmware and the embargoed security patches. You can try to reverse engineer that. Depending on how skilled you and your bots are, you may be able to get a good guess.
But you'll still have to trust Google. Much more than Graphene.
I was mostly addressing arguments similar to "what is preventing Graphene devs from backdooring it?"
I addressed EXACTLY that argument. Read again.
What I'm trying to say is that most people won't do that, so instead they rely on accountability. E.g., you don't need to review Apple's code (some of it is open source), because you can always sue them (in theory) because they are a legit company.
I feel like to many Graphene is a toy project, but it is now backed by a foundation and has a reputation, so the argument is moot, and there's no need to be worried about who is responsible.
Of course not. In fact, I doubt that there are any stackers here besides their employees and yours truly that ever even looked at the repo further than seeing the manifest and realizing that there is a shitton of stuff you need to look at in order to really know. I had to design a system just for my notes back when I did it all manually. To not miss anything.
You cannot sue Apple when you're dead. You cannot sue Graphene when you're dead. And guess what, you can not sue Google when you're dead either. Posthumous security is interesting by the time we can upload our consciousness to a substrate, Iain Banks style. Until then, prevention takes precedence.
Here is the test to see if you actually need security: how many people could you comfortably share your location with the past month without lying to them? If the answer is greater than 1, you're probably not in great need of elevated security measures. After all, do you trust your mom to not tell your adversary where you are at with the wrong side of a barrel pointed at them?
However, situations change. If you feel you may ever be in that situation in the future, take it from someone that didn't prepare: its better to build your security now, before you're under attack.
I recall @optimism pushing back on this generality. I think the idea is that there's so much information adjacent to us that imputing what's missing is pretty easy until you hit a pretty high threshold of restricting what's leaking.
Right, so I decided to just read the chapter to better understand what Max means. He's right in the way that in both depth and breadth of measures, (but I'd argue mostly depth, that's also what the "3 vpns" comment is about) there must be an end to your scope or you will just make it impossible to do anything and you'll mess up. On top, security goes principally at the cost of functionality, so he is also right that the further you drive it the more complex and the less functional your operational environment becomes.
What I'd push back against: I think that the diminishing returns do not apply to precision, but only to the extent of the scope, and most significantly to depth and much less to breadth: if you need to secure something there are easy(ish) to define limits to what and whom is in-scope. That scope is often fairly static if it is well reasoned. Then you make informed decisions and you test everything you want to do before you do it against that scope. If you mess up, and leak something critical once, you need to reset, because you cannot unleak. And resets are disruptive, expensive events. So you want to prevent that. The biggest mistake is taking that leak as residual risk inside the must-secure scope and letting it sit.
Data is fluid.
deleted by author