Adjust privacy policy #6666

Gargron · Mar 7, 2018

Describe in detail Mastodon's use of data
Change data retention period of IP addresses from 5 years to 12 months

Sorry about localizations, but I think it would be bad to keep incorrect translations.

Also, I am not sure if:

The old version must be kept somehow?
This requires opt-in from everybody's users? (This is why "breaking" label)

Below is a render of the policy:

Privacy Policy

What information do we collect?

Basic account information: If you register on this server, you may be asked to enter a username, an e-mail address and a password. You may also enter additional profile information such as a display name and biography, and upload a profile picture and header image. The username, display name, biography, profile picture and header image are always listed publicly.

Posts, following and other public information: The list of people you follow is listed publicly, the same is true for your followers. When you submit a message, the date and time is stored as well as the application you submitted the message from. Messages may contain media attachments, such as pictures and videos. Public and unlisted posts are available publicly. When you feature a post on your profile, that is also publicly available information. Your posts are delivered to your followers, in some cases it means they are delivered to different servers and copies are stored there. When you delete posts, this is likewise delivered to your followers. The action of reblogging or favouriting another post is always public.

Direct and followers-only posts: All posts are stored and processed on the server. Followers-only posts are delivered to your followers and users who are mentioned in them, and direct posts are delivered only to users mentioned in them. In some cases it means they are delivered to different servers and copies are stored there. We make a good faith effort to limit the access to those posts only to authorized persons, but other servers may fail to do so. Therefore it's important to review servers your followers belong to. You may toggle an option to approve and reject new followers manually in the settings. Please keep in mind that the operators of the server and any receiving server may view such messages, and that recipients may screenshot, copy or otherwise re-share them. Do not share any dangerous information over Mastodon.

IPs and other metadata: When you log in, we record the IP address you log in from, as well as the name of your browser application. All the logged in sessions are available for your review and revocation in the settings. The latest IP address used is stored for up to 12 months. We also may retain server logs which include the IP address of every request to our server.

What do we use your information for?

Any of the information we collect from you may be used in the following ways:

To provide the core functionality of Mastodon. You can only interact with other people's content and post your own content when you are logged in. For example, you may follow other people to view their combined posts in your own personalized home timeline.

The email address you provide may be used to send you information, notifications about other people interacting with your content or sending you messages, and to respond to inquiries, and/or other requests or questions.

How do we protect your information?

We implement a variety of security measures to maintain the safety of your personal information when you enter, submit, or access your personal information. Among other things, your browser session, as well as the traffic between your applications and the API, are secured with SSL, and your password is hashed using a strong one-way algorithm. You may enable two-factor authentication to further secure access to your account.

What is our data retention policy?

We will make a good faith effort to:

Retain server logs containing the IP address of all requests to this server, in so far as such logs are kept, no more than 90 days.

Retain the IP addresses associated with registered users no more than 12 months.

You can request and download an archive of your content, including your posts, media attachments, profile picture, and header image.

You may irreversibly delete your account at any time.

Do we use cookies?

Yes. Cookies are small files that a site or its service provider transfers to your computer's hard drive through your Web browser (if you allow). These cookies enable the site to recognize your browser and, if you have a registered account, associate it with your registered account.

We use cookies to understand and save your preferences for future visits.

Do we disclose any information to outside parties?

We do not sell, trade, or otherwise transfer to outside parties your personally identifiable information. This does not include trusted third parties who assist us in operating our site, conducting our business, or servicing you, so long as those parties agree to keep this information confidential. We may also release your information when we believe release is appropriate to comply with the law, enforce our site policies, or protect ours or others rights, property, or safety.

Your public content may be downloaded by other servers in the network. Your public and followers-only posts are delivered to the servers where your followers reside, and direct messages are delivered to the servers of the recipients, in so far as those followers or recipients reside on a different server than this.

When you authorize an application to use your account, depending on the scope of permissions you approve, it may access your public profile information, your following list, your followers, your lists, all your posts, and your favourites. Applications can never access your e-mail address or password.

