S/MIME vs. PGP

Why companies need email encryption

Cyber incidents are one of the most significant risks for companies. Encrypted communication is an important contribution to preventing cyber incidents and data breaches—especially email communication.

S/MIME and PGP are the best-known and most "common" solutions for email encryption. Both methods have existed since the 1990s, but to date, they have not gained widespread acceptance, either in the private sphere or in business correspondence.

For companies, email is still the medium of choice for communication, and it is impossible to imagine today's business world without it. After all, it is the medium that everyone knows and uses.

However, email must first be made secure for business communication that regularly contains sensitive data. This is achieved with encryption. It enables companies to protect their most valuable resource – their own data – from unauthorized access.

Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on.

Edward Snowden, US Whistleblower

Therefore, companies need email encryption – with S/MIME and PGP, solutions for this purpose have been available for decades. But despite this, neither method has been able to support companies in encrypting their business communication across the board. How can this be?

The reason becomes clear when you take a closer look at how S/MIME and PGP actually work and what business requirements they fulfill.

In practice: 

S/MIME and PGP for encrypting emails in private and business communication

S/MIME and PGP: not compatible with each other

First of all, it is important to know that the email encryption methods S/MIME and PGP are incompatible. To protect their own emails by encrypting them with S/MIME or PGP, enterprises or users must first decide which method they want to use– and then clarify whether they can do so with their respective contact partners. It may, therefore, be necessary to make the extra effort to use both encryption methods in parallel.

No one-size-fits-all solution for private users

What makes the use of S/MIME and PGP even more difficult in the private sector is that there is no "one S/MIME" or "one PGP" that can be used for email encryption. Email is used in many forms: there are email applications that can be installed on an operating system directly, as well as internet browsers that can access various email clients. The actual integration of email encryption with S/MIME and PGP depends on the individual circumstances of the person who wants to encrypt. Unfortunately, there is no one way that everyone can use S/MIME and PGP for email encryption, meaning these do not provide a uniform solution for all users.

For end users, email encryption simply needs to work. This means sending encrypted messages without in-depth technical knowledge or preconditions must be possible. Ideally, the users should have to do as little as possible for this themselves; after all, not everyone is an IT administrator. S/MIME and PGP have clear shortcomings for the end user, particularly concerning the critical point of user-friendliness. This is because of how these two encryption methods work and all the things the user has to do to set them up.

For enterprises, security only works through usability and acceptance

Even with solutions for S/MIME and PGP specifically for the use of encryption in enterprises, there are differences in the concrete design and the scope of functions. For companies, however, the requirements go even further. They, too, need a solution for protected business communication that is easy to use and maintains email as a popular medium for their workforce as well as their communication partners. For this, it is crucial that the gain in security is not at the expense of usability. Any security solution can only be implemented effectively throughout the company if users accept and use it. Even the smallest hurdle in its application is often too high and can cause even the best technical solution to fail, so it really can't be simple enough.

Why encryption for communication alone is not enough for enterprises

In the modern business world, however, communication from and with enterprises also has major intersections with areas such as data protection, IT security, compliance, the automation of communication processes, etc. With this comes requirements and needs that go far beyond mere encryption and demand much more from communication solutions. Many solutions for companies that provide email security by means of common email encryption methods are more user-friendly than S/MIME, and PGP are for private use. However, they fall short and do not provide the added value that makes the difference for today's business communication.

S/MIME:

Basic principle and function of S/MIME encryption

S/MIME ("Secure Multipurpose Internet Mail Extension") was developed in 1995 and defined in 1999. With this procedure, messages can be encrypted and signed so that their content cannot be read by unauthorized third parties, and the recipient knows that the specified sender is, in fact, the one who sent the message. It can be individually determined whether a message is to be encrypted and/or signed. Nowadays, S/MIME is supported by most email clients and does not require any additional software installation for private use. To use email encryption with S/MIME, two things are required:

1. The X.509 certificate must be obtained for the user in question.

2. This certificate must then be integrated into the respective email client of the user.
   In the actual implementation, however, there are still a few intermediate steps for both of these points, which must be successfully completed by the respective user.

Nowadays, the use of S/MIME in enterprises is mostly done via special business solutions from third-party providers. The concrete implementation of such solutions for email encryption, which function on the basis of S/MIME, depends on the given circumstances and is carried out by the IT experts, usually the respective admin.

