TLDR;
There exists a resource and knowledge gap, between the privacy-conscious consumers and producers of software. I believe PG’s community is uniquely suited to help.
As a long-time lurker, I have observed a clear crossover between developers and end users in the PG community.
I have benefited greatly from PG’s resources, as an end user of software and the internet, as I imagine many have. There however seems to be significant opportunity and potential to offer resources and recommendations to developers as well.
A handful of topics I found interesting in the last couple days, from a developer perspective:
Examples
Opinions: Are privacy-friendly analytics ever ethical?
Cactus Comments: federated comment system for the open web, based on the Matrix protocol
Add supply chain attacks to "Common Threats" page
Flatpak builds are not reproducible and why that's a practical problem - #4 by dngray
Any rebuttal to Simplified Privacy's article "PrivacyGuides Loves Spyware"? - #5 by dngray (silly article, but the concern about Cloudflare is what I’m referring to)
Whether a separate category or adjacent resource altogether, offering resources to developers is tackling the problem at the root.
College programs, computer science degrees and bootcamps very rarely feature privacy as part of their curriculum, in fact, their incentives, value alignment, and taught practices often fall squarely opposed to privacy.
Awareness and regulation around “user data as a monetary vehicle” is catching up. In my opinion, industry tools, standards and learning resources are not keeping pace.
For every app or project launched with privacy in mind, 10 times as many launch the same day, without having to worry about the same concerns or guarantees. This is not inherently malicious by those developers, as their exposure to privacy principles is limited the same way that of any given individual’s is before they find something like PG. It is a resource for the end user which consumes software, but the developers that produce it, have perhaps equally limited exposure to the principles. After all, a developer is and end user.
If we concede that many end users will never (or should never have to) care about their privacy, the least we can attempt is to make sure developers do care.
There are steps a developer can take, with varying difficulty of implementation. Mapping them out serves to:
- Clarify PG’s stance on inclusion of recommendations they make today, and serves as something that can be referred to
- Track changes in the ecosystem related to that tech or principle
- Disseminate them to developers who are unaware
- List practical ways a company can do better, which enables the privacy-conscious individual to take these resources up with the way their company operates.
- Show developers areas of improvement they can contribute to, and potentially organize community effort to improve these ecosystems
Some software principles, practices and ideas that are worth exploring in many commonly available software projects:
- Local-first
- Encryption, both end-to-end and zero-knowledge
- 2FA including hardware keys
- Passkey support
- KYC and compliance in the context of privacy
- Organizing community around a project (matrix, discourse, etc.)
- GDPR, “the right to be forgotten”, and defining self-service data management flows from the start (graceful offboarding)
- UX and dark patterns
- Supply chain security
- Source licensing: questions of copyleft licenses, CLAs and “what is the right license” have already been asked
- Peer-to-peer, decentralization and censorship resistant paradigms
- Privacy-respecting hosting and domain options and offerings (see also recent Cloudflare FUD and criticism)
- Many more
I cannot overstate how much a “have you considered” or “have you heard of” or “did you know that this is possible” checklist would help me deliver software more aligned with my own ideals and those of regular PG consumers. Information exists, but it is fragmented, niche, out of date, or heavily opinionated.
A recommendation by PG carries weight. I suggest we apply that weight to why those recommendations are necessary to begin with. I am happy to contribute.
As I suspect many developers frequent PG, I also - perhaps naively - hope to one day see organized community action. To make these ideas easier to adopt, to demystify their use, and to make them a matter of firm principle towards employers, investors and industry as a whole.
Food for thought.