[HN Gopher] The Line of Death (2017)
___________________________________________________________________
The Line of Death (2017)
Author : Natfan
Score : 253 points
Date : 2022-03-18 13:10 UTC (9 hours ago)
(HTM) web link (textslashplain.com)
(TXT) w3m dump (textslashplain.com)
| BenjiWiebe wrote:
| Using a bookmarks toolbar not only saves you time accessing
| frequently-used sites, it also makes the line of death a lot
| clearer and makes it harder to fake notifications/permissions
| popups.
| whoisjuan wrote:
| Popup windows don't show the bookmark bar, though.
| NAR8789 wrote:
| It really bugs me that browsers allow popups to decide
| whether the top bars get shown. In firefox you can work
| around this: set `browser.link.open_newwindow.restriction =
| 0` and force everything to open in tabs. https://kb.mozillazi
| ne.org/Browser.link.open_newwindow.restr...
|
| It bugs me further that browsers don't let _me_ decide
| whether the top bars get shown. Sometimes it 'd be really
| nice to toggle off all the browser chrome and just have a
| true full-window view of a page (Full-window, not full-
| screen: in particular if I'm opening multiple pages and
| tiling them vertically, all that browser chrome starts taking
| up a lot of space really quickly).
|
| Dear browsers: this is hopelessly backwards! Websites should
| _never_ be allowed control my browserchrome. I should
| _always_ be in control my browserchrome. Given that this is
| already configurable per-window, put that switch solidly in
| my hands!
| mooreds wrote:
| People still use bookmarks?
|
| I thought everyone just googled and looked for links they'd
| previously visited...
| not2b wrote:
| I use bookmarks heavily, but I'm old.
| mooreds wrote:
| "Security UI is hard". Yup.
|
| It combines a lot of different aspects that make UI (which is
| always hard) more difficult:
|
| * Catastrophic implications, but rare (in the typical user's
| experience). How often does the average user get phished or have
| their account taken over, compared to how often do they have to
| log in to Random App X to do their job?
|
| * Can impede user's job, even when done right.
|
| * Competes with functional features, sometimes directly. Why is
| there now a full window API? Because it is useful.
|
| * People who work in the space are experts and will notice things
| that typical users will not (the example the author gives about
| Vista/XP)
| jgeada wrote:
| Useful to whom?
|
| There is far too much marketing/designer pressure for
| appearance over function, appearance over convenience,
| appearance over <any actual useful metric>. All the extra
| complication brought onto the web protocols just so designers
| could control appearance of a page to a pixel (even though the
| original intent of web protocols was that appearance and
| content be disassociated).
|
| Stuff may look prettier (debatable), but much has also been
| lost.
| gowld wrote:
| Users like nice-looking sites and web apps too. How would you
| make a language that allows some customization but "not
| enough to resemble a browser" ?
|
| Really, the only thing missing is "all popups must have
| browser Chrome until the user chooses to hide it for that
| site (or whatever the latest subset of "site" is for Origin
| security)
| IshKebab wrote:
| Funny that he clearly has a lot of insight into secure UI design
| but _still_ thought that some kind of "trustbadge" would help
| with full screen web pages.
| mholt wrote:
| My masters thesis [1] was about ways browsers can help protect
| users from risks involving deception. We concluded that we can't
| stop attackers from imitating or manipulating UI/UX elements, but
| we can be clever about how we protect users by being more
| attentive to their interactions and more focused on subtle cues,
| rather than codified, absolute allow/block lists.
|
| We discussed about how most browser warnings currently fill the
| page below the line of death in a way that is easy for phishing
| sites to impersonate. The user can click "Back to Safety" only to
| be taken to the real phishing page.
|
| One of the experiments we conducted was presenting browser
| warnings above the line of death by replacing security indicators
| with risk indicators, and even popping-out a warning explanation
| upon a risky interaction.
|
| Overall, subjects reported that they felt safer when the browser
| alerted them to abnormalities, rather than simply showing them
| when they were "secure" or having the browser making absolute
| trust decisions for them by blocking access to a page with a big
| warning.
|
| [1]: https://scholarsarchive.byu.edu/etd/7403/
| pizzaknife wrote:
| jiriro wrote:
| Elaborate, please.
| gowld wrote:
| https://en.wikipedia.org/wiki/ELinks
|
| ELinks is a free text-based web browser for Unix-like
| operating systems.
| moltke wrote:
| Does Elinks have a line of death? Is it possible to recreate its
| dialogs (even on a totally static page?)
| jabbany wrote:
| There doesn't seem to be a lot of research done for these kinds
| of text-based browsers (mostly due to their negligible user
| base) but I would guess that there could be a possibility to
| design pages with weird control sequences that trick the
| underlying renderer (curses etc.) into doing something weird or
| dangerous.
| na85 wrote:
| Seems to me a lot of this is possible because developers are lazy
| and want to shoehorn application delivery and runtime into a
| system originally designed for sharing documents.
|
| Those same developers seem to heavily overlap with the group that
| loves to shit on FTP and DNS etc., because they were designed for
| a less adversarial internet. I'm not sure what to make of that
| cognitive dissonance.
|
| But, maybe browsers as we know them should die and be replaced
| with something better.
| tenebrisalietum wrote:
| The term "browser" is easier to say than "Javascript/WASM
| Application And Document Object Model Rendering Engine With
| Bidirectional-but-mostly-client HTTP Interface".
|
| Internet Explorer should definitely be renamed "Application
| Runtime Engine for ActiveX" though.
| gowld wrote:
| Even if the application is "delivered", it can still be evil.
|
| What's missing is clear attribution of which "app" created the
| window.
| fluoridation wrote:
| While I think stuff like Google Docs is practically magic, I
| agree. I think it'd be a net positive if it wasn't possible to
| do stuff like that on a browser.
|
| Sometimes I wonder how things would have turned out if Java
| plugins hadn't been security Swiss cheese.
| DarraghBurke wrote:
| Would it better for the majority of applications to be native
| apps that run outside a sandbox with full access to the
| filesystem?
|
| The browser actually gives us _more_ security.
| fluoridation wrote:
| There's no reason why applets couldn't have been sandboxed
| as much as any browser scripting. If they had taken the
| role JS now occupies, we might have seen that development.
| Etherlord87 wrote:
| I'm working on a project that aims to give a lot of freedom for
| user-generated content, and I've been wondering for a while how
| to protect from the picture-in-picture attacks.
|
| One way is to ban an entire color region around a particular
| color you choose for fields requesting passwords or doing other
| sensitive data. The problem with it is of course that it's too
| big of a limitation.
|
| But how about a pattern like yellow/black checkerboard or
| stripes? This would require the parent to be able to analyze the
| child's look, and whenever the security pattern would be
| detected, it would display some kind of a warning about the
| content being similar to a secured input without actually being
| the secured input...
| miohtama wrote:
| See the related browser-in-a-browser attack:
|
| https://news.ycombinator.com/item?id=30697329
|
| The trusted UI battle has been effectively lost. Or it was not
| much of a battle in the first place, as an average consumer
| trusts anything with a lock icon on it, as UX researchers found
| out in 00s - 10s. WebAuthn and passwordless trust flows are our
| best hope to stop phishcalypse.
| marcosdumay wrote:
| I don't get how that's still useful. (As in, it really
| shouldn't be. I get what the problems are, they just shouldn't
| exist.)
|
| Pop-up login windows shouldn't be a thing. First because
| browsers have some hard rules about pop-ups, but also because
| inter-window communication isn't reliable so doing everything
| on the same window is easier in every way.
|
| Browsers shouldn't let the site open windows as they wish.
| That's incredibly user-hostile. Take the example from Firefox:
| if the user allows pop-ups, by default they can only open on
| tabs, without the focus, and with full chrome. (It took a while
| for Firefox to get over the usual web culture and restrict the
| sites, but it seems that other browsers aren't there yet.)
|
| And finally, there is the issue with passwords. We just
| shouldn't be using them on random sites anymore. But browsers
| just can't innovate.
| taneq wrote:
| Any time you use the word 'should' (or variants) you're
| describing the world as you want it to be, not as it is.
| marcosdumay wrote:
| Yes. I picked that word because of its meaning.
|
| If anywhere on that comment I gave the impression that it
| is how I believe things are, it is due to a bad choice of
| words.
| jkaptur wrote:
| Sorry, what would your desired future look like?
| tedunangst wrote:
| A less homogeneous computing ecosystem.
| notriddle wrote:
| I get why you want this, but I'm not sure how it actually
| work in practice without also sacrificing
| interoperability.
|
| There are a number of reasons why we can basically expect
| everything to converge on all computers behaving exactly
| the same, even if the interop standard notionally says
| they don't have to:
|
| * Any observable behavior will eventually be relied upon.
| You know, Hyrum's Law.
|
| * Extending a protocol means that someone, somewhere is
| behaving differently in response to that protocol
| extension. This means extending a protocol changes its
| semantics, and that people will either rely on the
| extension being supported [1], or they will (accidentally
| or maliciously) create crap data in the extended
| namespace and penalize anyone who actually tries to use
| it [2].
|
| * In other words, there is no such thing as optional
| features in standards. Either the feature works, and
| implementations that do not support it get fucked*, or it
| doesn't work, because the implementations that do not
| support it had enough clout to make it unusable.
|
| * If vendor-locked-in solutions provide a better UX, a
| lot of people will just use that [3]. Especially if the
| locked-in version is a superset of the standard, and
| everyone gradually just moves to the version with
| proprietary extensions because fixing the interop hazards
| is more important than whatever feature ties them to a
| niche implementation. Consider how Linux EEE'ed POSIX.
| Was there a conspiracy, like with ActiveDirectory and
| LDAP? Or did it just sort of happen?
|
| [1]: https://acko.net/blog/on-variance-and-extensibility/
|
| [2]: https://web.archive.org/web/20070508200721/http://ww
| w.well.c...
|
| [3]: https://signal.org/blog/the-ecosystem-is-moving/
|
| * By "get fucked", I mean "not interoperable." It might
| still be usable in a limited context, but that means
| network effects are working against it instead of for it.
| I need very, very good reason to use two different web
| browsers.
| gowld wrote:
| 1. Visit site A. 2. A links to auth provider site B -- in
| same window/tab 3. B links back to site A, or user uses
| Back button -- in same window/tab.
| MrPatan wrote:
| 4. Auth provider B cancels your account. GG
| marcosdumay wrote:
| Yep, or do that with redirects if it's better.
|
| By the way, this is the standard OAuth flow.
| whoisjuan wrote:
| A safeguard against this type of attack is to right-click on
| buttons and links, and open them in a new tab.
|
| That means that you can end up with a lot of tabs open, but it
| really helps to unmask these types of attacks.
|
| Ultimately, I think browser vendors should implement better
| patterns to discern actual windows from mimicked windows. For
| example, showing a personal secret signature in the UI above
| the "line of death".
|
| The attacker won't be able to figure out the secret signature
| so only a legit browser window will be able to display it. Here
| is a quick wireframe of how it could work:
| https://cln.sh/0GbV3A
| MauranKilom wrote:
| Many website workflows completely break as soon as you have
| more than one of it open. Online shop checkouts are at this
| terrifying intersection of "high stakes" and "almost certain
| to break if you don't do what 99% of users do".
| thrashh wrote:
| Is the line of death actually a thing? I thought that users just
| trust everything that's on the screen tbh
|
| A "line of death" sounds like something only technical users
| would notice
| easton wrote:
| If there were two address bars it would at least make a user
| curious if they didn't expect that to happen. It's similar to
| the UAC prompt, if it appears among your other windows instead
| of shading the desktop and hiding everything, even if you don't
| immediately think malware you might at least think "this is
| unexpected".
| taneq wrote:
| Honestly I lost all faith in humanity's ability to adhere to
| security protocols the day that (as a young tacker, and after
| me explaining why he shouldn't ever do so) the senior manager
| at the place I was working told me his password over the phone
| because it was easier than me walking him through a reset
| procedure.
| gowld wrote:
| or the CEO who asks for copies of web pages over email
| because they don't want to log into the secure site.
| LordDragonfang wrote:
| See also, when this was first posted:
|
| https://news.ycombinator.com/item?id=13400291 - Jan 2017 (106
| comments)
| account-5 wrote:
| Can this not be mitigated by paying attention and having browser
| add-on buttons on the main interface or a non-default config for
| the window? I see the bookmark bar has been mentioned.
|
| I think this likely less affects me as I use Linux and Firefox.
| The window manager on my distro supersedes Firefox's, so if
| window in widow happened it would look weird because no window
| manager.
___________________________________________________________________
(page generated 2022-03-18 23:00 UTC)