Email encryption with S/MIME – a hybrid encryption method

Encryption with S/MIME works with key pairs. Each communication partner has a public and a private key, which makes this an asymmetric encryption method as both parties use different keys. The encryption is carried out by the sender, who encodes the message utilizing a session key; this takes place within the framework of a symmetrical encryption. The session key is then encrypted asymmetrically with the recipient's public key. Since both symmetric encryption (with the session key) and asymmetric encryption (with the public key) are used in this procedure, S/MIME is referred to as hybrid encryption.

During decryption, the recipient decodes the encrypted message with their private key. To ensure that no one else can do this, it is therefore important to store the private key carefully and ensure that no one has access to it.

Signing messages with S/MIME

Signing emails serves to authenticate the identity of the sender and simultaneously transmits the sender's public key to the recipient. This enables the recipient to verify beyond doubt whether the email really comes from the specified sender. In the corporate environment, this is, therefore, particularly interesting for the defense against phishing attacks. With S/MIME, a unique signature is added to an email to be sent using the sender's private key. On the recipient's side, the signature is then checked using the sender's public key. If something is wrong, the recipient is notified and must assume that the message has been tampered with.

Key exchange between communication partners as a basic requirement for encrypted email communication

For encrypted email communication with S/MIME, the desired email communication partners must know the public key. This works on the one hand, as already mentioned, via the signature: with this, the public key of the sender is transmitted to the recipient at the same time. In addition to the possibility of transmitting the public key directly to the relevant contacts, it can also be uploaded to an external key server. Other methods include publishing the key on a website or transmitting it in physical form, for example, on a USB stick. In practice, however, the latter is unusual and rather inconvenient. The public key is then used to encrypt all emails to the key holder. S/MIME does not work without the exchange of public keys.

Decryption of messages with S/MIME

Emails encrypted with S/MIME are then decrypted with the private key of the recipient. This decrypts the session key, which can then be used to decrypt the encrypted message.

The private key must, therefore, only be known to its owner and must also be protected by a password. If the private key should fall into the hands of a third party, the entire communication for which this key was used is affected. This means not just an email or correspondence with one contact partner but everything.

S/MIME certificates for key generation

For the use of S/MIME for email encryption, an X.509 certificate is required. Private users can obtain this from various providers or generate one themselves. The latter option is free of charge but quite time-consuming, as you have to ensure that your certificate is accepted. It is then necessary to first create a so-called root certificate, which all contact partners must import for the email exchange before the public keys are finally exchanged. Typically, recognized certification authorities are therefore used to obtain certificates.

Certification authorities and certificate classes

Certification authorities offer the advantage of ensuring that public keys and their owners really belong together, meaning that the key belongs to the intended recipient and that an email actually originates from the specified sender. This is an advantage over PGP, where this certainty does not exist in this form.

There are different classes for certificates; the class to which a certificate belongs depends on how the person who wants to obtain the certificate is checked:

• Class 1: the existence of a specified email address is verified.

• Class 2: in addition to the email address, the name and, if applicable, the company is confirmed in writing.

• Class 3: the certificate holder must authenticate their identity, e.g. with the help of an identity card.

• Class 4: the certificate holder proves their identity by appearing in person at the respective certification authority. This would be the most secure way to authenticate identity, but it is impractical and expensive and, therefore, not an option that is actually used in practice.

These classes have no effect on the security of email encryption with S/MIME certificates; they only say something about whether/how the applicant for the certificate has confirmed their identity. The certificates are of limited validity, which is usually one year (but some are valid for longer). To be able to use S/MIME permanently and reliably, it is, therefore, absolutely necessary to ensure that you always have a currently valid certificate.

For the successful issue of a certificate, several provider-specific steps must be completed. After the certificate has been successfully issued, it can usually be downloaded, or the private user receives an email that contains the corresponding URL where it can be retrieved.

Setting up S/MIME manually

Overall, setting up S/MIME is easier to implement than PGP. In recent years, technical requirements have been created to support S/MIME in various configurations.

S/MIME in an email client

After the S/MIME certificate has been obtained, a personal certificate must be generated and then installed. Next, the necessary settings must be made in the email client so that it uses S/MIME with the help of the corresponding certificate. Usually, the email client is restarted after the configuration is complete.