Children's Online Privacy Protection Act Compliance

Our site, products and services are all directed to people who are at least 13 years old. If this server is in the USA, and you are under the age of 13, per the requirements of COPPA (Children's Online Privacy Protection Act) do not use this site.

Changes to our Privacy Policy

If we decide to change our privacy policy, we will post those changes on this page.

This document is CC-BY-SA. It was last updated March 7, 2018.

Originally adapted from the Discourse privacy policy.

I guess that depends of the country, so what about for example making old instances not work after upgrade if owners won’t add one line line to config file, to state that they know about the change and they will do the things required by their local law?

m4sk1n · Mar 7, 2018

I guess that depends of the country, so what about for example making old instances not work after upgrade if owners won’t add one line line to config file, to state that they know about the change and they will do the things required by their local law?

nightpool · Mar 8, 2018

nightpool requested changes Mar 8, 2018

View changes

"to review servers your followers belong to" is slightly odd wording, i'd say "to review the servers your followers belong to".

you might want to make sure to say that "authorized persons" here includes the moderator of the server.

"In some cases it means they are delivered to different servers ..."
Is it uncertain in which cases posts get delivered to other servers?
My understanding may be incorrect but I what I thought was:
if those users' accounts are hosted on other Mastodon instances, then the posts they are eligible to read will be copied to the server for their instance, and will be subject to the privacy policy of that instance, which may be more permissive than this one.

The fact that we list here explicitly all the different types of data you can create makes me a little scared that we'll have to update the privacy policy every time we add a new feature, which would be bad. For example, where do reports fall under here? What if we made lists public? You might want to add a more general category, or something like "information we collect from you includes but is not limited to"

While the specificity is good and useful, because you removed the very general We collect information from you when you register on our site and gather data when you participate in the forum by reading, writing, and evaluating the content shared here it's possible someone could read this and conclude that recording who made a report is against our privacy policy, or that displaying a list will be, which would be bad.

The fact that we list here explicitly all the different types of data you can create makes me a little scared that we'll have to update the privacy policy every time we add a new feature, which would be bad. For example, where do reports fall under here? What if we made lists public? You might want to add a more general category, or something like "information we collect from you includes but is not limited to"

While the specificity is good and useful, because you removed the very general We collect information from you when you register on our site and gather data when you participate in the forum by reading, writing, and evaluating the content shared here it's possible someone could read this and conclude that recording who made a report is against our privacy policy, or that displaying a list will be, which would be bad.

I think the idea that a privacy policy is something you set and forget is antiquated and problematic. As convenient as it might be in the short term to just not bother with it, we developers have to come to grips with the fact that the privacy policy is something that grows with the site, just like test suites and documentation. Point of fact, the privacy policy IS documentation, and it needs to remain both up to date, and specific. Developers should make a habit of updating the privacy policy whenever the data collected changes. (ideally, this could be at least partially automated)

"Includes but is not limited to" effectively expands the bounds on what could be collected to infinity, which kind of defeats the purpose of this document.

I think the idea that a privacy policy is something you set and forget is antiquated and problematic. As convenient as it might be in the short term to just not bother with it, we developers have to come to grips with the fact that the privacy policy is something that grows with the site, just like test suites and documentation. Point of fact, the privacy policy IS documentation, and it needs to remain both up to date, and specific. Developers should make a habit of updating the privacy policy whenever the data collected changes. (ideally, this could be at least partially automated)

"Includes but is not limited to" effectively expands the bounds on what could be collected to infinity, which kind of defeats the purpose of this document.

I am inclined to agree that being explicit, and updating when we need to collect more, is what makes a privacy policy useful and trustworthy...

"— For example, you can...."

again, same issue here with ", including but not limited to"

(IANAL, this is not legal advice, etc)

nightpool · Mar 8, 2018

(IANAL, this is not legal advice, etc)

I think it's still US centric, like the mention of COPPA. Also it's important to separate the retention of IP adresses in the web server logs (depends on the server config) and in the Mastodon database (done by the Mastodon software).

ghost · Mar 8, 2018

I think it's still US centric, like the mention of COPPA. Also it's important to separate the retention of IP adresses in the web server logs (depends on the server config) and in the Mastodon database (done by the Mastodon software).

@jeroenpraat we're adapting a privacy policy (from Discourse) for US sites. If other jurisdictions have other requirements, we're not really qualified to asses or handle that, unfortunately.

nightpool · Mar 8, 2018

@jeroenpraat we're adapting a privacy policy (from Discourse) for US sites. If other jurisdictions have other requirements, we're not really qualified to asses or handle that, unfortunately.

@nightpool If it's for US sites only, I think it's better to ask during setup if the instance is hosted (and such) in the US. Most instances are not hosted in the US, so a default like this makes no sense IMO.

ghost · Mar 8, 2018

@nightpool If it's for US sites only, I think it's better to ask during setup if the instance is hosted (and such) in the US. Most instances are not hosted in the US, so a default like this makes no sense IMO.

If it's for US sites only, I think it's better to ask during setup if the instance is hosted (and such) in the US. Most instances are not hosted in the US, so a default like this makes no sense IMO.

That is true, but nobody knows what should be the default, which is unfortunate, I guess.

akihikodaki · Mar 10, 2018

If it's for US sites only, I think it's better to ask during setup if the instance is hosted (and such) in the US. Most instances are not hosted in the US, so a default like this makes no sense IMO.

That is true, but nobody knows what should be the default, which is unfortunate, I guess.

duggulous · Mar 27, 2018

duggulous reviewed Mar 27, 2018

View changes

Any trusted third parties should be explicitly listed, so that users can seek the corresponding privacy policies and understand who is accessing their data.

"agree to keep the information confidential" is not a particularly strong protection, as there are many ways to misuse data that don't involve sharing it with others.
Ideally, no no information would be transferred to third parties unless they were also:
bound to not use the information for any purposes outside of assisting us in operating the site, conducting our business and providing the service.
Also, these guarantees should apply not just to PII, but to any data the user has not made public.

We need to distribute such a privacy policy that would be valid for all installations. So it can't get too specific. I doubt that admins will go hunting down the, say, DigitalOcean privacy policy, or Mailgun privacy policy (please mind that admins can completely rewrite the privacy policy themselves from the admin interface, if they decide to include that information)

You also have to see this in perspective to the prior privacy policy. Is it overall an improvement, or is it not? I can't fix everything at once.

We need to distribute such a privacy policy that would be valid for all installations. So it can't get too specific. I doubt that admins will go hunting down the, say, DigitalOcean privacy policy, or Mailgun privacy policy (please mind that admins can completely rewrite the privacy policy themselves from the admin interface, if they decide to include that information)

You also have to see this in perspective to the prior privacy policy. Is it overall an improvement, or is it not? I can't fix everything at once.

Ah, yeah, I was thinking about this as an instance-level final document rather than a master template that would be customized.

Yeah, this is definitely an improvement over the old privacy policy! Don't get me wrong, I'm not trying to criticize here - I think it's great that it's moving in this direction. And I'm totally sympathetic to the fact that you can't fix everything in one fell swoop. I'm just saying, as long as we're inside the engine bay replacing the radiator, maybe we can replace these cracked coolant hoses too. (Did that metaphor land?)

Might I suggest a placeholder (some kind of "[insert services here]" or something) that would nudge admins in the right direction? For the record, I don't think admins would need to go copy the text of the third parties' policies. Linking to them would be great (I think privacy policies tend to stay at the same url), but at the very least, they can list the names of the companies/services so that users can look them up.

When you say that admins will have to go "hunt down" privacy policies, you make it sound like you don't expect admins to have ever even looked at the privacy policies and terms of service for the services they use. If that's the case, it's a problem. Data stewardship is part of being an admin, and as such, admins have a responsibility to read and understand the agreements they enter into with third parties. The terms of service of some third parties (Google Analytics for example) place responsibilities on the other party regarding how they implement the service and what they do or do not record with it. Without reading the policies, an admin would not know that. An admin might use a service that has a policy that conflicts with theirs, etc...

I understand that privacy policies are sometimes designed to be difficult to understand, and admins tend to be technologists rather than lawyers, but all the more reason for them to list the parties, so that users can do their own investigation and pick up any slack.

Ah, yeah, I was thinking about this as an instance-level final document rather than a master template that would be customized.

Yeah, this is definitely an improvement over the old privacy policy! Don't get me wrong, I'm not trying to criticize here - I think it's great that it's moving in this direction. And I'm totally sympathetic to the fact that you can't fix everything in one fell swoop. I'm just saying, as long as we're inside the engine bay replacing the radiator, maybe we can replace these cracked coolant hoses too. (Did that metaphor land?)

Might I suggest a placeholder (some kind of "[insert services here]" or something) that would nudge admins in the right direction? For the record, I don't think admins would need to go copy the text of the third parties' policies. Linking to them would be great (I think privacy policies tend to stay at the same url), but at the very least, they can list the names of the companies/services so that users can look them up.

When you say that admins will have to go "hunt down" privacy policies, you make it sound like you don't expect admins to have ever even looked at the privacy policies and terms of service for the services they use. If that's the case, it's a problem. Data stewardship is part of being an admin, and as such, admins have a responsibility to read and understand the agreements they enter into with third parties. The terms of service of some third parties (Google Analytics for example) place responsibilities on the other party regarding how they implement the service and what they do or do not record with it. Without reading the policies, an admin would not know that. An admin might use a service that has a policy that conflicts with theirs, etc...

I understand that privacy policies are sometimes designed to be difficult to understand, and admins tend to be technologists rather than lawyers, but all the more reason for them to list the parties, so that users can do their own investigation and pick up any slack.

Without an enforcement provision, the policy is fairly meaningless. You make it clear that the policy is merely a "good faith" effort in which the weakest link is the default for privacy. What is that actual mechanism for safeguarding privacy from abuse? I'll be honest and suggest that as a new user, I took a dim view of the privacy options offered and assume they are no better than any other service but that there was less crass commercialization of my own posts. It's hard to imagine that even the metadata provided is necessary for the improvement of the user experience as users tend to provide concrete feedback on services and will let you know what they want changed. As for "private communications", the service appears to provide no real protection at all. Unless users were to communicate with some kind of trusted encryption, it appears that private communications are somewhat open. The ACLU has a 45 page report on "Informational Privacy in the Digital Age" which might provide you with some background as to the complexity of the issues at hand- but no one read reports.

It says "we, us, our" in all the headings, except this one:

What is your data retention policy?

It should be changed to "What is our data retention policy?"

Cassolotl · Apr 1, 2018

It says "we, us, our" in all the headings, except this one:

What is your data retention policy?

It should be changed to "What is our data retention policy?"

nightpool · Apr 2, 2018

nightpool requested changes Apr 2, 2018

View changes

I think this needs to have a list bullet about site moderation, or using your information (such as IP addresses) to determine a code of conduct violations or attempts to evade a moderation action.

Other then that one bullet point, LGTM

nightpool · Apr 2, 2018

Other then that one bullet point, LGTM

Please keep in mind that the operators of the server and any receiving server may view such messages, and that recipients may screenshot, copy or otherwise re-share them. Do not share any dangerous information over Mastodon.

I feel like "operator" is not very clear to the average user, who is used to terms like "admins" and "mods"! So maybe it could say "the admins and moderators of the server and any receiving server may view such messages"?

Cassolotl · Apr 4, 2018

Please keep in mind that the operators of the server and any receiving server may view such messages, and that recipients may screenshot, copy or otherwise re-share them. Do not share any dangerous information over Mastodon.

I feel like "operator" is not very clear to the average user, who is used to terms like "admins" and "mods"! So maybe it could say "the admins and moderators of the server and any receiving server may view such messages"?

I disagree, I think "operator" is the most appropriate term, i.e. someone involved in operating the service: mod, admin, sysadmin, database administrator

Gargron · Apr 4, 2018

I disagree, I think "operator" is the most appropriate term, i.e. someone involved in operating the service: mod, admin, sysadmin, database administrator

Yes, there are people responsible for and that may have access to your database that are not moderators or administrators—for example, sysadmins like hugo/alice, or virtual hosting providers like digital ocean

nightpool · Apr 4, 2018

Yes, there are people responsible for and that may have access to your database that are not moderators or administrators—for example, sysadmins like hugo/alice, or virtual hosting providers like digital ocean

nightpool · Apr 4, 2018

nightpool approved these changes Apr 4, 2018

View changes

Gargron added breaking legal labels Mar 7, 2018

Cassolotl referenced this pull request Apr 4, 2018
Closed
Reword direct message warning to set proper privacy expectations #7030

Gargron merged commit f1867a7 into master Apr 4, 2018
2 checks passed

2 checks passed

codeclimate All good!
Details

continuous-integration/travis-ci/pr The Travis CI build passed
Details

Gargron deleted the fix-privacy-policy branch Apr 4, 2018

mayaeh referenced this pull request Apr 5, 2018
Merged
i18n: Add Japanese translations for privacy policy and more #7049

Sylvhem referenced this pull request May 16, 2018
Merged
Reword the direct message warning #7420

SerCom-KC referenced this pull request May 21, 2018
Merged
i18n: Update Simplified Chinese translations #7565

+        +      <ul>
+        +        <li><em>Basic account information</em>: If you register on this server, you may be asked to enter a username, an e-mail address and a password. You may also enter additional profile information such as a display name and biography, and upload a profile picture and header image. The username, display name, biography, profile picture and header image are always listed publicly.</li>
+        +        <li><em>Posts, following and other public information</em>: The list of people you follow is listed publicly, the same is true for your followers. When you submit a message, the date and time is stored as well as the application you submitted the message from. Messages may contain media attachments, such as pictures and videos. Public and unlisted posts are available publicly. When you feature a post on your profile, that is also publicly available information. Your posts are delivered to your followers, in some cases it means they are delivered to different servers and copies are stored there. When you delete posts, this is likewise delivered to your followers. The action of reblogging or favouriting another post is always public.</li>
+        +        <li><em>Direct and followers-only posts</em>: All posts are stored and processed on the server. Followers-only posts are delivered to your followers and users who are mentioned in them, and direct posts are delivered only to users mentioned in them. In some cases it means they are delivered to different servers and copies are stored there. We make a good faith effort to limit the access to those posts only to authorized persons, but other servers may fail to do so. Therefore it's important to review servers your followers belong to. You may toggle an option to approve and reject new followers manually in the settings. Please keep in mind that the operators of the server and any receiving server may view such messages, and that recipients may screenshot, copy or otherwise re-share them.</li>

-        -      <p>When registering on our site, you may be asked to enter your name and e-mail address. You may, however, visit our site without registering. Your e-mail address will be verified by an email containing a unique link. If that link is visited, we know that you control the e-mail address.</p>
+        +      <ul>
+        +        <li><em>Basic account information</em>: If you register on this server, you may be asked to enter a username, an e-mail address and a password. You may also enter additional profile information such as a display name and biography, and upload a profile picture and header image. The username, display name, biography, profile picture and header image are always listed publicly.</li>
+        +        <li><em>Posts, following and other public information</em>: The list of people you follow is listed publicly, the same is true for your followers. When you submit a message, the date and time is stored as well as the application you submitted the message from. Messages may contain media attachments, such as pictures and videos. Public and unlisted posts are available publicly. When you feature a post on your profile, that is also publicly available information. Your posts are delivered to your followers, in some cases it means they are delivered to different servers and copies are stored there. When you delete posts, this is likewise delivered to your followers. The action of reblogging or favouriting another post is always public.</li>

-        -        <li>To improve our site &mdash; we continually strive to improve our site offerings based on the information and feedback we receive from you.</li>
-        -        <li>To improve customer service &mdash; your information helps us to more effectively respond to your customer service requests and support needs.</li>
-        -        <li>To send periodic emails &mdash; The email address you provide may be used to send you information, notifications that you request about changes to topics or in response to your user name, respond to inquiries, and/or other requests or questions.</li>
+        +        <li><em>To personalize your experience</em> &mdash; you can only interact with other people's content and post your own content when you are logged in. Furthermore you may follow other people to view their combined posts in your own personalized home timeline.</li>

-        -        <li>To improve customer service &mdash; your information helps us to more effectively respond to your customer service requests and support needs.</li>
-        -        <li>To send periodic emails &mdash; The email address you provide may be used to send you information, notifications that you request about changes to topics or in response to your user name, respond to inquiries, and/or other requests or questions.</li>
+        +        <li>To provide the core functionality of Mastodon. You can only interact with other people's content and post your own content when you are logged in. For example, you may follow other people to view their combined posts in your own personalized home timeline.</li>
+        +        <li>The email address you provide may be used to send you information, notifications about other people interacting with your content or sending you messages, and to respond to inquiries, and/or other requests or questions.</li>

tootsuite/mastodon

Join GitHub today

Adjust privacy policy #6666

Conversation

Gargron commented Mar 7, 2018 • edited Edited 4 times Gargron edited Apr 1, 2018 (most recent) Gargron edited Apr 1, 2018 Gargron edited Apr 1, 2018 Gargron edited Mar 7, 2018

Privacy Policy

What information do we collect?

What do we use your information for?

How do we protect your information?

What is our data retention policy?

Do we use cookies?

Do we disclose any information to outside parties?

Children's Online Privacy Protection Act Compliance

Changes to our Privacy Policy

Gargron added breaking legal labels Mar 7, 2018

This comment has been minimized.

m4sk1n commented Mar 7, 2018

nightpool requested changes Mar 8, 2018 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

nightpool commented Mar 8, 2018

This comment has been minimized.

ghost commented Mar 8, 2018

This comment has been minimized.

nightpool commented Mar 8, 2018

This comment has been minimized.

ghost commented Mar 8, 2018

This comment has been minimized.

akihikodaki commented Mar 10, 2018

duggulous reviewed Mar 27, 2018 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Cassolotl commented Apr 1, 2018

nightpool requested changes Apr 2, 2018 View changes

This comment has been minimized.

This comment has been minimized.

nightpool commented Apr 2, 2018

Cassolotl referenced this pull request Apr 4, 2018

This comment has been minimized.

Cassolotl commented Apr 4, 2018

This comment has been minimized.

Gargron commented Apr 4, 2018

Gargron added some commits Mar 7, 2018

This comment has been minimized.

nightpool commented Apr 4, 2018 • edited Edited 1 time nightpool edited Apr 4, 2018 (most recent)

nightpool approved these changes Apr 4, 2018 View changes

Hide details View details Gargron merged commit f1867a7 into master Apr 4, 2018 2 checks passed

2 checks passed

Gargron deleted the fix-privacy-policy branch Apr 4, 2018

mayaeh referenced this pull request Apr 5, 2018

Sylvhem referenced this pull request May 16, 2018

SerCom-KC referenced this pull request May 21, 2018

Gargron commented Mar 7, 2018 •

edited

Edited 4 times

Gargron edited Apr 1, 2018 (most recent)

Gargron edited Apr 1, 2018

Gargron edited Apr 1, 2018

Gargron edited Mar 7, 2018

nightpool requested changes Mar 8, 2018

View changes

duggulous reviewed Mar 27, 2018

View changes

nightpool requested changes Apr 2, 2018

View changes

nightpool commented Apr 4, 2018 •

edited

Edited 1 time

nightpool edited Apr 4, 2018 (most recent)

nightpool approved these changes Apr 4, 2018

View changes

Gargron merged commit `f1867a7` into master Apr 4, 2018
2 checks passed