-
-
Notifications
You must be signed in to change notification settings - Fork 385
💬 Discussion | Requirements for recommendations on privacytools.io #780
Comments
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. |
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. |
👍 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). |
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. |
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. |
mission statement
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
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 marketingThe 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 popularityThe 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 usefulPTIO 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.
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:
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
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. |
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. |
I request this issue to be reopened as without concrete requirements I think the discussions will often keep going around in circles. |
I just realized that I have gotten the power to reopen this. |
closing issue as discussion has continued on #997 |
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. |
Actually closing in favour of https://github.com/privacytoolsIO/privacytools.io/issues/977 which is a pinned issue and @blacklight447-ptio possibly intended it. |
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:
The text was updated successfully, but these errors were encountered: