[jasode]

To generalize, it's not easy to judge what pixels on a browser's rendered webpage are trustworthy and legitimate.

For example, every time I see a "Are you sure you want to leave this page?"[1], I hesitate for a moment and wonder if that dialog box is being spoofed. That dialog shows up for many scammy websites but also legitimate ones too. Yes, one could try to learn which dialogs can't be spoofed[2] but there's always paranoia because you can't keep up-to-date with all unknown future exploits.

Chrome makes that dialog box scarier because it is modal and you can't click outside of the box on the browser's tab [x] to close the window. (You also can't use the keyboard Ctrl+F4 to close it either.) In contrast, Firefox let's you avoid clicking the dialog box by letting you click on the tab's [x] or press Ctrl+F4.

It's easy to replicate these differences in behavior on website regex101.com.[3] Type a few characters there and then try to navigate away from the page. Chrome forces you to interact with the dialog box but Firefox lets you click [x] on the browser tab.

It's nearly impossible for any combination of CSS and Javascript to "escape" the browser window and hijack the [x] button on the browser's tab so it feels "safer" just to click there.

[1] https://www.google.com/search?q=google+chrome+%22are+you+sur...

[2] https://superuser.com/questions/639084/malicious-confirm-nav...

[3] https://regex101.com/

[niftich]

FWIW, every time a browser pops up a modal that I find suspicious, I use a task manager or an OS shell to kill the process. If I have lost faith in anything a program has rendered to the screen, I no longer trust any of the program's own ways -- including the topmost 'x' -- of making the modal cleanly go away without triggering an action I didn't want to approve of.

The essay 'The Line of Death' [1] talks about users' trust placed into UI elements, and the implications thereof.

[1] https://textslashplain.com/2017/01/14/the-line-of-death/

[madeofpalk]

I think Safari has actually made some good improvements here. It now renders all JS-initiated alerts with a different chrome app fully within the page’s frame with a different UI than what’s used elsewhere on the system.

[amelius]

Perhaps there should be a symbol for "trustworthy", that you can't render on a browser. (The browser would detect it and censor it, e.g. by blackening it out). But the browser itself can use it, e.g. in dialog boxes.

[jasode]

>Perhaps there should be a symbol for "trustworthy", that you can't render on a browser.

To expand on this, the web browsers are missing:

1) trusted pixels: Some bank websites implement this idea when you try to sign in. When you enter your id, you are shown a special secret image that you chose when you created the account. If that image isn't there, you should not trust the password field presented. Therefore, any criminal who wants to present a fake bank login screen also has to know the secret image as well. E.g. Chrome could use this technique to show the secret image with dialog boxes truly triggered by Chrome itself instead of painted by malicious HTML.

2) a trusted keyboard sequence that is well-known and standard : Windows operating system had this with Ctrl+Alt+Del. Instead of trusting any login screen, you just press Ctrl+Alt+Del because no user-mode program can hijack that special key sequence. Intercepting it requires a kernel patch or a registry hack. A similar idea could be used in browsers to toggle a special keyboard mode that disables all javascript keyboard events. This mode may be useful for password fields or as a special key sequence to "unstack" hidden buttons, etc.

[JumpCrisscross]

> any criminal who wants to present a fake bank login screen also has to know the secret image as well

This mechanism is theatre:

1. User enters ID into fake bank website.

2. Fake bank website enters said ID into real bank website.

3. Real bank website shows fake bank website your "secret" image.

4. Fake bank website shows you your "secret image".

[lmkg]

Someone tried defeating the secret-image security... it turns out all it takes is a static image saying "Error with Secret Image Server, call us if the problem lasts more than 24 hours."

[jasode]

>3. Real bank website shows fake bank website your "secret" image.

I had left out some implementation details for brevity. Any first time use of a "new" computer to access the online account requires verification from the bank. (E.g. random code is emailed.) At that point, a bank cookie is set. The bank doesn't show the secret image unless the computer already has a cookie from a previous verification.