Is there a simpler way? S/MIME solutions in enterprises

When you briefly estimate how many employees would have to set up S/MIME manually – and how many of their contact partners would potentially have to do the same – does this sound like a practicable solution for everyday business in companies? Hardly! Not to mention the hurdles in the actual use of S/MIME for email encryption.

More influence for the admin with gateway solutions

Various providers on the market have specialized in using S/MIME for email encryption in companies. Their solutions reduce the workload for their corporate customers, which the respective organization's own admin would otherwise have had when setting up S/MIME for the staff independently and manually. As a rule, such products are gateway solutions; otherwise, using S/MIME would be very costly. In addition, much of this would then also take place at the individual user level. This would be critical, however, as there would be a great dependence on correct user behavior, and the admin would thus have fewer opportunities to exert centralized influence concerning IT security and compliance.

A mail gateway has the advantage that the administrator has leeway for a company-specific configuration. For example, they can connect archiving for their own company or centrally define encryption. At the same time, however, despite the use of S/MIME, this no longer represents end-to-end encryption because there is no encryption from the sender to the gateway for the email. As a concrete example: from Outlook to the Exchange Server, it would be a completely ordinary (and thus unencrypted) email.

Implementation takes less time with such S/MIME solutions, and end users' usability is better than with "regular S/MIME", such as in the private sector.

Even with S/MIME solutions, various basic problems remain for companies

• Size restrictions for file attachments
  Often, it is not the messages themselves but the attached files containing the data worth protecting and requiring encryption. This quickly results in file sizes of more than 25 MB. However, operating within a regular email infrastructure, such files are too large for mail servers and thus cannot be transmitted in encrypted form between sender and recipient. Some of the S/MIME solutions do have additional modules for transferring large files that can be added – but this is usually associated with an extra charge.

• Ad hoc
  Even if different S/MIME solutions work together and encryption takes place, all those who do not use S/MIME (and this is still the clear majority) are left out and excluded from ad hoc communication. There are alternative approaches for recipients without S/MIME, e.g., making the message available in a web mailer, but here, the recipient must first log in with a username and password. This creates another hurdle, which is detrimental to usability on the recipient's side. *

• Static key pairs
  S/MIME solutions use static key pairs: the public key is used for encryption, and the private key is used for decryption. These do not change during their entire period of validity and remain the same for all correspondence. If a private key is compromised and third parties have access to the business correspondence, not only can one email from the person concerned be viewed, but also, retroactively, all data that can be decrypted with the compromised key. If the user is unaware of the unauthorized access, even all future incoming messages and files will be affected until a new key is used.

• Metadata such as the subject line are transmitted unencrypted
  While messages with S/MIME are protected by encryption in transmission, metadata such as the subject line is excluded from this. However, even subject lines contain data worthy of protection, especially when aggregated, allowing valuable and personal conclusions to be drawn. These can be misused, for example, in social engineering attacks.

*Of note for recipients without S/MIME: For incoming and outgoing emails via portal solutions, meaning those outside an email inbox, the company's own archiving is not connected. If, for example, emails are to be archived on the recipient's side, this must be done manually each time by the respective user, over whom the administrator has no influence. This can pose major problems for a company's compliance.

S/MIME for email encryption - conclusion

With the solutions offered by various providers, email encryption for companies is becoming more practical – in setting up S/MIME for the admin and in using encryption for users in the workforce.

Nevertheless, it is important to realize that there are also significant shortcomings. Secure digital communication for companies reaches its limits, even with S/MIME solutions, when it comes to simple ad hoc exchanges with anyone where everything transmitted is encrypted – including subject lines and large files. In addition, all communication partners must use a solution based on S/MIME so that the encrypted exchange of mails also functions without hurdles. Contacts who do not use S/MIME are left out in the cold and suffer noticeable disadvantages. 

Encryption based on S/MIME thus means that encrypted emails can no longer be exchanged

• between anyone
• at any time and
• easily. 

Thus, encryption ultimately becomes a hurdle to usability after all. This, however, means that email loses a great deal of its most important feature.

Disadvantages of remaining in the email infrastructure

