Mention that users should not use multiple of our services #987

New Issue

2019-06-11T14:08:11Z

ghost commented

2019-06-11 14:08:11 +00:00

(Migrated from github.com)

We are for decentralization, but at the same time, us hosting so many of these services looks like we want our visitors to use them.

It's okay to use one of our services but users shouldn't centralize their privacy around PTIO.

We should add a notice to the site.

We are for decentralization, but at the same time, us hosting so many of these services looks like we want our visitors to use them. It's okay to use one of our services but users shouldn't centralize their privacy around PTIO. We should add a notice to the site.

👍 1 😕 2 ❤️ 3

five-c-d commented

2019-06-12 20:44:51 +00:00

(Migrated from github.com)

One of the problems with decentralization, is that if an enduser has the choice of

going through the time&trouble to self-host
or, just using a well-known brand they already trust

plenty of people will pick door#2 ... which tends to make the brand even more-well known, and pretty soon you have a "centralized despite intending to be decentralized" actuality.

In most ways this is an unavoidable paradox: 99% of people are NOT going to be able to secure a server-node, and configure it in a privacy-respecting manner, as the folks who run privacyToolsIO. Thus, they are actually better off entrusting the privacyToolsIO team to run the server portion, because Bob trying to secure his own firewall and patch/harden his own server-side OS and install/configure his own federated service-node... well, to put it bluntly, Bob will screw the pooch if he tries to DIY because he is not competent enough.

But once you have millions of Bob-type-folks trusting the central privacyToolsIO server-cluster with their sensitive info... THAT turns the server-cluster into a juicy target!

Pretty related == https://matrix.org/blog/2019/05/08/post-mortem-and-remediations-for-apr-11-security-incident Kinda related == https://lwn.net/Articles/687294/

To me, the thing that is worrisome for privacyToolsIO services, is that if they succeed they will cost a lot of money to operate (since hosting-fees go up as userbase goes up), AND they will make the privacyToolsIO servers and nearby-router-boxen and such into juicy targets (because surveillance-value of a popular service with lots of endusers goes up as the userbase goes up as well). Definitely related == #966 about funding the work ...and defining WHAT the work is, which you really want to put your minds to accomplishing

One of the problems with decentralization, is that if an enduser has the choice of 1. going through the time&trouble to self-host 2. or, just using a well-known brand they already trust plenty of people will pick door#2 ... which tends to make the brand even more-well known, and pretty soon you have a "centralized despite intending to be decentralized" actuality. In most ways this is an unavoidable paradox: 99% of people are NOT going to be able to secure a server-node, and configure it in a privacy-respecting manner, as the folks who run privacyToolsIO. Thus, they are actually better off entrusting the privacyToolsIO team to run the server portion, because Bob trying to secure his own firewall and patch/harden his own server-side OS and install/configure his own federated service-node... well, to put it bluntly, Bob will screw the pooch if he tries to DIY because he is not competent enough. But once you have millions of Bob-type-folks trusting the central privacyToolsIO server-cluster with their sensitive info... **THAT turns the server-cluster into a juicy target!** Pretty related == https://matrix.org/blog/2019/05/08/post-mortem-and-remediations-for-apr-11-security-incident Kinda related == https://lwn.net/Articles/687294/ To me, the thing that is worrisome for privacyToolsIO services, is that if they succeed they will cost a lot of money to operate (since hosting-fees go up as userbase goes up), AND they will make the privacyToolsIO servers and nearby-router-boxen and such into juicy targets (because surveillance-value of a popular service with lots of endusers goes up as the userbase goes up as well). Definitely related == #966 about funding the work ...and defining WHAT the work is, which you really want to put your minds to accomplishing

Perelandra0x309 commented

2019-06-18 02:59:42 +00:00

(Migrated from github.com)

@Shifterovich What is your concern with "consolidation" (I think that is a better term) of using several services from the same provider (PTIO)? Is it that if the Mastodon instance is down or compromised, the other services like Matrix and Write are also unavailable or compromised?

ghost commented

2019-07-18 18:40:07 +00:00

