By disabling user input the application security actually gets worse. Users that can’t copy e.g. passwords will use less complex passwords to overcome the trouble of typing in their initially good passwords. But also user experience is degrading when applications enforce complex input and users generate that input like a chad as they should. But now they cannot paste…
I'll add to that systems that require particular characters to be used, like "must use capital, number and special character". I prefer to generate longer passwords but using only regular characters because I find it easier to type on the occasions I do have to do that.
Even worse, there are some that restrict what kind of special character you can use. So even when I've generated one I still have to edit to remove one particular character.
Would it really be that difficult to display password strength and say things like "use more characters, e.g. you could use four words".
Even Apple was so annoyed at this themselves that they actually went for a full open-source open-for-contributions GitHub repository at https://github.com/apple/password-manager-resources to get around these issues.
> Many password managers generate strong, unique passwords for people so that they aren't tempted to create their passwords by hand, which leads to easily guessed and reused passwords. Every time a password manager generates a password that isn't compatible with a website, a person not only has a bad experience but a reason to be tempted to create their password. Compiling password rule quirks helps fewer people run into issues like these while also documenting that a service's password policy is too restrictive for people using password managers, which may incentivize the services to change.
You don't even have to make a single line change to your backend to fix this. You can fix this entirely on the frontend by just applying a digest hash on the password before sending to the backend for proper password hashing. This way you can even support "unlimited" length password.
That's a very much backwards incompatible change: password that used to work no longer does.
Sure, just put your 500M users through a forced-password reset.
Theoretically, it might also lead to weaker passwords depending on the hash size (that's how you support unlimited lengths by transforming a larger space into finite one) or any issues with the hashing algorithm uncovered in the future.
One thing to keep in mind is that the hash actually becomes the password, so I can imagine plenty of buggy implementations where a developer does not do what you advise ("proper password hashing"): "hey, it's already hashed, I can just store it as-is".
Limiting characters can also be a feature, so users can't use emojis in their password (this is so fun), to realize later they can't login, because they don't know how to input emojis from their desktop computer.
Hopefully passwords will be gone soon (at least that's my hope).
Don't get me wrong, it's a stupid limitation indeed -- but sometimes decisions like these are meant to stop users from doing stupider things :)
I'm no fan of oversimplification, but Apple's audience is everyone, not just power users. In that case, I'd prefer having advanced options surfaced to me as "advanced" so I can do what I want, but leave the simple experiences for the simple folk.
You might have half a point about emojis, but that's not what Apple is doing here.
Is there a reason I as a Swede should be limited from using my full native alphabet in my passwords for example?
As an example, you know how people sometimes suggest using a short sentence as a password? Here's a phrase in a local dialect, which means "and in the river there's an island"
Å i åa e ä ö
Notice how only 2 of those letters are available in ASCII.
ASCII only is not a feature, and I honestly doubt anyone would try to argue that it is if this was about any company other than Apple. Try to look past the "who" and focus on the "what".
Aren't those keyboards usually readily switchable with a standard US keyboard layout (e.g., in Windows, MacOS, or Linux)?
Do you have any direct experience with this?
My point is that 7-bit ASCII underlies virtually all other keyboard / character encodings. Among the few cases where it doesn't (e.g., IBM mainframe EBCDIC, independent of ASCII), the principle encoding remains the Latin alphabet, and can readily be converted using standard system utilities.
They aren't readily switchable unless explicitly configured to be, and yes, I am speaking from direct experience.
I get your point, I am just saying that it is not universally true, even if my example is a stretched one (Cyrillic keyboard users always configure Latin-based layouts too, but it's not a default, and it's easy to forget esp if you install from a fully live env configured with both).
If it's still not clear, you can end up on a login screen with an ASCII password you can't type in, especially so without the GUI.
The worst I've seen have uncommunicated password length maximums—but don't error when you exceed them. Instead, they just truncate your password, but only on creation. When authenticating, they don't truncate, so your password you just made with a password manager is "wrong".
Spotify did/does this. Made canceling my free trial really tricky, because I needed to log in again to do so.
That one irks me too... When I built an auth/rbac app previously I did make Max length configurable and it would display a night if set. I set a hidden hard limit to 1k only to reduce attack surfaces that would only display and error if exceeded.
Default was a min-length of 15 as the only requirement with the default hint of "try using a short sentence"
I also had optional use of zxcvbn and haveibeenpwned checks during new passphrase creation.
I really wanted to open source the application but couldn't get approval to do so.
It was a pretty nice little simple auth application that issued RSA signed JWT to configured applications. It was interested into a few internal apps as well as for clients that didn't have something like azure ad, okta, etc. where we wrote bridge apps for auth.
If I had my configuration doc, I'd probably recreate it exactly, but with a Rust backend with HTMX instead of C#+react.
The date store used SQLite as a KV store, with simple methods for access that allowed an exception later for the values. Also wrote support for PostgreSQL and MS-SQL so they could be used where available.
Spent a lot of time on same defaults, hashing and encryption along with required configuration options for a few clients.
Aside: more devs really need to better understand public/private key generation and usage... Like not using the same keys for different environments.
Even worse, when the password has an arbitrary length requirement of 20, but the site doesn't tell you and just cuts of any trailing characters exceeding the requirement during account creation.
You have no idea how long it took me to figure that one out.
Slightly easier to figure out but no less annoying is when the maxLength attributes on the password fields for the two forms (create account and login) are different.
Even worse, some will simply arbitrarily silently truncate the password. But not everywhere! The sign up page might silently truncate and then the actual login page might not.
What happened to me once is that a long-time password of mine got truncated as the website lowered it's maximum password length, and the login page didn't truncate, so my full correct password suddenly stopped working. The pain.
Several comments mention passwords getting silently truncated by input maxlength. FWIW my extension provides a visible warning when this occurs: https://underpassapp.com/StopTheMadness/
Are you referring to 'security questions' where the user must choose from a predetermined list? A predetermined list which is often questions whose answers may be know to close attackers (first school), not applicable to everyone (name of first pet), or anglocentrically blind to worldwide cultural diversity (mother's maiden name). I hate that so much.
Providing a list is fine as long as they let the user type their own question if they want to. I cannot trust the security of a single one of their crap questions if I were to answer them honestly. However, if they let me type my own question, I can absolutely guarantee it.
For my own applications I typically require only three rules to be kept, two of which most users will never even encounter, the password must:
1. be long enough (e.g. 8 characters or more)
2. not be in the list of 10k most used passwords
3. not simply reuse words present in the username, email, birthday (if my application knows about it)
This keeps it open and only interferes with truly stupid (aka insecure) password choices.
Additionally I like to propose 8 passphrases to the user so they can choose one of their liking with one click (this also serves as a proposal what a good passphrase could look like).
Good, except min 8 chars is not safe at all. Don't approach any semblance of security before min 12 chars. Min 14 is when you get into real security. The increase in entropy is exponential with password length, so security increases quickly after this.
That is why I wrote e.g., actual length can be tuned to fit the purpose of the application. If there is really sensitive data or attackers gain privileges that could wreak havoc in the wrong hands I'd probably go with 12. If an attacker would gain next to nothing I'd go with 8 for comfort reasons.
This is in addition to other mechanisms of course, like rate limiting password attempts, fail2ban, salting, peppering, chosing the right hash, proper database separation etc.
The goal should be that only an attacker that has a copy of the database could profit from too short passwords, and only if they get the salt and pepper correct, to avoid rainbow-table-attacks.
The entropy doesn't increase exponentially if my password is just N copies of the same character or phrase, it only increases linearly.
Minimal password requirements allow people who know what they're doing to do the right thing. If you want to stop people who don't know what they're doing from doing the wrong thing, it will take a lot more than just length restrictions.
All that users do when they get hit with restrictions like that is repeat their password again, or fill it out with exclamation points. Not a lot of entropy getting added.
I miss the old days of youtube when they had no restrictions. My password was x for ages. I think the only thing I use which still allows short passwords is my apple system password which thankfully is still three characters.
Shout out to forms which error out with "Password too long! Must be at most ten characters. All from this subset of ascii". Which seems especially popular with banks.
I suspect, somehow, that this is stupidity with the bank's processing core systems, which ... things are weird with financials.
They buy someone out, and now there are two systems. Glued together with duct tape. Then they release a new web product, or mobile app, or whatever, and that gets taped on too. Duct tape and spit all the way down, with everything eventually limited by the most broken part (if you're lucky).
Very frustrating that any place where I can store code has way more security than what's more important to me: place where I store my money. Financial companies still using SMS for 2FA!
You want to have weird password rules? Fine. Please make some standardized meta tags my password manager can find so it generates perfect passwords every time. Bonus points for a well-known URI facilitating touchless password rotation.
I'd be fine with storing the password policy in the password manager, and having it generate based on that policy next time.
And having all sorts of weird stuff in a password isn't necessary, so neither is the policy. To top it all off, many of the sites obsessed with password quality actually limit password length. Why?! You are comparing passwords hashes and storing them as hashes, right? So the length shouldn't matter.
Allow passwords of effectively unbounded length, set a reasonable minimum length, and don't obsess about password 'complexity'.
And for the love of all that is good, don't eff with paste.
(Those of us who know, already know. I'd like to say that we all know here.
But if a reader does not recognize "correct horse battery staple", then you're obliged to click the above link -- you're one of today's lucky 10,000![1])
I have multiple Google Accounts. One of them, I want to remember the password. The others, eh. I just want to copy paste. Doubly so for practically anything else. I wish they'd just let me copy paste.
I have developed a maybe irrational fear of space in strings such as passwords and paths. It always scares me when people use spaces in either case.
For passwords I have to actually remember and type in (os login, password mgr evs) I expressly use a short sentence, often with spacing and punctuation. Sometimes an intentionally misspelled word.
In addition, they will probably also still try to copy to clipboard first, since they probably don't use that interface often enough to remember its special rule.
I generally agree that you should let the user use the facilities they're used to, but if you have a habit of copying and pasting credentials you'll be more vulnerable to phishing.
Firefox and Chrome's built-in password management tools would never accidentally enter your credentials on a lookalike site, but you very well might.
That's all great, but then there are the times when they don't offer to copy the credentials where they should. Maybe the "correct" URL was too narrowly defined to be useful, or was taken from the setup context and is otherwise wrong for regular usage.... maybe the site changed their authentication process... etc. In the end, all of this tends to defeat the very resistance to the manual entry impulse you describe. If these password manager entry systems worked more flawlessly, your point would carry more weight... but having to defeat the protection your assertion relies upon is commonplace enough in legitimate purposes that it may well be nullified at all times.
In the end, as long as a site is going to use username/password authentication there will always be the need to educate users about what to expect sans the aid of tools.
> I generally agree that you should let the user use the facilities they're used to, but if you have a habit of copying and pasting credentials you'll be more vulnerable to phishing
This is like advising that glass sidelights be installed next to the vault door.
> In order to provide the smoothest experience as possible, the extension needs to know when you change active tabs. In order for the extension to know about that event, it needs the tabs permission, which Chrome describes as "can read and change all your data on websites you visit." That description is very scary, and is certainly not what this extension is doing. Being an open-sourced project, you can always read all the code to see how this extension works, and what it's [not] doing with your data.
The problem is that even if I read the code, or more likely chose to trust that someone has, it's not guaranteed to remain true for future updates. The author's scruples may weaken with time, or they might sell the extension, etc. (I think Chrome's extensions auto-update, but even if they didn't I'd still have to remember that this extension is one that I can't assume it's safe to update.)
The thing is there is no alternative way to do this. I have written some extensions my self and often you cant do anything without having full read and write access to every page.
For example I have an extension that lets you right click an image and rotate it by -90/+90/180 degrees. All I want is for the browser to hit me up when there is a `<img>` tag, but that is not an option. Either I have to white list every page separately in the code or ask the user to white list every single page or just ask for full read and write permissions for every single web page the user visits.
As someone working on an extension right now, I can definitely say that you only need the “ActiveTab” permission. With this, the extension only becomes active (and can interact with the page) when the user right-clicks an image and selects the action from the extension.
I have an extension to replace the "backspace for back" keybind they intentionally broke after 30 or how many years and of course it needs access to everything everywhere, because apparently they can't envision extension functionality that isn't "inject JavaScript".
On Firefox this is an option in about:config, no need for an extension. I’m on mobile rn so I don’t have an reference to the specific key, but it’s something like “enhanced backspace”
> The thing is there is no alternative way to do this.
Maybe. But this is not clear at all from the given explanation:
> In order to provide the smoothest experience as possible, the extension needs to know when you change active tabs.
The "smoothest experience"... This is corporate wooden language, and sounds disrespectful towards the users. Why does the extension need, precisely, to deal with tabs at all? A smooth experience would allow the users the choice to disable this permission while still working correctly on a single tab (as the previous version did). If this is not clearly explained upfront, it sounds like bullshit, even if it isn't.
Maybe there is no alternative way to do this. But certainly there is an better way to explain this.
This is a bit cynical isn't it, when the author is clearly being as transparent as possible about what they need and why, which is due to factors outside their control.
Of course you're right in a technical sense. They could do whatever they want later.
But still let's celebrate and attitude like this rather than criticizing it.
This has been used as an attack vector in the past: spot reasonably popular plugin; make author an offer; inject whatever tracking/other malwate stuff new owners want (typically after a delay).
So now we'd have to trust the author to do thorough vetting of a potential buyer and also not sell if vetting is inconclusive. And this against an adversary aiming to cheat their way past vetting.
Might be a cynical take, but it is not one without reason.
As a sibling comment points out, this is due to the permission model. This doesn't let the author entirely of the hook though: the permissions model created the situation, the author chose a particular path. The consequences may not have been foreseen by either, but they do exist and affect users.
>the permissions model created the situation, the author chose a particular path.
perhaps the most reasonable or even only possible path if they wanted their plugin to be able to do what they wanted it to do, which was to keep sites and from messing with your copy and paste functionality - in other words to prevent minor maliciousness.
on edit: sure, to provide the smoothest behavior, but really if it wasn't smooth people would be irritated and not want to use it. I know if I was implementing for myself I would want it to be smooth.
I understand the whole "bad things can be done" perspective, but here for some reason I fall under a "trust but verify" perspective instead.
It's not cynical - see what happened to ublock. That kind of mess has happened, and will continue to happen, and should be a factor in what you choose to trust.
The extension in the Chrome Web Store (CWS) never changed hands. I just reverse-forked a GitHub repo, which was of no consequences to those who installed the extension from the CWS. I was asked to transfer the CWS entry, I refused. This can't be compared to an extension changing hands or going rogue in the CWS.
Wasn't the worst that happened with it that the guy who took over uBlock tried to take credit for it and asked for donations? Not like he could get away with anything outright illegal when everyone knew he was running the project.
The Wiki article has a brief summary of the history, but basically the original author wanted to transfer responsibility for the user-facing maintenance to someone else, who started seeking donations and (I believe) taking payment for "acceptable ads" and the like.
Nope. People are being asked to give a bunch of deep access to their system, it's not enough for the author to have pure intensions and explain why they asked. The user should understand the risks, many of which are non-obvious (like the extension being sold).
Let's put it this way: there have been FLOSS projects whose maintainers intentionally pushed compromised code to unsuspecting end users. See for example the colors attack.
What leads you to believe that good intentions are enough?
> Let's put it this way: there have been FLOSS projects whose maintainers intentionally pushed compromised code to unsuspecting end users. See for example the colors attack.
Following this logic, we should all stop using any and all software for which we haven't personally inspected the full source code for, since this could happen to any of them.
A more reasonable take would be to assess your risk tolerance and the possible benefit for each piece of software you install, and then make the best decision for yourself based on that assessment.
For some people, that means not running an extension that provides minor quality of life improvements due to the possibility of it turning malicious further down the road. For other people, it means the opposite.
Not sure why every security-related conversation devolves into one extreme vs. another extreme. Security must be appropriately balanced against risk tolerance, inconvenience, and a number of individual concerns and preferences.
If you personally think extensions are too much of a security risk for you, sure, don't use them. But please don't comment "ackshually extensions are insecure and using them is a bad idea" on every post about a browser extension. We already know the risks, it's explained when you install them, we don't need to hear the same lecture every day.
>But please don't comment "ackshually extensions are insecure and using them is a bad idea"
I haven't? My first comment on this entire topic is the one you are replying to... And it can be summed up as "risk tolerance and security decisions is personal".
This one is the version linked by the Firefox addon [0]. Honestly can't tell if one or the other is better but I like having it automatically enabled. Considering it hasn't been updated for years (but still works) I'm not particularly worried.
I get around that by downloading the extension source and then using Chrome extension developer mode to “load unpacked extension”. Then I’m confident the extension won’t change on me.
(But for this extension I don’t give it all site permissions anyway. I just enable on site by site basis)
This is exactly the point I was making. I personally don't care that this is how some people manage their chrome extensions. It's clever, and will help if the source suddenly changes. If there is a vulnerability in the version you've downloaded & keep installing, it'll never be fixed because no automatic updates. Plenty of examples of extension vulnerabilities in Chrome, but the stability of your plugins not auto updating is definitely appealing to avoid unexpected changes/behavior
That's exactly why I use my system package manager to install and update browser extensions.
And whenever the package repository is missing a browser extension I need, I contribute the package and take responsibility for its ongoing vetting and maintenance.
You should have read a few more lines of that source - it also sends an "active" message to the tab, which is what adds and removes the copy/cut/paste event handlers.
You mean the permissions system is broken and most extensions do suffer from the same issue?
Nah mate, we at Google, (bless them Mozilla crooks giving us control over their extensions), don't care about actual issues, we only update extensions to make money and limit user freedom.
that argument only matters if you're using it on Firefox
if you're using it under chrome you're already working under the profit making goal of a failing advertising company. how worse do you think it can get?
To work around this I usually drag and drop text pasted into the URL field or somewhere, on my Mac at least.
Can I just say though that disabling paste, apparently in the name of security, is the dumbest shit I have ever encountered, right in front of ultra short timeouts everywhere.
If only I could meet the people who make these decisions in person...
> right in front of ultra short timeouts everywhere
> If only I could meet the people who make these decisions in person...
For what it's worth, I was once forced to implement a half hour auto-logout on a website that could hardly be considered as containing sensitive data because an external pentest firm flagged the lack of a short timeout as an issue. The only way we could show clients a passing pentest was to comply with all of the findings. We all knew it was stupid but management gave us no choice but to implement it.
Sometimes they will just be excessive because nobody applies any kind of critical thinking and/or because they favour looking like they find a lot over any kind of precision. I once had a site where they insisted on disabling ping responses for the website, citing it as a serious security concern. Because surely nobody would otherwise know that the very public website was there.
I replied with listing a number of websites of security focused organisations whose websites responded to ping, including assorted security services, military, and the pentesting company's own website.
(I didn't object to them querying what actually responded to the ICMP requests - none of them made it past the firewall, which is what replied and revealed nothing of our internal infra - I objected to them ignoring that answer and still insisting it revealed things it demonstrably didn't, and that lack of understanding was consistent through their report)
Yes, but with the problem that the pentester had been hired by our client and our client was a multibillion budget quasi-governmental organisation (transit authority) that was not inclined to listen because that'd involve mid-level managers sticking their necks out when they didn't need to and didn't know who was right.
So we did the British thing and went for a lot of passive-aggressive "oh, but how come it's ok for the CIA and your own website?" etc. to force them on the defensive and demonstrate that a lot of what they did was basically ticking pointless boxes.
We did manage to carve out some willingness in the client organisation to ignore bits and pieces as we clearly increased our credibility relative to the pen testers, but it was a massive pain.
Hah..you just reminded of me of something I implemented at my old company. We had a similarly short timeout, so I put in a 'heartbeat' that would refresh the timeout if you move your mouse or do anything.
That might work if your company hired the pen testers, it's a lot less likely to work if they were hired by a client. In the latter case, the overhead of all the required explanation and smoothing of ruffled feathers for the client likely costs a lot more than implementing the stupid timeout in the first place.
Pen testers are often very resistant to pushback. They get it a lot, and usually on things that are real concerns.
- My password manager had a saved login for it, I didn’t remember it, but it worked
- Then the site asked me for an authenticator app code. I checked my authenticator apps and there was nothing there for login.gov.
- There’s a login another way button so I click that and the other way is use the authenticator app!
- I click what if I can’t get my code?
- It says I must DELETE my account.
- I click to delete my account and it sends me an email.
- The email says to wait 24 hours for another account deletion email.
- 24 hours later I get an email that allows me to delete my account.
What was in the account? I have no idea, but it seems that it must be sensitive for some uses of the login. But if it’s sensitive and important why am I able to delete the account, the most destructive thing? Why is an email enough for me to delete it but not enough for me to get an auth code?
I would guess that the 24 hour delay is to allow the real owner of the account a change to cancel the delete if someone tries to mess with their account.
It's been too long and I don't clearly remember, but I think I had to use login.gov to establish an account for mumble. There was an option to print out a onetime pad (for 2FA); I chose it just for kicks. Haven't used it but I have it on file "against the day" I lose my normal second factor.
While an attacker being able to use just a password (and no 2fa) to delete someone else’s account is pretty bad, stealing information from their account may well be worse. There is a lot of personal information that I have that I'd rather see destroyed than fall into the wrong hands.
Mstsc doesn't allow it because the login screen for windows doesn't have copy-paste. It's not that it has been disabled, it's that it was never programmed to have something in the clipboard before logging in. Still, they probably could load the thing first easily, but it's Microsoft we're talking about.
I use Hammerspoon for Mac, have a shortcut set up for Cmd+Shift+V to actually type the letters rather than use the paste function. Works every time someone pulls this stunt.
I do the same with AutoHotkey for Windows. It's also come in handy in remote connection GUIs that default to the remote clipboard and legacy desktop applications with controls that don't support pasting.
Keyboard Maestro is also a fantastic app for this kind of stuff, and even adds a reasonable delay between keystrokes (something like 0.05 seconds) to prevent any weirdness.
I also do this with AHK on Windows, even using the same keystroke. Though I add a small 10-50ms delay between each keystroke, otherwise the input can get mangled sometimes.
Is there any way to do this using a Javascript bookmarklet? I'm on Linux (Wayland), and can't use Hammerspoon or Autokey / Autohotkey.
On one banking website (https://yesonline.yesbank.co.in/) that blocks pasting, even if I enable paste, pasted passwords don't work whereas typed passwords do.
I wish I could selectively disable only the "paste" events, because it's extremely useful to have "click to copy this value" type of buttons in our various work tools, and I miss the ability to do that every time I try turning off clipboard events to deal with bad actors.
The solution to this is to treat your clipboard as public in the long term. Don't keep sensitive data in it for longer than you need it. KeePass does this and it's great.
The worst is when it breaks web apps in really confusing, weird, and broken ways.
Slack, for example. Pasting becomes a complete clusterfuck. Things paste in the wrong location, incompletely, etc. I have no idea how they manage to fuck up "paste in a text box"...
Facebook Messenger also broke last time I used it where the tab would start using 100% CPU, but it's been a few years since I last used it, so don't know if that's still the case.
Anyway, I really wish I could do this per website. I have it disabled because GitHub started doing weird and annoying shit when I copy/paste stuff from comments and I absolutely hate it. But ... then it breaks Slack :-/
> I have no idea how they manage to fuck up "paste in a text box"...
For over 5 years Enter has been broken in YouTube's comment text fields. It inserts a new line but often won't move the cursor.
Last year for a while they changed the text to black in the dark theme and it was impossible to write comments because the text fields simply never showed up.
google docs, WYSIWYG editors built into any number of webapps
>terminal emulators
ssh/serial consoles on whatever your hosting provider is. Sure, sometimes there's a command line tool to do the same on your OS's terminal emulator, but if it's for a task that you're doing once every few months (eg. recovering a bricked server), clicking a button on a website and getting a shell is just more convenient.
Wikipedia does. Every site with a CMS. Google docs.
Here to write in the comments you use a simple text editor.
Chrome dev tools can also be used to change the code directly. Quite convenient to have the same dev tool behave and look the same on all the different plattforms.
I welcome this extension as I, too, hate when sites prevent me from pasting (eg. to confirm my account and routing number, email address, etc). It fucks with my password manager and of course it's annoying when intricate password rules are implemented to counter the use of weak passwords. BUT. Yeah there's always a but.
But. I have implemented these exact security measures into web applications. I've been handed the requirements and I implemented them. I asked my client why we had to do this, when "everyone" knows that this stuff is terrible user-experience and can backfire spectacularly for security (the same people who would memorize a shitty password and use it everywhere, will now write their expiring, "strong", impossible-to-remember password on a sticky note or save it to a text file or spreadsheet called 'passwords.txt' on their Desktop). The answer is: we have to, for compliance. To pass a security audit. To prove to some major client or insurance company that we have a number of industry-standard measures in place to improve security. Unfortunately, your bank does not care about the 2% of us using password managers. Everyone else is still memorizing passwords, forgetting them, and making jokes about it like it's 2003.
I don’t remember seeing any compliance requirements you can’t reasonably push back. This is just overzealous compliance consultants meeting a team that doesn’t really care about their users. People never really question anything.
Probably not. In my experience most standards are pretty broadly defined with hardly any technical requirements.
For instance in ISO 27001 it states that you should create awareness in your organisation about information security. A very minimal way is to send a mass email to everyone in the organisation or hang up posters in the office. But I also spoke to someone that was determined that a half day security awareness training was minimally required.
As someone who has worked in both PCI and PHI environments (and by extension PII), often times these aren't actually about compliance but about someone's interpretation of compliance.
What tends to happen is that auditors aren't going to tell you not to do something you don't have to, they're going to tell you to do to the things you must. Then the ones going "above and beyond" become convinced they're great at this compliance thing and others who don't do it are mistaken.
A perfect example is that PCI compliances requires firewalls but I know of a CISO that insisted on hardware level separation between networks with no way to bridge between them. The amount of pain and harm he did to that company cannot be overstated but he was convinced it was a requirement of PCI-DSS.
Our PCI-compliance audit dings us for not disabling autocomplete on the login form fields. That's not the same as disabling paste, but heading that direction.
For personal use I just abandon any site that won't let me use my password manager (Bitwarden).
You know that if paste-blocking countermeasures get too popular then the same sites will just implement virtual keyboards.
But I guess if that is to easy for folks with touchscreens then next will be the virtual mouse to click the virtual keyboard. Maybe add a randomly changing acceleration factor to the mouse to tell human and computer apart.
> You know that if paste-blocking countermeasures get too popular
Considering we've had password managers for ~20 years and most people have no idea they exist, you'll forgive me if I'm not concerned about paste-blocking taking off in popularity.
I really wish bookmarklets caught on more. They can provide a lot of the value of extensions, without running all the time and bogging down the browser (or tracking the user around the web). The lack of persistent tracking is probably what led companies like Amazon to abandon them.
I wish firefox would let the wonderbar '*' search feature work with bookmarklets... As it stands I have a few I'll never use because they're 4+ clicks away with no typeable shortcut.
You can define a keyword for this, eg. ctrl+l - `ks` (kill sticky) - enter. It has some backwards because you still can't search by name and you have to remember the keyword and there is no auto-complete, but once muscle memory gets used to it, it works pretty well.
I use keywords for bang searches (!keyword search term) and bookmarklets too.
I wasn't aware of 'keywords', thank you! Shame there's no completion / easy list (I think?) for things I'd rarely use, but I'll give it a try for a couple and add more progressively if it works well.
In case of not being able to past I normally right click -> inspect element and in the console write $0.value="value from clipboard". Works almost everywhere.
Tampering with paste is kinda is like turning of autofill and the HTML5 standard is pretty clear when it should only be turned of: ".. particularly sensitive (for example the activation code for a nuclear weapon); or that it is a value that will never be reused (for example a one-time-key for a bank login) ..."
That plainly seems like a mistake in the standard that harms security. What's the reasoning there? That somehow human fingers are less prone to error than password managers?
The only thing I can think of is malware changing the value of the clipboard to fool someone into pasting the wrong thing - but if you open that scenario then you've got all kinds of ways malware could mess with a manually typed field too.
I see I was missing an f in off. The standard says unless it's an interface on a WMD or similar let the browser autofill. The part of one time passwords that might have been indeed obsoleted by 2FA. On the other hand we might still want a single user interaction there even if it's just confirming the full value instead of typing in the 6 digits - much like passkey is doing it.
There's a lot of keyboard shortcuts that mean one thing in the browser but something totally different in another application. Now that it is common for many of these other applications to now be a web app, these keyboard short cuts are possible to start colliding.
Take GoogDocs as an example. Do you want the browser's find or the app's find if you hit ctrl-f in a Doc/Sheet/etc? The vast majority of the users want the app's. Reading a news site, most people would probably expect ctrl-f for the browser's search.
Just pointing out that hard rules will always have exceptions. Except for the TFA's point of copy/paste. Stop manipulating my clipboard with bullshit marketing/tracking bullshit!!!!!!!
why is all of the sudden ctrl-s wrong by the browser?? you make no sense here. you've never needed to save a web page? i guess i'm showing my age, while i don't use it daily, it has been a valuable feature for many reasons before.
Edit: >Then the vast majority of users are wrong.
I strongly disagree, and people unwilling to be flexible ruins the experience as those people tend to be the minority
You’re absolutely correct though, the parent comment seems to think there are absolute right and wrong answers for UI. I think that’s just not true, a good UI is one that works for your customers.
Of course there are absolute right and wrong answers for UI. Accessibility, minimum text contrast and font size, minimum size for clickable items. Keyboard shortcuts may not be (or may be) one of them, but in fact consistency across applications _is_ considered a hallmark of good UI and every Human Interface Guideline I've ever read, including open source ones such as that from KDE, specify such.
You're being obtuse. Even most of those you list will not reasonably have a fixed, absolute value that is right for all users, all applications, and all situations, and assuming they do is the cause of a lot of awful UI limitations.
(Your user will never need characters to render as single pixels? Try again - sooner or later someone will decide to abuse your spreadsheet as a raytracer and be annoyed they can't make cells single pixel)
And a feeling of consistentency often requires exceptions for specific cases such as the example of "find" where few users want to specifically find what happens to be in the browsers idea of what the document currently contains, but what it logically contains in their model of what it should contain. Consistency means that in an app that dynamically updates a scrollable region, for example, it should still find things in the currently not part of the browser document bits, and so shouldn't use the browsers find in those cases.
Some users might want a shortcut that always does the browsers own find, and there generally ought to be ways to override the app, but consistently acting how the user will want is rarely compatible with absolute rules.
I agree with almost all of the specific examples you give, but I think I agree _because_ those UI decisions work better for customers, and not because they are absolute right and wrong. I think I can illustrate this with some examples:
1. Consider a keyboard without an f-key, eg Arabic. If the user is using an Arabic keyboard, what should bring up the browsers 'find' functionality. Of course ctrl-f won't cut it. Perhaps it should be ctrl-[first letter of 'find' in Arabic]? Or perhaps ctrl-[the letter in the same position as f on qwerty keyboard]? It makes sense to follow convention if one is already established for Arabic, but then what about languages that are new to the web?
2. Consider a phone-tree, which is a sort of UI. For this UI, the 'absolute right answers' of minimum text contrast, font size, keyboard shortcuts, etc, make no sense, but there are surely other ways to make the UI work well for customers.
In both these scenarios, I feel the 'right' choice is to pick the UI that is best for users. I think there isn't a-priori a right answer, and users habits change over time and across cultures, so it's not necessarily an easy choice.
It's also trivial to use Ctrl+F on such pages if you so choose by clicking into the URL bar and then doing the keyboard combo. (Or just make two clicks in the browser menu.)
Discourse apps bind the first hit of Ctrl/cmd-f to the app's search feature, and then the second passes through and hits the browsers. Seems to be the right way to do it
There are semi-legitimate cases where this is warranted. For instance when looking at a Notion database, standard Ctrl-F is almost useless, and document search needs to go through the notion API to return results, sometimes even related to the entries that are displayed on screen.
I say "semi-legitimate" because I actually wish they'd map to a different shortcut, but can see the case for user wanted the remapping.
This of course stems from earlier decisions to have that document handling style in the first place. IMHO it becomes a complex debate when on line between an online application and a webpage.
Recently learned that if you Ctrl-F again after the highjacking, it brings up the browser search box.
Discovered this thanks to a site (don't remember which) that included a tooltip about this fact in their hijacked search box. I was curious if it would work on Redocly search, which has no such tooltip, and it did. I'm not positive if this works universally, or is just an undocumented feature of Redocly's interface and won't work in places the developers didn't make specific accommodations for it.
I just don't get it why browsers allow websites to override their own hotkeys. I'm sure it even required extra code to be written to work correctly.
Linear hijacks Cmd+F for example, very helpfully providing some terrible thing instead of my browser's built-in search that works the same everywhere. (it's the same Linear that thinks you can't not want wysiwyg markdown editing)
Well, for Ctrl+F there is sometimes a reason. Many websites uses technique called virtualization of lists. That boosts performance, but standard Ctrl+F doesn't works anymore properly
I know of 2 websites that do this.
1. Confluence
It's super annoying and takes up a lot of screen space
2. Nexus
It simply kills it. You can use ctrl-f but it simply will not find text right in front of you..
DOS emulator and Vim emulator, and that's almost all I can imagine. Maybe games that would use the control key as an additional input---but in the browser???
FWIW, the / search isn't part of Tridactyl but we do inject some code that frees up / from most websites so Firefox can use it.
It's possible to write your own user script to do it (you just need to add a keypress event handler that does preventDefault() and maybe stopPropagation()) with no need for Tridactyl :)
But it still doesn't seem to work on GitHub, did you whitelist GitHub for the preventDefault or is GitHub just a bit extra when it comes to hijacking keybinds?
Ah bummers, but nonetheless thanks for implementing this feature!
EDIT: I just took a look at GitHub's source code, and they mentioned a setting to turn off these shortcuts, and it really exists!! Under https://github.com/settings/accessibility one can turn off, all "Character keys" which means shortcuts without a modifier. I've never used them, so I just disabled it, and now forward slash always opens the Firefox search :0
We're talking about you, Slack.
(At least I can now remember which app is the one that breaks Cmd-K, but it's still annoying that I have to think that little bit longer to recall that info. every single time I press Cmd-K anywhere)
My personal hate is when webpages rebind scrolling to zoom.
I haven't used a mouse in almost 15 years. It's a constant source of annoyance when I try to scroll something with a map with my trackpad and it goes crazy zooming in and out.
Stripe docs do that and it annoys me to no end. They let you use the native search if you press ctrl+f a second time but since there is a delay it causes chaos.
In that case, I'd highly recommend browsing through the drop down menus for any of your apps. It is very common* for the keyboard shortcut to be listed, and very frustrating when it is not. This is my primary source for finding these shortcuts for a new app.
I don't think anyone here can imagine my bewilderment, confusion, and ultimately anger, the day I discovered that in the web interface for Outlook, Ctrl+V is the default shortcut for... send email.
I would very much like to know what went through their heads when they decided on that. On further thought, maybe I don't.
"Find in page" will only show a result if it is visible on the page (even though the scrollbar indicates the full vault has loaded, and even after scrolling down to the desired result and then back up).
They have a "Search vault" field that works fine, so it's not a major inconvenience, but the first few times I've Ctrl+F'd a newly added site and gotten "Phrase not found" when I know I added credentials? That's a mild anxiety I'd rather not have.
I could be convinced there's a security-related reason for this---in fact, I never really thought about it until now---but then I'd assume anyone able to get access to your vault can use Selenium and fill in the "Search vault" input field.
The fork is for supporting Firefox, which I consider to be a significant upgrade as I don't use Chrome in the first place. You can see the original repo easily, but it's far more annoying with GitHub to find a particular fork. I can keep it to myself next time if it offends you that much though, no reason to tell other people on HN about something I found interesting.
This was one of those things that frustrated me so much that we ended building this natively into Orion browser (Tools menu -> Allow Copy & Paste). [1]
Cheers for making Orion. I don't know how you guys managed to support Firefox and Chrome extensions (on iOS) but it's amazing and made moving from Android so much easier!
Brave has a "force paste" that I use now instead of Chrome and the linked plugin. I assume the motivation was the same. (What a*hole thinks blocking paste is reasonable??)
Good on you for solving this too. It's a nonsense bit of functionality.
It's kind of a misfeature, but the non-evil idea was probably to provide hooks for customizing copy and paste (or other standard command functionality) in beneficial ways, for example seamlessly copying and pasting custom data formats between web apps, or between web and desktop apps.
It is a law of the web that any potentially beneficial browser feature will immediately be (mis)used in an abusive, user-hostile manner.
It's not about disabling it, it's about intercepting it by telling the browser that you're directly handling paste events and then doing nothing. The extensions just forces the browser default handler.
Same as Safari in that regard, albeit with a much smaller team (we inherit upstream patches from the WebKit team and publish them regularly, sometimes even before Safari like in the case of patching iLeakage vulnerability).
For something simple like this that doesn't really need to be on all the time I've started leaning back towards bookmarklets over extensions. The code is usually simple enough to actually audit, it only runs when you click the bookmarklet, and it doesn't update underneath you without warning.
A few months back someone shared several bookmarklets that they use, one of which was a simple one that disables all clipboard events on the open tab:
I run into one of these broken-clipboard situations once every few months, I can afford to spend an extra click in order to not have an extension active on every website I ever visit.
I was going to mention this but glad I found it. Great extension for Safari. One of the greatest things about this is you can change the options per website. So if you use something like Notion you can use their shortcuts just for their website and the default browser ones for everything else.
I use both safari and chrome (and dabble in FF), and in my safari usage I haven't actually come across sites that disable paste. I kind of assumed this was built-in to safari, but I may just be getting lucky.
But the best feature of StopTheMadness is that it defeats the google link tracking! I've so missed that feature of whatever chrome extension I was using.
This really irks me to no end with password managers in particular. I like to generate 30 character random passwords and sites that limit input or block paste in the verify field are particularly annoying.
Similar for login and 2FA entry fields. There's no good reason for it.
I've often gone an extra bit to ensure password managers work well. I wish more sites would do the same.
I find passphrases to be better at tackling this exact scenario (and others). The password is long and secure but easy to type because it’s composed with actual English words.
There is one thing I hate more. Its having my cursor moved to another application as I am typing out a password in a field. I've literally had to change a password after it suddenly got sent out in a google search when I wasn't paying attention.
Merging the bookmarklet version of the upstream addon this one is forked from [1] and another bookmarklet that has been posted in comments here [2], I got to this:
Used to be simple to workaround this with basic web APIs (el.value = 'whateverIwant'), until this newfangled web framework from Facebook broke the web.
This. One especially infuriating trend appears to be not even using the HTML input box at all, the JavaScript just intercepts the keydown event which then (deliberately?) triggers a slow calculation before eventually rendering a star in the text-field-that-actually-isn't, breaking even "auto type" solutions. So you sit there like an idiot every time you log in, with your password manager open and password unmasked, copying each character, laboriously, one-by-one. I can't fathom how this sort of thing gets by management, who are presumably told it increases security, but then apparently never actually try to use the end product.
Even worse is when the suggestion comes to use an app instead of the website, and then the app comes with its own dedicated keyboard that isn't your own phone's keyboard, because "security" and then they scramble the position of all the letters and numbers, making it even slower.
How about an extension that STOPS websites from NOT letting me right-click. When a site forceS me to go through the stupid Chrome menu to laboriously drill down and find Developer Tools manually I want to throw it out the window.
100% in agreement with regaining paste. Another workaround is to create a macro that will "type" the clipboard contents, simulating typing it out by hand.
On macOS you can do this via Keyboard Maestro [1]. Create a macro with the action "Insert text by typing" and for the text to insert use `%PastClipboard%0%`.
Yes, very niche, but I'm sure some HN users already use Keyboard Maestro.
The only one I've ever heard is "security." Sometimes people try to "yeah it's because for security we don't want some tool to paste credentials or clickjacking mumble something malware hacking clipboard spyware javascript browser" but most of the time the truth is "our sec people need to show controls for hardening the authentication process so they came up with that and we just did it because it wasn't worth the fight"
I've also heard "being able to copy/paste defeats the purpose of having a 'confirm email' field." I reject that but it's at least somewhat logical.
Too much gets justified with vague, handwavey "because security" excuses. We can't do this because... uh... because security, yea, that's it! It should be "Specific vulnerability or GTFO."
Yeah. NordVPN is an example of this handwaviness. They refuse to delete my account to which I can successfully log into and which I've never used because they claim that as "a security-oriented company we do not take account change or deletion requests lightly, hence we request payment information to confirm ownership of the account, as we would not want anyone but the rightful owner making such changes." Problem being, I've never paid NordVPN, and when I told them as much and asked what security problem could result from them deleting an unused account, they didn't respond.
I consider it a reduction in security because it makes entering proper random passwords more difficult - either I have to paste it somewhere else first (and leave it in plaintext on my screen) OR I have to use a more memorable/shorter password. When I can paste passwords, they can be as long as possible and never are actually visible in any way.
Completely agree. There was a particular US government-run website that I had to use that disabled pasting, and required obscenely long passwords (like 15 character minimum, at least two letters/numbers/symbols/capitals/etc), and forced rotation every 60 days, and aggressively blocked "keyboard patterns" and once a password had been used, it couldn't be used again forever. Given I only had to log in about once every 90 days, I literally had to change my password every time. I've never been more enraged at a product in my life. My passwords for that site may have looked good out of context, but in reality I just figured out "keyboard patterns" that it wouldn't detect and used those, and kept the password in plaintext where I could read and type it. It was the biggest security anti-pattern that I could possibly think of.
They finally fixed it after years of griping (I assume because the skyrocketing interest rates meant a large number of people suddenly began using it), but for a long time the official website for buying US government bonds wouldn't let you use your keyboard at all to enter your password, you had to click on an on-screen keyboard Java applet. For "security". Fortunately most password manager tools could break through it and paste into the password field anyway, but what a fuckup that was.
(And the site still sucks- you can't use the back button at all, for example-- but it sucks infinitesimally less now)
That’s exactly what I’ve heard. In a discussion about this recently at my job they wanted to add this to some login related forms.
I pointed out this was obnoxious and I’ve heard in the past copy & paste can be important for accessibility though I can’t be sure first hand.
Security BS was the reason I was given.
The irony is our IT department tells us to use a specific password manager and copy & paste usernames and complex passwords because the app doesn’t have browser integration. I assume “for security”.
When you have a confirmation field, like signups that require you to type your email and then verify your email, blocking paste stops the user from typing a typo and then copy-pasting the typo into the confirmation field.
Another use case is when you want the user to type in the name of the project or resource before they delete it, sites sometimes block copy and pasting the name to avoid having users get into that habit and make a mistake.
Personally I dislike the UX, I think it's too user hostile to 99% of users at the benefit of 1% that are making a mistake that's obviously their own fault, but it does cut down on support time I assume.
> When you have a confirmation field, like signups that require you to type your email and then verify your email, blocking paste stops the user from typing a typo and then copy-pasting the typo into the confirmation field.
This argument is indefensible. Browsers have had autocomplete for over a decade, Contact book applications that store email addresses have existed over a decade, password managers that also handle email addresses over a decade.
To be clear, I'm not saying I agree with it. But this isn't a feature for users that have password managers. It's a feature for the staff that handle dozens of calls per week from users complaining they never got the signup email when they had given the wrong email. There's better solutions to that problem though, and like I said I'd be the first to advocate for one. But I can see how it's an easy tool to reach for.
On the github "delete repository" screen or other extremely destructive actions, it stops you from muscle-memorying the confirmation and then accidentally deleting the wrong thing. Since you are actually forced, like really forced, to type out what you expect to happen, you won't delete my-important-work-repo when you meant to delete my-temp-test-repo.
You're forced to copy the name manually, which is just mindless typing, so doesn't force thinking, for that you'd need to provide some meaningful info about the repo to make it click that it's not a temp, or better yet make this actions undoable for some time
Mostly it seems to be a countermeasure against mistyping your email/password and then copy/pasting that bad value into the “confirm email/password” box.
Nowadays it’s a (hopefully accidental) countermeasure against password managers!
like when you get trolled by Atlassian's crap tier website where the wiki/jira-pages do not allow selecting some text blocks (and makes it even harder to tell somebody to browser-page-search for a particular string)
Has anyone else noticed that copy / paste on Mac OS / Firefox has become unreliable some time in the last 5 years? I don’t know if it’s Firefox or Mac OS but I’ve started finding it copied the wrong thing or ignored a copy command.
pretty sure it's macOS. i don't use firefox but id say roughly 4/10 times i try to paste something i just copied, the clipboard is empty and i have to do the whole thing again.
Yesterday I stumbled upon something even worse : breaking CTRL+F to replace it by a custom search. I know Google Docs / Drive does this but I tolerate it because classical ctrl+f doesn’t even make sense on their apps but here it was on a forum. I knew what a searched was on the displayed page but no, they forced me to search on the entire hundreds pages of the topic.
Blame ACH. It’s a putrid protocol that is far easier to get wrong than right. Once that daily file is pushed it’s a dozen people’s time to hope to fix a failed transaction, and there is no guarantee that the money will stay where it wasn’t meant to go. It’s one of those things the leaves you feeling “this needs to be better” yet it moves more money than almost any other means. All the upfront friction on users is to get it right should be some indication of what a catastrophe it is to fix.
My HMO does this, and I've complained year after year.
They also specify a limit of 15 characters in the text above the "change your password" field, but it actually is limited to 14 characters.
Imagine the frustration when you type in a 15-character randomly generated (from a password generator) password twice, and then have the system reject it because it is too long!
If I ever have any extra time, I'll see if I can sue Sutter Health for an "ADA" or similar violation over this.
Lol it is for this exact problem that I added one more shortcut to my script
Ctrl+8 will paste in the latest item on my clipboard, and honestly it has been so helpful that I'm quite elated.
I recommend others running a userscript for themselves, this extension is awesome, but it's something that can be broken again and again. not really a permanent solution
I don’t think it’s as simple as this: it’s annoying in the context of text editing, but when you’re dealing with spreadsheets or file managers or copying from an spreadsheet into a document or an image into a document, the rich object behavior makes a lot of sense.
I vaguely remember that really old versions of windows had a “live paste” feature where if you copied a range from a spreadsheet and pasted into a word document, the pasted object would update when you changed the spreadsheet
I guarantee it's the guy who invented rich text fields and he just big dicked the fledgling UX team and because Big Development is incredibly paternal these crappy UX patterns never go away.
Paste with format is actually usefull sometimes. For example, you can copy from vscode and paste into Microsoft Word, then the resulting code will be property formatted and highlighted.
It’s beyond aggravating. I use a clipboard manager (PasteBot on macOS) set to paste plain text by default. I can pop open the history and do command+enter to paste the rich text version.
This should really be a browser config option or context menu item, among other things. Browsers today take far too much control out of the user to allow web developers to create hostile websites.
- Force select
- Force copy
- Force paste
- Spoof tab visibility ("Don't make me watch" extension)
Copy and pasting is such an essential part of everyday computer usage
Also can relate a bit as a developer, recently been struggling trying to get scrolling paste capture on a remote terminal with ncurses (wide lines, long texts, utf8 characters, can all be tricky)
For me this is annoying and I really hate websites hijacking paste. But it is more annoying on the phone specially when creating passwords with password manager. Does anyone know something that will work for safari?
At a more general level you can use a keyboard remapping app like Keyboard Maestro on a Mac and Autohotkey on Windows to insert text by simulated typing, though it has the downside of requiring a different shortcut
In a similar vain some of the AWS console pages make it hard to select text and use ctrl^c to copy it. It often deselects the text as soon as you hit ctrl. It is extremely irritating.
My peeve with copy&paste is that it often fails to copy, not to paste. I sometimes need to copy three times until I succeed a paste. Does anyone see this problem?
This is why I build an external password thing that emulates a keyboard. Nothing some stupid braindead "security" implementation can do to prevent that from working. It does TOTP too. I had fun with hooking it up to my phone via BT for proximity unlocking. Part of its secret lives on the phone.
I wouldn't say it very secure since i didn't bother with implement a proper asnc encryption for the bt part. And its still vulnerable to a variety of evil maid attacks. My threat model doesn't involve that to ever matter. It should be practically fully resistant to remote full-take attacks.
I was paying my real estate taxes recently and the payment processor chosen by the county wouldn't let me paste anything. It was fucking bananas. I had to type in bank account numbers and routing numbers. None of the form filling worked. I was paranoid the whole time about entering the wrong data, and I wanted to punch someone in the throat for that bullshit.
I normally just inspect the element in dev tools and disable the attached paste event handler. Not the most convenient way, but also I don’t need to do it all that often
A bank had once the fucked up idea to require some characters of the password. It was a Polish bank and I know that another one there has the same idiotic idea.
So you had to write down your passwords, map an index (1, 2, 3, ...) to each character and check the ones that match.
But it was not all! You had a time limit!
These idiots disabled it for some time and then apparently reenabled it again.
I wonder, seriously, which education the inventor had and to which point his team was saying yes to everything.
Do we really have to put up with vulgarity even on HN?
It's bad enough to see it in the title--cause someone will say that's what the title is--but, as can be seen, it breeds unnecessary vulgarity throughout this thread.
To see the irony of it all, I'll get fucking downvoted for fucking complaining about this fucking shit and maybe get really fucked up by getting fucking banned.
I don't understand people who give a shit about vulgarity. And more importantly, people that expect other people to adjust to them. They're just fucking words. Lots of little things about the way some people write or speak may annoy me, like their dialect or some word/phrase they use too much, but the adult thing to do is to fucking deal with it and keep it to yourself. It's your problem, not everyone else's.
Find it utterly infuriating when devs feel the need to disable me autocomplete settings, spellchecking or paste.
Like I have a setting to auto insert my email if I type @@ and so many input fields have text complete disabled somehow despite me using it as a sure fire way my email is correct.
Disabling spellchecking or rolling your own spellchecking is the most egregious of all
It would have been fine literally everywhere I've worked.
I'm not saying there aren't places where this can be an issue. Partly this seems to depend on the region – in the US, in particular, it seems to be a big no-no, which I find odd considering how fucking often fuck is in fucking American media – the fuck is up with that? But outside of that? It seems to be mostly a non-issue.
Probably because the US does have a pretty wide diversity, particularly when it comes to religion. In some areas you'll find a lot of Mormons (who are greatly offended by "fuck"), and in some Christians (where some denonimations don't even like the word "crap" let alone "fuck"), in some Catholics who generally don't seem to care (I've heard some Catholic priests let loose some pretty blue streaks lol), and all kinds of others. Then there are people who aren't offended, but don't want to talk that way in front of their kids and don't allow their kids to talk that way. In a workplace in the US (where you can't discriminate based on religion as it's a protected class), it's a very bad idea to use that kind of language unless you know everyone around and you know that they don't mind. Even then, be aware of who might be nearby enough to hear. Getting an HR complaint against you for dropping an f-bomb is embarrasing and not very fun.
Eh, European countries have diversity too. I've worked with religious extremists of all stripes over the years. The idea that the US is somehow unique diverse is one of those deeply mistaken views Americans have about themselves.
> The idea that the US is somehow unique diverse is one of those deeply mistaken views Americans have about themselves.
I didn't say we were uniquely diverse, I just said we were religously diverse. Big difference. If you're going to shit on someone, at least shit based on accurate information, otherwise you make yourself look like a pretentious asshole.
> Partly this seems to depend on the region – in the US, in particular, it seems to be a big no-no
Having lived and worked in the US my entire life at various companies all over the country, religion is a huge factor in whether people take offense to it. It's not the only factor, but it is a significant one, I would guess the most significant one. Unless you have data showing otherwise, I would think you'd give my opinion at least some weight, but maybe thinking they have superior knowledge about US culture is one of those deeply mistaken views that Europeans have about themselves.
> Partly this seems to depend on the region – in the US, in particular, it seems to be a big no-no
I reread this and I apologize, I feel I came off very harsh. I was a little irritated at being unfairly stereotyped as an American, and that got a little under my skin and caused me to be much more abrasive than I would normally think appropriate.
If I'm in a situation where I need to recommend a browser extension to my parents to workaround UI dark patterns, I think we'd all be reassured by an extension name that makes it clear the author has the right attitude toward those dark patterns.
Let's not pretend there's anything polite about user-hostile UIs.
