There are also some more obvious smaller examples, like expanding/collapsing an accordion menu.
It makes sense because adding an upvote is the same as adding other form data to a database semantically so really should be treated the same way.
They’ve just discovered that displaying the URL bar is more secure than not.
You want to expose the functionality to make a drastic change on some resource, identified by a string, to the user. Users want this functionality for good reason. It's not reversible, for legal or security reasons. This is a change that could easily destroy the user's company or cost it millions of dollars.
Text specifying what they're doing is insufficient, as users just click through without verifying. Even a checkbox does nothing to make them pay attention. Even an input where they specify what resource they're performing this action on isn't enough, as two users have reported that they just copied and pasted the id of the resource instead of typing it in.
Sometimes you want to break the consistent interface. I don't think "verify that you typed in the password you wanted to for some shitty small company's website" rises to that level, but there are legitimate reasons to drastically increase the cognitive load involved in simple actions by breaking the uniform interface.
The purpose of this input field isn't specifically to make the user type. It's simply to ensure they know the name of the repository they're deleting.
Sure Github could (and do) display the repository name; but users are accustomed to just hitting next without reading written text.
Input boxes (as opposed to buttons) requires user attention because the user has to know what content to place in the input field. Copying and pasting still meets this requirement as the user has to scan for the repository name (i.e. read) then copy and paste that into the field.
This is why you should (almost) always offer undo for any action that would require a confirmation.
A good balance would be Confirmation -> a window of time (5 seconds - 30 days) when undo is possible -> a slightly hidden menu for irreversible confirmation.
Can someone please tell SAP?
Just like you have new NIST recommendation about not enforcing complexity. Big customers on the other hannd have it as number 1 requirement when they buy. So even if I wanted to have no complexity enforcement, I had to build in one...
$('*').unbind('paste');Trivia: Shift-Ins actually predates Ctrl-V :-)
You might be able to inspect the code of an extension, but it is less straightforward and easy compared to a simple userscript. Plus, with a userscript, there is no risk of the extension author turning malicious and updating it with malware, even if it was clean at one point.
My rule of thumb is using userscripts to modify websites' behavior, and using extensions to modify the browser's behavior. (At least that is the case for Firefox 56: Firefox Quantum and Chrome limits extensions from modifying the browser much; often they are little more than glorified userscripts.)
$0.value = 'hunter2'I use that in reverse when I can’t remember a password. Get the value from input element gives the browser remembered passwords.
Works on other peoples machines too. If you wanna steal remembered passwords.
That’s how chrome extensions steal passwords. Just sayin.
So, consider this an anti-debunk.
This should change all password fields on the page into plain text fields, with values intact. Prefix with `javascript:` and paste into a bookmark
(Can they steal Basic-auth passwords, though?)
Obviously autofill is nicer, but that works even for non-browser apps, so it's nice to have.
Presumably for making it more secure
So that kind of explains why it’s done. It’s a misinformed cargo cult.
I think “protecting” against attacks (and/or accidentally leaking password details) from these kind of sources has to be a big part of the reasoning that has lead so many big sites to make their login experiences so insanely horrible.
There must be a tracker network or big consultant out their that popularized these kinds of techniques and marketed them as a “low hanging fruit defense in depth best practice” ...
Such an amateur-hour mistake: https://goldmanosi.blogspot.com/2012/06/forcing-people-to-us...
At least the email address can be easily changed when needed, whereas most sites don't allow changing the user ID.
Similarly my banks issue me my website user strings.
Why do so many website permit users to choose? Forcing the user to write-down their assigned designator might lead to better security, too, since they would seem at that point more open to writing-down a strong password.
Even with the security risks I prefer email login. Logins are in 2 categories: a) stuff I don’t care if it’s compromised. Basically forum memberships, preferences on various sites such as retailers storing a shipping address but no payment details. b) Important things such as my email account.
For category a) sites (hundreds) I use a crap password that has been owned already. It’s 5 chars and the same on most sites. It’s been in pwned dbs for years. I can’t be bothered to use a person manager if it’s more work than 5 keystrokes to do on any platform.
For category b) sites (say ten or something) I use long unique passwords and 2FA.
Obviously it’s better to put everything in b), but I’m lazy. So as a good second best I take good care of the important passwords.