Glossary of terms

Common factors to JEMH (Server) and JEMHC (Cloud)

This page is subordinate to the Privacy Policy and its purpose is to be transparent about how this particular application handles your data. Features vary between Server and Cloud, we cover both here, support is common to both.

Related to this is our cloud-specific page on General Data Protection Regulation (GDPR).

Billing

The Server version (JEMH) is currently still licensed through us directly. As part of order processing, we track a lot of conversations and generate quotes by Email and through our Jira. As a legal requirement to retain records, we retain order data in spreadsheet form, copies of all quotes, invoices and purchase order documents for 7 years, these documents containing the Name and Email of involved parties. Where card checkout is used for purchases, details of the purchaser are also stored long term.

The Cloud version (JEMHC) is licensed through Atlassian Marketplace, as such we don't get or collect any details. When customer Plan capacity becomes exhausted, they may choose to purchase additional capacity as a "Data Pack" or a "Plan Upgrade". In such cases, we collect and retain the name and email of the purchasing party as above. This information is stored in JEMHC so as to enable customer admins to track who did what and expires after a year.

JEMH (Server) licensing: Use of email addresses

During licensing, users supply an email address that generated keys will be sent to. Supplied addresses are not used for any other purpose than key delivery. Addresses are retained through email history, kept by The Plugin People for auditing and abuse detection. Users who use anonymizing mail servers may have trouble generating evaluations.

Product Differences

JEMH is the Jira Server (customer hosts on their Jira instance, behind the firewall), JEMHC is for Jira Cloud (we host in the cloud). The different deployments have differences which will be clarified below by referring to JEMH or JEMHC.

What Data is accessed/stored

JEMH (for Jira Server)

All data processed by is stored and managed on hardware under the control of the customer.

1. JEMH processes email supplied by users, using connectivity mechanisms controlled by the user. If enabled, the action of Auditing stores those emails in raw, unencrypted form in the JIRA_HOME/jemh/auditing folder.

2. As part of supporting email only users, JEMH stores non-Jira email addresses in TEXT custom fields, unencrypted.

3. As part of processing user comments by email, JEMH also stores some of those comments, and the email addresses involved within the JEMH tables (prefixed with AO_78C957_), unencrypted.

4. As part of support, JEMH Profiles are often requested in order to reproduce configuration scenarios and solve problem. The XML payload contains email addresses, website URL’s, server license details and database settings, but no authentication details. When attached to the public JEMH Jira Issue Tracker, standard practice is to mark the issue security as Private between Reporter and Developers.

5. As part of support, JEMH Test Cases, which are exports of real emails supplied by the customer. Usually these emails contain 'test' data and are not sensitive, but still may contain IP address or other identifying data. Issues containing test cases are not always marked as private, if there are concerns, users may do this.

JEMHC (for Jira Cloud)

We categorically do not extract data from your site for any purpose other than fulfilling functionality that you configure within your JEMHC instance.

When does JEMHC store data from customer instances

1. If you configure JEMHC to send outbound notifications the app will need to access data from your Jira instance to be able to provide that functionality.

2. When an issue event webhook is sent to JEMHC, they are stored in an AWS SQS queue. JEMHC has compute nodes that process items from this queue, determining whether you have outbound notifications setup for the related project. If not, we drop the data at this point. That is the life span of data that you don’t expect to be processed by JEMHC.

3. During generation of notifications, we call back to Jira to retrieve additional data (e.g. attachments) that are related to the current notification, do a range of user lookups.

4. As part of sending the notification, JEMHC creates audit history of who got sent what. We retain, in JEMHC, the email addresses of recipients, as well as the content of the notification (stored in AWS S3 buckets). We have no access to this, it is for your benefit (as is the incoming auditing). If you choose to disable auditing, you can, but our ability to help you solve your problems relating to processing mail will be much harder, and may not be possible.

5. During support, you (the JEMHC admin) may elect to ‘flag’ incoming mails for support. This action makes the Email, its incoming processing Report and the related JEMHC Profile available to support staff. That email could be anything, including a reply to a Jira notification, containing data from Jira.

Where is data stored

All retained data is held within a virtual private cloud database and S3 storage buckets (both are encrypted at REST) managed by AWS located within the USA. We have no way to shard user data to European data centers at this time.

AWS have adopted GDPR terms as part of our agreement with them:

• https://aws.amazon.com/blogs/security/aws-gdpr-data-processing-addendum/ linking to https://d1.awsstatic.com/legal/aws-gdpr/AWS_GDPR_DPA.pdf

Registration / System Notifications / Life Cycle

