I've written easily over a hundred terms of use agreements for my clients. When the lawyer's done, they send it to the client, and tell them to add a checkbox to their signup flow that says: "[ ] I agree to the Terms Of Use Agreement", with the agreement title being hyperlinked, usually to a PDF or sometimes a webpage. This is great. On day 1: everything works. This blog post is about what happens after day 1.
Two Important Things That Are Usually Missed
There are two big things that companies (and lawyers) miss:
1. How were the legal terms/privacy policy/whatever presented to the user, what did the page actually look like on YYYY-MM-DD? Is there any proof? Were screenshots taken of the user interface?
2. Can the company know exactly what versions the particular user agreed to, and on what dates?
Amendments And Version Tracking
At some point, the company wants to amend their agreement. So they post a new one online, and rely on the amendment process that makes amendments effective after X days. But how does the user get notice of this? Does the user click through a box in the app or website agreeing to the new terms? Is the new version emailed out to them to let them know?
If users are assenting to the new version, where is that assent stored? How does the company know which version of the agreement someone actually agreed to?
Most of the time, companies have no idea what version of the user agreement was agreed to. If the amendment is important enough they usually force some sort of assent through, but this is a clumsy process. And there's a big gap for most companies in assessing what each individual user/company actually agreed to.
The problem can be solved by having a version field in the user database, so that each user has a recorded version number of the highest version of the agreement that they've accepted (since agreements generally become more favourable to the company over time, or at least more suitable, this method is almost always fine).
Privacy Policies
Did the user look at the privacy policy? Was it displayed to them? How does anyone know the circumstances of that consent? As privacy laws strengthen, it will become more important to show that the users actually understood the nature of what they were consenting to, which is a different standard than for enforceable contracts. This is different than for contracts where merely knowing that terms apply is usually sufficient, whether or not they bothered to read them. But consent for a privacy policy is different, and it may be important how it was displayed to the user.
Tracking Assent & Consent: What Were The Circumstances?
Most companies don't track what their website looked like, or their app, at the time the user used it. They just assume that they set up an enforceable system, and then when the UI updates they just update it. Legal doesn't get a say in that, or even notification. So if the company is sued a year later, how do they know what the website looked like? If they're lucky, there's a screenshot, but very few companies proactively do that.
Ideally a company would want to know exactly what their user interface looked like, so that they can show that they made one that obtained the user's consent properly.
Acceptance Tracking Of The Current Version
There's some commercial software out there that tracks contract acceptances. They offer APIs so people can build their own solutions. These can usually be used with a hash of the user id or a hash of the email to not provide the PII of the entire user base to the service. So they can be used in a privacy-preserving manner, but they typically are cumbersome, usually requiring tracking to be based on a specific version of an agreement.
Ideally, the tools would be in place to present the current terms and get assent, rather than for a specific version. This is necessary to handle upgrades to the legal agreements, without necessarily going in and changing the code or the CMS system that's embedding the right code into the page. The reality of implementing these solutions is cumbersome.
Legal Ops
There's little attention paid to this unusual corner of the world of online legal agreements, probably because not many people ever challenge company's assertions about what user agreement applied at the time. It's also because there's very few people who have a deep enough understanding of legal agreements/policies to be able to properly use the APIs that vendors provide, and make sure they're working properly with the website/app. It's a distant after-thought for all but the very largest companies. I've often seen this be an area that gets overlooked, especially because the pain point comes later after there's been a few versions and changes to the UI.
Some Work I've Been Doing
I've been thinking about this problem for a decade (on and off). It's a bit outside of the scope of my work for clients, but it's also a bit of a pain point that's hard for them to address. And it's a fair bit of work to build a solution to it. That's why my main service for many years has been a website archiving service that I use to take weekly full page, high-resolution screenshots of their terms of use pages and privacy policy pages. The archives can allow my clients to look up what UI existed on any date. This is perhaps even more important than the assent tracking that vendors offer because what lawyers care about is the circumstances under which consent/assent was obtained.
I've recently been working on expanding the page monitoring to also include consent/assent tracking. There's a surprising amount of nuance to this, and my system is designed for privacy by only accepting hashes of the user information. For example, assent to a contract is recorded by taking the hash of the email, the hash of the phone number, and the hash of the user id, and then all three hashed identifiers are sent when the assent is recorded, so that it can be looked up later by any of those fields. This also creates a third-party record of the assent, so there's no issue with the company claiming a certain agreement applied but not having any support for it. A vendor-supplied system takes away that mistrust about the company's own-generated data.
My system allows companies to also generate client keys that can be used by third parties, which is helpful where the assent takes place off platform. It's also flexible enough to include assents related to emails sent out, effective dates, and even displaying the terms themselves (which are HTML generated from markdown).
If you're interested in talking about this unusual corner of the world of online agreements, please feel free to email me: addison@cameronhuff.com. You're welcome to try out the new system I'm building, or tell me about your own unusual use cases.