RFC-27: Data Residency for Forge Hosted Storage

[SushantBista]

RFCs are a way for Atlassian to share what we’re working on with our valued developer community.

It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas , but more so a collaborative practice to shape an idea and to find serious flaws early.

Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!

Summary of Project:

To help partners more easily meet customer data residency needs, we are enabling data residency support for apps that choose to exclusively use Forge Hosted Storage (i.e. Storage API). This will make supporting data residency much easier for partners with apps that exclusively use Forge Hosted Storage for in-scope data, as these apps will automatically support data residency.

Data residency for Forge Hosted Storage will be available for all the same locations as Jira and Confluence data residency at launch, and Forge will support new locations on the same timeline as other Atlassian products.

• Publish : 10 October 2023
• Discuss : 27 October 2023
• Resolve : 10 November 2023 17 November 2023

Problem

Data residency gives organisations more control over their data by helping to ensure any private data is stored within the location they trust. Many organisations care about data residency and see it as a requirement to do business with a SaaS vendor. Data residency can also make it easier for companies to meet regulatory obligations.

If customers work in a regulated industry like finance, government, or healthcare, data residency may be a necessity for operating in a cloud environment. In fact, according to our customer surveys, 80% of Atlassian enterprise cloud customers say that apps supporting data residency is very or extremely important to them.

That said, independently supporting multiple locations takes extra work and can come at an additional cost to Marketplace Partners. Such investments must be weighed against other improvements to your app, which often leads partners and developers to put off adoption of this important feature.

Proposed Solution

To help partners more easily meet customer data residency needs, we are enabling data residency support for apps that choose to exclusively use Forge Hosted Storage. These apps will be able support data residency for in-scope data with less separate investment (compared to supporting data residency for external databases).

Forge will take care of the hosting, pinning, and migration of hosted data between supported locations, so partners can focus on building a high quality app for their customers.

The proposed solution is designed to work harmoniously with product data residency and consequently is based on similar concepts and terminology. (Refer to Understand data residency for more information about product data residency).

How will it work?

Upon release, data residency will be available as an inherent feature of Forge Hosted Storage. With this change:

• Any data that is stored in Forge Hosted Storage will be automatically migrated to the same location as the host product (starting at the time of Beta release).
• All new installations of an app using Forge Hosted Storage will have data stored (for relevant tenant) in the same location as the parent product.
• When a customer requests the parent product to be moved to a new location, the relevant Forge Hosted Storage partition will move along with the host product data.
• Forge apps that exclusively store in-scope End User Data within Forge Hosted Storage will automatically be shown under “pinned” in the customer data residency UI (meaning they have pinned stored data to the same location as the parent product).
• If the parent product is not pinned, Forge apps will remain in the Global location along with the parent product data.

Forge Hosted Storage

• Pinning location: App partition (for relevant tenant) will be pinned/migrated to same location as the host product

• Who determines the location: Customer admin determine the pinning location of the host product (and hence the location of the relevant Forge app partition). If the parent product is not pinned, Forge apps will remain in the Global location along with the parent product data.

Forge Hosted Compute

• Pinning location: Forge Hosted Compute will be provisioned and operational in all Atlassian supported locations to ensure acceptable performance (when Forge Hosted Storage is multi-location enabled). As with Jira and Confluence data residency, data-in-transit will not be pinned to any particular location.

• Who determines the location: Atlassian will determine the location of the hosted compute to ensure acceptable level of performance.

Note: Like Jira or Confluence data residency, only at-rest data will be pinned. Data-in-transit (up to 30 days), app logs, cached content and user account information will not be pinned. If the data residency scope changes for the parent product data residency, we will evaluate similar changes for Forge.

Determining the app pinning status

An app’s pinning status is a status field presented to customer admins in the admin.atlassian.com data residency UI, in order for admins to determine which apps are ‘pinned’ to their requested location.

A Forge app’s pinning status (for the relevant tenant) criteria will be determined based on the app’s manifest declarations:

