Some difficult-to-meet requirements
- Be open source. Don’t make users have to trust your black box. I don’t want to have to trust you. I don’t know you.
- Don’t just release your in-house source code. Develop in public; practice outreach to OSS developers to loop in others; make distributed code reviews a standard practice.
- Be fully open source. Don’t depend on proprietary vendors or use APIs that, for example, make sensitive user data open to systematic collection.
- If you must keep some of your server-side code private (it could happen), then hire a third party to do public, independent audits of security and user privacy issues. I don’t want to take your word for it. The more often an audit is performed, the better.
- Don’t use a business model based on selling or datamining user data. Prefer subscription, non-targeted ad, and other non-intrusive models. Maybe tokenize. Prove to your users that this is your business model, and go on the record loud and clear that it is.
- If you have a cloud app with any data that some users might reasonably want to be kept private (which is almost all cloud apps), store the data using zero-knowledge encryption or other similarly secure tech whenever possible.
- When private user data needs to be processed, do it client-side, not server-side, so that you don’t need to see the data.
- Use strong, standard, end-to-end encryption for all user-to-user communication features.
- Obviously, follow best modern practices when it comes to user authentication. E.g., save hashes of user passwords.
- If you must make it easier for users to log in by using social media/OAuth logins, then at least give users the clear and prominent option of using their own password for your site. (I strongly advise users to use their own passwords, tracked with a modern, secure password manager. Social media logins are a backdoor for corporate surveillance.)
- Conspicuously distinguish between public and private data. Of course, sometimes users don’t care about privacy; they want the widest possible exposure for a public post or profile. Just make it really, really clear what information is exposed to whom, and especially whenever anything is not 100% private (and kept that way through encryption).
- Support various kinds of two-factor authentication.
- Don’t keep unnecessary logs of user/visitor data. Never use feckin’ Google Analytics!
- Make it hard for governments to get user information out of you. The best way to respond to government information requests when you run a private service is with, “We do not have access to that information. It is never sent to or recorded on our servers, or if it is, it is done so in an encrypted format.”
- Make your mailing lists and notifications opt-in, for the love of all that is holy.
- Don’t force users to use your proprietary mobile app. Some of us like to use browser versions because we the user have more control and transparency about what the hell is going on.
- Speaking of transparency, be totally transparent to OSS devs and regular users alike about how your app works and allay any concerns they might have.
- Clarify where your management and developers live and where your offices are located. If we can’t find out who you are, how can we trust anything you say about yourselves?
- All of the above goes double if you live in a country that is associated with hacking or a highly intrusive or totalitarian government, or if you have any other red flags that might make users worried about their privacy or security when using your app.
I’ve reviewed and installed a lot of software lately and have designed (if not coded) a lot over the years. As a consumer, this is the ideal I’m after. I’m not sure I know of many consumer web apps that satisfy all of these “requirements.” But this is what we need if we want to respect privacy and help users with their security.
I might add more to this list as I think of more things. If you have additions you think I should make, please list them below.