When your instance installs JEMHC, or, is rebooted as part of maintenance with JEMHC installed (but unlicensed) JEMHC will create some basic record of the installation. We store Billing Contact email addresses, and enable further email addresses to defined for administration notifications (JEMHC > Licensing > System Notifications). The Company doesn't manage customer data that is stored in our system, its not The Company's data. For example, a contractor that setup a cloud instance and used their own name and email address was set as the billing contact. JEMHC notifies the billing contact about usage every month but they no longer work 'for the company', we can't fix that, we don't access or change customer data.

Google OAuth usage

Customers can optionally configure JEMHC to use Google OAuth to link google services including SMTP, IMAP and Drive with JEMHC.

Permissions

When OAuth is setup, the following google API permissions are required by JEMHC to operate. It is not possible to split required permissions in JEMHC (access to mail requires access to drive, even if unused - but no access will be performed unless configured)

• https://mail.google.com/ (Full access to Google Mail so JEMHC can read, send and delete processed emails)

• https://www.googleapis.com/auth/userinfo.email (JEMHC can autocomplete the username in the SMTP/IMAP configuration form)

The usage of these permissions within JEMHC is as follows:

SMTP

Once authorized and configured, JEMHC will be able to send mail from your Jira instance and JEMHC itself through the linked email account(s) as described below.

IMAP

Once authorized and configured, JEMHC will be able to retrieve email from the linked account(s) and process as described below.

Inbound processing

1. JEMHC processes email supplied by users, using connectivity mechanisms controlled by the user. By default, the action of email retrieval:

   1. stores those complete emails in S3 buckets with an ‘audit’ link in the JEMHC database. Customers can opt out of the storage and audit retention (re-enabling requires support intervention). Opting out makes diagnosing email related problems much harder to resolve, if not impossible.

   2. stores subject, sender (from:), and recipients (to:, cc:) email address in JEMHC database, unencrypted.

2. As part of supporting email only users, JEMHC stores non-Jira email addresses in TEXT custom fields, unencrypted.

3. Email content is stored in Jira in plain text as issue summary/description/comment.

Outbound processing

1. Regardless of whether you have a license present for JEMHC or not, if JEMHC installed, the issue https://ecosystem.atlassian.net/browse/AC-1620 means that your Jira will send us issue webhook data for every issue event in your instance (over SSL). JEMHC stores this event data which is encrypted

2. JEMHC will by default attach files added to issues to outbound emails.

3. JEMHC will by default store in an S3 bucket (with a link in the outbound auditing view), the full email content of recently sent mail.

4. After sending email, JEMHC retains a recent history of the event, this includes email addresses and subject (stored in encrypted form in the db).

Registration and feedback

The Plugin People Ltd use Slack for this:

1. JEMHC writes registration event data to a private Plugin People Instant Message room (over SSL) identifying the host URL involved

2. JEMHC writes user supplied feedback to a private Plugin People Instant Message room (over SSL) identifying the host URL and the user email address involved

Logging

1. JEMHC writes some debug level logs to a logging database, this contains various information about email processing, subjects and sender email addresses are also hashed, only in some specific situation would we log PII data we'd use proactively to talk to the customer about particular problems. We purge the entire log archive from time to time, its use is transitory.

Support

1. As part of support, JEMHC Profiles are often requested in order to reproduce configuration scenarios and solve problem. The JSON payload contains email addresses, website URL’s, groups, usernames, but no authentication details. When attached to the public JEMHC Jira Issue Tracker, standard practice is to mark the issue security as Private between Reporter and Developers.

2. As part of support, JEMH Test Cases, which are exports of real emails supplied by the customer. Usually these emails contain 'test' data and are not sensitive, but still may contain IP address or other identifying data. Issues containing test cases are not always marked as private, if there are concerns, users may do this.

Use of email Test Cases

As part of Our support for JEMH and JEMHC, its common for us to require test case emails in order to reproduce a processing problem. These emails can contain personal information identifying users, e.g. names, email address, as well as related content. As the point of the Test Case is to validate specific processing, editing the content after the fact is not always an option. Such information is private and not shared.

Auto-purging

In JEMHC (cloud), we already have a Post-Function that is responsible for deleting External Attachments (for large log files etc) that is stored with our our own cloud infrastructure, not Jira. We plan on adding a further post-function / feature to expire/remove attachments to support cases after 3 months of being resolved, achieving a data-retention lifetime. This is for customer convenience, should an issue need to be re-opened after resolution.

Accidental mail

With the use of 'live' example emails, and the nature of JEMH for notifications, it is always possible that as part of testing emails are unintentionally sent, this is manually managed, and is a rare occurrence. If this becomes excessive, it can be reported to andy @ thepluginpeople.com

Data usage

Your data will not be used for any kind of 3rd party use, marketing etc. The Plugin People may contact registered users from time to time, with pro-active advice on configuration, or more general service-related announcements.

Data Flow Diagrams

Open