The use of communication solutions that remain in the email infrastructure in their approach also entails potential risks from man-in-the-middle attacks. This is because even if emails are protected in transfer with SSL/TLS, they are unencrypted on the mail servers en route. Added to this are the size limitations of the mail server when sending and receiving files and the fact that redundancies often arise in data storage. Thus, the mail server quickly degenerates into a data graveyard, which results in additional costs for the company. In addition, there is significant potential for GDPR violations if the overview of which data is stored where and for how long is lost.

Compliance is a particularly important area, combined with the increasing automation of communication processes and adaptability to company-specific IT security, where modern communication solutions must offer enterprises added value. Here, however, many S/MIME solutions often fall short.

What about email encryption using PGP? How does this method compare in terms of acquisition and set-up? And what steps are needed in order to use PGP to encrypt email communication?

PGP

Basic principle and function of PGP encryption

PGP ("Pretty Good Privacy") was developed as early as 1991. With this method, messages, including emails, can be encrypted and/or signed. Encryption prevents the messages from being read by unauthorised third parties. The signature ensures that the message is authentic, i.e. that it really comes from the sender, and that its integrity is given, i.e. that it has not been changed or replaced after signing.

Email encryption with PGP – a hybrid encryption method

With PGP, the encryption process works with key pairs consisting of a public and a private key for each communication partner. Since both parties use different keys, this is basically an asymmetric encryption method. However, these procedures require a lot of computing power, which is why the entire message is not encoded with the public key. The encryption is done with so-called session keys, which are symmetrical and are created randomly and each time anew. The session key is then asymmetrically encrypted with the recipient's public key and appended to the sent message. In this way, the required computing power can be noticeably reduced, which is particularly important when sending messages to multiple recipients. Through the combination of asymmetric encryption (with public keys) and symmetric encryption (with session keys), PGP is a hybrid encryption.

Signing messages with PGP

When signing with PGP, a unique fingerprint is generated from the plain text of the respective message by a cryptological hash function (SHA-256), which is then encrypted with the sender's private key and appended to the message. The recipient can then use the sender's public key to check whether the message actually is from the sender or whether it has been manipulated by a third party.

Key exchange among communication partners as a basic requirement for encrypted email traffic

For encrypted email communication to take place at all, the desired email communication partners must know the public key. Therefore, it is necessary to either transmit it directly to the respective contacts or to upload it to an external key server. The public key is then used to encrypt all emails to the key holder. The exchange of public keys is an essential component without which PGP would not work. This process requires – depending on which form of PGP is used – some intermediate steps that have to be carried out for each individual communication partner.

However, since it is possible for a person with a public key to impersonate someone else, it requires verification of the authenticity of that key.

"Web of trust", the PGP trust network – a decentralised approach to verifying key authenticity

For verification of key authenticity, PGP uses a decentralised approach, the so-called "web of trust". This is based on participants in the web of trust who express their trust in each other and confirm that public keys belong to specified owners by signing them. This is therefore a manual process without a central authority. With GnuPG, a free encryption system that conforms to the OpenPGP standard, the software itself determines the trustworthiness of a key. If existing signatures of a public key have already been made by users who are credible in the web of trust, the corresponding degree of trustworthiness is derived from this. The more the corresponding users are trusted, the higher the degree of credibility for the key that was classified as trustworthy by them. Each signing of a key creates a certificate (which acts as a digital confirmation). Each certificate that a public key receives from the participants in the web of trust is then attached to it. The more such certificates a key receives, the greater the certainty that the key and the stated owner really belong together.

Disadvantages of the web of trust

However, all of this requires prior technical knowledge on the part of the users and is neither easy nor intuitive to handle for those less experienced. Moreover, public keys are also linked to personal data. The signatures of keys by other people contain a list of all those who have checked it and confirmed the identity of the key holder. In terms of data protection, this is an aspect that users should be aware of. And as far as data sovereignty is concerned, there is a restriction for PGP users: once public keys have been uploaded to a key server, they can no longer be deleted. Since key servers synchronise globally with each other, uploaded keys can quickly be accessed everywhere (regardless of who uploaded them and regardless of whether they are in fact the owners of the keys). This means that the corresponding email address is published as well and can be found by anyone. After uploading to a key server, users in the web of trust consequently no longer have any influence on the dissemination of the data.

Decrypting messages with PGP

The encrypted emails are decrypted with the private key; this must only be known to its owner and must also be protected by a password. If the private key should fall into the hands of a third party, the entire communication for which this key was used is affected. This means not just one email or the correspondence with one contact partner, but everything.

