https://bugs.chromium.org/p/chromium/issues/detail?id=587466
In the end, i find a lot of chrome's decision to implement spec-breaking behavior awful in the context of having a website that works forever (Looking at you, samesite). But this behavior rarely breaks functionality and on the whole makes the web a lot more secure.
* Username and Password fields must not autocomplete * Username and Password fields must not allow text to be pasted in to the field * Password must be at least 8 characters with lower case, upper case, numbers, and special characters (they didn't care it had a maximum length of 8 characters)
I straight up told our project management it was actively hurting our security, and was told the the point here was to fulfill a regulatory requirement to complete and resolve all issues from a independent "pentest" not to improve security.
I still can't believe that whole business managed to interpret 2FA for whole EU as "you MUST use SMS for 2FA!".
as a low-risk privacy defect yes, because things like bank account and routing numbers would be stored in autofills for certain banking sites that don't require authn/authz to initiate a transfer.
(I can think of a handful of platforms frequently used for common services like paying HOA fees which are currently vulnerable to this, meaning another user sharing the machine can simply hit ⬇ on the keyboard in form fields on a page that doesn't require authn/authz to initiate an external transfer in order to capture any stored banking details that were previously entered into the form.)
Source: I was one of those brain-damaged appsec pentesters.
My biggest security vuln is Google. And I've seen too many new account usernames out there like forgotlastpasspw to use an external manager.
Firefox, thankfully, keeps the passwords.
One of our local banks disabled autofill without warning, and they went out of their way to detect if someone was pasting a password.
There was backlash and frustration, and they eventually reversed the decision.
After reversing it, they still put a disclaimer about not pasting passwords, but that disappeared after a few weeks.
I recall working with some folks who supported load balancers when Chrome decided that something seemed 'unnecessary' and they updated Chrome and ... it broke load balancing.
IMHO, the decision of whether to show auto-complete should be with the user and not with the website. When I install an auto-complete add-on or activate a browser feature, I expect the AC to be available on ALL input fields, whether the site owner thought that would be a good idea or not.
Now, there is a valid question on how the user should be able to configure the AC behavior, and how the website may help inform this configuration, but the decision should be with the user. The website should not have the final say.
So I would see this as more of a shortcoming of the HTML Spec.
1. A "name" field on a dialog for creating values in a controlled vocabulary (e.g. genres in fiction) -- Chrome thinks this is a username field so brings up a user autocomplete. I guess it thinks that "Jane Smith" is a valid label!
2. Editing user details (username, full name, email, etc.) -- Firefox thinks the email is a good place to autocomplete the password.
With these, I've had to employ several workarounds to tell the web browsers that these are not login forms, so please don't autocomplete them as such, all because they ignore `autocomplete="off"`. I've got these working now, but if Chrome/Firefox decide to ignore the markup because of sites misusing them (like they've done before), I'll need to work out how to avoid this again.
For example, for a multiplayer game I worked on, you could set a password when you create a private room in the game. The browser always auto-filled it with your account password, which is definitely not good because you have to share the room password with others. Telling the browser to not autocomplete that filled didn't work, because "the browser should know better than the website" thing you mentioned.
There's a setting in Chrome where you can disable auto-complete on a field-by-field basis?
Well the alternatives may not be perfect, this clearly isn't either. They can create videos rebuking disabling password fields, or put warnings in the webmaster console, or apparently just release a vague statement about how "disabling password fields or disabling pasting in to them will now majorly detract your placement in search results" and turn the Marketing/SEO team against bad security contractors.
It;s fundamentally wrong to decide what 'rights' website users have (aside from when it comes to privacy).
There are myriad ways how a website can become un-user friendly to the point of being unusable not the least is of which you can completely disable the cursor or completely not display certain parts which are really there (e.g. display: none).
Point being there is a fundamental 'trust' which a user gives to a website developer, that the website they visit will behave as 'the developer' intended. The user even expects to get the site just s the developer created it, however 'bad' that may be.
Now of course it is in the interest of the web developer to make their site user-friendly if they want to appeal to a wide populace. But it is totally in the purview of the developer to make the site even completely unusable.
I don't understand how a browser has the audacity to force their assumptions on site behavior on the user/developer.
The only way I was able to fix it was renaming the field.
The recommended alternative solution posted by a Googler in the above Chromium thread is to specify:
autocomplete="semantic-description-of-field"
autocomplete="new-password"The other side is the situation we have now, autocomplete doing the wrong thing all over the place with no way to stop it. Stomping on my apps specific database driven autocomplete really hurts the user experience. Also autofilling fields without the user noticing and entering wrong data into forms. What a mess.
Because they do put autocomplete="off" on login form, username, and password fields. At least for me:
UPDATE: please help me write a sarcastic comment about Apple Store team putting autocomplete="off" there, and Apple Safari browser ignoring it.
See https://developer.mozilla.org/en-US/docs/Web/Security/Securi...
Also, the confirmation requires authentication (at least by default, unsure if this can be changed).
> The phrase “welcome back” on a page causes Safari to autofill a password
To me as a web developer (among other things :D) this is quite annoying because password managers often hijack our forms when they decide that the label (or id or classname etc.) sounds suspiciously usernamely, passwordly or credit cardly.
I don't care about the reason they have to be so intrusive in UX, probably some malware fight and/or prevention. The fact is that if I am going to use 1Password or other password managers per site, with 25 characters long passwords with symbols and numbers, I want to be able to somehow fill that in without typing each letter. Some sites don't care about this use cases as they are trying to cover the asses of non-tech-savvy users. They must protect the password123 crowd, right? So password managers need to fight back, unfortunately.
Also, if you have a problem contact their customer support. I had a tweet get a few hundred likes about a non pastable field for a transportation website and they actually changed it later that week!
> Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.
https://pages.nist.gov/800-63-3/sp800-63b.html
I use the "Don't Fuck With Paste" add on for Chrome/Firefox, which mostly works well.
We've spent countless developer hours trying to work around password managers. I agree that sites shouldn't attempt to disable password management for login and sign up pages, but it's annoying how often these password managers do the wrong thing and break the user experience for pages… like Safari is doing for livewire-ui/spotlight.
As an administrator was trying to work though a users problem. But their account details all matches mine. It took an embarrassing amount of time for it to click.
I've also had to scrub data when users somehow put their credit card numbers into public fields. Still no explanation on that one, but it happened with enough users that our only guess was browser auto-fill gone awry and people blindly hitting submit.
And it's the browser itself rather than an electively installed plugin where you asked for it.
It's outrageous. By rights, modifying the content this way should be seen as utterly outrageous by both site authers and users, not just some quirky glitch that it's not smart enough and doing the modification in the wrong place sometimes and will shortly be improved to false-positive less often.
I use 1Password, with browser integrations (it works better with Safari than Chrome).
I don't know most of my passwords; relying on 1Password to access the strings of garbage I autogenerate.
So I am constantly using it to fill forms.
It keys on things like attached <label>...</label> elements. Not all sites use these. Some sites also sometimes add some kind of junk that causes 1Password to fail.
Other times, 1Password insists that the field I just selected needs an autofill; even for non-auth fields.
Not really a big deal for me. No one that shouldn't gets my auth, and I ignore the prompt when it is not necessary.
This is more likely normal behavior than abnormal. The number of sites a person uses likely increases the chances they don't actually know most of their passwords. The default "flow" becomes "password reset and recovery", which makes most services about a secure as the system being used for recovery if the password is reset.
It's important to understand the value of the data or service being "protected" by authentication. Banks should probably continue using passwords. Bookmarking sites, or things like Discord can get away with token logins. This eases the burden on the user.
Gmail leaves me logged in for long periods of time once I've authenticated on a given machine/browser. This is also a form of "autocompletion" in a way, allowing me to access sensitive data (my email) without having to re-authenticate with a password (by using a stored cookie). Anything using my email for password recovery is susceptible to being attacked through my persistent session, but then again I do a pretty decent job of retaining possession of my laptop physically.
By using email tokens to log in to a site, instead of resetting a password that will likely be forgotten, one could just skip straight to logging in the user with the one time tokens, which are as secure as the system being used for transmitting the token.
There is no icon in any of the fields to click to populate them.
There is no auto filling.
You have to cursor into the field, right click and manually select the relevant entry to fill.
From a security standpoint this is much better and safer overall.
It also prevents accidental autofilling and login of an account you're trying NOT to login with on sites where you have multiple accounts and need to keep things carefully separated.
Additionally, if you have Bitwarden in your toolbar, you can click the Bitwarden icon, then click the entry for the site, and it will auto-fill in the page for you.
I'm surprised anyone uses context menus to do this, though I agree with you that it's probably safer.
I have encountered this mentality often. I'm not sure if Apple users have so many bugs that they are used to it, or if it's part of the fanaticism.
I had so many bugs on iphone 6 I was baffled because the marketing "It just works". Upon voicing my issues, I was told from numerous people, "it's probably just doing X,Y,Z". Like that's an acceptable reason for bugs.
Thanks for the insult.
I'm not an "Apple fanatic," but I do develop for the platform.
I don't rail against other platforms (I spent 25 years, managing a cross-platform team), and I would suggest that you may be doing yourself a real disservice by writing off an extremely lucrative venue.
I do support you, however, in demonstrating a commitment to your principles, by ignoring and insulting a gigantic swath of monied customers.
There are often two ways you can do something. In this case:
- Explicit clean markup and a deterministic GUI or
- Tons of heuristics and a magic GUI that works great most of the time but fails in ways that are hard to understand.
I feel you get this tradeoff a lot in "clever" systems. Whether it is just finding the main text on a page, blocking ads, doing search, or even self-driving cars: I often prefer the "pedestrian" approach over the "magic" approach. Even if it is a bit less powerful, it is also less surprizing.
Why do web page authors get a pass? I mean, most web page authors today at least also do JavaScript, where a single out-of-place character can cause the whole thing to simply break.
Yeah yeah, legacy and all that, but that's why we have doctypes.
IE wasn't mainly a problem because it didn't support things, rather because it was - in the beginning - superior, but also had all sorts of non standard behaviour that Microsoft pushed and that made competition crazy hard.
Oh, and also because they pushed it relentlessly in all ways including - as was later confirmed in court - illegal ways.
Exactly like Chrome today except the multi billion fine and forced changes to Chrome is still only barely visible in the horizon.
But we will keep pushing, won't we? For the record: I think I have contacted local authorities twice officialy over the last 18 months and maybe once over twitter. If two more people do the same here in Norway that is starting to make a difference.
Same if ten people in France or Germany do it. Or if someone makes a story that goes viral or reaches the headlines somehow.
Don't give up everyone! Chrome is an excellent browser but don't think for a moment that Google won't close it down the very moment it has finally crushed competition.
Now we have "Living Standard"...
clicking issues https://stackoverflow.com/questions/24077725/mobile-safari-s... (yeah even clicks are broken)
background jank https://stackoverflow.com/questions/9983520/webkit-animation... (not sure it's exactly this bug but I do have fixes in the codebase for that)
round corners https://stackoverflow.com/questions/50995411/cant-set-border... (still happening right now)
And countless other JS and CSS bugs I forgot I have in the codebase. There's scrolling bugs, navigation bugs, layout bugs, form bugs... I'm sorry to say but nothing really "fully works" it's always slightly off one way or another.
However, anecdotally I imagine there will be an uptick in sites using similars phrases — as following easing of Covid restrictions around the world even little brick and mortar stores will be making such welcoming statements on/across their homepages. :D
The first comment threads are all echoing derision of Safari as a janky browser but I feel that this is something that could be dissected 20 years later in a Raymond Chen-like blog [1] with how they had to painstakingly add a workaround in a newer version somewhere deep inside to make some questionable piece of software not crash or something.
Maybe “offers to” is a better way of saying this? The way this is being treated makes one thing that it goes ahead and fills in a user name without interaction. Instead it seems that login / password fields are being detected by the browser, which is expected behavior.
All the code reviews that passed this on to production make you wonder how competent these browser makers actually are..
I think that the browser should not treat every input field as a personal info form for the current user. There are plenty of cases of web apps I can think of where disabling autocomplete is best user experience overall.
For your amusement. Here's the code that was SUPPOSED to fix the bug: https://github.com/livewire/livewire/blob/0b3feda46a9dd6ad19...
https://github.com/livewire/livewire/blob/0b3feda46a9dd6ad19...
And here's the podcast I recorded a while back on what a pain it is: https://laravel-livewire.com/podcasts/ep65-safari-sucks-here...
Both "welcome back" and "Sign In" show the blue outline around the field and safari asks the user to select a username in the dropdown without actually filling the field. The user needs to actively click on the username for safari to fill the field.
I don't see how this is "bad behaviour". Seems like expected behaviour.
Personally I have this weird thing with Safari passwords - there's 2 sites where password dropdown would appear at top left corner for whatever reason.
It currently gives the _option_ to fill out the login info.
The title implies that it fills it automatically.
On the other hand I guess it must also happen on every page that mentions this bug.
I don't have safari so I can't try it out but, what if you wrote "bentornato"? Would it also trigger it?
Safari is in Finnish on my phone, and I used the phrase ”Tervetuloa takaisin” to test. For the other languages I used whatever Google Translate suggested.
(Though the real issue here seems to be field identification, not the auto-fill)
I miss netiquette and RTFM
Basically Chrome is just awful.
My work MacBook has Safari as the default, with Chrome and Firefox installed but often not running.
Chrome is such an abysmal memory hog, and slower, that I would also rather use Edge, and now that you've reminded me it exists, I might install it.
2. Battery
3. Performance