As a software engineer who specialized in cryptography in the 1990s and didn't work for the NSA (working for RSADSI, Bell Canada and Certicom) I feel I have an informed vantage point from which to offer notes.<p>a) This seems like a decent introduction to the subject of cryptographic regulation in the last 30 years. It's far from exhaustive, however. I <i>do</i> appreciate the collected references from diverse points in the last several decades.<p>b) I would have mentioned "Sink Clipper" and the ACLU "dotRights" campaigns. Neither are especially easy to find in the increasingly enshittified google cache, but Le Monde Diplomatique has this article, complete with a link to Sink Clipper poster (I think from the mind of Kurt Stammberger) that no collection of CypherPunk oriented ephemera from the era can be without: <a href="https://mondediplo.com/openpage/selling-your-secrets" rel="nofollow">https://mondediplo.com/openpage/selling-your-secrets</a><p>The ACLU dotRights.org site seems to have receded into history, but some of it's content is still available at the archive. For example: <a href="https://web.archive.org/web/20100126102126/http://dotrights.org/news" rel="nofollow">https://web.archive.org/web/20100126102126/http://dotrights....</a><p>c) Herb Lin presented a very nice paper back in the day comparing PROPOSED encryption regulation with ACTUAL encryption regulation. I think the thesis was through the 90s, proposed regulation was increasingly draconian (clipper, etc.) but actual regulation was liberalizing (effective deregulation of open-source tools.) I found Herb's page at Stanford and heartily recommend it if for no other reason than it's sheer volume of written material: <a href="https://herblin.stanford.edu/recent-publications/recent-publications/articles-and-book-chapters" rel="nofollow">https://herblin.stanford.edu/recent-publications/recent-publ...</a><p>d) I was a little surprised the wired article linked to at the beginning of the piece didn't have that issue's front cover, which was sort of a cultural touchstone at the time. But you can see it here: <a href="https://pluralistic.net/2022/03/27/the-best-defense-against-rubber-hose-cryptanalysis/" rel="nofollow">https://pluralistic.net/2022/03/27/the-best-defense-against-...</a> - and this one: <a href="https://www.reddit.com/r/Bitcoin/comments/1cgpktp/31_years_ago_today_the_forefathers_of_bitcoin_on/#lightbox" rel="nofollow">https://www.reddit.com/r/Bitcoin/comments/1cgpktp/31_years_a...</a> (dang, look at those non-receding hairlines!)<p>e) Making the web "secure" or "private" is like putting lipstick on a pig. Modern web technology is designed to de-anonymize and collect identifying information to enable targeted ad delivery. Thought I generally respect Moxie Marlinspike and have no great beef with Signal, there has been a concerted effort to exploit its device sharing protocol and your carrier and national governments can easily extract traffic analysis info from people using it. Were I to add one sentence to this guide, it would be "While these tools are better than nothing, they are far from perfect."<p>f) The guide seems to conflate encryption with privacy. Encryption technology <i>can</i> enable privacy, but you're not going to get privacy from encryption technology unless you pair it with well reasoned policy (for organizations) and operational guidelines (for both organizations and individuals.)<p>The extreme example is to say "nothing stops a participant in an encrypted communication from sharing the un-encrypted plaintext after it's recovered." People earnestly trying to maintain message security probably know not to do that, but when talking about exchanging keys and figuring out which keys or organizations you should trust, it's easy for even the well-informed to make privacy-eroding decisions.<p>So... I think this article is a good jumping off point, covering material I would call "required, but not sufficient." I would just view it as the beginning of a deep-dive instead of the end.