These tips are great and immediately actionable, the request maps are quite compelling, thank you. Limiting third parties' access to the user-agent is critical

These tips are great and immediately actionable, the request maps are quite compelling, thank you. Limiting third parties' access to the user-agent is critical for a private (and secure!) web, and it makes it easy to create really legible, transparent privacy policies and adhere to them. This type of advice works really well for a single-person company, or a small organization, but I think that they don't go far enough once your company starts to grow, and most of these things are not really "encoded" as truth unless they're expressed in the "contracts" signed between you and the customer, i.e. the T&C and Privacy Policy. For example, consider what happens in the case of a company sale or bankruptcy: if the service along with your users' accounts and whatever else is in your database get sold to an antagonistic company, can they simply amend your privacy policy and start re-selling the data? Is your privacy policy even valid in the event of an acquisition? Most privacy policies include a quite wide allowance for disclosure in the event of sales, mergers, etc.[1] Consider adding clauses to your privacy policy providing users with strong data controls if you end up in a situation like this, even if it will make those your organization less valuable in these situations. This is a very tough call to make, of course, you're making yourself less attractive to people who can bail you out when you're most in need of bailing, but a more equitable relationship with your users may build enough trust in your product to keep from needing to be bailed :) How do you design your systems so that they grow to be more privacy-preserving over time? Large/"global" tech companies will consider this in their security threat modeling, that e.g. anyone with root can dump the database, but even companies of 20-200 employees should be considering internal attacks like this. Businesses operating in complicated regulatory environments inevitably end up with some business-person running SQL against production once a week to get a CSV to send to a regulator, what else can they (or someone with their access) do with enough time and Stack Overflow? I'm a big fan of considering and expressing privacy values (along with other values of your organization's choice!) in the entire business lifecycle, not just in the code+infrastructure, adopting privacy by design[2] methodologies in to your product design lifecycle, for example, if you've already started. But if you're a small company or a single-person side-dish, considering these things from the very beginning will pay in dividends as time goes on. So much of this advice comes down to "treat your customers and potential customers with respect and dignity." I'm one of those weirdos who read the T&C and privacy policy before i sign up for most services, and I'm always taken aback by 1) how ambiguous they all are (in favor of the business) 2) how same-y they all are 3) how often they simply don't function [3]. I think that if business wants to continue to rely on the idea of "informed consent" for our data regulatory frameworks, we must be encouraged to build more transparent, informative controls for users, starting with those tiny fucking check-boxes at the bottom of every signup page. [1]: https://www.freeprivacypolicy.com/blog/privacy-policy-business-transfer-clause/ https://www.freeprivacypolicy.com/blog/privacy-policy-busine... [2]: https://en.wikipedia.org/wiki/Privacy_by_design#Foundational_principles_in_detail https://en.wikipedia.org/wiki/Privacy_by_design#Foundational... [3]: One example: F1TV, the Formula 1 online streaming service's signup page didn't have working links to the PP or T&C, their cookie control tool didn't work, and their contact email address didn't respond to multiple requests for a copy of the contracts. I live in the US, but I am considering filing a UK ICO complaint about this, but who knows what help that'll be ...