Now available: UI modifications allow you to change the Jira UI in the runtime

I’ve been pondering a while about what rubs me the wrong way about Forge and these changes, and I think I tend to agree with @remie on the way you are selling Forge. The problem is - remote iFrames are totally fine security wise, if you have a capable team with an eye on security (most bigger vendors do in my experience). If you look at other companies and their extensibility models, you will find plenty of remote iFrames (e.g. extending the Microsoft Teams UI). With telling us “that’s insecure” and Forge is the solution, it comes across that you solved a problem that no one else has managed to solve, which is a bit unfortunate to vendors who have been trying to become very good at security practises over the last few years.

I feel like the whole Forge thing was a bit rushed into C-level-visibility mode, without considering the impact. There are very good (technical) reasons to prefer an extensibility model like Forge for certain features (e.g. the UI modifications, or rendering single custom fields, which is not really a great with iFrames - remote or not). In addition to that, allowing capable customers (or inexperienced vendors) to quickly implement custom functions or logic without spinning up some own, hosted infrastructure is great, totally behind this reasoning. Same for secure, hosted Atlassian storage.

Unfortunately, along the way, Forge lost focus and suddenly became the Connect “successor”, trying to replace Connect because security. In my opinion, that’s where you went wrong unfortunately, even torpedoing the success of Forge, by wanting it to be too much. The problem with this is, you are trying to find a technical solution to a problem (trust for 3rd party vendors), that’s in my opionion (and I can’t believe I’m saying this as a developer) an organizational maturity problem. Something that ISO27001 and SOC 2/3 are trying to solve. You can, perfectly fine, be a company offering a secure, remote iFrame. We are currently in the process of certifying us with ISO27001 and I have gained utmost respect for this framework, as it really makes you think about operational security, besides the “code”, like proper access control, on/offboarding etc.

Now, you might be saying: Well, if it’s on Forge, everything is hosted with us, so that matters less. While that was kind of true with the original vision, you are now weaking in Forge in a way to be compatible with Connect, so this becomes murky. Before, Forge was something customers could look at and almost blindely accept as secure, while now, they will need to look at “Well what Stage of Forge is this app, 4,5? What exactly does that mean for this particular app, better send them the stupid 33-pages security survey anyway”. You are not solving this problem anymore, because you basically still allow everyone to do anything, except hosting their own JS.

To make my point, let me qoute this other thread (Forge and Connect unified - #3 by jhazelwood)

For example, if your migration work can fit within Forge limits, it should be possible to, from within a Forge function, fetch data from your Connect app server (you’ll need to implement some auth) and then use the storage APIs to store it in Forge storage. You could also make use of Web Triggers to push the data in from the connect app server.

I don’t think it’s a good idea to move to a model where it’s encouraged practise to to roll your JWT authentication while sending data (in or out) to an external server - I fear this is not the improvement you are looking for, and I don’t think customers will appreciate this kind of thing.

Unfortunately, I don’t have any call to action. I think it’s too late in the process and Forge is now the spiritual successor of Connect, for the better or worse. I think, it would’ve been better to let Forge and Connect (or maybe something like Secure Connect) coexist, with proper integration points. I’d like to suggest that you think about a proper deprecation period for remote iFrames and JWT auth, because 6 month is really not going to cut it here. We have customer requirements and own 1+ year roadmaps, which we can’t just throw out the window to do a more less complicated move to Forge, with no benefit for our customers. You have a multi-million dollar ecosystem you are working with, please be considerate of the fact.

Thanks
Tobias

12 Likes