It is important for a Start-up developer to know the purpose of a "Privacy Policy" and its cousin "The Terms of Use." They are not simply "make work" hassles for lawyers, or something to be copied blindly off of a Git repository. {Ed. Except if it is a Privacy Policy template from www.Baselex.com}.
The purpose of both can be summarized as the contractual obligations of each side, the user and the App provider, that exists when the App is used. {Ed. For our purposes, App covers any minimally interactive website.}
The purpose of both can be summarized as the contractual obligations of each side, the user and the App provider, that exists when the App is used. {Ed. For our purposes, App covers any minimally interactive website.}
Terms of Use
The Terms of Use are fairly straight forward and mostly deal with the User obligations. In an effective ToU, the App Provider lays out some explanation of the functionality that will be encountered in using the App (such as forums or comments) and a code of conduct that the users agree to be held to when using the App. For example, many apps have a "non-harassment" component to their Terms of Use. Users that violate this, generally find themselves on the wrong side of the "Ban Hammer". The Terms of Use are similar to an End-User License agreement, and tend to contain similar language. ToS, when effective, provide a User of an App with a clear list behaviors, rights, and obligations (such as honoring Intellectual property) that exist when they use the App.
Privacy Policy
Privacy Policies differ in significant way from Terms of Use and generally lay out how the App Provider will use the data of the User. The goal of any effective Privacy Policy is to highlight the ways that a User's personal identification and data might be used by the App Provider. Aggregated stats, geolocation, and preferences for Ad-Targeting are all pieces of data that an App Provider might collect about individual or collective users. There is no explicit rule in the U.S. that limits the data that an App provider can collect to specific categories. (with the exception of various HIPPA relevant issues which are beyond the scope of this brief post.)
What is required is that the App Provider lay what those pieces of information that are being collected. A well drafted Privacy Policy provides enough scope to the App Provider to modify their data collection practices based on market need, while not deceiving or misleading Users as to the scope and extent of the data collected.
Where SnapChat ran afoul of the FTC was in failing to abide by this primary role. The Snapchat Privacy Policy (according to the FTC) provided explicit statements on what data was and what was not collected through the use of the App. Specifically, Snapchat claimed that the communications sent to recipients was ephemeral to the recipient and not stored in any database or server. Through a series of hacker data breeches, it became clear that not only was this not true (there were vast databases of Snaps retained by Snapchat) but the data was not ephemeral to the recipient. The recipient of a Snap could, through various technological methods, obtain a permanent copy of the snap.
Furthermore, the Snapchat privacy policy explicitly disclaimed the storing of geolocation data. Again, after a review of the data stored by Snapchat, it became clear that geolocation data was being stored for future use.
As a result of these revelations, it became clear that the Privacy Policy and Terms of Use for SnapChat's app was woefully deficient and confusing. The natural outcome when consumers feel deceived and confused about the true nature of a product is an investigation by the FTC.
Therefore the first thing to ask when crafting a privacy policy is what does your app or website seek to accomplish, and how does it use the user data in order to accomplish task? There is no benefit in making a statement about specific functionality and features if these features are not present. Quite the contrary, there is a significant downside to telling App users one story about functionality, while the truth tells another. Likewise, if you need geolocation data, or contact lists, explicitly state that you need them and use them in your privacy policy. It is better to lose a few privacy adherents in the early use stage then have potentially millions of potential plaintiffs in a class action suit based on deception.
As final matter, Privacy Policies should not be drafted and locked in a drawer under the TOS/PP file folder in your server root. Every iteration of the App, from customer feedback, to posts, to direct messaging might change what type of data you need to collect from your users. Similarly, if you are changing revenue models, you might need to update your privacy policy to indicate the structural change in how you are using the data (from purely analytic, to a data broker model). A quaterly review of both the ToS and PP are a good way to ensure that you are not providing inadvertently misleading information to your Users about the App and their privacy.
Jordan Garner
Privacy Policies differ in significant way from Terms of Use and generally lay out how the App Provider will use the data of the User. The goal of any effective Privacy Policy is to highlight the ways that a User's personal identification and data might be used by the App Provider. Aggregated stats, geolocation, and preferences for Ad-Targeting are all pieces of data that an App Provider might collect about individual or collective users. There is no explicit rule in the U.S. that limits the data that an App provider can collect to specific categories. (with the exception of various HIPPA relevant issues which are beyond the scope of this brief post.)
What is required is that the App Provider lay what those pieces of information that are being collected. A well drafted Privacy Policy provides enough scope to the App Provider to modify their data collection practices based on market need, while not deceiving or misleading Users as to the scope and extent of the data collected.
Where SnapChat ran afoul of the FTC was in failing to abide by this primary role. The Snapchat Privacy Policy (according to the FTC) provided explicit statements on what data was and what was not collected through the use of the App. Specifically, Snapchat claimed that the communications sent to recipients was ephemeral to the recipient and not stored in any database or server. Through a series of hacker data breeches, it became clear that not only was this not true (there were vast databases of Snaps retained by Snapchat) but the data was not ephemeral to the recipient. The recipient of a Snap could, through various technological methods, obtain a permanent copy of the snap.
Furthermore, the Snapchat privacy policy explicitly disclaimed the storing of geolocation data. Again, after a review of the data stored by Snapchat, it became clear that geolocation data was being stored for future use.
As a result of these revelations, it became clear that the Privacy Policy and Terms of Use for SnapChat's app was woefully deficient and confusing. The natural outcome when consumers feel deceived and confused about the true nature of a product is an investigation by the FTC.
Therefore the first thing to ask when crafting a privacy policy is what does your app or website seek to accomplish, and how does it use the user data in order to accomplish task? There is no benefit in making a statement about specific functionality and features if these features are not present. Quite the contrary, there is a significant downside to telling App users one story about functionality, while the truth tells another. Likewise, if you need geolocation data, or contact lists, explicitly state that you need them and use them in your privacy policy. It is better to lose a few privacy adherents in the early use stage then have potentially millions of potential plaintiffs in a class action suit based on deception.
As final matter, Privacy Policies should not be drafted and locked in a drawer under the TOS/PP file folder in your server root. Every iteration of the App, from customer feedback, to posts, to direct messaging might change what type of data you need to collect from your users. Similarly, if you are changing revenue models, you might need to update your privacy policy to indicate the structural change in how you are using the data (from purely analytic, to a data broker model). A quaterly review of both the ToS and PP are a good way to ensure that you are not providing inadvertently misleading information to your Users about the App and their privacy.
Jordan Garner
No comments:
Post a Comment