Skip to content
This repository has been archived by the owner on Jun 24, 2022. It is now read-only.

💬 Discussion | Requirements for recommendations on privacytools.io #780

Closed
ghost opened this issue Mar 12, 2019 · 12 comments
Closed

💬 Discussion | Requirements for recommendations on privacytools.io #780

ghost opened this issue Mar 12, 2019 · 12 comments

Comments

@ghost
Copy link

ghost commented Mar 12, 2019

As mentioned in #779, every other day, someone opens an issue to suggest the removal of software. Sometimes, these people suggest a replacement they prefer, another time, the discussions come to nothing. Sometimes, there are questionable reasons for the removal, another time, the reasons are totally valid.

However, there are no defined requirements for recommendations on privacytools.io. We tell users that specific software is "good" (due to what?), and after some months, we replace the recommendation due to the opinion of less than 10 people on GitHub. In my opinion, this process is non-transparent and often only rely on people who were "in the right spot at the right time".

I suggest to define requirements for software. For instance, write down a list of features that MUST be present in an instant messenger recommended on privacytools.io. I also suggest to distinguish between information security, privacy, and other requirements.

Especially, the "software criteria" is somewhat wishy-washy:

  • Open Source (this is a lincense topic)
  • Cross-platform (which platforms? Windows/Linux? Or Windows/macOS? Which variants of Linux? Debian? Arch? …)
  • Easy to use (who defines "easy to use"? This is clearly subjective if we don't use standardized UX criteria to evaluate this)
  • Privacy respecting (what is "privacy respecting"? A website that doesn't embed third-party content? Software using federated services? Software that avoids metadata wherever possible?)
@ghost ghost added the feedback wanted label Mar 12, 2019
@ghost
Copy link

ghost commented Mar 13, 2019

Considering the complexity of the decisions hard and fast rules with absolute criteria would actually introduce constraints that would lower the quality of the decision making. But I agree there should be an abstract high-level guidance to at least establish a set of values, goals, and known threats.

E.g. a guideline could say that walled-gardens such as CloudFlare are detrimental which could then be a basis for evaluations, but a hard and fast rule to disqualify all CF users might hinder the need to endorse a lesser of evils. Although in terms of how an endorsement is expressed, a hard and fast rule that all endorsements that subject users to CF must have a caution label would be sensible, for example.

@beerisgood
Copy link

Well this project is for new people which looks for a first step away from Google, Facebook and others.

So all alternatives are good, no matter if better exists.

@Atavic
Copy link

Atavic commented Mar 13, 2019

👍 For license and privacy respecting sides. Ease of use should be replaced with a link to some official FAQ page or forum or community IMHO

Also more OS support, the better (but it's not something that should exclude a project).

@danarel
Copy link
Contributor

danarel commented Mar 15, 2019

I think a lot of the debate on this site comes down to what this site's purpose it. It seems the fight to remove the most popular apps come from purists who see privacy as an incredibly strict set of rules. ie, Signal using AWS disqualifies it, and other see this site as offering the best solutions available that everyday people can use.

I think somewhere there is a balance of offering both.

@ghost
Copy link
Author

ghost commented Mar 16, 2019

It seems the fight to remove the most popular apps come from purists who see privacy as an incredibly strict set of rules.

And these purist rules aren't even consequently applied. Regarding the "Signal is bad since it uses AWS" point: GitHub is also on AWS. So, from the perspective of a purist, we all must leave GitHub. But what about all those open source apps recommended by privacytools.io that let GitHub host their source code? Are the purists puristic enough to remove all these apps, too?

Thinking in a puristic "black and white" scheme moves all of us from one walled garden into another. The walled gardens we leave are defined by conglomerates and the new walled gardens are defined by purists. The results are free blinders for everyone and a digital culture of exclusion. The mission of privacytools.io should be helping users to define their own gardens and to live in peace with their neighbors, not to allocate predefined gardens to users and build a wall around them.

@ghost
Copy link

ghost commented Mar 16, 2019

mission statement

I think a lot of the debate on this site comes down to what this site's purpose it.

Indeed. We have this high-level mission statement:

"You are being watched. Private and state-sponsored organizations are monitoring and recording your online activities. privacytools.io provides knowledge and tools to protect your privacy against global mass surveillance."

Criteria can be derived from that.

popularity as a criteria

It seems the fight to remove the most popular apps come from purists who see privacy as an incredibly strict set of rules.

Popularity is a lousy criteria for privacy evaluation. Popularity already has a damaging influence on this project just by the mere undercurrent of bias from those who become loyal to a vendor. Vendor loyalty has lead to some endorsements that undermine PTIO credibility. When privacy experts and security analysts look at PTIO and see a spotlight on DDG, Signal, Brave, Twitter, Github, and Reddit, it's immediately evident to them that the project has followed the crowd and neglected objective investigation ultimately undermining their own mission. This makes it hard for an expert to recommend PTIO to non-experts who they advise.

popularity is a product of marketing

The unspoken problem with popularity is that corporate marketing has hyper-evolved toward grabbing as much market share as possible and retaining it by fostering undue loyalty. DDG in particular has mastered marketing tactics that foster loyalty - a loyalty strong enough to cause followers to pound the table when the facts are against them. Often the popular choice becomes popular due to centralized profit-driven initiatives. Whereas a decentralized free software solution loses the marketing arms race and doesn't get the traction that's due. Favoring popularity has the side-effect of bringing people toward surveillance funded projects. It's a conflict of interest that runs in contention with the PTIO mission statement. Decentralized community-driven projects rely on PTIO to set the record straight in the face of the marketing arms race that lies to the users. PTIO has a duty to consider those privacy-centric but marketing-poor projects.

legit benefit to popularity

The scenario where popularity benefits users is w.r.t. interoperabile communication with other users (a Signal user can't call a Jami user). But we don't need PTIO to tell people what's popular. Users naturally know what their contacts use and that's out of our hands.

purists are useful

PTIO can greatly benefit from purists who are motivated to unearth and expose privacy abuses for our analysis. The fear that they would push for an empty section on the page as a consequence of all choices being lousy is not a legit fear. It's easily controlled by making endorsement a lesser of evils.

Thinking in a puristic "black and white" scheme moves all of us from one walled garden into another.

Actually it's the other way around. Letting popularity control direction instead of sound critical analysis is what takes us from one walled-garden to another. Signal is the most popular and it exposes users to more walled-gardens than they left behind:

  • Google Playstore walled-garden
  • Google's search filter bubble in aggregation with Playstore assets
  • Amazon's filter bubble
  • CloudFlare's walled-garden of privacy abuses
  • CDMA+GSM systems of surveillance (and consequential forced-feeding of privacy abusers AT&T, Verizon, Sprint, and T-mobile in the US)

ie, Signal using AWS disqualifies it,

Signal has a very long list of privacy abuses that collectively give substantial cause to condemn it in the face of alternatives that do not force users to compromise privacy and feed large-scale surveillance-funded corporations.

usability criteria

and other see this site as offering the best solutions available that everyday people can use.
I think somewhere there is a balance of offering both.

Ease of use does not derive from the mission statement. I'm not strongly opposed to ease of use being a criteria but note that PRISM-Break already has ease of use as a criteria so if PTIO makes that a strong criteria carrying a lot of weight then the two projects will likely become overly redundant.

@ghost
Copy link
Author

ghost commented Mar 17, 2019

Since @libBletchley also captures this thread to lobby against Signal, I will close it.

It is hard to understand a puristic black and white world and statements against centralized "evil US companies" like Google, Amazon, CloudFlare stated by a person on GitHub, a closed platform that runs on AWS, for a project like privacytools.io that obviously uses CloudFlare.

@ghost ghost closed this as completed Mar 17, 2019
@Mikaela
Copy link
Contributor

Mikaela commented Mar 17, 2019

I request this issue to be reopened as without concrete requirements I think the discussions will often keep going around in circles.

@Mikaela
Copy link
Contributor

Mikaela commented Apr 10, 2019

I just realized that I have gotten the power to reopen this.

@blacklight447
Copy link
Collaborator

blacklight447 commented Sep 3, 2019

closing issue as discussion has continued on #997

@Mikaela
Copy link
Contributor

Mikaela commented Jan 20, 2020

Reopening as #997 appears irrelevant to me and it didn't result in a change in CONTRIBUTING.md or the website itself on the requirements.

@Mikaela Mikaela reopened this Jan 20, 2020
@Mikaela
Copy link
Contributor

Mikaela commented Jan 20, 2020

Actually closing in favour of https://github.com/privacytoolsIO/privacytools.io/issues/977 which is a pinned issue and @blacklight447-ptio possibly intended it.

@Mikaela Mikaela closed this as completed Jan 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants