💬 Discussion | Criteria for Sponsorships #2134

Open
opened 2020-11-23 09:17:55 +00:00 by lynn-stephenson · 7 comments
lynn-stephenson commented 2020-11-23 09:17:55 +00:00 (Migrated from github.com)

The development will be open to all, and suggestions are highly encouraged.

First off let us tackle Privacy Policies.

  1. Should it be a REQUIREMENT for Sponsors to NOT share users' data in any way shape or form to third parties?
  2. Should it be permitted to share that data if it is not personally identifiable?
  3. If they go against this particular criteria point, should they be removed as a Sponsor? If so, for how long? And how many times can they be re-added?
The development will be open to all, and suggestions are highly encouraged. First off let us tackle Privacy Policies. 1. Should it be a REQUIREMENT for Sponsors to NOT share users' data in any way shape or form to third parties? 2. Should it be permitted to share that data if it is not personally identifiable? 3. If they go against this particular criteria point, should they be removed as a Sponsor? If so, for how long? And how many times can they be re-added?
gary-host-laptop commented 2020-11-23 20:51:38 +00:00 (Migrated from github.com)

My two cents, although it is not something directed to a specific type of service provider.

At the time of recommending something in your website, what should be considered into account are numerous technical details which are extremely specific to that kind of service (for example it is not same a VPN than an e-mail provider) and I imagine there are even small details among similar providers (for example Safing is kind of a VPN, but the same requirements would fit them than the ones that Mullvad fulfills?). I think a good idea would be to limit the sponsors to providers/software that wouldn't require so much additional research. Crypton seems like a good project to me, and I like the idea, but if they decide to sponsor you all, would you go through all the efforts of finding out what should be considered in order to know they are trustworthy?

My two cents, although it is not something directed to a specific type of service provider. At the time of recommending something in your website, what should be considered into account are numerous technical details which are extremely specific to that kind of service (for example it is not same a VPN than an e-mail provider) and I imagine there are even small details among similar providers (for example Safing is kind of a VPN, but the same requirements would fit them than the ones that Mullvad fulfills?). I think a good idea would be to limit the sponsors to providers/software that wouldn't require so much additional research. [Crypton](https://crypton.sh/) seems like a good project to me, and I like the idea, but if they decide to sponsor you all, would you go through all the efforts of finding out what should be considered in order to know they are trustworthy?
samuel-lucas6 commented 2020-11-23 23:02:47 +00:00 (Migrated from github.com)
  1. Ideally yes.
  2. You could argue this is better than 1 since more sponsors may be accepted, meaning more funding for the site. On the other hand, it would be easier to check for no third party data sharing. It depends how far you want to restrict things, but not sharing user data is obviously preferable.
  3. Yes, to be consistent. It also makes sense to remove them until they change their privacy policy to meet the requirement. Perhaps a maximum of once or twice.

Being more restrictive is the best way of avoiding any issues with questionable sponsors. It also makes vetting sponsors less of a hassle. Less funding is the main limitation, but it's not clear how dependent you are on these large donations.

1. Ideally yes. 2. You could argue this is better than 1 since more sponsors may be accepted, meaning more funding for the site. On the other hand, it would be easier to check for no third party data sharing. It depends how far you want to restrict things, but not sharing user data is obviously preferable. 3. Yes, to be consistent. It also makes sense to remove them until they change their privacy policy to meet the requirement. Perhaps a maximum of once or twice. Being more restrictive is the best way of avoiding any issues with questionable sponsors. It also makes vetting sponsors less of a hassle. Less funding is the main limitation, but it's not clear how dependent you are on these large donations.
lynn-stephenson commented 2020-11-23 23:56:55 +00:00 (Migrated from github.com)

I am in favor of the first over the second point. It will produce less work for us, and only accept the best of sponsors. Sponsors can also change for the better.

And what I meant about the third point is "What if the sponsor breaks their privacy policy?", to be more specific. I would suggest only permitting this devastating promise breaking once after the sponsor meets our criteria, but only having to be removed for half a year in addition to a re-submission, instead of two years. Should it happen again, they should be removed for at least two years before they can attempt for a re-submission.

I am in favor of the first over the second point. It will produce less work for us, and only accept the best of sponsors. Sponsors can also change for the better. And what I meant about the third point is "What if the sponsor breaks their privacy policy?", to be more specific. I would suggest only permitting this devastating promise breaking once after the sponsor meets our criteria, but only having to be removed for half a year in addition to a re-submission, instead of two years. Should it happen again, they should be removed for at least two years before they can attempt for a re-submission.
davegson commented 2020-12-16 12:54:18 +00:00 (Migrated from github.com)

Disclaimer: I'm co-founder of Safing, which currently sponsors PrivacyTools.


The best way to protect user data is to not collect it in the first place.

As of such, I feel PTIO should first evaluate WHAT is being collected and WHY, and if that is reasonable naturally also investigate with WHO they share the data.

