Links are explicit. You could always right up a trivial browser extension to do this on a case by case basis if you really desire.
There's nothing preventing a bad actor from copying the existing banking app and attaching a backdoor, assuming local code execution capability - either re-sign it with a local codesign certificate or use runtime code injection/linker overrides.
A web app has always the URL bar and the banking site can rely on HSTS to prevent man-in-the-middle attacks.
Getting an app to a user is imho FAR more difficult than showing him a website. (Fake ones even more so)
How easily would you click on a link if I would provide it here vs How easily would you install a new program if I provided you a link here?
Is there a bigger threat model people are worried about with extending the app schema to include normal URLs as well? Or do you just think the problem would be worse if the scope was broader?
Trying to figure out where people are drawing the line on this.
And I guess Slack is signed on Mac via Gatekeeper, but it's not distributed through an app store.
I don't run Windows and I won't install Slack natively on my Linux boxes, so I can't check the other platforms. But I would be a little surprised if the same doesn't work on them. This is basically how mailto links work today, right?
See https://developer.mozilla.org/en-US/docs/Web/API/Navigator/r...
But of course, technically it's the exact same thing, it's just a layer above. So you have a point.
On Linux, Slack installs a custom protocol handler, and includes a hidden iframe with the slack://RANDOMSTRING/magic-login/LONGRANDOMSTRING URL. I assume it's the same on Mac.
This prevents malicious third-parties from opening bank.com in their own app, but of course it also prevents useful things like using a custom YouTube app.