Privacy Settings & Security
Privacy Mechanisms | Security Mechanisms | Managing email privacy and security | Sharing internal email | Recommendations
Privacy Mechanisms
General Rules
Messages ingested by Threads (emails and phone calls) may fall into one of 3 categories:
- Not stored by Threads
- Viewable only by specific Threads’ users
- Viewable by all Threads’ users
The category applied to a message will depend on the contact channels contained in the message address fields.
Additionally, contact channels may or may not be shared via the subscriber’s LDAP directory. LDAP is the standard method of sharing address books amongst a community of users.
Contact Channel Settings
Each contact in Threads has one or more contact channels linking the contact to a company. The contact channel defines the way in which digital communications may be addressed to the contact.
Each contact channel has 3 privacy settings:
- Exclude Messsages – Setting this flag prevents any message containing this channel address from being ingested into Threads.
- Is active – Setting this flag indicates that the channel is no longer active. If the user preference “show only active records” is set (default), messages with exclusively inactive contacts will not be displayed.
- Shared/Private – Messages where all contact channels are Private are visible only by addressed Threads users.
Messages where any contact channels are ‘Shared’ are visible by all Threads users.
Security Mechanisms
User Authentication
Password Hashed – Password Hashing is a way to convert a user-supplied password into a one-way derived token for storage. By using the derived token, it makes it impossible to reverse the stored token and get the original password used by the user. This adds a layer of defence in case an attacker gets access to the database storing the password.
Data in Transit
All access to customer confidential information is made via our secure HTTPS websites, hosted on our threads.uk.com domain. The HTTPS protocol creates an encrypted connection between your computer and Threads to ensure the security and integrity of data you transmit and receive. We use SHA-256 with RSA Encryption.
Data at Rest
Customer data is encrypted at rest within our Amazon Web Services (AWS) hosting environment using AWS EBS volume encryption. This protects the customer data stored within our systems, including email content, attachments, metadata, indexes, logs and backups.
Employee Access & Monitoring
Strict Access Controls
Access to customer data is restricted according to an employee’s role and responsibilities. All Threads employees are subject to confidentiality obligations and we monitor account activity to help identify suspicious or unauthorised access.
Limited access to customer content
Threads employees do not routinely access customer email content or attachments. Where access is necessary to provide technical support, it is restricted to no more than two specifically authorised members of our technical support team.
Access may be permitted only where necessary to:
- investigate and resolve a technical issue; or
- respond to a customer support request.
We will obtain the customer’s approval before accessing email content or attachments, unless access is required by law or is urgently necessary to protect the security of the service or customer data.
Logging & audit
Access to customer data is logged and subject to audit, helping us maintain accountability and identify inappropriate or unauthorised access.
Data Hosting and Location
Data Center Location
Customer data is hosted on Amazon Web Services infrastructure in Dublin, Ireland and is stored and processed within the European Economic Area (EEA).
International Data Transfers
Where personal data is transferred outside the UK or EEA, Threads ensures that appropriate safeguards are in place in accordance with applicable data protection law. Depending on the destination, these safeguards may include an adequacy decision, the European Commission’s Standard Contractual Clauses and, where applicable, the UK International Data Transfer Addendum.
Managing email privacy and security
Threads can ingest email from many sources simultaneously – from an individual user’s email client to an organisation’s email server. Threads supports any email system that uses the IMAP email protocol – this covers most common systems such as Microsoft eXchange and Office 365, AppleMail and GoogleMail. There are two basic methods of ingesting email into Threads: Pulling or Pushing.
Pulled Ingestion (Threads pulls)
In this scheme, Threads periodically logs into subscriber nominated email accounts and collects (or pulls) any email found since the last ingestion. The subscriber can specify either to ingest ‘all’ mail from the account, or can specify specific IMAP folders from which to ingest.
If the user account has an IMAP folder structure in place, then Threads can create Threads Projects with the same structure. Whenever email is added or removed from a user IMAP folder, then the Threads Project will reflect this within a short period of time (typically 10 mins). If several Threads’ users have identically named IMAP folders, then a single Threads project will contain all messages for all users.
Whenever Threads pulls messages from subscriber accounts, the messages remain in the subscriber account and their read/unread status is not changed.
Pushed Ingestion (Subscriber pushes)
In this scheme, an email account is created specifically for Threads’ ingestion. Users may drag and drop email into the Threads account for ingestion or, more commonly, an email “rule” will be set up to copy email to be ingested into the Threads’ email account.
Depending on the systems in use, rules can be executed on either an email client or server or both. Typically a server-based rule would copy all of an organisation’s email into the Threads account. A client-based rule might copy selected emails (example above). However, a client-based rule would only be executed while the user was logged in, whereas a server-based rule would operate continuously.
Once Threads has ingested an email pushed into its account, Threads deletes it.
If the Threads email account has an IMAP folder structure in place, then Threads can create Threads Projects with the same structure. Whenever, email is added to the Threads’ account IMAP folder, then this will be added to the Threads Project within a short period of time (typically 10 mins).
Once Threads has ingested the email from an IMAP folder, it deletes the email from the Threads account. This handling of IMAP folder in the Threads account is slightly different from IMAP folders in Subscriber account where Threads attempt to synchronise Projects.
It is important to understand that the process of copying an email from one email account to another is not the same as forwarding or cc’ing. A copied email is a clone of the original with all headers remaining intact. An email may be copied by means of a rule or special command.
The paragraphs below summarise the advantages and disadvantages of different types of ingestion.
Pulled Ingestion Advantages
- Easier to set up for a small number of users.
- Requires no email-server administration privilege.
Pulled Ingestion Disadvantages
- Requires Threads to have authentication details of any subscriber accounts.
- Susceptible to failing due to password changes.
- Generally slower than push ingestion due to the fact that previously ingested mail has to be processed.
Pushed Ingestion Advantages
- Unnecessary to share any email account authentication details although a server-based rule will need to be set up by server administrator.
- Impervious to password changes.
- Fast ingestion since previously ingested mails are deleted and need not be processed.
- Unnecessary to share authentication details of
Pushed Ingestion Disadvantages
- Need to create rules.
- Where email is pushed by server-based rule, users have no control over which email is pushed.
Recommendations
It is difficult, if not impossible to prevent employees from using their company email account for personal communications. However, provided that employees follow some simple guidelines, they should soon be comfortable with Threads ingesting company email directly from the the server. These are as follows:
- Avoid using a company email account for personal communications. If the same contact is known both personally and for business, obtain a private email address for the contact.
- User should set up a separate email account for their personal communications (this can generally be accessed from the same email client).
- Avoid storing personal contact email addresses in Threads – instead use a local private address books.
For more information about our privacy and security controls, please feel free to contact us at hello@threads.cloud