I believe 1) has the right spirit, but goes too far making it hard for any company to fulfill 100%. As an example, we do not collect any user data at all through our products, and hence cannot share it. However, next to paying with cash, users do have the choice to subscribe to one service via PayPal [ugh, I know] (or credit cards in the future) and there, we delegate handling sensitive payment data to these external companies. Or they can sign up to our newsletter, where we explicitly mention we share their email with the newsletter partner service we pay for.

So fmpov, context matters, both for 1. and 2. Sometimes yes, sometimes no, but more importantly, why collect it in the first place? Which brings me back to the point mentioned above.


In regards to 3. yes, I believe they should be removed. As soon as the criteria is defined, you should re-evaluate all current sponsors and remove them if they don't fit, allowing for an a prompt re-addition after they made changes to satisfy the new criteria.

For all failures in the future, I'd penalize them for 6M. In company terms, that's not very harsh and leaves enough room for them to change things around. If they fail twice I'd personally remove them completely - as I feel two is a pattern. (But maybe I see this too harsh)

Disclaimer: I'm co-founder of [Safing](https://safing.io), which currently sponsors PrivacyTools. --- > **The best way to protect user data is to not collect it in the first place.** As of such, I feel PTIO should first evaluate WHAT is being collected and WHY, and if that is reasonable naturally also investigate with WHO they share the data. I believe 1) has the right spirit, but goes too far making it hard for any company to fulfill 100%. As an example, we do not collect any user data at all through our products, and hence cannot share it. However, next to paying with cash, users do have the choice to subscribe to one service via PayPal [_ugh, I know_] (or credit cards in the future) and there, we delegate handling sensitive payment data to these external companies. Or they can sign up to our newsletter, where we explicitly mention we share their email with the newsletter partner service we pay for. So fmpov, context matters, both for 1. and 2. Sometimes yes, sometimes no, but more importantly, why collect it in the first place? Which brings me back to the point mentioned above. --- In regards to 3. yes, I believe they should be removed. As soon as the criteria is defined, you should re-evaluate all current sponsors and remove them if they don't fit, allowing for an a prompt re-addition after they made changes to satisfy the new criteria. For all failures in the future, I'd penalize them for 6M. In company terms, that's not very harsh and leaves enough room for them to change things around. If they fail twice I'd personally remove them completely - as I feel two is a pattern. (But maybe I see this too harsh)
freddy-m commented 2021-01-17 19:14:09 +00:00 (Migrated from github.com)

I think that it should be a requirement for sponsors not to share users' data unless it is not personally identifiable. We are a project focused on privacy, and if the company wanting to sponsor us seemingly is not, then they should not have a space on our site. If they decide to change their stance on the matter (i.e. remove trackers etc..) then they should be able to be re-added if they so desire.

I think that it should be a requirement for sponsors not to share users' data unless it is not personally identifiable. We are a project focused on privacy, and if the company wanting to sponsor us seemingly is not, then they should not have a space on our site. If they decide to change their stance on the matter (i.e. remove trackers etc..) then they should be able to be re-added if they so desire.
nkvname commented 2021-04-09 19:34:24 +00:00 (Migrated from github.com)

Disclaimer: I'm the founder of Xeovo, which started sponsoring PrivacyTools, but found out that you are not accepting new organizations.

1 & 2. Ideally yes, but maybe make an exception for websites that are using 3rd party privacy-oriented analytics such as Matomo, SimpleAnalytics, etc? This can be a good way to force companies to switch from Google Analytics.
3. Absolutely. Maybe one time re-add possibility depending on what happened.

It should be noted that these changes can reduce significantly how many companies will sponsor PrivacyTools and should be taken with care. I am all in for no analytics/trackers in any form, but you guys should do the math first.

_Disclaimer: I'm the founder of [Xeovo](https://xeovo.com), which started sponsoring PrivacyTools, but found out that you are not accepting new organizations._ 1 & 2. Ideally yes, but maybe make an exception for websites that are using 3rd party privacy-oriented analytics such as Matomo, SimpleAnalytics, etc? This can be a good way to force companies to switch from Google Analytics. 3. Absolutely. Maybe one time re-add possibility depending on what happened. It should be noted that these changes can reduce significantly how many companies will sponsor PrivacyTools and should be taken with care. I am all in for no analytics/trackers in any form, but you guys should do the math first.
freddy-m commented 2021-04-12 15:17:19 +00:00 (Migrated from github.com)

maybe make an exception for websites that are using 3rd party privacy-oriented analytics such as Matomo, SimpleAnalytics, etc? This can be a good way to force companies to switch from Google Analytics.

This seems like a good idea. The most preferable option is no analytics at all, however I'm not opposed to the use of GoAccess as a privacy respecting analytics tool.

> maybe make an exception for websites that are using 3rd party privacy-oriented analytics such as Matomo, SimpleAnalytics, etc? This can be a good way to force companies to switch from Google Analytics. This seems like a good idea. The most preferable option is no analytics at all, however I'm not opposed to the use of [GoAccess](https://goaccess.io/) as a privacy respecting analytics tool.
This repo is archived. You cannot comment on issues.
No Milestone
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: privacyguides/privacytools.io#2134
No description provided.