✨ Feature Suggestion | Document the shortcomings of the options #729

New Issue

2019-01-20T12:40:00Z

ghost commented

2019-01-20 12:40:00 +00:00

(Migrated from github.com)

Description:

The website provides good guidance in general but it neglects to warn users of privacy pitfalls and shortcomings of many of the options. I find this a little reckless and it immediately strikes me that the site must be taken with a very big grain of salt. For Privacytools to demonstrate credibility it's very important to disclose the negatives of the tools and services being recommended.

For example...

Brave

Brave is controversial. I won't detail the issues here because I'm fuzzy on them myself but there is clearly something contentious about the advertising or funding which often comes up in forum chatter.

Signal

No F-Droid distribution. Pushes users into Google Playstore unless they compile the code themselves or find the deliberately-hidden "Danger Zone". Most visitors to Signal's website are lead to believe the Playstore is the only option and thus pushed into the most privacy-abusing option.
Pushes users seeking support into privacy-hostile private walled-garden of CloudFlare.
(details)

(edit) actually Signal has too many issues, not worth endorsing while showing shortcomings. Perhaps all the shortcomings should be listed on a separate page for condemned apps.

BTW, Jami (aka GNU Ring; available on F-Droid) is more privacy-respecting than Signal AFAICT and it's not even mentioned. (edit) Jami is mentioned in the voice/video section but not the IM section - it should be in both.

However, the Playstore version of Jami has a tracker and the F-Droid version does not, so that should be highlighted.

Wire

Good that plaintext metadata is mentioned. Another privacy anti-feature is that the phone app forces users to supply a phone number, while the desktop version of the app does not.

Privacy Badger

Good that Google Analytics case is mentioned. Also, the tool takes time to learn what to block. According to EFF users are vulnerable during that learning period. Also, a DNT website may conform in the strictest sense but the negotiation between industry players and privacy advocates went badly, leaving significant loopholes in the established rules. So a site can claim to honor DNT but abuse the loopholes and Privacy Badger will not block in those cases. EFF mentions this as well.

DDG

DuckDuckGo should be removed or at a very minimum these issues should be disclosed so the user is informed.

Startpage

No privacy issue, but this interesting discussion on DDG and Startpage reveals that Startpage pays money to Google, so using Startpage ultimately helps support a privacy abuser and users should be aware of this.

Searx

Searx is certainly your best search engine recommendation IMO, but I'm not sure how you can claim "No logs, no ads and no tracking" for all searx instances. There is a page somewhere showing how each searx instance gets funding and some have ads. I don't have the link to that ATM but this needs to be investigated.

Qwant

It's unclear why Qwant is being seen as privacy-respecting when it treats Tor users with hostility. CAPTCHA hell for Tor users. And the CAPTCHA sometimes causes the search query to clear so the user must re-type their query. A search tool that is hostile toward Tor users is probably not worth mentioning -- but certainly if there is mention then it needs this anti-feature documented.

"Follow us on Twitter" -- eat your own dog food plz

Really? You're going to (quite rightfully) recommend GNU Social and Mastodon, and then at the bottom of the page direct visitors to Twitter showing that you don't take your own advice? Sure, have a Twitter account but use it strictly to point users to your GNU Social timeline - which you should have.

