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.
Privacy Policy
Threads subscribers (each a Subscriber) own and control their personal data (messages, contacts, etc) and Threads does not share this data with any other parties. All Subscriber data is encrypted in transit and account password security meets the highest modern standards.
Threads currently stores Subscriber data in Amazon Web Services (AWS), Elastic Block Storage (EBS) and S3 Storage. These facilities are physically located in the Republic of Ireland.
Threads is committed to complying with the General Data Protection Regulations (GDPR) across all of its services and you can find a copy of our updated Privacy Policy here.
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 is not encrypted in Store
For Threads employees, access rights and levels are based on job function and role. All Threads employees are required to sign a confidentiality agreement with respect to the protection of Subscriber information and data. We routinely monitor account logins to detect suspicious behaviour.
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. For example.
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. For example in OSX Mail…
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.
Sharing internal email
Some organisations will wish to share internal email – that is email exclusively between users with no non-user senders or recipients – and others will not.
If it is required to keep exclusively local email private, then this can be achieved by setting the “hide emails” flag on all channels to be hidden for all (or some) Threads users. Bear in mind that this setting is on contact channels and not on users, hence it is possible to selectively hide emails according to which email address is used.
When ingesting by rule, some email servers provide the option of invoking rules only on non-local traffic. If available, this is a better option than using the “hide emails” flag because it reduces the amount of email traffic that Threads must process.
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