• App uses Forge Hosted Storage: “Storage:app” scope is defined in the app manifest
• In-scope EUD (End User Data) is stored exclusively in Forge Hosted Storage: In-scope EUD is NOT egressed to remote storage (Note: Partners will need to define and document what is ‘in-scope’ for their app’s data residency policy)

New parameters will be available within the Forge manifest to allow developers to declare additional information that will determine the app’s pinning status:

• operation of remotes (e.g. storage, compute or other)
• If the remotes is used for storage, if it stores in-scope EUD (as defined in the app’s data residency policy) or not

Here are some examples of the manifest declarations that determine the app’s pinning status:

Example 1: App is shown as ‘Pinned’

Permissions:
  Scopes:
  - "Storage:app"

• Forge Hosted Storage scope is used
• No remotes is defined

Example 2: App is shown as ‘Pinned’

Permissions:
  Scopes:
  - "Storage:app"
  
remotes:
  - key: jsonplaceholder
    baseUrl: "https://jsonplaceholder.typicode.com"
    operations:
    - storage
    storage:
      in-scope EUD: false

• Forge Hosted Storage scope is used
• Defined remotes is used for storage, however, not for storage of in-scope EUD

Example 3: App is shown as ‘Pinned’

Permissions:
  Scopes:
  - "Storage:app"
  
remotes:
  - key: jsonplaceholder
    baseUrl: "https://jsonplaceholder.typicode.com"
    operations:
    - compute 

• Forge Hosted Storage scope is used
• Defined remotes is used for compute

Note: in-scope EUD is only required to be defined if operation = storage

Example 4: App is shown as ‘Not Eligible’

Permissions:
  Scopes:
  - "Storage:app"
  
remotes:
  - key: jsonplaceholder
    baseUrl: "https://jsonplaceholder.typicode.com"
    operations:
    - storage
    storage:
      in-scope EUD: true

• Forge Hosted Storage scope is used
• Defined remotes is used for storage, AND stores in-scope EUD (i.e. in-scope EUD is not exclusively stored in Forge Hosted Storage)

Example 5: App is shown as ‘Not Eligible’

Permissions:
  Scopes:
  - "Storage:app"
  
remotes:
  - key: jsonplaceholder
    baseUrl: "https://jsonplaceholder.typicode.com"

• Forge Hosted Storage scope is used
• remotes is defined, however its operation is not defined (therefore, it cannot be determined if in-scope EUD is exclusively stored within Forge Hosted Storage)

Things to consider:

• For the manifest changes listed above, what constitutes a major or minor version bump for an app depends on if the scope of remotes is increasing or decreasing. If it’s increasing the scope of what is being done with the operation, such as adding a new operation or changing in-scope EUD to true, this would constitute a major version bump. If it’s decreasing the scope of what it’s used for, such as reducing the number of operation, adding a classification to a remote (where previously had no classifications) or changing in-scope EUD to false, that would be a minor version bump.
• Defining the operation for remotes is not mandatory for the initial release. However, if your app has remotes defined, without an operation and in-scope EUD (when applicable) defined, the app will not be shown to customers as ‘pinned’
• If you define the operation as storage, it is mandatory to declare if it does/doesn’t store in-scope EUD. Validation checks for app deployment will be added.
• If a new app version includes remotes that is now storing in-scope EUD (as part of the change), the pinning status of the app may change

Changes for external permissions

As part of external permissions, you can declare URLs that your app should have access to as part of the external.fetch section of the manifest. As part of these calls, an app can potentially be egressing data for storage. In order to identify these scenarios, we are adding support to pass a key to a remote, as well as the existing system today. The changes would look like:

From:

permissions:
  external:
    fetch:
      backend:
        - '*.example-dev.com'

To:

permissions:
  external:
    fetch:
      backend:
        - remote-backend
remotes:
  key: remote-backend
  baseUrl: '*.example-dev.com'
  operations:
    - other

Note: In future, we will explore extending data residency capabilities to Forge remote storage. Depending on the exploration outcomes, the status criteria may be updated to accommodate for apps storing in-scope EUD in remote storage services with data residency capabilities.

FAQ

How will multi-location hosted compute be enabled?