(Migrated from github.com)

Yes. Also users shouldn't trust us more than any other provider -- even less, in fact, since a paid service comes with more guarantee than a volunteer project like PTIO.

Yes. Also users shouldn't trust *us* more than any other provider -- even less, in fact, since a paid service comes with more guarantee than a volunteer project like PTIO.

👍 1

blacklight447 commented

2019-09-03 13:53:42 +00:00

(Migrated from github.com)

How would we be implementing this warning, where would it be posted? does it also have to be on the main site, or just a blog post on blog.privacytools.io? We also need to think whether we want the warning on every service homepage.

ghost commented

2019-09-06 20:54:32 +00:00

(Migrated from github.com)

A link to a new page should be added to the Services dropdown. That page should explain why users shouldn't centralize their privacy on our services.

A link to a new page should be added to the *Services* dropdown. That page should explain why users shouldn't centralize their privacy on our services.

👍 1

Mikaela commented

2020-02-11 21:20:38 +00:00

(Migrated from github.com)

Hi @privacytoolsIO/editorial, is anyone thinking of this issue actively (or at least remembering it exists)? Due to its ghost status (#1379), it's difficult to find and I just remembered this while referring here from the forum thread on replacing Matrix with XMPP.

Hi @privacytoolsIO/editorial, is anyone thinking of this issue actively (or at least remembering it exists)? Due to its ghost status (#1379), it's difficult to find and I just remembered this while referring here from the [forum thread on replacing Matrix with XMPP](https://forum.privacytools.io/t/replace-matrix-with-xmpp/2667/2?u=mikaela).

👍 1

strypey commented

2020-02-20 06:45:26 +00:00

(Migrated from github.com)

Two possible ways to mitigate this:

have a page on PTIO evaluating the privacy implications of some other hosts, along the lines of the FSF page evaluating the software freedom status of webmail services
have a page linking to other groups and forums like Librehosters or homebrewserver.club that help people interested in learning to self-host or run community-hosting

Two possible ways to mitigate this: * have a page on PTIO evaluating the privacy implications of some other hosts, along the lines of the FSF page evaluating the [software freedom status of webmail services](https://www.fsf.org/resources/webmail-systems) * have a page linking to other groups and forums like [Librehosters](libreho.st/) or [homebrewserver.club](https://homebrewserver.club/) that help people interested in learning to self-host or run community-hosting

👍 1

blacklight447 commented

2020-03-02 12:31:02 +00:00

(Migrated from github.com)

Two possible ways to mitigate this:

have a page on PTIO evaluating the privacy implications of some other hosts, along the lines of the FSF page evaluating the software freedom status of webmail services

have a page linking to other groups and forums like Librehosters or homebrewserver.club that help people interested in learning to self-host or run community-hosting

We could make a explanition on why federation is important in a "don't put all your eggs in one basket" kind of sense, together with a link to librehosters on our services page. what do you think @dngray @JonahAragon

> > > Two possible ways to mitigate this: > > * have a page on PTIO evaluating the privacy implications of some other hosts, along the lines of the FSF page evaluating the [software freedom status of webmail services](https://www.fsf.org/resources/webmail-systems) > > * have a page linking to other groups and forums like [Librehosters](libreho.st/) or [homebrewserver.club](https://homebrewserver.club/) that help people interested in learning to self-host or run community-hosting We could make a explanition on why federation is important in a "don't put all your eggs in one basket" kind of sense, together with a link to librehosters on our services page. what do you think @dngray @JonahAragon

jonah commented

2020-03-03 04:02:07 +00:00

This is essentially what #1732 covers already, no? If you want to adjust the wording you can add a suggestion there.

blacklight447 commented

2020-03-03 10:57:04 +00:00

(Migrated from github.com)

This is essentially what #1732 covers already, no? If you want to adjust the wording you can add a suggestion there.

ive added it to the PR.

> > > This is essentially what #1732 covers already, no? If you want to adjust the wording you can add a suggestion there. ive added it to the PR.

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: privacyguides/privacytools.io#987