An important value at Status is transparency, but sometimes development moves so quickly that we don’t have the opportunity to pause, document, discuss, and disseminate the various components of the mobile app.
One way to help address this is by adding a privacy policy to the app to let our community know what services we use to make Status work, and how personal data is used. It is also an important reminder that we do have some centralized dependencies and employ services that may expose user info. This is just one step but an important one to be true to our principles as well as providing informed context to our users.
This process started by surveying our teams and asking members to list third-party services and how the data is used. We then took this starting point and used a service to create a thorough and encompassing privacy policy.
Next steps are to share the draft privacy policy and ensure it is accurate, clear and concise. Your feedback is appreciated to help make sure the policy is complete and digestible.
Finally, we plan to surface some of these options into the product to provide users with a clear and in-context way to be fully in control of their privacy and own their choices.
In parallel, we will also be updating the policy and where appropriate removing or editing services that clash with our principles, such as Mixpanel.
So for now please take a look at the draft privacy policy and let us know how we can make this better. Or simply become familiar with the various parts of Status
Messages. Signal cannot decrypt or otherwise access the content of your messages or calls. Signal queues end-to-end encrypted messages on its servers for delivery to devices that are temporarily offline (e.g. a phone whose battery has died). Your message history is stored on your own devices.
could be adapted to:
Messages. Status cannot decrypt or otherwise access the content of your messages. Status stores end-to-end encrypted messages on its servers for delivery to devices that are temporarily offline (e.g. a phone whose battery has died).
We can’t say that we queue messages as we don’t delete them once the users has asked for them ( we can’t do that), but I think it’s important to add the fact that we don’t have access to them.
Now that the policy is available in the app, we can look for way to improve the UX around it. In this case especially, user-friendliness increases transparency so I’ve been looking at ways to make the content easier to read.
The current standard seems to be that organizations have privacy policies that they don’t expect users to actually read. This makes companies legally compliant, but with an uninformed userbase. In fact, some reports claim that a majority of users think a privacy policy = the company doesn’t share data. (To that end, we explored giving the policy a different name, but there may be legal constraints here…)
By contrast, it’s our goal to have a user base that is well-informed and empowered to make choices in the app according to their preferred level of privacy. To achieve this Status could have a privacy policy that also serves to educate users about common data types and how they affect the anonymity of the user.
There are some formatting and input constraints in the tool we’re currently using to publish our policy, but I’m thinking we could have a table or legend of some kind with definitions & impact. Then, the user can scan the services listed in the policy and note the data types associated with them.
This is a rudimentary step toward productifying privacy, as has been discussed by @Chad@hester . Would love your thoughts on the above + any explication you can share on how this might be woven throughout the Status platform.
@Chad, now that we’ve borrowed iubenda to create an initial privacy policy, what we limit us from moving them somewhere else where we can create a table?
