Table showing compatibility of Web Crypto API with various browsers

Legal platforms like Clio have brought large firm tools to small firm/sole practitioners, and greatly improved the toolkit available to lawyers. What these platforms don't offer, and what almost all online platforms (e.g. Facebook) don't offer, is local encryption (explained below). The current way of doing things is that lawyers are uploading important information about their clients to systems that they don't control, and that disclosure is often not mentioned in lawyers' retainer agreements. How does this interact with the rules for lawyers, such as the rules for confidentiality in Ontario? How should lawyers be safeguarding client information? The rest of this blog post talks about one possible way of addressing confidentiality in the era of cloud software tools for lawyers.

Encryption is a broad topic and it's a term that is often abused. I use the term "local encryption" to mean that the contents are encrypted on the users' local computer and then uploaded to the "cloud" (i.e. a company), so that the cloud provider (e.g. Clio) can't read the contents of your messages or know who your clients are. This can be accomplished to a degree with Clio using extensions like Cloudmask but the Clio service, and all of its competitors, are built around the idea of plaintext data that's encrypted (maybe) server-side, not locally. Access is controlled through user accounts and SSL ("https://..."), and the software provider has full visibility of the data (subject to their own internal controls, which are almost always not disclosed in privacy policies). It is possible to build a service that operates very similarly, but relies on locally encrypting all of the user data so that only the lawyer has access to it. The key to this system is using the now standard Web Crypto API.

Web Crypto API allows developers to use native encryption tools (i.e. not huge, inefficient Javascript libraries like Forge) so that users can create private keys that are used to encrypt all sensitive data, then send that encrypted data to a server. The data stored on the server is then decrypted when the user logs back in and made available in their brwoser. This can be done using familiar username/password systems that encrypt a private key locally using a hash of the user's password (or a derived hash) and then stores that on the server so that it can be downloaded when the user next logs in.

Local encryption hasn't been done because it's complicated and can result in data being lost if the private key(s) are lost. Users have to-date been far more interested in convenience and price than they have with confidentiality. It's also been held back by the lack of standardized native tools, but this has been solved with the wide availability of Web Crypto API. Lawyers should be the biggest advocates for local encryption and yet it's an issue that's very poorly understood, even by power users of lawyer SaaS platforms.

Why switch to local encryption? It allows lawyers to freely use services without having the risk of their client data being divulged to service providers, who generally don't need the data anyway. These services could also include messaging components to ensure a higher degree of security than email systems offer, but retain the convenience of web-based tools.

The best protection of privacy is not a privacy policy. The best protection of privacy is to ensure that no one else can see your data. Local encryption achieves that, and it can be done in a way that's visible to the user (although only technically-sophisticated users would be able to actually see this for themselves). At the very least, I think there's room for power users to enable these options so that they can choose a higher level of security that may come with trade-offs that regular users aren't yet prepared to make. That said, lawyers ought to be first in line for a service that's slightly less convenient but better protects client confidentiality, one of the core elements of the legal profession.