Multi-location hosted compute will be automatically enabled for all Forge apps by the time Forge Hosted Storage data residency is rolled out to production. This will ensure there is acceptable level of performance when Forge Hosted Storage is multi-location enabled.

However, in order for it to take effect, a redeployment of your app will be required. This will be a minor version update. We will make an announcement and give you advanced notice before you need to take this action.

Additionally, as Atlassian continues to release support for new locations, subsequent redeployment of your app will be required for these new locations to take effect. If you have not redeployed your app, the app and its users may experience performance issues due to cross-location latency.

NOTE: Automated redeployment is something we are still exploring, and will not be available in the initial releases. We are assessing the level of improvement this will achieve for developer experience and determining its priority.

What will the customer experience look like?

The customer experience within AdminHub for data residency of cloud apps will continue to be a unified experience between Forge and Connect apps. The biggest change that will result from this project will be that for Forge apps using hosted storage, the relevant app partition will be migrated together with the host product, within a single migration window determined by the customer admin. Admins will be able to assess which apps will be moved together with the product, as well as see an updated pinning status of the app post-migration.

What will partners need to do?

Partners will be responsible for defining, documenting, and communicating what data is in-scope for data residency for each of their Forge apps. In-scope data will include any data stored in Forge Hosted Storage.

Partners with apps that use Forge Hosted Storage will be encouraged to take a few steps near the Beta release, including:

• Define and document for customers what is “in-scope” for data residency (which should include all data stored in Forge Hosted Storage).
• Update the manifest, in order to accurately show the pinning status to customer (i.e. declare that the app does not egress in-scope End User Data for storage purposes). Any remotes defined should have the operation and in-scope EUD (when applicable) details declared. A redeployment of the app will required.
• Update the Privacy & Security tab for any app that exclusively uses Forge storage to show customers that the app supports data residency in the same locations as Atlassian for any in-scope data.

What should partners do if they don’t want to support a location?

If your app uses Forge Hosted Storage but you don’t wish to support one of the Atlassian supported locations for your app data residency, you can stipulate this in your terms with customers.

While there is no technical limitation to a customer moving their data to an Atlassian supported location, you can include stipulations about locations where customers can store data in your end user terms or any other customer contracts at your own discretion. That said, it’s important to note that Atlassian is not a party to your contracts with customers and cannot enforce the terms by prohibiting the customer from storing data in certain locations.

Asks

While we would appreciate any reactions you have to this RFC (even if it’s simply giving it a supportive “Agree, no serious flaws”), we’re especially interested in learning more about:

1. What do you think about installed apps (that meet pinning criteria) being automatically shown as pinned to customers? Are there any use-cases for an app (that meets pinning criteria) to be not shown as ‘pinned’?
2. What level of visibility do you anticipate needing around migration requests and hosting location of hosted storage/compute, and why?
3. What do you think about having to provide additional declarations for an app’s remotes, in order to accurately determine the app’s pinning status?
4. What are your thoughts on if we make operation declarations mandatory for any definedremotes in the future (i.e. app deployments will be blocked if operation is not defined)? What are the ways this may impact you that we may not have anticipated?
5. What do you think about having to redeploy your app every time Atlassian supports new locations? Are there other ways this may impact that we haven’t anticipated?
6. Considering the app pinning status may change depending on the manifest declaration updates for a new app version, how do you currently communicate any such changes to your customer admins that could affect their compliance requirements? Are there other ways this may impact that we haven’t anticipated?

We are currently targeting Q1 CY24 for release of Forge Hosted Storage data residency Preview (Customer Beta). You can track this project in Atlassian public cloud roadmap, Forge public roadmap and FRGE feedback board.

Thanks for your feedback!

[JulianWolf]

Thank you for sharing your plans in advance. The RFC overall meets our expectations for how Data Residency for Forge Hosted Storage should work. We expected that solely relying on Forge Storage would put us in the fortunate situation of being more or less automatically compliant with new Data Residency requirements and locations. This is what this RFC outlines to my understanding.

The feedback that comes to my mind is probably mostly about functionality that is out of scope for now.

• The need for re-deploying based on changes that Atlassian has under its control is obviously annoying. Please consider notifying vendors via email as soon as such changes happen, as well as offering a CLI command that reveals the current status of an app in terms of a missing deployment. Showing a status like “Your app needs to be re-deployed to support XYZ” in the Developer Console should also be viable.
• It seems reasonable that apps are automatically shown as pinned if they meet the criteria. What about Connect-on-Forge apps? I assume they are not eligible for pinning for now.
• What about Data Residency Support for Connect-on-Forge apps? Forge apps that have remotes outside of Forge-land but are used for Storage. Can we expect an API that is comparable to the one offered for Connect apps?
• A clear definition from Atlassian of what data are considered “in-scope EUD” would be great. Maybe it is already available somewhere. Also the abbreviation is not very self explanatory (how about in-scope-data or in-scope-end-user-data for that part in the manifest.yml).
• I don’t quite get why we need to do adjustments to the Privacy Tab. Couldn’t Atlassian detect and highlight eligable apps automatically to prevent fraud?

Best,
Julian

[ibuchanan]

@JulianWolf,

I’m just reading along as you are so I’m no authority on this RFC. You asked for:

@JulianWolf

A clear definition from Atlassian of what data are considered “in-scope EUD” would be great. Maybe it is already available somewhere.

But the original post reads:

@SushantBista

Note: Partners will need to define and document what is ‘in-scope’ for their app’s data residency policy

If Atlassian can’t or doesn’t provide a clear definition by example, what are the other ways to make this term and it’s implications more clear?

[lkimmel]

My assumption to “What will partners need to do?” is for an app that is completely build in Forge: I do not have to change anything.

We are building an app completely in the Forge platform and we expect, that data residency is managed under the hood completely automatically without any need for us to change anything. Neither technical nor documentary, whether in the manifest nor in the marketplace security tabs. That’s why we chose Forge above Connect although the integration features were not in our favor by choosing Forge.

[jbevan]

Thanks for writing this up.

A. I’m probably bike-shedding here but please can we avoid “in-scope EUD” as a YAML key? while it’s valid YAML its super confusing looking, and YAML is hard enough already…

B. Is other the only valid operation value for a remote that is only referenced by the external permissions section?

C. How can we indicate that a remote is Data Residency compatible and is being used for EUD storage? There’s an assumption in this RFC that all remote storage is incompatible with Data Residency which isn’t the case.

D. Are there any in-app Forge events we can subscribe to so we know a “realm migration” is going to happen, or has happened? We’d use this to make sure our Data Residency compatible remote storage keeps the data in the right region.

In response to your questions:

1. auto-pinning sounds good
2. See D
3. I think this is fine
4. I think this is fine
5. A bit of annoying maintenance overhead but we can live with it
6. We have a real problem communicating to the right people in the customer organisation. The technical/sales contact from Marketplace usually isn’t the right person to contact. In-app messages aren’t always seen and its been a GDPR/Atlassian policy pain to collect email addresses of end-users who are actively interested in changes to the app, especially potentially breaking changes. I’d really like something to be built into Forge that would inform us ahead of a deployment that a change will cause unpinning or repinning and for which customers so we don’t have to memorise all the rules and try and work out the impact manually or build our own tooling so we can inform the right people. Equally we don’t have a REST API in Connect or Forge AFAIK that allows us to find out where a Jira/Confluence is pinned in order to do any validation/checking on our end and we’ve had a lot of push back from a “privacy” or “legal” team at Atlassian when asking for this in the past.

[JuliaWester]

While this certainly makes it easy for the customer in some ways it doesn’t respect the relationships in regards to who is controller, processor, and sub-processor in certain situations.

While Atlassian is the processor for their customers in the host app, they are a sub-processor for data generated by partners from apps. Sub-processors can’t unilaterally make decisions for processors. According to our understanding of how the GDPR needs to be interpreted, this is breaking the rules.

I think the section “ What should partners do if they don’t want to support a location?” doesn’t make sense. We can’t say we don’t do something when you do it for them anyway. I am not sure how any contradictory messaging would be beneficial to the user.

I know we have given this feedback in other forums but Atlassian needs to avoid making decisions when someone else has the legal responsibility. There has to be a clear definition of where you’re the processor. If you are always the processor for Forge somehow that might be ideal but I don’t think you’re currently taking that level of responsibility.

[SushantBista]

Thanks @JulianWolf! Glad to hear proposed solution resonates with you. Here are a few responses:

• Great feedback on redeployment notifications - we’ll keep your thoughts in mind when working on our solution.

• You’re right. Connect-on-Forge apps are not in scope for this project. We are still exploring the implications for Connect-on-Forge apps using hosted storage.

• Data residency for Connect-on-Forge and Forge apps with remote storage is not in scope for this project, however is planned for the future.

• “In-Scope EUD” refers to the categories of End User Data that are in-scope for your data residency policy. This may vary from developer to developer because some apps may store some data in Forge Hosted Storage and some data externally, and we can’t determine for you what data you consider “in scope” for your app’s data residency (as an example, Atlassian documents what types of data are in-scope for our own products here). This is something you’ll need to determine for your own app and document for your customers. Also, thanks for the feedback on the EUD abbreviation. We will keep this in mind.

• Currently, the Privacy and Security tab responses are not integrated with backend systems to populate this information automatically. This is something we plan to do in the future.

[SushantBista]

Hey @lkimmel, thanks for sharing your thoughts on this.

I understand where you’re coming from, however because Forge apps can use Forge hosted components, as well as external components, there are some things app developers will still be required to do.

With this project, only Forge apps that choose to use Forge hosted storage will inherit data residency (and by choosing to use Forge hosted storage, instructing us to provide data residency). Updates to the manifest by the app developer will be required to determine the pinning status of an app. In regards to the Privacy and Security tab, and any other app documentation, partners will need to continue defining what is in-scope for an app. As mentioned above, this is because what is considered in-scope may vary between developer to developer, as some apps may store some data in Forge hosted storage and some data externally, and we can’t determine for you what data you consider “in scope” for your app’s data residency.

[SushantBista]

Thanks a lot for your feedback @jbevan !

A. Would something like in-scope-end-user-data, as suggested in earlier comment, work better ? Do you have any suggestions on what you would expect?

B. Would having an additional value like external or permissions be better aligned with your expectations for this?

C. We currently do not have a method for supporting and calling migrations for external remotes in Forge. Data residency for Connect-on-Forge and Forge apps with remote storage is currently not in scope for this project, however is planned for the future.

D. For this project, we are thinking about providing an audit trail or logs that can be accessed by developers to know when, what and by who certain requests regarding migrations has been made by the customer. This can include information that a customer has requested a realm migration for their Forge app/host product. Would something like this work?

Its great to hear the solution mostly meets your expectations. Regarding point 6, thanks for the great feedback on this. We will explore this more and weigh whether or not this is something that can be in scope for this project. We’ll address it in the RFC resolution.

[SushantBista]

Hi @JuliaWester, thanks again for raising this.

As we mentioned previously, we chose to implement data residency for Forge Hosted Storage based on requests from Forge Developers, following feedback they received from their customers who want Forge developers to store data for their apps in the same location as the host product.

By choosing to use Forge hosted storage, app developers are instructing Atlassian to store the relevant Forge app data in the same location as the host product, and migrate the Forge app data when the customer’s relevant host product is migrated. The pinning location of the host product (and in effect the relevant Forge app data) will be determined by the customer via the AdminHub UI. We are also thinking about ways to provide information to app developers to enable them to identify when such migration requests were made, and by whom (this is partly related to Asks question number 2).

We’ve consulted with external privacy counsel to ensure that we can offer this functionality while acting as a processor of app data on behalf of the Forge Developer. We want to provide clear guidance on the nature of Forge Hosted Storage (and the way it implements data residency in Atlassian-supported regions) in the Forge Product Documentation, which we will also link to the Forge DPA, in effect making the documentation part of our contractual relationship with the Forge Developers. We will also provide advanced notice before rollout of the solution to ensure developers have time to assess impact to their apps.

