I also have to voice our disappointment with this decision. Providing guest access to a knowledge base tool is inherently risky and by taking it on you’re always opening it up to human error. Putting a blanket ban on apps like this is going to break functionality in exciting new ways and adding a catch-all phrase like ‘You don’t have access to see this content’ doesn’t provide enough context for users or app vendors. So, I’ll also ask if you would reconsider this implementation.
There are plenty of methods by which we could preserve app functionality and ensure greater data control/privacy (some mentioned above). The pessimistic reading of the RFC is that apps can’t be trusted and that Atlassian don’t want to invest in building out a robust solution that would enable apps to work for guests (hoping this isn’t true ). Maybe understanding a bit more about the importance/priority of adding guests to the growth strategy might help us provide a more moderated response?
I will also mention that the concept of adding guest/external access to systems that store company’s knowledge isn’t unique to Atlassian, there are other examples out there where permissions have been fleshed out to provide a more secure experience. Off the top of my head, solutions could range from confirmation dialogs for signed-in users to confirm that they are willing to own sharing this content or limiting app features that share user details for guest users.
Last point, trust. The point has been made many times before that big decisions like this without consultation break trust. We’re used to adapting to changes/limitations that come down the pipe from Atlassian. If there are security/privacy concerns with the implementation of this experience, trust us to find solutions or work with you to do so.
Here’s just a few examples of how this will impact users of two of our apps.
Content Formatting Macros for Confluence -
A signed-in user creates a page that has a number of macros that impact the styling of the page (not inherently a security/privacy risk). For example changing the background colour of a section of the page or adding buttons that link off to other content. This content has been deemed ‘safe’ to share with a guest but the signed-in user but after this change the guest user will have no idea about the content in those macros and the signed-in user will have to go back and forth to extract content from our macros. It causes confusion, extra work and will create a negative experience of our app.
Forms for Confluence -
A signed-in user creates a form explicitly for guests to complete as part of their onboarding. The app now simply won’t function.
To be honest, I think the essence of this issue is poor communication on Atlassian part.
@marc and @daviddrawio nailed it by saying that even though Atlassian has been warned of potential security issues, both with regard to AP and specific API endpoints as well as guest access permissions, Atlassian decided to push the feature forward. They must have either received a bug bounty vulnerability report or customer complained about a possible security threat and as a result scrambled to fix this by disabling guest access altogether.
The problem in terms of communication is that A) Atlassian never bothered to specify if this decision came from an actual undisclosed exploited vulnerability, or that this is a theoretic security issue that somehow, despite multiple warnings, is now suddenly an issue and B) that there is absolutely no details whatsoever what Atlassian is planning to do with guest access for apps in the future.
By presenting this as an AS IS, non-debatable decision without any context, apologies nor insights into future work, Atlassian has failed to get partners on board with this decision.
Or, to put it more bluntly: we have no f*cking idea where this is coming from, and as such we cannot be sympathetic to it.
Dear Atlassian, you would achieve so much more if you would spent some time working on your emotional intelligence. It continues to amaze me how you manage to alienate the one group of people that are your biggest supporters.
We, as Marketplace partners, fully acknowledge and appreciate the importance of security measures. However, the recent decision to block guest access has generated significant concerns within our community.
One particular aspect that stands out is the guest access feature, which has been eagerly awaited, especially in conjunction with our Smart Courses for Confluence app. This feature has enabled us to extend learning opportunities to external users, fostering both internal and external knowledge sharing within Confluence. Disabling guest access would render our app virtually useless for a substantial number of our users, which is undeniably disheartening.
Furthermore, guest access has become an integral part of our customers’ Confluence experience. Removing this functionality would not only disappoint them but could also disrupt their established workflows and content strategies. It feels like apps are being relegated to a secondary role within Confluence, which fundamentally contradicts our perspective and the entire Marketplace ecosystem.
Given these developments, it is foreseeable that many of your customers will share our disappointment. They have actively sought clarification on guest access compatibility with our apps based on the information available to us. Regrettably, with the upcoming changes, something previously functioning seamlessly will cease to be operational. This has the potential to generate frustration and dissatisfaction among our valued customers.
As dedicated Marketplace partners, our ultimate goal is to deliver the best possible experience to our users. It is disheartening to witness the disabling of a highly anticipated and actively utilized feature. We sincerely hope that Atlassian will reconsider this decision🤞 and explore alternative solutions that effectively address the privacy concerns without entirely removing the functionality that holds substantial value for us and our customers.
Maybe it is also good to re-iterate that the criticism displayed in this thread or any other RFC is not directed to the author personally (in this case @MorganWang).
We fully understand and appreciate the constraints in which individual Atlassians are operating. Many of us have been around longer than most Atlassians, and have worked in equally challenging environments. We get it.
The burden of the issues with this RFC and/or the Atlassian Ecosystem/Economy at large should never be put on individuals. This is an Atlassian leadership problem, to the extend that it’s not even possible to tag Keran McKenzie on this forum. There is no channel for us to vent our frustrations other than through DX, Product Mangers or Engineers.
@MorganWang, If I understand @DaveMeyer correctly, the decision to block guest access to 3rd-party apps came from the Confluence teams. If this is indeed the case, would you please engage with the Atlassian Marketplace Partners (incl. multiple Gold & Platinum metal-tier partners) that have expressed their concern over this upcoming change and how this will negatively impact their customer experience of their apps?
If Dave is incorrect in saying this is something your team decided, would you please be so kind to tell us who within Atlassian we need to express these concerns to?
On a more personal note, it is my belief that waiting 10 days to respond to an RFC only to comment on a select few contributions and disappearing again is not within the spirit of keeping it welcoming and safe or empowering the community and being constructive. But perhaps these guidelines are only applicable to non-Atlassian contributors @ibuchanan?
I’ve scheduled a follow up session with @MorganWang next week on Monday to help get some answers posted here. We’ll also be discussing the RFC timeline with the goal of making sure there’s time for meaningful back-and-forth.
Thank you for all the great responses on the RFC. We value your feedback and want to reiterate that we are invested in this developer community. We love the enthusiasm that you all have for ensuring our customers have the best experience in Confluence. In light of this feedback, we have re-reviewed the relevant security, user experience, and partner trade-offs and we are pleased to announce that we will be changing course and allowing guests to use apps.
Our new guidelines:
By default, guests will be able to use all apps installed on the instance.
Partners have the option to opt-out if they wish (we will create a guide on how to do this shortly)
Guests will not be charged for app usage because app licensing is aligned with paid user licensing, and guests are not being counted as a licensed user on a customer’s instance.
Customers may be able to add up to 5 free guests for every 1 paid Confluence user. Guests can only collaborate within a single space in Confluence.
Guest apps will only have access a single space within a Confluence site. It is critical that all apps are applying the correct authorisation checks to ensure permissions are enforced (as per our security requirements). Please review and ensure your apps implement the correct guidelines for Atlassian Connect apps and Forge apps.
We will be following up shortly with a guide on how to identify and manage guest users, and details of how to opt-out if you elect to.
). Maybe understanding a bit more about the importance/priority of adding guests to the growth strategy might help us provide a more moderated response?