[91iejrj20310]

You're shifting responsibility from developers to the users. If reading a QR code triggers a bank transaction, that's an issue with the QR scanner and the banking application.

Users cannot check if a domain is "ok" by looking at it. You visit websites to discover what's there. A few years ago it was common knowledge that ".to" is shady and ".com" looks more legit. Now we have more TLDs than I can count. How is someone supposed to check that with visual inspection?

The way it should go: you scan a QR code. It gets interpreted into something useful that doesn't cause harm.

"Hey this QR would cause a 5€ transaction to Jon Doe. OK?" That's something the user can decide upon. payment://jon-doe:5€ doesn't help much.

(Edit: reading your post again, I realize it might be exactly what you have in mind)

[gpvos]

I was mostly thinking about URLs in untrusted contexts, like maybe from an ad you see on the street, that you want to screen by hand against malicious intent; not so much about things like your banking app example, which should always have some kind of confirmation anyway.

[91iejrj20310]

It really shouldn't matter to the browser what URL you enter. Maybe it's not the page you're looking for. But opening a website itself should cause no harm.

Just compare with today's internet advertising. Legit websites are still full of somewhat malicious ads. And users click on it - of course, since that's what a website is for.

What I'm trying to make clear is that there is no such case where QR scanners, browsers or application may consider a safe context where the user implicitly consents with malicious actions by the QR/website/...

[Fnoord]

> It really shouldn't matter to the browser what URL you enter.

In a world where browsers are vulnerable to remote code execution, and a world where users do not run the latest version of a browser, and in a world where zero days exist in browers, it absolutely does matter.