Data Protection by Design and by Default in Confluence Server and Data Center
Article 25 of the GDPR sets forth the principle of data protection by design and by default. This is a broad principle with varying meaning and application depending on the context and type of personal data being processed. This principle is unique to each organization, and should always be evaluated with the assistance of legal counsel to determine all efforts required to comply. These efforts may include ensuring certain third party applications you use to process personal data are configured to default to the most privacy-friendly settings available whenever personal data is input. Below is a summary of relevant settings and configurations available through certain Atlassian products, and a discussion of any limitations.
Description
Confluence may be configured to support your efforts to comply with Article 25 of GDPR by using the permissions & restrictions features, and the anonymous access permission system to configure certain aspects of your instance as private by default.
Permissions and restrictions for content
The global permission system allows administrators to control which users have access to Confluence. Please read Global Permissions Overview for more information. Unlicensed access, such as access from Service Management users, is also controlled by this mechanism.
The second set of permissions are space permissions, and they control which users have access to which spaces, as well as the actions they can perform in that space (for example, creating and deleting content). Please read Space Permissions Overview for more information.
Individual pages can be further restricted by the use of the page restrictions feature. Please read Page Restrictions for more information.
Please read Permissions and restrictions to learn more above how they all interact.
Anonymous users and view profile permission
If an administrator enables the view user profiles permission for anonymous users, then Confluence end-user profiles will be publicly accessible. We recommend that administrators turn off view user profile permission for anonymous users, or make Confluence instance not publicly accessible if you would like to ensure that end-user profile information is not publicly accessible.
Email address visibility
Confluence administrators can choose the level of visibility for email addresses of licensed users. The most private setting is the 'only visible to administrator' option, ensuring the user's email address is only visible to the administrator and the user. Please read User Email Visibility for a detailed description of this feature.
Public signups
Confluence can be configured for public signups. This feature allows anybody with access to the instance to create an account. It is recommended that the 'restricted domains' (for email addresses) option be used when enabling the public signup, so the instance is not exposed unnecessarily. Please read Add and Invite Users for information on how to change public signup options.
Please review Setting Up Public Access and make adjustments to space permissions if required, to secure your Confluence instance.
Jira Service Management (formerly Service Desk) and Confluence knowledge base
Jira Service Management integrates with Confluence to allow unlicensed users to view knowledge base articles that are hosted on Confluence. Please read Serving customers with a knowledge base for more information. It is recommended that the view user profile permission be disabled for unlicensed users.
Limitations
The Confluence permissions and restrictions system is unable to restrict access to user profile information among licensed users on a user-by-user basis. The existing permission system can only distinguish the anonymous user from licensed users, and may only restrict anonymous users from being able to view, search or mention other users.
Display name, username, and email address
When anonymous access is turned on, some information related to user profiles is still accessible to the anonymous user, even if the view profile permission is disabled. Only the username, the display name, and in one case, the email address are accessible - other profile information (for example, profile picture) remain masked to the anonymous user. The location and a screenshot of all such instances are outlined below:
Byline
Pages created by other users have a byline containing the display name of the author, and modifier (if any). Even if profile permission is disabled for the anonymous user, these names are still displayed (in the screenshot, it's displaying the user named 'A. D. Ministrator').
Space contributor macro
The space contributor macro correctly restricts the anonymous user when viewing a page, but does not correctly restrict when the page is exported as a PDF. The display name of the contributors are shown to anonymous users who export a page containing the macro.
Above: screenshot of a page exported as a PDF file
Contributors summary macro
Contributors summary macro shows the list of contributors of a page (and can include child pages). This macro shows the display name of authors and modifiers of the page to the anonymous user, regardless of the view-profile permission.
Recently updated macro
This macro shows the author's display name as part of an updated item, regardless of the view profile permission (similar to the byline).
Activity stream gadget macro
The activity stream gadget macro shows activities on a space to anonymous users, which includes the author's display name, regardless of the view profile permission.
Content by user macro
This macro displays all content created by a particular user. The macro itself is secure when in a view page. However, the edit panel for the macro has a preview feature, which shows a display name, even if the user selection dropdown is restricted for anonymous users. If the anonymous user knows which username to type into the input, the preview will display that user's contents, including the display name.
Space summary
Viewing the summary of a space can reveal the display name of the space administrator and creator.
Content REST api
Similar to the byline in a page, the author's display name is shown in the content REST api (documented in the developer documentation). The profile picture is not accessible, only the display name and user name of content authors/contributors are shown.
Recently Updated Macro REST api
The recently updated macro uses an internal REST api, which an anonymous user may be able to access, if anonymous access is turned on by an administrator. This api contains a 'modifier' section which contains the display name, user name and the email address of the user who has performed the recent modifications. This information is shown, regardless of the anonymous profile permission setting.
Additional notes
There may be limitations based on your product version.
Note, the above-related GDPR workaround has been optimized for the latest version of this product. If you are running on a legacy version of the product, the efficacy of the workaround may be limited. Please consider upgrading to the latest product version to optimize the workarounds available under this article.
Third-party add-ons may store personal data in their own database tables or on the filesystem.
The above article in support of your GDPR compliance efforts applies only to personal data stored within the Atlassian server and data center products. To the extent you have installed third-party add-ons within your server or data center environment, you will need to contact that third-party add-on provider to understand what personal data from your server or data center environment they may access, transfer or otherwise process and how they will support your GDPR compliance efforts.
If you are a server or data center customer, Atlassian does not access, store, or otherwise process the personal data you choose to store within the products. For information about personal data Atlassian processes, see our Privacy Policy.