A fake webpage that tries to forward credentials to a "robo" browser on a computer in Russia wouldn't have that cookie so they'd never be able to see the secret image.

There are probably other security checks the banks do such as ip blacklists etc.

The secret image isn't foolproof but it's an extra signal to signify trust. Likewise, 2-factor authentication with mobile phones isn't foolproof either and can also be hacked.

[polyomino]

What if they open the bank website in a hidden iframe on the malicious site?

[majewsky]

X-Frame-Options: DENY

[Retric]

Banks should notice a new IP/browser and then force 2 factor authentication before showing the image. ex: Sending a text. Which would make Users far more suspicious as rather than a normal login they see one of those "we don't recognize your browser" screens. The bank can also track the 3rd party connection to their servers making this more tricky to get away with. So, while not fool proof done correctly it is actually very useful.

However, a website would not have access to the browsers image unless the machine was already compromised.

[Matumio]

Hm... the way I remember this feature (forgot where it was) is that your custom image is stored in your browser (localstorage?), not on the remote site. So when you see your image, you know it's the same origin. (E.g. not a similar URL with two letters swapped, I guess.)

[Ajedi32]

That's not an issue though if we're talking about the browser UI, as there's no way for a website (malicious or otherwise) to obtain secret image data from the browser.

[hunter2_]

That secret image thing... Can't the fake site easily proxy your chosen image from the real site the moment you submit your username to the fake site?

[jasode]

Sorry for not being clear. For the Chrome implementation of the secret image, I was thinking that the user would store it locally inside of Google Chrome configuration. E.g. in "chrome://settings" or "chrome://flags", the user sets the secret image (e.g. a photo of their cat or whatever.)

[hunter2_]

Oops, I was the one being unclear. I was just going off on a tangent about the HTML ones that some banks use. A native one indeed wouldn't have the problem I'm mentioning.

[Ajedi32]

There kinda is. It's the line of death: https://textslashplain.com/2017/01/14/the-line-of-death/ (But, as the article points out, even that isn't perfect.)

[amelius]

True. Like the other commenter noted, perhaps we could use a special key-combination (or perhaps a new key even) to enter a secure mode. Pressing that key-combination could trigger the area above the line-of-death to increase in size. Then it could show more security-related information, and perhaps even password entry fields. Just brainstorming here.

[PurpleBoxDragon]

I think that'll end up back firing by making a single target a lot of people will aim to break, creating an arms race that the browser will lose on occasion, to great determent to its users.

[jessriedel]

I think the issue you're describing has been fixed for years in Chrome. (The SuperUser question is from 2013.) Websites no longer have full control over the content of the dialog box, they do not control the button labels ("leave page"), and they are (I believe) prevented from so much text that the button runs off the screen.

The fact that the dialog box is modal proves that it's not spoofed.

[jasode]

> has been fixed for years in Chrome.

Right, it was fixed (past tense) but that doesn't change the cognitive burden for tomorrow's unknown exploits that look very similar (future tense). Everytime a popup shows up on screen, I have to question myself, "am I up-to-date on the latest browser engine internals to safely click this UI element?"

>The fact that the dialog box is modal proves that it's not spoofed.

Right but... this creates a very convoluted "decision tree" in the web surfer's brain to know whether dialog boxes are real and trustworthy. E.g. if I want to instruct my grandmother to only click on the trustworthy "Leave this Page" buttons, I have to tell her to click outside the box and if she hears a beep while at the same time nothing happens, (the layman's determination for the computer geek's jargon of "modal"), she can then safely click that button. Otherwise that "Leave this Page" button could be a fake and it downloads malware on her computer. Those are very nuanced and error-prone step-by-step instructions for safe web surfing.

Instead of that, using the spatial rules of clicking on the tab browser (the "line of death" as others pointed out) is a much easier guideline to follow.

[tomp]

> I hesitate for a moment

Does pressing Escape also allow "keypress-jacking"?