A label on food is easily looked at and any important information can be found within seconds.
The vast majority of Privacy Policies do the exact opposite. The function as a method to obscure the important details.
The vast majority of Privacy Policies do the exact opposite. The function as a method to obscure the important details.
I co-authored the Snowdrift.coop terms of service[2], which we adapted from GitHub -- we could not afford legal review and figured GitHub has enough lawyers to make sure the CYA language included was thorough enough to cover us pre-launch (we will get legal review before processing payments for outside projects). There was some legalese we'd prefer to remove but didn't feel comfortable without legal counsel, but the summaries are non-binding so we rewrote many of them to be more descriptive. Curious what you think!
On the privacy policy[3] side, we agreed with you -- if our policy was long or complicated enough that a summary was necessary, we were doing something wrong. So we just described all the ways we collect personal data, in "If you X, we will Y" format. For example,
> If you create a Snowdrift.coop account, we store your email address and use cookies to keep you logged in.
I wish more sites had policies like this, so that "long and unreadable policy" would become more of a red flag.
[1]: https://help.github.com/en/github/site-policy/github-terms-o...
I read through a good amount and I think they make sense. The short version helps, but that always worries me from a legal standpoint. If we summarize something in a legally ambiguous way have we undermined the original intent?
There are some inconsistencies with how you present the data that I think would help to smooth out. On your summary table. You start with the description being more of a goal for that section, than sporadically start switching to the "short version" of what your terms are.
For me I was hoping that it would be the short-version so I essentially get a comprehensive cliff-notes kind of view.
Also some minor issues with bolding some headers 4. Project Termination 4. Survival
As well as inconsistently formatting the short version. (I prefer the all bold version to help clearly show where the short part ends)
Privacy policies are much easier for me to wrap my head around. What you store, How you store it, and what you do with it.
This clause was a good idea that I will "borrow":
If our corporate structure or status changes (e.g., if we restructure, are acquired, or go bankrupt), we will notify all users so that you may choose to anonymize or delete your private data before we pass on any data to a successor or affiliate.
My version is here https://www.pritact.com/privacy-policy.html which I think follows along a lot with yours in spirit, but just has less ground to cover because of the nature of my platform.
I share some of your concern. A written contract (including ToS) is supposed to capture an agreement between two parties, so if they later disagree on what was agreed, there's an unambiguous record. If one party isn't clear on the terms as written (say, because they only read the legally-ambiguous summary), then it's hard to say there was an agreement.
Unfortunately, these goals are often at odds: many websites/services feel the need to include lots of boilerplate to shield themselves from liability, and in the pursuit of precision, legalese is often jargony and inscrutable. In my opinion, we'd be better off if people didn't disclaim so much liability and were willing to take a chance on clearer but less established language. But there are societal reasons for those things that I can't really fix as an individual.
So, ideally, terms should be both legally precise and short/layperson-readable; in practice that's often not possible, which means any readable summary is necessarily ambiguous (otherwise, we'd just replace the terms with it). Given that existing ToS are often not layperson-readable, I think they're already failing to establish agreement, so I think that summaries, while clearly a non-ideal compromise, are a net positive.
> You start with the description being more of a goal for that section, than sporadically start switching to the "short version" of what your terms are.
I agree it could use more consistency and I agree the "shortest version" is better (many "goals for the section" barely have more meaningful words than the section title alone). It is how it is because summarizing is hard and our time is not unlimited. Definitely open to future revision.
For what it's worth, there is a "short version" at the top of each individual section; the table at the top is a further summary (hence "shortest" above). Given more bandwidth, I'd make each of the table sections expandable to show the "short version" as well.
> Also some minor issues with bolding some headers 4. Project Termination 4. Survival
Thanks. I suspect this has to do with the conversion from markdown (as they were written) to hamlet (for display). Opened an issue to track it. https://gitlab.com/snowdrift/snowdrift/-/issues/186
> As well as inconsistently formatting the short version. (I prefer the all bold version to help clearly show where the short part ends)
This was intentional; the bolded summaries are for two sections (warranty and liability) which, IIRC, are legally required to be emphasized. Usually that's done by putting the sections themselves in all caps (ugh), with the side effect of making them unreadable. GitHub's terms, on which ours are based, have a bold "Please read this section carefully; you should understand what to expect." in that section after the summary; we opted to just bold the whole thing. Maybe that's confusing, though, and we should just follow their lead.
> https://www.pritact.com/privacy-policy.html
I agree, it looks nice. :) Especially, I like putting the form of data collected as the first words of each sentence under "what we store". Having our "If you…" part first makes it read better but harder to skim. I'll propose changing that next time we modify the policy.
Aside, I looked at the home page and while I understood what your service does, it wasn't clear to me how it was delivered (app? website? dedicated hardware (joking)?). I don't think I would have figured it out if I hadn't seen a reference to app.pritact.com in the privacy policy.
Concise, understandable, and explanations for almost all items are available.
As a consumer it's extremely hard to find out what you need in a Privacy Policy, as it is simply too big of a document generally.
For companies its different as they should have someone payed to read that.
So what is needed is a standard way of conveying what data is being collected. And what is kept in-company, and what is shared/sold. Just like the ingredients in a package, a simple Table.
I don't really agree. if I look at the label on a box of poptarts, I can see the number of calories in a serving and the ratio of carbs, fat, and protein. from this I can conclude that it is a relatively unhealthy food, but I have no idea how to interpret the breakdown of exactly what types of fat they contain. are polyunsaturated fats bad? what about monounsaturated? the nutrition facts are right there on the box, but I don't really know what they mean without doing a bunch of research.
the actual ingredients list is worse. there are at least ten ingredients in poptarts that I just don't recognize. I can clearly tell that they are not an "all natural" food, but not much else. if I had a food allergy or wanted to avoid a specific additive for whatever reason, it would certainly be useful, but otherwise not so much.
Privacy policies are many, many more than 3 tweets.
The format of the page is mandated by the government, including the font and margins. It is easily scraped and must be by law. This label is required in place of a privacy policy.
Facebook.com will:
Store data about you forever in a profile.
Share data about you with 3rd parties.
Show you advertisements based on a profile.
Show you content based on a profile.
Share profile about you information with law enforcement.
Facebook.com’s top five markets by revenue are:
Advertising
News Redistribution
Device Development
This may still be opaque and ignored by most people. Standardizing the language and format in a way that laypeople can read delivers actual value to consumers.
With a few things people like to avoid, it's tricky -- MSG notably can be under a bunch of different names -- but most common allergies are clearly highlighted, or at least not hidden.
If you don''t have specific things you need to avoid, then of course a list of the specific things in it is not useful, but why/how would it be? It has a purpose and it serves that purpose.
"Is this healthy?" isn't an answerable question. There's no one specific answer true for multiple people--it's analogous to "Will this website respect my privacy?" On the other hand, "Is this vegetarian" and "Will this website share my data with third parties" are. (Or are closer to being so.)
I want to know if there's meat in an item of food, and the label tells me that in a fairly easy-to-read format.
I want to know if my data will be shared to third-parties by a website, and the privacy policy maybe provides it to me, but in a very inaccessible manner.