This is part of the assumption in my previous comment, saying that I think as vendors we should be able to expect Atlassian to enforce permissions in API calls when using the bridge (AP.request) or impersonation (ACT_AS_USER).
This is no different from the current situation. For instance I would expect that getting a list of spaces using either the bridge or impersonation would return only spaces visible to the calling user. This only means that Atlassian will have to spent time implementing permissions based responses for all API endpoints and formulate an opinion about what these endpoints should return for guest users.
I think as vendors we should be able to expect Atlassian to enforce permissions in API calls when using the bridge (AP.request) or impersonation (ACT_AS_USER).
Yes, particularly since this is an enterprise app.
I see that this RFC is listed with a “Discuss” date of May 11. Although this RFC has been posted for a week and it has received numerous ecosystem comments, I have not seen any Atlassian updates since the initial posting.
Just to set expectations correctly, should we not expect any feedback or any back-and-forth from Atlassian until the “Discuss” date arrives (ie. the “discussion” starts)? Or is that the date where the back-and-forth discussion is supposed to end? Given the context of this issue, this component of RFC-1 is unclear.
Thank you, yet again, for your participation in the community, and on this topic. Thanks for raising the lack of response to my attention. If it was unclear, dates should indicate conclusion (ie when discussion ends). For short-term, I’ll discuss with @MorganWang to see how we can get some better engagement over the next week.
For longer-term, this has not been the only RFC where I’ve observed long (or never) response times. I’m looking at ways we can better prepare authors for the level of expected engagement and some guidance about shorter vs longer RFC schedules.
Thank you and great suggestion. We are working through a few new iterations that will make it more clear to the user that this experience is being rendered this way because they are a Guest and therefore are unable to view apps because of an Atlassian policy.
Great suggestion - we have relayed this feedback to our designers.
Thank you for sharing. We are aware of the potential data leakage so we have decided to block apps. Is what we have sufficient for you to understand if your app is impacted and what the block will look like?
Sorry, we will not have a way for developers to opt out of this in the short term (by July). If Guests want to be able to access the App, they will need to be added as full licensed users.
Can you tell us if the request that prompted this RFC originated in your team, or was it from a different team (such as, say, security)? If this is from somewhere else, can the decision-makers who raised this flag in the first place pretty please be included in this thread?
Atlassian is saying “we must do X (block all apps) because Y (possible security issue)”. This represents the least-possible-effort approach (which also happens to hurt your partners) even though there are plenty of other actions possible. Plenty of existing apps are not insecure for guest users, for example. You also mentioned that there will be no way for developers to opt out “by July”.
Can Atlassian postpone the launch of this “feature” until there is a way to opt out, so that the ecosystem works as expected for everyone? And can Atlassian make a commitment as to when this opt-out will be scheduled and delivered?
If Atlassian were not to block guest access, they need a new beta period and let app vendors make sure their apps do not allow guest users too much access.
Some company workflows assume that confluence users have access to certain organization information, which guest users should not have. In order to keep the boundaries of what Confluence admins, Confluence users, and Confluence guests can do, Atlassian needs to implement an information security model suited to this situation. The current guest user feature was explicitly developed and marketed as NOT requiring any security related changes to their apps.
Like the other Marketplace partners, I am rather disappointed with this announcement.
Many apps, including ours, has already been acting as an app and potentially having wider permissions compared to a user. I want to highlight that the privacy concern raised is not a new concern.
Apps can be a vital part of the content strategy in Confluence. The content of the pages might lose a lot of relevance when the apps are blocked. To me, this looks like apps are considered a non vital part of Confluence, which I (and I would guess the entire Marketplace ecosystem) obviously disagree with. This is almost as if Atlassian was discouraging the use of apps.
I can imagine that some of your customers will be quite disappointed too. Some of these customers have reached out to Marketplace partners and asked if the guest access will work with our apps. Based on the information we had, we have answered them. Something that was working before, will no longer work when these changes come into effect. Don’t #@!% the customer.
Since the main concern highlighted in the RFC is the privacy concern, perhaps it would make sense to clarify to the privacy team how the app authentication works already today.
I really do think your use case is highly specific @marc, and not representative for the majority of apps.
Take into consideration our Figma app, which can be used to document design systems. We have customers that have included over 100 embedded designs on a single page. If they want to share their design system with guests, which is the whole purpose of the app (to share annotated designs without providing access to Figma) this will mean that there will be 100 macro’s that will show an error message saying the app is not available.
Another example, which might proof my point by making an ad absurdum argument, are our WordArt for Confluence and Sticky Notes apps. Like Draw.io, these are completely harmless apps that fully work on the front-end and do not require any access to Confluence API. Yet, if guest access is disabled, it would mean that guests would not see the visual content making the pages less understandable because they may include section headers or break-out texts.
Disabling access to macro’s for guests will deteriorate the experience of viewing Confluence pages to the point that the pages are no longer meaningful. This would be akin to just blocking guest access at all.
As another example I believe is a problem with guest users is the user property API. In the discussion We just added user property APIs in Confluence Cloud - #9 by RonnyWinkler it is explained that once you open an app iframe, you can use AP.request to get and set user properties AS THE APP. There is nothing a connect app can do to prevent a malicious user to do AP.request calls from within the iframe, but it is at least unexpected if a guest user were allowed to set other user’s properties.
The decision has obviously been made, so there’s just the details of rollout to deal with. Can we inform users of this change now? If not, when can we?
We are already doing it. We’re sending out the email today. This is a public RFC, so I do not feel bound to any embargo or NDA. If Atlassian decides to fuck over their customers, the least thing I can do is tell my customers.
The only example you are giving here is Atlassian poorly implementing permissions. If there is data leaking as a result of using User properties and the lack of permissions enforcement, this is on Atlassian, not app developers.
@remie I agree with you, and I think the problem lies with the original go ahead of guest users, and ignoring the warnings raised about data leakage and permissions.
I would keep in mind there will be some reasoning on Atlassian’s side and, likely, they are unable to share the exact details. Given the tightness of the dates I’d guess there is a specific security problem that a large customer has flagged up and Atlassian has to be seen to move quickly to plug the hole.
My own view is that we owe Atlassian the professional courtesy of a netural message. The text I’m preparing currently reads:
In the near future high usage Atlassian connect apps in confluence cloud will be blocked from displaying when viewed by guest users. This means guest users will not be able to see draw.io diagrams when viewing confluence pages. This change is required due to security considerations, the details of which remain undisclosed. Further discussions can be found at this link.
We understand that this adjustment might cause some disruption to your workflows, and we apologise for any inconvenience this may cause. The key concern for both Atlassian and us is always the security of systems and data, thus the swift implementation of these changes. Post-implementation, we will continue to explore possibilities for potential exceptions. However, until the details of the security concern are known, we appreciate your understanding that we cannot make any definitive commitments.
Here is the email we just sent to our customers. We’ve also used neutral language as there is no point in burdening our customers with any discussion between us and atlassian.
This is a quote from the announcement of the feature. To me it seems like blocking guest users goes against what they stated in the beginning.
We put quite a lot of effort as a team to make sure that guest users could use our “frontend only” app which relies on the AP library to get the content it needs. In fact, in order for guest users to work with the app, an admin user would have to enable “anonymous access” for some specific spaces where we store data, otherwise the request sent through AP would not return anything. “anonymous access” would only need to be enabled for the space not the Confluence, to avoid any confusion. So in this case, the admin would be responsible for deciding if they want guest users to use app or not