## Description: The website provides good guidance in general but it neglects to warn users of privacy pitfalls and shortcomings of many of the options. I find this a little reckless and it immediately strikes me that the site must be taken with a very big grain of salt. For Privacytools to demonstrate credibility it's very important to disclose the negatives of the tools and services being recommended. ## For example... ### Brave Brave is controversial. I won't detail the issues here because I'm fuzzy on them myself but there is clearly something contentious about the advertising or funding which often comes up in forum chatter. ### Signal * No F-Droid distribution. Pushes users into Google Playstore unless they compile the code themselves or find the deliberately-hidden "Danger Zone". Most visitors to Signal's website are lead to believe the Playstore is the only option and thus pushed into the most privacy-abusing option. * Pushes users seeking support into privacy-hostile private walled-garden of CloudFlare. ([details](https://github.com/guardianproject/haven/issues/320)) (edit) actually Signal [has too many issues](https://github.com/privacytoolsIO/privacytools.io/issues/779), not worth endorsing while showing shortcomings. Perhaps all the shortcomings should be listed on a separate page for condemned apps. BTW, Jami (aka GNU Ring; available on F-Droid) is more privacy-respecting than Signal AFAICT and it's not even mentioned. (edit) Jami is mentioned in the voice/video section but not the IM section - it should be in both. However, the Playstore version of Jami [has a tracker](https://reports.exodus-privacy.eu.org/en/reports/63024/) and the F-Droid version [does not](https://github.com/guardianproject/haven/issues/320#issuecomment-475791100), so that should be highlighted. ### Wire Good that plaintext metadata is mentioned. Another privacy anti-feature is that the phone app forces users to supply a phone number, while the desktop version of the app does not. ### Privacy Badger Good that Google Analytics case is mentioned. Also, the tool takes time to learn what to block. According to EFF users are vulnerable during that learning period. Also, a DNT website may conform in the strictest sense but the negotiation between industry players and privacy advocates went badly, leaving significant loopholes in the established rules. So a site can claim to honor DNT but abuse the loopholes and Privacy Badger will not block in those cases. EFF mentions this as well. ### DDG DuckDuckGo should be removed or at a very minimum [these issues](https://github.com/privacytoolsIO/privacytools.io/issues/84#issuecomment-455862442) should be disclosed so the user is informed. ### Startpage No privacy issue, but this [interesting discussion](https://github.com/prism-break/prism-break/issues/168) on DDG and Startpage reveals that Startpage pays money to Google, so using Startpage ultimately helps support a privacy abuser and users should be aware of this. ### Searx Searx is certainly your best search engine recommendation IMO, but I'm not sure how you can claim "No logs, no ads and no tracking" for all searx instances. There is a page somewhere showing how each searx instance gets funding and some have ads. I don't have the link to that ATM but this needs to be investigated. ### Qwant It's unclear why Qwant is being seen as privacy-respecting when it treats Tor users with hostility. CAPTCHA hell for Tor users. And the CAPTCHA sometimes causes the search query to clear so the user must re-type their query. A search tool that is hostile toward Tor users is probably not worth mentioning -- but certainly if there is mention then it needs this anti-feature documented. ### "Follow us on Twitter" -- eat your own dog food plz Really? You're going to (quite rightfully) recommend GNU Social and Mastodon, and then at the bottom of the page direct visitors to Twitter showing that you don't take your own advice? Sure, have a Twitter account but use it strictly to point users to your GNU Social timeline - which you should have.

👍 1 👎 1

ghost commented

2019-01-20 13:01:55 +00:00

(Migrated from github.com)

No F-Droid distribution. Pushes users into Google Playstore unless they compile the code themselves.

Is this an issue? Aren't the apks signed by Signal?

> No F-Droid distribution. Pushes users into Google Playstore unless they compile the code themselves. Is this an issue? Aren't the apks signed by Signal?

ghost commented

2019-01-20 13:10:06 +00:00

(Migrated from github.com)

@Shifterovich

Is this an issue? Aren't the apks signed by Signal?

Copious issues stem from Google Playstore:

Users must give google their phone number to get a google account.
Google records the IMEI number for the device you are using and links that to your account.
Google records users' IP addresses and browser prints when logged in, which is later used to link to your logged-out traffic and behavior.
Google keeps track of what users' download from the Playstore. From this Google also knows all the vulnerabilities a user has.
Scientific study titled Understanding the Security Management of Global Third-Party Android Marketplaces proves F-droid is more secure than Google Playstore.
Playstore apps are closed-source. The user has no way of knowing whether the binary they obtain was produced by the source published by the project. Even if it's signed users are trusting the developer who deploys the binaries not the source code.

Signal should be moved to "worth mentioning".

@Shifterovich > Is this an issue? Aren't the apks signed by Signal? Copious issues stem from Google Playstore: * Users must give google their phone number to get a google account. * Google records the IMEI number for the device you are using and links that to your account. * Google records users' IP addresses and browser prints when logged in, which is later used to link to your logged-out traffic and behavior. * Google keeps track of what users' download from the Playstore. From this Google also knows all the vulnerabilities a user has. * Scientific study titled Understanding the Security Management of Global Third-Party Android Marketplaces [proves](https://nsl.cs.waseda.ac.jp/wp-content/uploads/2018/04/submitted_wama2017.pdf) F-droid is more secure than Google Playstore. * Playstore apps are closed-source. The user has no way of knowing whether the binary they obtain was produced by the source published by the project. Even if it's signed users are trusting the developer who deploys the binaries not the source code. Signal should be moved to "worth mentioning".