S/MIME and PGP for email encryption – conclusion

S/MIME and PGP work within email infrastructure. This brings with it the aforementioned size restrictions for file attachments as specified by mail servers. Another problem, however, lies in the way email and email clients work, and this can jeopardise security – cue "Efail".

What is Efail and what does it mean for S/MIME and PGP?

In 2018, Efail revealed the possibility of successfully bypassing email encryption with S/MIME and PGP. Researchers found significant security vulnerabilities due to which emails encrypted with S/MIME and PGP could be decrypted and read by third parties. The starting point was the dependence on the way email clients work.

Starting point for hackers or intelligence agencies: email infrastructure allows man-in-the-middle attacks

The vulnerabilities that were uncovered in Efail were from man-in-the-middle attacks, which are mainly possible when effective transport encryption such as TLS (Transport Layer Security) is not in place. But even if the encryption takes place on the transmission path with TLS, emails are unencrypted on the mail servers en route. Emails are not transferred directly from sender to recipient, but via intermediate stations (mail servers) which are not easily traceable for communication partners.

This circumstance makes it easier for third parties to intercept emails en route. Intelligence agencies, for example, can intercept emails in this way and store them. Decryption can then be tackled at a later point in time, for example by specifically trying to obtain the private key or when the computing power required for decryption is more readily available.

Vulnerability: email clients

If an attacker had access to the encrypted email as well as the possibility to send an email (modified by themself) to the recipient, S/MIME and PGP could be successfully bypassed. Through encryption, the contents of emails are initially protected from foreign eyes. However, this protection could be undermined by the way an email client handles emails. In the case of Efail, the clients that usually executed active content by default and reloaded external content were exploited.

One possibility for a successful attack was for third parties to manipulate an encrypted email intercepted en route. This was done by supplementing it with HTML code, which, for example, loaded an image before the email went on to the recipient. On the recipient's end, this email was then decrypted as usual with the recipient's private key. In order to be able to load the image, the regularly configured client (meaning HTML is activated) then sent the decrypted text to the attacker. This vulnerability affected both PGP and S/MIME. Even though the problem with this vulnerability was not the encryption itself, emails were not protected from unauthorised third parties despite the use of S/MIME and PGP. This problem could initially be solved by switching off the loading of external images. However, the approach of switching off HTML as well would have been rather counterproductive, because many things in normal (i.e. unencrypted) emails could no longer be read due to the high HTML distribution.

Another security problem of S/MIME and PGP came to light when so-called "direct exfiltration" was used, which was based on an implementation error of the MIME standard in email clients. In technical terms, the exact procedure is very complex; simplified, it went as follows: intercepted emails were manipulated by implementing certain additions before and after the encrypted text of the email. After some intermediate steps, the decrypted text was finally copied by the recipient's email client into a URL and sent to a server controlled by the attacker. The attacker thus received the decrypted text of the email via the URL.

S/MIME and PGP – what’s the bottom line?

When taking a closer look at all the steps that must be undertaken to set up and use S/MIME and PGP, it instantly becomes clear why these two methods have not been able to establish themselves in email encryption for private use or for use in enterprises:

• For private use, they are too costly, too technical, and too complex for users
• For use in enterprises, they are time-consuming and cost-intensive, even in the form of encryption solutions from various providers, and their scope of services is limited

Secure communication can thus not take place ad hoc and with ease – and is in most cases reduced to those who also use S/MIME and PGP. In addition, the dependence on email infrastructure and the functioning of email clients not only restricts the scope of services, but can also directly affect security, as noted in Efail.

Email encryption with S/MIME or PGP are therefore not the most viable options for enterprises in practice and have therefore never been able to gain widespread acceptance. Nevertheless, there is still an urgent need for enterprises to have secure digital communication, especially since the requirements of the modern business world go beyond mere encryption.

We need to think about encryption not as this sort of arcane, black art. It's a basic protection.

Edward Snowden, US whistle-blower

User-friendly alternative to S/MIME and PGP: Cryptshare

Secure usability for all!

The good news is that there are alternatives to S/MIME and PGP that provide secure email encryption and usability as well as offer enterprises significant added value in areas such as compliance and automation.

