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 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? What about agreement opt-outs (e.g. arbitration opt-out notice from the customer)?

Understanding User Acceptance

Below are some points to consider about the challenges of doing this properly. If it's not done properly, a company might not be in compliance with an applicable regulatory regime, or it might not gain the benefits of the contract it paid lawyers thousands of dollars to draft.

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 only a vague 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 On Automating This

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 to dive into their technical systems, 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.

For many years I've tracked my clients' agreements and their consent flows with a website archiving service that I made. I originally made it to track pages related to some large-scale litigation I worked on. It takes daily or weekly full page, high-resolution screenshots of any page (something that is somewhat difficult to do properly). 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. I also want to build a system that's privacy-oriented, because I don't want to receive personal inforamation about my clients' users. My system is designed for privacy by only accepting hashes of the user information, rather than the PII itself. 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.

Using a software system 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, and is one reason for companies to use vendors to do this task rather than develop it in-huose.

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). This works by providing a flexible set of APIs.

Legal Ops For Assent: Email Me!

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.