Osano Free Tier

Privacy and cookie consent are all the rage as lawyers pretend to have an understanding of how the Internet works and try to write laws about it using ridiculous terms like “right to be forgotten” no matter how technically infeasible they are. Luckily, companies like Osano can help you navigate the changing world.

The Landscape

Europe’s GDPR is the granddaddy of privacy laws, with GDPR which secretly stands for Grossly Detrimental to Procurement of Resources - it’s a LOT of work to be compliant and, like many laws, it’s a Sword of Damocles hanging over every startup’s head dependant on matching interpretations of how Personally Identifying Information (PII) is defined. Since then, a growing number of countries have introduced similar legislation and the US has set the stage for state-level laws meaning 50 times the regulatory compliance overheadi for a single country.

Osano’s primary benefit is their frequent newsletters. Startups often don’t have a Chief Regulatory and Compliance officer on staff to monitor these things, but Osano does monitor them and provides regular updates.

I tend to split privacy and compliance into five different classes of problems, and any new product should consider these from the start even if the initial rollout is limited to a single region.

Transparency

Document EVERYTHING. Any third party tooling should be placed into a list for easy reference. Ideally, this list should include the name of the library/tool, the specific reason it was included, the current version (if applicable), and preferably a link to their Data Processing Agreement indicating how the tool uses any data it collects. Many of these may be no-ops from a transparency perspective. A downloaded library may not collect any data and reside as part of your system software, but having a single repository will assist in any vulnerabilities discovered that may have inadvertently created an exposure.

Privacy

Be careful about what data you collect, who has access to the data, where it’s stored, and how long it’s stored for. Most applications need an email or mobile number for communications, but do they really need physical address information, age, or gender? Passing that email address to a marketing email system may be deemed necessary for certain system emails, but that does not mean that they have opted in to marketing emails or that the email should be used for purposes outside of the product the customer is using. You don’t want to have your legitimate application confused with a sleazy product gathering emails for spam.

Data Residency

This is often the most sinister side-effect of privacy laws, it moves data within reach of governments and may expose certain users to a distinct lack of privacy under certain jurisdictions. Data Residency involves the physical location where data is stored, as a general rule it is useful to have at least two data centers in each major geography where your application is sold, this also helps performance as files owned by a US customer can be stored in the US while content for EU customers can be stored in the EU. However, selling to global organizations becomes problematic and you need to think through how to tag content (Is it for each file? For each project? For each customer? For each end user?) and how, or if, a user in one geography can access content from another when it is shared with them. As with many regulations, much of it comes down to an official description used to create these definitions rather than the actual implementation details. And, of course, weighing the government’s desire to have access to your customers’ data vs. your customers’ need for privacy FROM the government is also a critical factor for many messaging platforms and discussing creative solutions with an actual attorney is generally recommended in those cases.

Removal of Data

An early feature should be the ability for a user to remove their own account - whether this is a support ticket leading to an internal process that can be followed or (ideally) an automated feature. Again, this process needs to be documented. Does account removal automatically remove the user from marketing lists? Should the user information be deleted, or flagged as do not contact so they will never be added again? What if the user signs up for another account with the same email? With a different email? Having the ability to enumerate the places where customer data is held, why the system has the data, and having a process to remove the data is critical to build into a modern system.

Security

Of course, all of this is useless without a proper security posture. You may not be selling your users’ information to spammers but if your marketing engine is wide open or if an underpaid intern has access and sees a way to make a quick buck, you could be on the hook. Don’t automatically give people access to systems, especially those containing PII. Keep track of who has access to what, and when someone leaves the company for any reason ensure their access is removed. The more places this data is stored, the larger the attack surface for bad guys hungry for lists. Every decision made around customer PII needs to be made thoughtfully and purposefully.

Installation and Configuration

Osano is similar to most other tools I use, it’s just a simple JavaScript include in your header that will produce a banner and start monitoring cookies. However, it also puts a cookie icon on your app to adjust privacy, and not one I really like. But there’s a quick fix for that which allows me to tie the privacy controls to a link styled to match my page.

Once done, you can configure a website to monitor and Osano will start gathering data associated with it. It can monitor the cookies you’re setting, the JavaScript being loaded, iframes potentially leaking additional content, etc. You can classify the cookies and scripts as Essential, Analytics, Marketing, Personalization, or you can Blocklist them in case you’d rather not have them included but they come with a toolset that tries to set them.

However, by far the most useful feature is access to a bunch of documentation on the subject, and you don’t even need an account.

Limitations in the Free Tier

Cookie management and discovery is useful, but it’s only part of the story. Subject Rights offers a ticketing system for privacy concerns. Osano true plugin support, but does offer webhooks which can be used to do things like create Slack messaging when events occur, and then users of the system with the appropriate permissions can manually handle these requests. You may wish to use other mechanisms to generate these tickets into a more common support platform, but the Osano offload here could provide value as a third party system geared around privacy.

There’s also a bunch of tooling such as Data Mapping which allows for a better visualization of your privacy landscape. This is useful if there is one individual responsible for privacy in your company, but I feel that many of these tools are more templates to help you properly document in your own language (for example, Miro) and to have that data accessible to more of your organization. Developers make different decisions when they are presented with privacy data and realize that elements X, Y, and Z will end up in the hands of marketing and this helps reduce your privacy headaches in the long run.

Summary

Global Privacy laws are a mess, Osano (and companies like them) help to aggregate data into a common place with a focus on compliance. They provide a great stop-gap solution for early stage startups without a proper legal team in place, but they don’t obviate the need for a consultation with a privacy lawyer to hash out details. While the idea behind privacy laws is good, the reality is that most information gatherers are throwaway companies that simply disappear once they get busted only to reappear under another name. Using something like Osano can not only set you apart from a fly-by-night company out to make a quick buck, but more importantly helps you with a global privacy mindset as you’re creating your application.