Email encryption and modern business communication: Security made easy – with Cryptshare

Business communication requirements that S/MIME and PGP do not fulfil

With S/MIME and PGP, emails are encrypted and secured during transfer, with the exception having been pointed out in Efail. However, the use of S/MIME and PGP does not sufficiently fulfil the very important requirements for modern digital communication and thus does not meet the needs of modern enterprises. This has noticeable disadvantages:

Email loses its appeal for business communication

As a widespread form of messaging, email can be used easily and ad hoc by everyone for exchanges with anyone. In B2B and especially in B2C communication, this is of vital importance. This key aspect, however, is completely undermined by the complexity of S/MIME and PGP. Even with a fully set up S/MIME or PGP solution, it is by no means a given that the recipients’ side uses the same solution and that the exchange of encrypted messages via email can thus take place smoothly. 

Shadow IT is often not prevented and is therefore inadvertently facilitated.

Solutions that are complex for users, such as S/MIME and PGP, run the risk of not being accepted by the staff. Especially when they involve additional tasks for the users. As a result, emails continue to be sent unencrypted in everyday business. Or even more detrimental, users switch to unauthorised (yet easy to handle) alternative solutions, especially if their own communication solution is not used by their contact partners. This results in Shadow IT for enterprises, which includes undermining data security and higher vulnerability to cyberattacks.

Implementation of S/MIME and PGP is potentially time and cost intensive and the burden on IT administrators is high.

Complex solutions that require a technically extensive effort are a nightmare for in-house IT administrators. From roll-out to end user support in day-to-day use, they require considerable training – and still remain prone to user error.

Metadata and subject lines remain unencrypted

S/MIME and PGP encrypt the content of email messages but information about the subject, sender, and recipient is sent unencrypted. Thus, they can provide hackers with valuable information for social engineering attacks.

The problem of large and sensitive file attachments is not solved

Large files that are attached to emails, and often contain very sensitive data, are not protected by S/MIME and PGP and are therefore transmitted unencrypted. The size limit of mail servers for email attachments remains.

Cryptshare provides companies with an alternative that combines security with usability – and goes far beyond what S/MIME and PGP can do.

As a secure digital transfer service, Cryptshare offers you encryption not only of emails but also of subject lines and file attachments. There is no size limit for your data exchanges, so you can send files with several gigabytes without any problems. All transfer processes are logged, ensuring traceability for your company's compliance.

Data sovereignty, not data graveyards

The retention period of transfers on the Cryptshare Server can be tailored company-specific through an individual configuration so that data graveyards are effectively prevented. This not only helps your compliance with data protection regulations but also saves you money.

Usability for everyone

What makes Cryptshare special is that, from the beginning, it was designed so truly anyone could use it – intuitively and without deep technical knowledge. Every IT administrator will confirm: effective security only works in combination with high usability!

However, usability does not end with your own staff but also extends to their communication partners: Cryptshare works bidirectionally, which means that all communication partners can not only receive messages and files from the sender, but also send them back. All of this works ad hoc and without any preconditions – internet access and a web browser are all you need to communicate digitally in a secure way.

With Cryptshare, there is no need to:

• Buy and renew certificates
• Exchange keys
• Create and manage user accounts
• Install software

Integrations into familiar work environments & via API connection to in-house tools

With Cryptshare, your employees continue to benefit from the ease and familiarity of email and can engage in ad hoc exchanges with third parties. Integrations for Outlook and HCL Notes allow staff to securely conduct business communication directly from their own work environment. Thanks to the Cryptshare API, it is also possible to connect Cryptshare directly to in-house tools or to send information generated automatically from system processes. For the recipient of a Cryptshare transfer, it does not matter whether the transfer was sent by a person or a system.

Selected the wrong recipient or wrong attachment and already sent the email? No problem!

But what if an employee suddenly realises that they have accidentally sent the wrong file or sent the transfer to the wrong recipient? After all, this is a mistake that has happened to almost everyone at some point – and can have very unpleasant consequences: this can mean a GDPR violation or even the loss of a company's intellectual property. Don't worry, because Cryptshare has a solution for this, too! With the revoke feature, this is no longer a risk: even after sending a transfer, the employee as the sender can retroactively block access to erroneously sent files. This allows them to quickly correct their mishap and prevent the accidental loss of data for their company.