JPY’s policy is that the Threads Subscriber (the organisation that uses Threads) owns and controls their data (messages, contacts, etc) and it is shared with no 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.
Beta Threads Subscribers will be required to execute a mutual Non-Disclosure Agreement, the template for which can be downloaded here.
Messages ingested by Threads (emails and phone calls) may fall into one of 3 categories:
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 4 privacy settings:
Hide from directory
Setting this flag prevents the channel address from appearing in the subscriber’s LDAP directory. An LDAP directory is commonly used by email and phone clients to lookup addresses “on the fly”.
Setting this flag makes messages viewable only by those users that are specifically in the message address fields.
Setting this flag prevents any message containing this channel address from being ingested into Threads.
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.
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 in Store
In the beta version, data is not encrypted in store. In the final subscription version we plan offer support for encryption of attachments.
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
Pulled Ingestion Disadvantages
Pushed Ingestion Advantages
Pushed Ingestion Disadvantages
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.
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: