We need to talk about Runs on Atlassian

[AaronMorris1]

@JamesDumay

Before Runs On Atlassian, customers moving to Cloud were often concerned about where app data was processed and stored. These customers had already conducted thorough assessments of Atlassian’s trust posture, and applying the same level of scrutiny to each Marketplace app was both complex and burdensome for customers and partners alike. This challenge is even more pronounced with Connect and Forge Remote apps, where there’s uncertainty around how and where user-generated content is stored, processed, and managed.

We’re hearing from customers that Runs On Atlassian provides the assurance they need - that compute and storage happen on our platform, with the data lifecycle and egress controls they require, without the need for costly individual evaluations.

-- I primarily work with companies in the life sciences industry (pharma, medtech, etc.), and this is 100% accurate for them.

@JamesDumay

We’ve taken a strong initial stance on the requirements and I think our initial goals are being met.

I respectfully disagree. You have the right goals, but you’re not on track to meet them. RoA is going to fall flat as soon as you test it in a real-world situation. (IMHO)

Here’s the problem: Customers expect data egress. And the bigger the customer, the more they want data egress…whether they initially realize it or not.

Customers want eSign to send an email notification to the quality guy who only logs into Confluence when there’s something to approve. They want Xray to push Jira keys into Jenkins so they can include automated tests in their requirement coverage. They want ScriptRunner to trigger a webhook in ServiceNow when a Fix Version is released.

These are not integration (i.e., “connector”) apps specialized for data egress. These are business apps that require data egress to be useful inside a larger company. Shouldn’t they be eligible for RoA if the other requirements are satisfied?

@JamesDumay

Some are comfortable with Atlassian and Slack processing and storing their data, provided the app developer doesn’t have access to it and Slack has already been vetted by the customer.

Basically that. But I’d bet it’s most, not some.

In 12+ years, I’ve never worked with a large customer who didn’t have these kinds of requirements. I understand that I work in a niche industry…but then I can’t imagine any industry being more risk-averse than mine.

So, I’m seeing two problems:

1. The initial RoA requirements are too strict to be useful, even for a highly-regulated industry like mine. This means you’re unlikely to solve the problem of Server/DC customers coming to the cloud and dropping most (or all) of their Marketplace apps in the process.
2. The recent RFCs have backward thinking. Configurable egress is less risky than REST APIs for customers who are interested in RoA. So, as many others have mentioned, it’s confusing that REST APIs are being considered for RoA while configurable egress is not.

RoA customers want to have controlled data egress between Jira/Confluence and a vetted system (as discussed above). If I understand it correctly, configurable egress will give that control. A REST API, on the other hand, may expose data to properly vetted systems and improperly vetted systems alike, with less ability for granular access control.

Thank you for listening! Again, I’m a proponent of what you’re trying to do.

[Paolommj]

I would love a Runs On Atlassian (no egress) and a Mostly Runs On Atlassian (Controlled Egress) and a Forge Analytics Platform will fix most of the issues of Purist RoAs.
Controlled Egress will not, imho, prevent security assessments, and relaxing the constraints even more will lead to end the trust signal of RoA.
no-egress is safer for all.
Apps that need Controlled or Uncontrolled egress can maybe build something modular with forge bridge or something like that? Customers will need to assess just the egress module with a clear scope. everything might get smooth

[AaronMorris1]

@Paolommj

Controlled Egress will not, imho, prevent security assessments

I completely agree. Controlled egress (or any other feature of Forge) will not and should not prevent security assessments.

But for me, it’s not about preventing security assessments; it’s about making security assessments easier and more reliable.

@Paolommj

relaxing the constraints even more will lead to end the trust signal of RoA.

That is an important concern. We definitely need to protect the trust signal. Certainly, in my industry, RoA will be useless if it isn’t trusted.

However, controlled egress will be controlled. And in my experience, giving control to admins increases trust rather than erodes it. (Unless the controls are broken. That erodes trust every time. )

Personally, I have no expectations of controlled egress or REST APIs or anything else eroding the trust in RoA if it’s all transparent and easily controlled. But we all have different experiences with customers, so I’m sure there’s an angle I’m insensitive to. (And I’d love to learn more about it.)

[remie]

For those who question whether or not this violates GDPR Article 25, here are some additional documents that explains what Privacy by Default means according to the European Commission, the European Data Protection Board and AI

European Data Protection Board
Guidelines 4/2019 on Article 25 Data Protection by Design and by Default

2.2 Article 25(2): Data protection by default
2.2.1 By default, only personal data which are necessary for each specific purpose of the processing are processed

• A “default”, as commonly defined in computer science, refers to the pre-existing or preselected value of a configurable setting that is assigned to a software application, computer program or device. Such settings are also called “presets” or “factory presets”, especially for electronic devices.

• Hence, the term “by default” when processing personal data, refers to making choices regarding configuration values or processing options that are set or prescribed in a processing system, such as a software application, service or device, or a manual processing procedure that affect the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility.

• The controller should choose and be accountable for implementing default processing settings and options in a way that only processing that is strictly necessary to achieve the set, lawful purpose is carried out by default. Here, controllers should rely on their assessment of the necessity of the processing with regards to the legal grounds of Article 6(1). This means that by default, the controller shall not collect more data than is necessary, they shall not process the data collected more than is necessary for their purposes, nor shall they store the data for longer than necessary. The basic requirement is that data protection is built into the processing by default.

edpb_guidelines_201904_dataprotection_by_design_and_by_default_v2.0_en.pdf

European Commission
What does data protection ‘by design’ and ‘by default’ mean?

Data protection by default
A social media platform should be encouraged to set users’ profile settings in the most privacy-friendly setting by, for example, limiting from the start the accessibility of the users’ profile so that it isn’t accessible by default to an indefinite number of persons.

What does data protection ‘by design’ and ‘by default’ mean?

Google AI

I mean, IANAL, but given that this only took me a couple of minutes to gather, and it is really easy to find dozens nay hundreds of website from legal consulting firms that confirm the legal consensus on this reading of Privacy by Default, there should absolutely not be any doubt that non-critical functionality like analytics should be disabled by default.

[t-bundt]

Doesn’t privacy by default only affect personal data? So it’s up to the app vendor to not include personal data in the analytics data that’s being sent.

[remie]

@t-bundt

Doesn’t privacy by default only affect personal data?

It does! But given that this is unfiltered data egress, there is no limitation on sending PII.

@t-bundt

So it’s up to the app vendor to not include personal data in the analytics data that’s being sent.

Only to some extend. This is where the Atlassian <> Customer <> Partner love triangle muddies the water a bit.

The best way to look at this from a GDPR point of view is to consider Atlassian and the Marketplace Partner to be Joint Controllers as per Article 26.

One of the important (and often overlooked) aspects of GDPR is that it establishes a chain responsibility. So both Atlassian and the Marketplace Partner are responsible for protecting customer data. By enabling partners to access customer data and egress it by default, Atlassian has failed her responsibility of providing privacy by default within the part of the chain that she is responsible for.

So yes, Partners are responsible for not using/abusing analytics for egressing PII, and they should also implement privacy by default on their end. But Atlassian should equally do the same on her end.

[Wizmur]

100%!
It’s the same with the apps that integrate Jira with other platforms. By definition, the data has to be transfered to let’s say ServiceNow, and then go back. I’m afraid that by advertising “Runs on Atlassian” too much in it’s current shape, some companies will make it as a hard requirement that any app they get needs to have this badge even when… it doesn’t make too much sense for applications like ScriptRunner you mentioned, or the integration apps.