ghost commented

2019-01-20 13:16:14 +00:00

(Migrated from github.com)

~~True.~~

~~I checked if they publish the apks elsewhere, but apparently they're only on Playstore. Releases don't come with the builds https://github.com/signalapp/Signal-Android/releases/tag/v4.32.7.~~

~~Yeah, Signal should definitely use F-Droid.~~

Edit: https://signal.org/android/apk/ Could the apk be self-updating? https://www.reddit.com/r/signal/comments/6lquju/where_is_signal_on_fdroid/djvwedw/

<strike>True. I checked if they publish the apks elsewhere, but apparently they're only on Playstore. Releases don't come with the builds https://github.com/signalapp/Signal-Android/releases/tag/v4.32.7. Yeah, Signal should definitely use F-Droid.</strike> Edit: https://signal.org/android/apk/ Could the apk be self-updating? https://www.reddit.com/r/signal/comments/6lquju/where_is_signal_on_fdroid/djvwedw/

ghost commented

2019-01-20 13:19:12 +00:00

(Migrated from github.com)

Perhaps this thread can be useful for this discussion? https://github.com/signalapp/Signal-Android/issues/127#issuecomment-13335689

👍 1

ghost commented

2019-01-20 14:17:21 +00:00

(Migrated from github.com)

That discussion continues to re-appear in many places because Google PlayStore is rightly unpopular among the privacy advocates that consider Signal. They've pushed the discussion out of github and the discussion continues here.

In the end their reasons to avoid F-Droid and encourage PlayStore are flimsy:

They want to track crashes and have stats on crash reports to make the app more stable.
Signal developers also want stats on platforms and versions their users are using.

This does not justify pushing users into PlayStore privacy abuses. Users should have the choice and control over whether they want to report crashes.

The fact that Signal is strongly encouraging Google PlayStore and Privacytools is strongly recommending Signal is something that needs to change. The APK download option is hidden and it really appears to most users that they must use Google PlayStore unless they go on a hunt. Signal's recommendation to use PlayStore and discouraging statement about the APK download if users manage to find it is ultimately to the detriment of privacy.

Signal should be "worth mentioning" at best or removed, and Jami should take Signal's place.

That discussion continues to re-appear in many places because Google PlayStore is rightly unpopular among the privacy advocates that consider Signal. They've pushed the discussion out of github and the discussion continues [here](https://community.signalusers.org/t/signal-f-droid-repository/2808/44). In the end their reasons to avoid F-Droid and encourage PlayStore are flimsy: * They want to track crashes and have stats on crash reports to make the app more stable. * Signal developers also want stats on platforms and versions their users are using. This does not justify pushing users into PlayStore privacy abuses. Users should have the choice and control over whether they want to report crashes. The fact that Signal is strongly encouraging Google PlayStore and Privacytools is strongly recommending Signal is something that needs to change. The APK download option is hidden and it really appears to most users that they must use Google PlayStore unless they go on a hunt. Signal's recommendation to use PlayStore and discouraging statement about the APK download if users manage to find it is ultimately to the detriment of privacy. Signal should be "worth mentioning" at best or removed, and Jami should take Signal's place.

ghost commented

2019-01-20 14:35:07 +00:00

(Migrated from github.com)

Signal should be "worth mentioning" and Jami should take Signal's place.

If Jami is as easy to use as Signal (and also as secure), sure. Otherwise, we need to discuss that change.

Edit: Sorry for the accidental close.

> Signal should be "worth mentioning" and Jami should take Signal's place. If Jami is as easy to use as Signal (and also as secure), sure. Otherwise, we need to discuss that change. Edit: Sorry for the accidental close.

Atavic commented

2019-01-22 20:42:30 +00:00

(Migrated from github.com)

Re: Signal, Wire

Privacy matters securemessagingapps comparison

...GNU Ring isn't listed

