As the founder of Simple Analytics, I’m running into privacy issues while building our product. Based on those learnings I listed some practical tips in this blog post to improve the privacy of your visitors.
If you –as an HN reader– have any comments on extra tips or improvements, please let me know! I would love to keep this guide up-to-date.
Great article, by the way! People need to put more thought into this kind of thing.
In fact SimpleAnalytics is my only 3rd party call from my SaaS site (pritact.com)
What I take from this post is the importance of considering, even on basic web interactions, how much you can chip away at your client's privacy by making easy choices with "free" platforms.
You are right, it's easy to just install that extra little script to improve a certain metric. At the same time you're trading the privacy of all your visitors. I hope people will become more aware of this.
Speaking of CSP, should it be in this list? It allows you to whitelist scripts that run on your page, prevent 3rd-party scripts from loading media, and act as a kind of application firewall with `connect-src`.
Edit: I just added a section about CSP 
As an example, to display 442 tweets on one page, it's around 2.4mb of network download - most of that is from media which some of the tweets use.
This way, text is selectable and links can be clicked.
Under Europe's GDPR, IP addresses are explicitly classified as personally identifiable information, and must not be recorded except for clearly identified and documented valid purposes that you communicate to your visitors and regularly review: https://ico.org.uk/for-organisations/guide-to-data-protectio...
California's CCPA currently doesn't apply to smaller companies, but imposes similar requirements: https://secureprivacy.ai/what-is-ccpa-and-how-to-become-comp...
Security is explicitly a valid purpose, but I doubt "might help finding offenders" is clear and specific enough to be compliant. I'm not a lawyer, but ethically, you need to explain to your visitors how long you're storing IPs for, what you do with them and what you promise not to do with them, who you share them with, why you need raw IPs and not just salted hashes, etc.
The elephant in the room: Facebook Pixel and the Facebook SDK.
I've held strong and refuse to add the SDK to our app. Or any Facebook integration (to the website). But per my marketing friends, we're essentially wasting our money on all our Facebook advertising. For better or worse, ads are very important for our consumer-facing product (https://www.joyapp.com).
The fact that 90% of apps out there have what many consider spyware should alarm more people. This is even if you don't use Facebook sign in!
Combined with rel=noreferrer, that’ll be rel="noopener noreferrer".
Update: sorry, this is not necessary. noreferrer implies noopener (https://html.spec.whatwg.org/multipage/links.html#link-type-...). But while a Referrer-Policy of no-referrer renders rel=noreferrer unnecessary, you still want rel=noopener, so you might as well go with rel=noreferrer. referrerpolicy=no-referrer is superfluous in this location.
Of course, many of those are profitable, but there's still technical room for improvement independent of that.
I wrote some thoughts on the trade-offs of choosing privacy for a social network. It might help other people trying to make product/business decisions with a privacy-focused approach:
Cookie banners are never necessary. If you want to collect analytics prior to obtaining consent, you should store this data locally on the browser so that you can ask for consent at a time that's more appropriate (e.g. during signup or content submission).
Specifically, they clarified that scrolling, etc. or navigating cookie consent walls prior to accessing the site did not constitute valid consent for GDPR purposes.
This is because it wasn’t freely given — to access the site, in most cases you were required to consent to cookies.
The Court of Justice of the European Union also ruled that pre-filled consent checkboxes for cookie banners, etc. were unlawful in October last year.
Exactly the reverse of the cross-origin request header.
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 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.
: 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 ...