Thanks for the feedback on “What should partners do if they don’t want to support a location?” section. The section was intended to explain that app developers can include in their customer terms/contracts the locations where a customer should (or shouldn’t) store or pin their app data (as there is currently no technical method on Forge). We are also thinking about ways to make such information more easily accessible to customers during a migration journey (e.g. linking to an app’s privacy policy etc.). Please let me know if you have any thoughts on this.

[lkimmel]

In our case, we don’t even have the need to define a remote yet. The only problem is, that we have to define Atlassian’s own domains as external to get assets like some avatars. This should also handle Atlassian’s platform and should not be considered to be external nor remote as it is Atlassian’s domain.

Edit: In fact we have to set "*.atlassian.net" as external for issue type and priority icons and user and project avatars at the moment.

[danielwester]

All right let’s start off the top…

To help partners more easily meet customer data residency needs, we are enabling data residency support for apps that choose to exclusively use Forge Hosted Storage. These apps will be able support data residency for in-scope data with less separate investment (compared to supporting data residency for external databases).

That’s a false premise. In order to support data residency - each vendor has to identify their legal risk/concerns. So while technically you can “resolve” items - each partner will need to consult their legal council about the liabilities (Forge doesn’t dissolve this).

Forge will take care of the hosting, pinning, and migration of hosted data between supported locations, so partners can focus on building a high quality app for their customers.

As sub-processor of the partner - right?

• Any data that is stored in Forge Hosted Storage will be automatically migrated to the same location as the host product (starting at the time of Beta release).

With the partner as the processor of the data? We’ll give you the “yepp - go ahead and do this?” Otherwise - you’re violating GDPR and not working as our subprocessor.

• All new installations of an app using Forge Hosted Storage will have data stored (for relevant tenant) in the same location as the parent product.

Again - the partner will give the “ok” of doing this?

• When a customer requests the parent product to be moved to a new location, the relevant Forge Hosted Storage partition will move along with the host product data.

Who is the customer here? I’m assuming from the Forge platform the partner is the customer and requestor?

• Forge apps that exclusively store in-scope End User Data within Forge Hosted Storage will automatically be shown under “pinned” in the customer data residency UI (meaning they have pinned stored data to the same location as the parent product).

I’ll repeat the same concern as above. What if I don’t want to support the pinning to Russia or China?

• If the parent product is not pinned, Forge apps will remain in the Global location along with the parent product data.

? * Pinning location: App partition (for relevant tenant) will be pinned/migrated to same location as the host product

• Who determines the location: Customer admin determine the pinning location of the host product (and hence the location of the relevant Forge app partition). If the parent product is not pinned, Forge apps will remain in the Global location along with the parent product data.

Explain how the customer is telling me (preferably in a flow chart) as partner where things are being “pinned” and then me telling Atlassian Forge is processing this…

• Pinning location: Forge Hosted Compute will be provisioned and operational in all Atlassian supported locations to ensure acceptable performance (when Forge Hosted Storage is multi-location enabled). As with Jira and Confluence data residency, data-in-transit will not be pinned to any particular location.

Uhm. What?!?!?! You’re going to ship my customer’s information to a region without my involvement? How that does that work? Can I get Atlassian to decree that any liabilities will be handled by them by this statement?

• Who determines the location: Atlassian will determine the location of the hosted compute to ensure acceptable level of performance.
  emphasized text
  No. Just no. Unless Atlassian is saying that they’re controllers of the data - no.

Note: Like Jira or Confluence data residency, only at-rest data will be pinned. Data-in-transit (up to 30 days), app logs, cached content and user account information will not be pinned. If the data residency scope changes for the parent product data residency, we will evaluate similar changes for Forge.

That doesn’t matter. That’s telling the partner that we’ll absorb Atlassian’s legal risks. Will you indemify the partners of the risks?

Multi-location hosted compute will be automatically enabled for all Forge apps by the time Forge Hosted Storage data residency is rolled out to production. This will ensure there is acceptable level of performance when Forge Hosted Storage is multi-location enabled.

Again no.

However, in order for it to take effect, a redeployment of your app will be required. This will be a minor version update. We will make an announcement and give you advanced notice before you need to take this action.

Atlassian deploys to a new area and things break because partners aren’t notified. What is the advanced notice?