Re: Signal, Wire Privacy matters [securemessagingapps comparison](https://www.securemessagingapps.com/) ...GNU Ring isn't listed

danarel commented

2019-01-23 00:39:39 +00:00

(Migrated from github.com)

@Shifterovich Jami is actually on the list, but listed as Ring (they changed their name about a month ago)

ghost commented

2019-01-23 09:59:40 +00:00

(Migrated from github.com)

Jami is missing from the Encrypted Instant Messenger section. It's in video and voice but it should appear in both.

Jami is missing from the [Encrypted Instant Messenger section](https://www.privacytools.io/#im). It's in *video and voice* but it should appear in both.

ghost commented

2019-01-26 15:22:06 +00:00

(Migrated from github.com)

I used Ring.cx (now Jami) a while back and did notice a few issues with it. The windows client didn't uninstall cleanly, and I did have trouble with initiating a video conferencing call. In the end I used qTox for that call.

I am curious to know if anyone has used Jami recently, and what they think of it in terms of stability. Ultimately if it isn't stable enough for every day use and gives off a poor UX, some users will get fed up and go back to centralized proprietary options where the company has to be trusted 100% for not doing anything dodgy with key distribution.

One of the things to keep in mind about Signal, is that it supports push notifications, which means there's likely to be better battery life on mobile platforms.

I wish there were more instant messengers that used https://f-droid.org/en/packages/com.github.gotify as I don't have GCM/FCM on my device (no gapps), maybe Matrix will do this.

Also some background on Signal and why it isn't in F-Droid:

https://github.com/signalapp/Signal-Android/issues/127
https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165
https://drewdevault.com/2018/08/08/Signal.html (👍 to @ddevault for putting it so eloquently, Google Play provides a nice platform for things like this.

I used Ring.cx (now Jami) a while back and did notice a few issues with it. The windows client didn't uninstall cleanly, and I did have trouble with initiating a video conferencing call. In the end I used qTox for that call. I am curious to know if anyone has used Jami recently, and what they think of it in terms of stability. Ultimately if it isn't stable enough for every day use and gives off a poor UX, some users will get fed up and go back to centralized proprietary options where the company has to be trusted 100% for not doing [anything dodgy with key distribution](https://blog.cryptographyengineering.com/2018/12/17/on-ghost-users-and-messaging-backdoors/). One of the things to keep in mind about Signal, is that it supports push notifications, which means there's likely to be better battery life on mobile platforms. I wish there were more instant messengers that used https://f-droid.org/en/packages/com.github.gotify as I don't have GCM/FCM on my device (no gapps), maybe Matrix will do this. Also some background on Signal and why it isn't in F-Droid: * https://github.com/signalapp/Signal-Android/issues/127 * https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165 * https://drewdevault.com/2018/08/08/Signal.html (👍 to @ddevault for putting it so eloquently, Google Play provides a nice platform for things like [this](https://www.zdnet.com/article/whats-actually-in-australias-encryption-laws-everything-you-need-to-know/).

ghost commented

2019-03-01 11:43:59 +00:00

(Migrated from github.com)

The discussion is a bit side-railed from the thesis. The individual tools should be discussed in separate threads. The idea with this thread is that the overall layout does a poor job of exposing anti-features - to the extent that it gives an unbalanced representation.

For example, a visitor of the voip section would think Wire has issues and Signal does not. It actually looks like Signal is perfect when in fact it's far from it (Google Play, CloudFlare). There are tons of micro issues that mushroom out of Signal exposing users to gplay and CF, more than you could present in that little box. The box should say something like:

Caution: anti-features--
* pushes users into Google Playstore
* uses CloudFlare

The "Playstore" string should link to an article that details the manner in which users are pushed into Playstore and reveal the hidden page for the APK and address the bad advice Signal gives to avoid it. It should also document the issues with playstore.

The "CloudFlare" string should link to an article that details the manner in which users are pushed into CloudFlare by Signal, and detail the issues with CF.

There are external links all over the page but there should also be internal links that expand and elaborate on issues. The recommended apps read like an advertisement, but credibility is conveyed when anti-features are also exposed. When I see sketchy recommendations on the page and anti-features I'm aware of are not presented, it sends the message this page is biased, the authors overlooked some things ==> big grain of salt needed.

The Privacytools project should be eager to document anti-features. Spotlighting room for improvement makes the project credible and also incentivizes improvements that the privacy-focused community needs. The project should take every opportunity to document noteworthy issues.

The discussion is a bit side-railed from the thesis. The individual tools should be discussed in separate threads. The idea with this thread is that the overall layout does a poor job of exposing anti-features - to the extent that it gives an unbalanced representation. For example, a visitor of the voip [section](https://www.privacytools.io/#voip) would think Wire has issues and Signal does not. It actually looks like Signal is perfect when in fact it's far from it (Google Play, CloudFlare). There are tons of micro issues that mushroom out of Signal exposing users to gplay and CF, more than you could present in that little box. The box should say something like: ``` Caution: anti-features-- * pushes users into Google Playstore * uses CloudFlare ``` The "Playstore" string should link to an article that details the manner in which users are pushed into Playstore and reveal the hidden page for the APK and address the bad advice Signal gives to avoid it. It should also document the issues with playstore. The "CloudFlare" string should link to an article that details the manner in which users are pushed into CloudFlare by Signal, and detail the issues with CF. There are external links all over the page but there should also be internal links that expand and elaborate on issues. The recommended apps read like an advertisement, but credibility is conveyed when anti-features are also exposed. When I see sketchy recommendations on the page and anti-features I'm aware of are not presented, it sends the message this page is biased, the authors overlooked some things ==> big grain of salt needed. The Privacytools project should be eager to document anti-features. Spotlighting room for improvement makes the project credible and also incentivizes improvements that the privacy-focused community needs. The project should take every opportunity to document noteworthy issues.

👍 1

ghost commented

2019-03-01 12:12:04 +00:00

(Migrated from github.com)

Initially I had suggested doing https://github.com/privacytoolsIO/privacytools.io/issues/746 but perhaps we could do better? Your post @libBletchley pretty much sums up my thoughts on the issue.

Now we just have to figure out how this will look.

The Privacytools project should be eager to document anti-features. Spotlighting room for improvement makes the project credible and also incentivizes improvements that the privacy-focused community needs. The project should take every opportunity to document noteworthy issues.

I have had some success with connecting to various email providers and their staff. Because of this issue https://github.com/privacytoolsIO/privacytools.io/issues/603 many adopted privacy enhancing features that they did not otherwise previously support.

Initially I had suggested doing https://github.com/privacytoolsIO/privacytools.io/issues/746 but perhaps we could do better? Your post @libBletchley pretty much sums up my thoughts on the issue. Now we just have to figure out how this will look. > The Privacytools project should be eager to document anti-features. Spotlighting room for improvement makes the project credible and also incentivizes improvements that the privacy-focused community needs. The project should take every opportunity to document noteworthy issues. I have had some success with connecting to various email providers and their staff. Because of this issue https://github.com/privacytoolsIO/privacytools.io/issues/603 many adopted privacy enhancing features that they did not otherwise previously support.

strypey commented

2019-04-10 19:54:12 +00:00

(Migrated from github.com)

I just want to +1 the idea of listing anti-features, as F-Droid does. Given the state of digital tech in 2019, chances are high that any tool involving a network-connected computer is not 100% privacy-respecting/ protecting. The best way to help users protect our privacy is education, and that includes both information about the privacy benefits of helpful tools and pointing out known flaws.

I actually think it's worth listing Signal somewhere on the PTIO website, because otherwise it's absence will be assumed to be an oversight, rather than a non-endorsement. My suggestion would be to either:

abandon the whole logic of endorsement, list all tools that promote themselves as privacy-friendly, and review their pros and cons
have both endorsement pages and "we do not endorse" pages for each category, and review the pros and cons of all tools listed on both sets of pages

I just want to +1 the idea of listing anti-features, as F-Droid does. Given the state of digital tech in 2019, chances are high that any tool involving a network-connected computer is not 100% privacy-respecting/ protecting. The best way to help users protect our privacy is education, and that includes both information about the privacy benefits of helpful tools *and* pointing out known flaws. I actually think it's worth listing Signal somewhere on the PTIO website, because otherwise it's absence will be assumed to be an oversight, rather than a non-endorsement. My suggestion would be to either: * abandon the whole logic of endorsement, list all tools that promote themselves as privacy-friendly, and review their pros and cons * have both endorsement pages and "we do not endorse" pages for each category, and review the pros and cons of all tools listed on both sets of pages

👍 2

return42 commented

2020-03-07 07:21:44 +00:00

(Migrated from github.com)

No privacy issue, but this interesting discussion on DDG and Startpage reveals that Startpage pays money to Google ...

Startpage is owned by an advertising company since 2019. System1 LLC Affiliate and lead generation:

We partner with leading companies to provide lead generation and incremental commerce opportunities.

> No privacy issue, but this interesting discussion on DDG and Startpage reveals that Startpage pays money to Google ... Startpage is owned by an advertising company since 2019. System1 LLC [Affiliate and lead generation](https://system1.com/partner/): > We partner with leading companies to provide lead generation and incremental commerce opportunities.

This repo is archived. You cannot comment on issues.