Don't Hijack Browser Keyboard Shortcuts(hypertexthero.com)
hypertexthero.com
Don't Hijack Browser Keyboard Shortcuts
http://hypertexthero.com/logbook/2014/04/dont-hijack-browsers-keyboard-shortcuts/
20 comments
The advice of this article is good, but I don't think it should be up to individual website authors to behave well. Ideally, there ought to be a standardized javascript API for binding control keys. Then the browser could prohibit rebinding if desired (while giving feedback to the webapp as to whether rebinding was allowed), and provide an accompanying UI for the user to see which controls are enabled/disabled, to whitelist or blacklist websites, and so on.
Yes please. Especially if it has a single browser option to disable all key rebinding.
One of the dumbest I've run into is to jack ctrl-f and send it to a site search box. If I use ctrl-f, it's because I meant to do an entirely different thing, or by accident. In no case is it because I want to search your article archives.
Likewise slash. I appreciate the nod to vim, but Firefox is already nodding there.
If by nodding, you mean nodding out. For some reason, they've specially crippled the '/' search, and removed the configuration variable to make it identical to ctrl-f (next/last arrows mostly.)
If you happen to read this and are irritated by the same thing: I was saved by "Findbar Tweak." New essential plugin for me.
If you happen to read this and are irritated by the same thing: I was saved by "Findbar Tweak." New essential plugin for me.
I've no objection to configurability, but I don't want slash to behave the same as ctrl-f. In particular, when my /-search matches part of a link, hitting return follows the link. Ctrl-f searches for next, which functionality I already have access to with ctrl-g.
Edited to add - how can you stand the lack of next/last arrows in vim?
Edited to add - how can you stand the lack of next/last arrows in vim?
Far worse are websites like Battle.net that hijack the onpaste events to prevent pasting passwords. Hijacking keyboard shortcuts may cause inconveniences but prohibiting password pasting is a security flaw.
Preventing users from pasting their passwords is quite irritating. I don't even understand the idea behind it. Most likely some developer saw a non-technical user copying/pasting from a plain-text password file, and "had a great idea" to discourage that kind of behavior.
To get around sites that do this, I inspect the HTML and add my password via the value="" attribute on the input element.
To get around sites that do this, I inspect the HTML and add my password via the value="" attribute on the input element.
I use KeePass' autotype.
I wanted to use a random password, unable to paste it, I pasted it into my firstname field and just typed while reading it from there.
Anyways, I forgot to remove it again so now my first name is <firstname><oldpassword>.
You can't change your name after your account has been created.
Anyways, I forgot to remove it again so now my first name is <firstname><oldpassword>.
You can't change your name after your account has been created.
KeePass has a great autotype feature that perfectly bypasses that by simulating real keyboard input.
When it comes to anti-clipboard, I really hate sites that make you enter your email address twice (Which is retarded anyway; WHY THE FUCK would I not know/check what I am typing?; it's a cleartext field, you might as well have 2 fields for everything up to first name FFS...), then stop you copying emailfield1 to emailfield2. Fortunately, most still let me click and drag from 1 to 2.
When it comes to anti-clipboard, I really hate sites that make you enter your email address twice (Which is retarded anyway; WHY THE FUCK would I not know/check what I am typing?; it's a cleartext field, you might as well have 2 fields for everything up to first name FFS...), then stop you copying emailfield1 to emailfield2. Fortunately, most still let me click and drag from 1 to 2.
What I really hate is accounting ledgers that make me enter things it two places. Geeeze.
The reason email is special is because if that's wrong there's often no good way to fix it (and certainly no way to notify you). Whether that's sufficient motivation is a matter of judgement, but it's clearly different than first name.
The reason email is special is because if that's wrong there's often no good way to fix it (and certainly no way to notify you). Whether that's sufficient motivation is a matter of judgement, but it's clearly different than first name.
PayPal is also doing this in their "change password" form.
Do tell, how is that a "security flaw"?
A lot of people that use password managers don't know their passwords (I only know a few of mine). Maybe calling it a flaw is too severe, but it isn't doing those folks any good.
I'm curious as to how that would affect a password manager? I was always under the impression that they would directly manipulate the DOM (or perhaps alter the outgoing request)?
No.
Here is a workflow:
1) Download keypass.
2) generate random password (however you do that...)
3) copy password into web form.
4) copy passwords into keypass and save.
for logging in:
1) open keypass
2) copy password
3) paste into webform.
Typing the passwords leaves room for errors. Truly random passwords are copied and pasted. Words are typed.
Here is a workflow:
1) Download keypass.
2) generate random password (however you do that...)
3) copy password into web form.
4) copy passwords into keypass and save.
for logging in:
1) open keypass
2) copy password
3) paste into webform.
Typing the passwords leaves room for errors. Truly random passwords are copied and pasted. Words are typed.
It could be that some people use password managers that require pasting. (though many don't) It could lead to people using passwords that are easier to remember if their password manager doesn't work.
Hm, this set me wondering how much risk there is passing the passwords through the copy-paste mechanism itself. Probably not terribly much more than passing through the keyboard and IO subsystems, though. Still, I know with X selection buffers, when data is requested the application it's requested from can run arbitrary code to generate (or check!) it and is passed the window-id requesting[0]. It seems like a password manager could make use of this to implement an ACL and lock things down tighter - do any do this?
[0]: http://tronche.com/gui/x/icccm/sec-2.html#s-2.4
[0]: http://tronche.com/gui/x/icccm/sec-2.html#s-2.4
I guess that is something of a double-edged sword then. You might force someone to use a weaker password, but then hopefully they wouldn't be keeping it in a place where they could simply copy/paste it. This really starts to delve into the whole "security is a gradient with tradeoffs" situation.
>hopefully they wouldn't be keeping it in a place where they could simply copy/paste it.
???
Passwords can be simple copy/pasted from.
Encrypted files can be simply copy/pasted from.
???
Passwords can be simple copy/pasted from.
Encrypted files can be simply copy/pasted from.
I'm assuming in this scenario that they would be keeping passwords in a plaintext file. If they kept passwords in an encrypted file, wouldn't they need to decrypt it? Wouldn't you presumably have a strong password to decrypt it? Where is that kept? How strong must one's password be when that password is keeping other passwords secure? If they can remember that password, why can they not remember others?
Remembering 1 password is easier than remembering dozens of them. Reusing passwords is not a great idea, so dozens of passwords is a real concern.
It's also the case that disabling paste doesn't do anything to stop a user from storing their passwords in an unencrypted file.
It's also the case that disabling paste doesn't do anything to stop a user from storing their passwords in an unencrypted file.
Because remembering one strong password is way easier than remembering 50 strong passwords.
Anything that makes passwords harder to do right without simultaneously blocking some attack worth caring about is bad for security. Two of the biggest problems in security are that it's hard to do things the right way and that people just don't understand it.
Whether you want to call it a "security flaw" is not obviously an important question.
Whether you want to call it a "security flaw" is not obviously an important question.
I am not sure why you are getting downvoted for asking a simple question.
It could be a security flaw because you discourage using passwords that are truly randomly generated.
It could be a security flaw because you discourage using passwords that are truly randomly generated.
Yahoo Mail hijacked the down arrow: Looking in the preview pain, press down arrow to scroll... and you jump to a new mail. Very, very jarring and frustrating. I recall they also hijacked a bunch of other keys, none of which made much sense, which is sad... mostly because it shows that they don't use their own products enough to see how this can affect users.
Google+ appears to do the same thing with C-PgUp and C-PgDown; if I had wanted those keys to stop working properly, I would have used some ass-backwards browser like IE. If I've got a Google+ post open and I'm scrolling brisking through tabs, it's like hitting a brick wall.
Well, I don't think it's a bad idea to have specific shortcuts which disable the normal behaviour of a browser, and improve the UX of a website. If they exists:
* they should be explicitly enabled (i.e. RES for reddit)
* you should be notified if they are changing browser behaviour, and an option to disable shall be provided.
* they should be explicitly enabled (i.e. RES for reddit)
* you should be notified if they are changing browser behaviour, and an option to disable shall be provided.
My personal pet peeve is the hijacking of / for in page search...
The problem is not that sites are choosing to override browser shortcuts, but that they can do so at all. The browser should not allow its shortcuts to be overridden. In Vimperator you have to enter a pass-through mode, so this kind of overlap never happens.
I agree. But unfortunately many of the browser creators want to support full-fledged apps within a browser, which in their minds necessitates the rebinding of core shortcuts. A great example is command/control-s in Google Drive Documents.
Conflicting interests.
Conflicting interests.
That's not a conflict, if you're using vimperator. In one mode, you pass whatever. In the other, you pass nothing. The only conflict would be around a site wanting to bind escape...
I’m talking to you, Blogger.
Is this the same Blogger that requires JavaScript to view plain text? Or maybe I'm getting it confused with blogspot, I can never keep them all straight. In any case, I don't think it's a coincidence . . .
Is this the same Blogger that requires JavaScript to view plain text? Or maybe I'm getting it confused with blogspot, I can never keep them all straight. In any case, I don't think it's a coincidence . . .
This speaks to a broader issue with trying to keep every hotkey at the top level when you have multiple, nested containers. There is a fantastic solution to this: have a leader key that says "I am talking to my browser", where one of the sub-commands is "pass a literal leader key through". This is the way screen/tmux and ratpoison handle key bindings, and it means there is literally zero chance of a collision that I can't trivially resolve by slightly modifying my interaction.
it sure is annoying, and let's not mention blogger's hyper-dependencies on javascript in order to display the page. No javascript, no content
anyway, well what can be done is - prompt for user agreement to allow these shortcuts, then save it as user preference / cookie / etc..
anyway, well what can be done is - prompt for user agreement to allow these shortcuts, then save it as user preference / cookie / etc..
Ever tried the "Metro" version of Outlook Web Access, the one used with Office 365? It hijacks "Ctrl/Command + R" as a shortcut to "Reply". How oblivious is this?
This is just the result of transitioning HTML to an applications framework. Now the application you use to view articles is not your browser, but Blogger (or WP etc).
Yeah this is big to me. Even for system utilities. I use an OS X volume booster called "Boom"(http://www.globaldelight.com/boom/) (which is nonfree but worth the $7) and it, by default, hijacks cmd + +/- for zooming in chrome. Please don't do this!
I have noticed issues with Firefox shortcuts while on YouTube, and have wondered if this sort of skulduggery was going on.
Big examples would be PgUp and PgDn in Google+, and (at least on the old design), F5 on Twitter.
Google itself hijacks / (forward slash) which I use in Firefox for quick search. Super annoying.
I’m talking to you, Stackoverflow. I use Ctrl-k, Ctrl-b quite often.
but what about things like ctrl-s and ctrl-b in Google Docs? Those are handy and I rarely save a page or create a bookmark by hotkey.
This is an inherent problem with web apps, since they're an app within an app. There are two different contexts fighting each other. Who's to say that Ctrl+S should save the app state or the page? Whatever we choose as the default, the non-default scenario would feel awkward when we need it.
I can think of two ways to solve this: (1) decouple apps from the browser frame or (2) use a special modifier key for app shortcuts (perhaps re-use the Windows key, e.g. Win+Ctrl+S).
I can think of two ways to solve this: (1) decouple apps from the browser frame or (2) use a special modifier key for app shortcuts (perhaps re-use the Windows key, e.g. Win+Ctrl+S).
(2) That was attempted (sort of)[1] and it failed pretty badly due to poor browser support and lack of understanding amongst users.
[1] http://en.wikipedia.org/wiki/Access_key
[1] http://en.wikipedia.org/wiki/Access_key
Yeah, that's pretty messy. As an Opera user I had no idea that other browsers used Ctrl or Alt for access keys. That's just a recipe for disaster. Opera's Shift+Esc combo guaranteed no clashes with browser shortcuts, but it was really kludgy to use.
See the footnote in the article:
"An exception may be if your site provides specific functionality such as in a drawing application. Even in this case it is best to provide shortcuts as an option the user has to turn on rather than one that is on by default."
"An exception may be if your site provides specific functionality such as in a drawing application. Even in this case it is best to provide shortcuts as an option the user has to turn on rather than one that is on by default."
Yeah. From a usability point of view, I think it's important to hijack some shortcuts, but only those who are not commonly used for such as the one mentioned in the article. I would also argue that this behaviour of blogger is not what users expect, hence it is not a bad behaviour. Wasn't there a pair of shortcuts commomly used for this purpose, Ctrl-K / Ctrl-J if i'm not mistaken?
NoScript with whitelist works well enough.
So fucking true. Obnoxious javascript masturbation pattern #47,601 that will make me blacklist scripts from your site. Same for single-key shortcuts (I'm looking at you there, JIRA...).
Let's take the horrible Onswipe themes as another example. They not only break functionality and make the page slower, but also break zooming in and show buttons that pretend to be iOS buttons, but aren't.
I could rant about this for hours. It's all the same basic problem: people trying to redefine/hijack basic browsing functionality. I interpret this as extreme hubris ("I know how to design this better!") or arrogance ("this is how you will view my site, period!").