I wrote this blog post as a reference guide for both technical people and not technical people.
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.
I've heard that upvotes don't count if they're from people who followed a link directly to the story. And you're not supposed to solicit votes in the first place. Just say "Join the discussion on Hacker News". :)
Great article, by the way! People need to put more thought into this kind of thing.
I've been following your activity because of your strong stance on privacy and very much agree with this post.
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.
I'm working on open source solution https://github.com/vaulty-co/vaulty that may help with data tokenization, encryption, etc. Few cases from your blog post may be covered. I also created a guide on how to tokenize email address (it can be anything like phone number, IP, SSN, etc.) and let application use tokenized email when sending emails via Mailgun: https://vaulty.co/docs/cookbooks/email-list-with-protected-e.... Would be great to hear feedback if any :D
Very interesting. I didn't know about `crossorigin=anonymous` and `referrerpolicy`. You wouldn't believe how many "privacy-focused", "E2E encrypted", etc. web apps are just blindly loading things from multiple CDNs with no SRI and no CSP (let alone anonymous CORS or no-referrer).
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`.
The suggestions here are fairly good. One complaint, though: embedding tweets lets you select their text; taking a screenshot does not. Consider perhaps using some styled text instead. Also, I think your example of using share links might be more actionable if they actually worked instead of just being a static image ;)
I had a similar issue for the tweet embedding, so I wrote a Node.js script to download tweets via their API, and construct the HTML and CSS necessary to display it on my own website, without needing to include their JavaScript: https://github.com/umaar/better-twitter-embed
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.
I think it is all good advice but I don't agree with anonymisation of IP addresses. Maybe better option is to remove logs after some time instead of removing it. When you are business owner you also have some right to protect your business. Logs with IP might help finding offenders. So it is a trade off.
Did you checked your logs in the web server and have seen how many exploits and malicious scans are daily coming? When by any chance you are hit with one of those it might be useful to have not hashed IP in logs.
Do you have website visitors in Europe or California? If so, you better be documenting what you're doing with those IPs much clearer than "might help finding offenders".
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...
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.
Great article. Would love to see something in this vein for App Store apps.
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![1][2]
For remote links, you should add rel=noopener as well, to prevent reverse tabnapping.
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.
Great reading! I am building a shareable journal/social network with a focus on privacy. It was very interesting, in particular the parts about CDN and IP anonymization.
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:
I'm not surprised that Simple Analytics' gripe with cookie banners is regarding misleading designs instead of their existence in itself. Companies need to start thinking outside these norms.
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).
It didn’t make them unlawful (they were already unlawful), the European Data Protection Board just updated its guidance to make that clear.
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.
I always wonder if there is value in extending the HTML spec to include contracts in webpages for 3rd party calls. Might help enforce a domain level policy by a domain owner making sure content creators have to oblige.
Exactly the reverse of the cross-origin request header.
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.
[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 ...
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.