What should partners do if they don’t want to support a location?

If your app uses Forge Hosted Storage but you don’t wish to support one of the Atlassian supported locations for your app data residency, you can stipulate this in your terms with customers.

While there is no technical limitation to a customer moving their data to an Atlassian supported location, you can include stipulations about locations where customers can store data in your end user terms or any other customer contracts at your own discretion. That said, it’s important to note that Atlassian is not a party to your contracts with customers and cannot enforce the terms by prohibiting the customer from storing data in certain locations.

You realize that is probably not legally possible? If somebody shouts in a forest about new terms - it doesn’t mean that folks know about it.

While we would appreciate any reactions you have to this RFC (even if it’s simply giving it a supportive “Agree, no serious flaws”), we’re especially interested in learning more about:

I’ve got several concerns. One being - anyone one using forge should seek legal council and not rely on this RFC. If Atlassian cared about the Vendor requirements - they would take a step back and look at what partners need in order to have a proper business - not what the customer wants (while we should work to get to - let’s build one that is legal);

2. What level of visibility do you anticipate needing around migration requests and hosting location of hosted storage/compute, and why?

I need to know who transfered data out and when ( with the pii details for audit rails).

5. What do you think about having to redeploy your app every time Atlassian supports new locations? Are there other ways this may impact that we haven’t anticipated?

Nope. See above

We are currently targeting Q1 CY24 for release of Forge Hosted Storage data residency Preview (Customer Beta). You can track this project in Atlassian public cloud roadmap, Forge public roadmap and [FRGE feedback board]([FRGE-1203] - Ecosystem Jira> lOrigin=eyJpIjoiY2Q2YzM4NDhmN2IyNGU5OGFlZTVlZTBhYTc5MjlhZTgiLCJwIjoiaiJ9).

Thanks for your feedback!

I’m really excited that ya’ll are working on making Forge becoming a Data Resident platform - let’s just make it without risks for vendors.

/Daniel

[remie]

+1 on everything @danielwester has said.

This is just another clear example of Atlassian getting tangled in the web of the legal love triangle of her own making.

Either Atlassian sticks to the premise of Marketplace Partners having their own contracts with customers (and thus full control over customer data with relation to the app), in which case Atlassian is a sub-processor to the Marketplace Partner,

or, and I suspect this is how Atlassian really feels,

Atlassian is the eternal guardian of all customer data and acts as a Data Controller who can determine how and when Marketplace Partners gets to access customer data.

Either can be true, but they can’t both be true at the same time. You can’t have your legal cake and eat it.

Atlassian will have to unequivocally choose to ditch ADPR (yes, that is indeed Atlassian Data Protection Regulation) and conform to GDPR, or Forge Storage will remain unusable for any EU partner.

[EliasBrattliSorensen]

I echo the concerns voiced by @JuliaWester, @danielwester and @remie. The proposal in this RFC won’t be enough to satisfy ours or any other serious interpretation of the GDPR. The examples stated above clearly shows that the proposed rig of Forge will breaks the rules for the role of Atlassian acting as a sub-processor on the Partner’s behalf.

I know Atlassian wants control and a functional and effective zero-trust system, and many aspects of the sandboxing in Forge are great stps toward achieving that. But if partners aren’t given any level of trust, that is to say, control of our data, then please don’t have us enter independent contracts with the customers while all the actions covered by the contract are at Atlassian’s mercy. EEA partners will have no means of upholding the rules of the GDPR and our contractual obligations to the customer while deploying our apps in this setup. A sub-processor cannot just move data to other locations without consent. That breaks the whole purpose of pinning data. Please offer the partner mechanisms like approve or deny data transfers, and control locations so that we can offer this to our customers.

/Elias

[aragot]

I also would like to request an implementation that will better enable us to respect the GDPR laws. It may seem far away for San Francisco-centric ecosystems, but it really does apply.

We’re tied to Atlassian’s choices for our customers, so we can try to deflect the blame when we receive an investigation, citing a legitimate incapacity to solve the issues and showing that we’ve requested improvements, but it would be better of the compliance was excellent by default, and Atlassian has the power to implement this properly.

