As a user, I want to click custom URIs to open the corresponding app

Feature requests
1

Q1. What is the problem that you are trying to solve?
If a user stores credentials in passbolt for an external application, it is not easy to launch the application even if the URI is given. While it works easy for web-URIs (https://*), it does not work with app-URIs (appname://*). Browsers know how to behave in both cases, but Passbolt treats them differently in the UI and therefore they are not linked/clickable. this causes an additional effort (select, copy, new tab, paste, enter) for what should be one click.

Specific behavior currently

On the webpage (main table, URI column), a HTTP(S) URI is displayed as a button:

<div title="https://example.tld/">
<button class="link no-border" type="button">
<span>https://example.tld/</span>
</button>
</div>

Meanwhile, a custom URI is not wrapped as a button:

<div title="myapp://user@tenant">
<span>myapp://user@tenant</span>
</div>

the same distinction happens in the info panel and in the extension popout

Q2 - Who is impacted?
Everyone who uses custom URI is affected, maybe more people would actually use custom URIs if it worked properly in passbolt. As a specific example, everyone who uses Amazon Workspaces is affected, but that is just one group of many.

Q3 - Why is it important and/or urgent?
Simply, it would cause less confusion for the user if a URI is always a link to click.

It is a strategic feature:
While more and more “apps” work in browser as websites, the amount of services that are providing additional apps outside of the browser is also drastically increasing (the passbolt desktop app is a good example here actually). a lot of these apps can be launched from URIs/deep-links (msteams://, webex://, workspaces://, there’s no limit as anyone can register their own). This feature would to some extend allow people to keep using the passbolt browser extension as usual even for external applications.

It is a security feature:
It would also allow passbolt to stay close to the user as it enables them to use it more like a bookmark manager, leading to better habits of having consistent vaults (no duplicates, always accurate URI) and thereby increasing security (don’t get people used to having old/no URIs set and therefore always use search function to insert credentials on potentially malicious websites)

Q4 - What is your proposed solution? (optional)
Simply treat all URIs the same. Let them always be clickable links that the browser evaluates as it can. Passbolt is not checking if the https:// link is valid, why should it check if the myapp:// link is valid?

Little extension to this but not quite the core of this request (but very related):

  • why are links always displayed as buttons anyways? they open pages in new tabs, we have target="_blank" for that. if it were just a link, users could treat it like a link and for example ctrl+click/middle-mouse-button-click it so it opens in a different tab in the background (there’s probably a few posts about this already)
  • this is not a duplicate of [PB-33629] As a user I can define url schemes that open the relevant desktop app, my post is about general behavior of clicking a URI, the other one is about adding fields to them
  • as I am writing this post, a user contacted me that the feature I am requesting here has actually been the standard in the extension popout until last week, but is now gone. I didn’t get to check patch notes yet

Q5. Community support
People can vote for this idea to show traction:

  • :ok_woman: Must have: this is critical for me to have this
  • :raising_hand_woman: Should have: this is important for me to have this
  • :tipping_hand_woman: Could have: this could be nice to have
  • :no_good_woman: Won’t have: we should not schedule this (explain why)
0 voters
2

Hi @Erik and thanks for the feature request!

I don’t know yet what to vote for it honestly, even though, I find your idea interesting actually.
However, just to put some details, we do some checks on the URI. We try to parse the urls via the URL JavaScript API (URL - Web APIs | MDN).
If it can be parse we check that the URL is not a dangerous URL like something that executes Javascript code from the address bar. If the URL doesn’t contain any scheme in it we assume a default scheme to open it in the browser.
That’s the approach we used. My guess on one of the reasons we don’t allow everything is to avoid to be able for an attacker to make code executed on a user machine.

3

Hey Steph, thanks for the additional info!
I’m very curious about the design decisions in that case and filtering executable javascript is a valid point. just giving this a quick thought, I somehow doubt that this is a better approach compared to just opening it as a url in another tab via target="_blank". I assume that would already get the execution “out of the vault” so to speak and at this point there’s no difference between a heap of JS or any malicious website. there might be some things I’m missing there about that specific behavior, I may need to test around a bit.

The argument of launching code on the user machine is also very valid generally, as it could potentially allow an attacker to share an entry with a victim that contains a URI that launches an app with specific (malicious) parameters. however, this is not only a very targeted attack, but can also be easily circumvented via linking to a malicious website that does the same thing. I don’t see how this feature would have a huge impact in that regard