About Email, the Cloud and Privacy

The privacy implications of multiple ISPs

When you send an email, as when you send a letter through the UK postal system, you are relying on the operator of the system (to deliver your email or letter to the recipient you specify and not to anyone else). With email the situation is more complex because a number of different Internet Service Providers (ISPs) will be involved.

Access provider ISPs provide Internet access, connecting users to their network by telephone wires, fibre-optic cable, or using mobile data (e.g. 5G).

Hosting ISPs may provide services such as web-hosting (e.g. Google Sites), and cloud storage services (e.g. Google Drive) as well as email servers to send, receive, accept, and store email (e.g. Gmail). Many hosting ISPs are also access providers (e.g. BT) while others are not (e.g. Google and Microsoft). Some large organisations such as universities and large businesses provide their own hosting ISP.

Transit ISPs provide large amounts of bandwidth for connecting hosting ISPs and access ISPs. Just as their customers pay them for Internet access, ISPs themselves pay upstream ISPs for Internet access. An upstream ISP usually has a larger network than the contracting ISP or is able to provide the contracting ISP with access to parts of the Internet the contracting ISP by itself has no access to. In the simplest case, a single connection is established to an upstream ISP and is used to transmit data to or from areas of the Internet beyond the home network; this mode of interconnection is often cascaded multiple times until reaching a tier 1 carrier. In reality, the situation is often more complex. ISPs may have separate connections to an upstream ISP at multiple points or they may be customers of multiple upstream ISPs and may have one or more connections to each of them. 

Letters sent via a British postal provider from one address to the other on the island of Great Britain should never leave the island. A letter from York to Dover might be routed via London but would never be routed via Calais. It is different with Email: if both you and the person you are sending an email to are both using computers or other devices within the island of Great Britain and you both use mailboxes provided by hosting ISPs in Great Britain then the route taken by your email will probably be wholly within Great Britain. But even this is not guaranteed. The internet is a network of connections and the routing of traffic can vary. If there is a fault on one connection, traffic will automatically be diverted. Traffic can also be rerouted over under-utilised connections as part of load balancing. This can result in GB to GB traffic being "tromboned" so that an email from a Birmingham mailbox provider to a London mailbox provider might be routed via Paris. Of course if either mailbox provider is actually in another country  then the email's route will always include that country, and possibly also other, countries, in addition to the UK.

The fact that multiple ISPs are involved in virtually every email transmission increases the risk of there being one ISP, out of all the ISPs involved, which might not respect your privacy or might not be secure. And the matter is further complicated if the ISPs are in different countries because the data protection laws may vary from country to country providing more or less or, at least, different legal protection. 

Email apps are known as "email clients". They run on the local device, providing the functionality of composing emails etc., and also communicate periodically with the mailbox to send completed emails and receive any incoming emails.

When you are using a webmail system (rather than an email client) the data packets passing between your browser and the email website may also pass, in this case almost instantaneously, through many ISPs.

In addition to webmail, other websites may provide other services such as cloud storage, legal document management/bundle production services (e.g. Bundledocs, eBrief Ready) online utilities, and file transfer. The providers of such services may provide the option of accessing their services by means of a client app instead of by website.

Data at rest and data in transit

How secure data, once it is stored in the mailbox of the recipient of email, or in a website or other server, is, depends on the capabilities and reputation of the mailbox or server provider and the legal system of the country where it resides. But the security of data in transit depends on a large number of ISPs often in a number of countries and is more of an unknown quantity.  

Encryption 

If data is encrypted then, in theory, it does not matter if an unauthorised third party sees it because the data is scrambled and can only be decrypted into a meaningful form with the secret encryption key (password). Encryption can be used for data at rest but is of particular importance for data in transit as a way of mitigating the security risks when data in transit passes through a number of ISPs.

Providing you use the HTTPS protocol when using a website, a public/private key pair will be used for encryption. The sender's system uses the recipient's public key to encrypt data sent using an algorithm which means that it cannot be decrypted except with the private key which only the recipient system knows. This protocol is known as TLS (sometimes known as SSL/TLS but not to be confused with older, less secure, versions of SSL). In the event that the website does not support the HTTPS protocol your browser should give you the option of either using the less secure HTTP protocol - which does not use any form of encryption - or else not proceeding at all.

Where services are accessed using a client app a similar protocol which employs encryption - TLS - can be used. 

But in the case of emails being sent between your mailbox and the mailbox of the person you are corresponding with - via any intermediate relays - encryption is typically "opportunistic". The fact that data passing between your browser and the webmail, or between an email client app and your mailbox server, is encrypted does not mean that other legs of the journey are also encrypted. Generally each email relay will request the next to use an encrypted protocol but, in the event that that request is declined, an unencrypted protocol will be used instead to ensure the email is delivered. After all being able to send an email to any email address is the key idea of email. 

The problem of emails sometimes being sent in clear text between mailboxes does not arise if both sender and recipient happen to use the use the same email provider but it would be an inconvenience to have to create a new email account using the same system as every recipient and thereafter have to check it regularly for new emails. After all the general idea of having an email address is that you only have one email address to check and anyone can use it to send to you using their existing email account without having to sign up to any new system.  

The risk of significant breaches of privacy is increased where an entire set of data (such as all the documents in a legal case) is in transit, all in one go, by email (as distinct from only portions of data being sent by email). It is possible to instead use a HTTPS web-based file transfer system which allows you to load the documents and then provides a download link consisting of randomly generated characters (effectively a password) which you can then be sent to the recipient who can then use it to download the file from the server without having to create an account. Alternatively, in such bulk data transfer situations, the end users may agree to send the documents as email attachments but apply end-to-end encryption between themselves. Most  data archiving programs - such as RAR and 7-ZIP - have the ability to encrypt data  - using a specified or generated password when an archive is being created to be sent by email. But you still have to send the link or encryption password to the recipient and if you send that by email there is a risk, albeit perhaps a smaller risk, of that being intercepted on an unencrypted leg of the journey (or by a disreputable relay).

Some tribunals (such as the Supreme Court and the Judicial Committee of the Privy Council) allow documents to be both filed and served simply by being uploaded to the tribunal's secure portal which uses HTTPS - the portal automatically generates an email notification to the party served that they can log on and view and/or download the document. However most tribunals which provide a portal only allow documents to be filed using the portal and service of documents on the other party still has to take place separately. In these tribunals if service by email is allowed any documents served by email must be actually sent as email attachments - sending a private download link would not be good service.  

Modern encryption algorithms are very strong and difficult to break at least without using enormous computer power which few organisations possess. But whatever the quality of the mathematics underlying the algorithm, and apart from the question of how well any software implements a particular encryption algorithm, ultimately you are trusting the provider of the supposedly encrypted service that it really does do what is claimed and will keep your data secure. You could use a program to encrypt data before sending it via a web-based data transfer system but then that depends on trusting the program supplier.

The overall risk   

Most people with ordinary legal cases (cases not involving trade secrets, for example) consider the risk of using email and the risk of sending data to reputable websites and other servers, to be acceptable risks, providing HTTPS is specified when accessing websites and TLS is used by client apps so that email is, so far as possible, encrypted (in the case of most email client apps they automatically use TLS. Otherwise TLS can be specified under "server settings" when initially setting up the app for a particular email account).   

This page was lasted updated in April 2025          Disclaimer