[remie]

@aragot

We’re tied to Atlassian’s choices for our customers, so we can try to deflect the blame when we receive an investigation

I would not take the change on getting away with this. You deliberately made the choice to use Forge Storage for your app data even though you had alternative options, knowing that the implementation was questionable (from a GDPR perspective)

[danielwester]

What @Remie said - The Forge Terms and DPA actually makes us vendors even more responsible than Atlassian. I highly recommend all vendors to read them. The day of the “bigger company is doing this” excuse is long gone. If there’s an investigation - you’ll be tied up with paper work and dealing with the authorities a lot.

So it’s really important that this RFC is updated to handle GDPR from a partner perspective - it’s not a nice to have - it’s a must.

[SushantBista]

Hi everyone, thank you for providing your valuable feedback around this important topic.

As we described in our initial post, when a partner chooses to use data residency within Forge Hosted Storage, then any data they store in Forge Hosted Storage will be migrated to and stored in the same location as the Atlassian customer’s host product(s). Some of you have asked whether storing data in a location chosen by the customer is consistent with Atlassian’s role as your processor (or sub-processor) under the EU and UK GDPR.

The short answer is: yes, it is. Forge Hosted Storage is a single, optional component of our Forge platform. You, as a partner, determine whether or not to use Forge Hosted Storage for your app. If you do not build your app to use Forge Hosted Storage, it will not be enabled. Put another way, if you instruct us to enable data residency, then we will comply with your data residency instruction consistent with our processor obligations. We do not make the decision to enable data residency for you.

Every data storage service comes with certain terms and conditions attached, and these necessarily include restrictions on where data can be stored. For example, if a partner utilises a hosting service that only has servers in the US and Ireland, then it can’t expect to store data in Germany - this is simply a limitation of the service provided. The data residency offered by Forge Hosted Storage is no different in this respect - our condition being that, if you enable data residency, we will store data in the location our (and your) customers have said they want to use.

Additionally, we have validated this feature with outside counsel, who have confirmed that Atlassian, when acting as either a processor or sub-processor, is able to comply with applicable privacy laws when providing data residency for Forge Hosted Storage in this manner.

Remember, though - you are always in control. If you don’t want to use data residency in Forge Hosted Storage, there’s no requirement to do so. Forge Hosted Storage will only ever be enabled if you choose to turn it on.

[danielwester]

This is very different from what we’ve been told from our legal counsel so we’ll send this thread over to the team and get their feedback.

[remie]

This is just utter nonsense.

The coupling of Forge Hosted Storage with the host product, and enacting changes to Forge Hosted Storage upon request from the customer within the context of the host product is not GDPR compliant, unless it is made abundantly clear to the customer that changing data residency of the host product also implies changing data residency for any installed apps using Forge Hosted Storage.

And with abundantly clear I mean the customer should have a checkbox list of apps that they can select for which data residency should also apply. It should be that transparant.

You can offer the customer the ability to make changes to Forge Hosted Storage data residency for apps on behalf of the app vendor (to improve UX), but you cannot make this an implicit feature.

By making this an implicit feature, you are assuming a role that you do not have, because A) the customer does not know that by choosing data residency for the host product they also chose data residency for the apps and B) the app vendor does not have a direct request from the customer to change data residency of data.

@SushantBista

You, as a partner, determine whether or not to use Forge Hosted Storage for your app. If you do not build your app to use Forge Hosted Storage, it will not be enabled.

@SushantBista

Remember, though - you are always in control. If you don’t want to use data residency in Forge Hosted Storage, there’s no requirement to do so. Forge Hosted Storage will only ever be enabled if you choose to turn it on.

These are just empty statements, because Atlassian and customers are pushing hard to using Forge and Forge Hosted Storage. This is basically what GDPR would consider an involuntary consent: partners do not really have a free choice to use Forge Hosted Storage.

BTW, the strong-arming of Atlassian with regard to Forge & Forge Hosted Storage also applies to the very limited liability Atlassian assumes. We need to use your platform, but we have no control over what you will do with it nor will you assume any responsibility for it when it fails. Those are not conditions on which one can build a healthy business.