Deprecation of Connect JS getSelectedText API for security reasons

What is changing?

We are deprecating the AP.Host.getSelectedText API in Jira and Confluence, due to security and privacy concerns.

Why is it changing?

This API grants access to text the user has selected anywhere on the page, without any confirmation or intervention by the user. It is not clear when an app is installed that this behaviour is possible. This presents a security and privacy risk to the user.

What do I need to do?

If your app does use this API, there’s nothing you need to do to keep your app running without errors.
The deprecation will be handled in a backwards compatible manner, the API will simply return the empty string "" under all circumstances.

If your app relies on this functionality, please first consider whether there is another way to get the information you need, such as asking the user to copy/paste the selected text. This restores the user’s control over which data they want to share.

Another option is migrating to our new app platform, Forge. Forge has implemented this same API in a much more privacy-preserving manner, by requiring the user to select the text they wish to share and then explicitly choosing an application to process that selected text.
See this guide for an example: Use selected text in a Confluence Forge app

If migrating to Forge is not an option, other app developers have created a browser extension to workaround this limitation, as this API already doesn’t exist in Server editions of our products.

By when do I need to do it?

We will be releasing this change to our developer beta groups this week, by Friday 14th Jan 2022. We will then be targeting a public rollout of this change by 10 Mar 2022, providing a deprecation period of 2 months.

@SamLeatherdale we have connect 2 apps that rely on this feature, and giving us zero alternative and only 2 months to migrate to forge, where this same feature is still enabled is just bad form.

We are using this feature in combination with the page.view.selection/action-panel web item location in Confluence, which seems to be specifically designed for this use case as this is also what is described on the Use selected text in a Confluence Forge app page.

I would strongly urge you to consider keeping AP.host.getSelectedText available for those situations in which the user selects the app through the context menu, or provide an alternative API for Connect comparable to Forge. There is no reason to force us to migrate to Forge only to have the same functionality.

CC: @bentley

12 Likes

Agree with @remie : why not offer the forge version of the API for connect?

4 Likes

I’m curious - you say “This presents a security and privacy risk to the user” but has anyone actually abused that in a connect app?

Not cool. You need to publish a roadmap of all the connect features that you are going to cripple and reasonable timeframes as well as detailed reasoning behind your decisions.

The “Forge is more secure” reasoning needs to be explained with details of the enhanced security. Also, exposing the equivalent Forge API to “connect on Forge” apps would be a reasonable middle ground, provided you give app developers a reasonable amount of lead time, say 6+ months (after Connect on Forge has gone GA).

5 Likes

Just to add up to the topic: the only source of the security submissions we see at Colined is not Connect. It’s XSS related issues caused by injections of valid JS code to assignee, epic, component, resolution, priority and other names. Atlassian API returns this code as is without any screening or sanitizing, so it’s us, vendors, to fix it in each and every UI we create. Yet another thing that consumes our development time.

This issue has been known for years. I’ve brought it up in person multiple times here, during calls with Atlassian and Bugcrowd representatives. Yet it’s still there without any intention of fixing it.

So, my question is: how do you pick those concerns? What happened so suddenly that you needed to remove that specific “risk”?

7 Likes

We’re supposed to build businesses on this “platform”. How long would Atlassian continue to use AWS as a vendor if you got 2 month deprecations?

9 Likes

Agree with what has been said by other vendors above. Also, why not just clearly declare this change as a breaking change? Instead, this post sounds like it is just a simple deprecation with a backward-compatible solution.

If your app does use this API, there’s nothing you need to do to keep your app running without errors.
The deprecation will be handled in a backwards compatible manner, the API will simply return the empty string "" under all circumstances.

This ugly “backward compatible solution” will produce silent errors, i.e. apps using this API will just not work anymore as expected but not produce errors. This is in many ways much worse than actually producing errors.

It is really discouraging to see an increasing amount of announcements formulated with simplistic solutions that make them sound like no big deal. I would like to see some more thought going into these announcements regarding

  • the actual impact on vendors
  • more carefully considered deprecation periods
  • clear explanation on why the change is necessary, not just “it is a security/privacy concern”

The most reasonable suggested solution seems to use Forge instead. However, like others already highlighted, for most vendors with Connect apps, this is not a 2-months quick-fix solution, apart from the fact that migration to Forge is for many simply not possible considering the current state of development of Forge.


Update: Just read this blog post again which says State 1 is a “Limited Alpha Release” and that Connect on Forge is actually not possible yet!?

8 Likes

@SamLeatherdale can you please comment on this?

@Bentley can we please discuss (perhaps separately) a CDAC policy for Atlassian Staff that if you post an announcement that you should be available to respond to replies within a reasonable time (even if that response is “Thanks for your feedback, we’re working on it”?

@remie Thanks for your feedback, we’re working on it.

Could you please provide us the marketplace links of the two apps that you have published that use this API? That would be helpful for our analytics.

To be honest… no I can’t. Because at this stage in the relationship between Atlassian and the Marketplace Partners I’ve become to question Atlassians motives in regard to these types of decisions. What type of metric are you trying to get out of those app listings? Number of installs?

It’s not up to Atlassian to decide whether or not the apps that are using this feature are worth it to maintain the feature for Connect. The only valid question would be: can you please tell us how much you’ve invested in your app and your bank account number so that we can compensate you. I’m more than willing to sell my apps to Atlassian Ventures for them to kill it.

Atlassian introduced a feature to the Marketplace Partners and is removing it without a viable alternative. Despite being “GA”, Forge is not production ready. Connect on Forge is not past Phase 1.

If you really want to fix this security & privacy issue, there are three ways to do it properly:

  1. buy the apps of all vendors that are using this feature (with proper compensation) and take the hit with customers for killing the apps
  2. build the feature for connect in the same way as forge (context menu only, with app selection and only provide the text through this flow)
  3. wait for Forge to be a viable alternative to Connect

Anything else would just make Atlassian a very unreliable partner.

7 Likes