Some Tips For Vendors When Looking At Your Privacy Policies
4 min read
This post is the result of many conversations over the last several years with Jeff Graham. It highlights some things that we have seen in our work on privacy and open educational resources. This post focuses on privacy, but the general lesson - that bad markup gets in the way of good content - holds true in both the OER and the privacy space.
When looking at privacy policies and terms of service, the most important element is the content of the policy. However, these policies are generally delivered over the web, so it's important to look at how the pages containing these policies perform on the web. Toward that end, here are some simple things that vendors should be doing to ensure that their policies are as accessible as possible to as many people as possible, with as few barriers as possible.
Toward that end, here are four things that vendors should be doing to test the technical performance of their policies.
- View the source. In a web browser, use the "view source" option. Does the text of your policy appear in the "main content" area of your page, or some semantic equivalent? Are you using h1-h6 tags appropriately? These are simple things to fix or do right.
- Google your privacy policy and terms of service, and see what comes up. First, use the string "privacy policy OR terms of service [your_product_name]". See what comes up. Then, use the more focused "privacy policy OR terms of service site:yoursite.com" - in this search, be sure to omit the initial "www" so that your search picks up any subdomains.
- Use an automated tool (like PhantomJS) to capture screenshots of your policies. If PhantomJS has issues grabbing a screenshot of your page, it's a sign that you have issues with the markup on your page.
- Use a screenreader to read your page. Listen to how or if it works. Where we have observed issues with a page failing to behave in a screenreader, it's frequently due to faulty markup, or the page being loaded dynamically via javascript.
To people working on the web or in software development, these checks probably sound rudimentary - and they are. They are the technical equivalent of being able to tie your shoes, or walking and chewing gum at the same time.
In our research and analysis of privacy policies, we have seen the following issues repeated in many places; some of these issues are present on the sites of large companies. Also worth noting: this is a short list, highlighting only the most basic issues.
- Pages where the policies are all wrapped in a
formtag. For readers unfamiliar with html, the form tag is used to create forms to collect data. - Pages where, according to the markup, the policies are part of the footer.
- Pages where, according to character count, the actual policies only account for 3% of the content on the page, with the other 97% being markup and scripts.
- Sites where Google couldn't pick up the text of the policy and was only able to index the script that is supposed to load it.
We are not going to be naming names or pointing fingers, at least not yet, and hopefully never. These issues are easy to fix, and require skills that can be found in a technically savvy middle schooler. Vendors can and should be doing these reviews on their own. The fix for these issues is simple: use standard html for your policies.
We hear a lot of talk in the privacy world about how privacy concerns could stifle innovation - that's a separate conversation that will almost certainly be the topic of a different post, but it's also relevant here. When the people claiming to be the innovators have basic, demonstrable problems mastering html, it doesn't speak well to their ability to solve more complex issues. Let's walk before we run.
