Hacker News Reader

Comment by da_chicken | Hacker News Reader

I've never understood this desire to make a web site behave like it isn't a web site. The entire benefit of web sites is that they've got a consistent interface even between web sites. Don't break that! Don't break copy and paste. Don't break the back button. Don't change or break the right click/context menu. Don't hide the toolbars.

View on HN

Blocking paste was supposed to discourage keeping your passwords in plain text on your desktop in 'my_secret_passwords.txt'. Now we have pw managers and people in a lot of places like big corp are lagging 10 years with policies.

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...

Keeping strong passwords in a plaintext file on your desktop seems like much better security given the most common threat model - compromised dbs leaking the weak password you reused on several sites.

Don't have any application state transitions that are not hyperlinks or a forms.

Hmm, what about upvoting or liking a post? Or do you consider an AJAX POST request a “form?”

There are also some more obvious smaller examples, like expanding/collapsing an accordion menu.

You could implement an upvote or like as a hyperlink or a form, then progressively enhance that feature to not initiate a full page reload (iirc this is how HN implements upvotes). Similarly expanding or collapsing an accordion menu could be a hyperlink which by default does request the additional content but which can be progressively enhanced to provide that feature with JavaScript for user agents that support it. As an added benefit to supporting more clients, I find it easier to reason about the state of the view when it is encoded entirely in the URL, and available state transitions being to be encoded using features of well known media types like html. This is one of the main benefits of REST: any user or user-agent which knows the media type knows how to interact with the application.

It makes some sense to have an upvote be a form that posts somewhere and the response of which is a redirect (maybe a 307?) back to the page you’re on and then the progressive JavaScript enhancement would be to perform the request asynchronously instead of redirecting.

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.

> Don't break the back button.

Can someone please tell SAP?

And Oracle.

Add it to the giant list of suck.

Try telling that to my enterprise.

They’ve just discovered that displaying the URL bar is more secure than not.

could you please elaborate? would appreciate maybe some links to read about this, find this relevant to my experience.

Is there any browser that still lets websites hide the URL bar?

And one that so many screw up: don't make scrolling anything other than a proportional shift in the page.

A use case where disabling paste events makes sense:

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.

If you need to do something like this, do it separately from the actual input. For example, something like "type in the name of the account you're trying to delete".

Disabling copy paste on the field that specifies the resource isn't a solution though, as that only increases the risk of typos.

An example of what GP is talking about is Github’s “type the name of the repository to delete it” workflow. Which I appreciate. A typo would just fail to delete, which is the correct response.

Github does allow pasting though.

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.

> but users are accustomed to just hitting next without reading written text.

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.

Reply on news.ycombinator.com