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.
They also flagged up that users can access JavaScript and CSS files. Not the original source files mind you, nor is directory indexing enabled or anything like that. They pointed to our compiled and minified app.js and app.css, and suggested we block access to these files as the source code to the app is “sensitive information”.
Having to tell a client another company they’ve hired are absolute clowns, without making it seem like we’re trying to save our own skin, is certainly interesting.
The auditors are typically 10 to 15 years behind technical security expertise.
It's because it's in some dumb regulatory pentest manual or something. OK.
I still can't believe that whole business managed to interpret 2FA for whole EU as "you MUST use SMS for 2FA!".
We're actively harming the user experience (and driving paying customers away) because of some "expert" advice.
Weeeeeelll...
I'm familiar with two (2) common kinds of "2FA" implementations. TOTP and SMS.
Of those two, only SMS is actually a second factor, albeit not a particularly secure one. TOTP is fundamentally a password, and two passwords are no different than one password.
I agree this is probably product managers, but may also be engineers who have strongly held "security" opinions and nobody to check them.
But I fully agree with the disable-paste stuff. Very few (web-related) things get as annoying as that.
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.
Besides, you can encrypt the local storage with a master password (and if you accept online as a requirement, you could even add 2FA to that).
I believe moat browsers will use the system keyring (which is usually encrypted based on your login password or a tpm) if present or use a master password to encrypt them at rest.
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.
Even if you add `autocomplete="email"` to that field?
However, conceptually the right place to fix/configure this is the browser. So the correct long-term approach is to open a bug/feature request and get this properly addressed. Everything else is, well, -- a workaround.
(Again: I understand that the correct approach can take years, and it is unclear if it will succeed at all - so it may be impractical.)
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.
So it's not even those "corner case big boring CRM business apps" that had to find workarounds to forced-autocomplete, it's "real" user-facing ones too. Very frustrating.
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"> Conforming to the spec is not a virtue.
> When the spec is malicious, conforming to the spec is malicious behavior.
> I'm comfortable calling it a bug in the spec. `a << 40` needs to have 0 in the lowest 40 bits. It does not need to have random values in bits 8-31.
> This behavior is documented, but that doesn't make things better, it makes them worse.
> But the philosophy that says "if it's documented, then it's OK" doesn't even allow for the concept of a bug in the spec.
Implementing a bad idea doesn't become a good idea just because someone once wrote that it was.
I encountered quite a few myself and was very annoyed. I guess devs took the "usability" side of the question.
EDIT: phrasing
Well apparently it is, because they're doing it.
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!
The absolute worst are fields where paste is disabled, and the characters are also echoed as "*" so you can't even see what you are typing. I saw this with SSNs when I submitted some tax forms on my state's website recently.
The only argument I can think of for disabling paste (and I think it's pretty weak) is on a form to set a new password, where you need to input the password twice (and the form validates that they match) you might want to make the user actually type the same password twice, rather than let them copy/paste the first entry into the second field.
> 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.
javascript:void(document.documentElement.addEventListener(
'copy',e=>e.stopPropagation(),true),
document.documentElement.addEventListener(
'paste',e=>e.stopPropagation(),true))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.
The strictest, most standards-compliant browser in the world dies a quick death, every time. The most widely-used and popular browser play fast and loose with everything. If they're powerful enough, they retroactively get their fast-and-loose playing recognized as a standard.
It's not that web developers get a pass, but that browsers want to add complete features that help its users. They're dealing with the reality of the long tail of websites that exist and trying to make their users happy.
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.
The end result is that the web right now has stuff that works only on Chrome and stuff that works everywhere besides Safari.
And the fact that iOS users can't change their browser forces developers that want their projects to reach the maximum amount of users to have Safari as a baseline instead of the current standard, making Safari a de facto standard.
So yeah, I think that both are the new IE, just in different stages of the life of IE.
In terms of market share and market power yes it's comparable, in term of tech issues, not really no, it's not even close. Chrome has a very good rendering engine, there's a few quirks here and there, I might have encountered some strange logic once or twice but that's about it.
Safari on the other hand is really comparable in terms of tech issues and the main problem is that you can't even tell people to upgrade on iOS since they are stuck with it.
Supporting multiple browsers is a uniquely annoying aspect of web development, and almost every developer uses Chrome for development (I’m a Safari user and it’s kind of a running gag at work). This means that for most developers, Safari is the main browser they have to support that isn’t the one they use for development, which is a recipe for resentment.
Also, I bristle at this comparison a bit because Safari is wayyyyy better than IE ever was about adopting (and helping to draft) standards. They’re slower than the Chrome team and adopting new standards, but that’s because Alphabet and Apple’s business models are different, not because it’s an inherently good idea to adopt every new standard immediately (especially when many are focused on turning the web into a crappy replacement for native app platforms).
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.
- SVG background issue from 2016. Tested on my Safari Tech Preview 113 (Sep 2020), can't replicate.
- Clicking issue. This is related to mouse event bubbling on iOS only (will affect both Safari and Chrome since they both use the same WebView). It's theorised that Apple set a specific set of rules when mouse events (on touch devices) will bubble up for performance/usability. Or it's just a bug.
- A rendering issue from 2012. It's explained in your link this is related to pre iOS 7 era performance improvement by WebKit to only redraw those parts of an image that have changed. Sounds like a very reasonable thing to do, taking into account how Apple heavily pushed performance and battery savings on mobile/laptop devices a decade ago.
- Round Corners. Tested on my Safari Tech Preview 113 (Sep 2020), can't replicate.
I don't see how any of these are anywhere close to being "total nonsense", feels like you're being biased and just exaggerating on purpose to bash Safari.
Chrome force logging in you when you use Gmail to hijack your privacy and link your browser history to an account sounds more "nonsense" than Apple focusing on performance/battery on mobile devices a decade ago that created a regression/new bug that requires 1 line to solve. https://news.ycombinator.com/item?id=17942252
I primarily use Safari for privacy/battery/performance reasons, and on my web app of 2 years with tons of styling I have 5 lines of scss code with "// safari" comment to make some elements render the same as Chrome.
Never in my career writing a single digit line of additional css made me think "oh my god this is total nonsense". Everyone has to accept there will be differences from one browser engine to another, and from my personal experience, these are minimal and nowhere near IE6 back in the days.
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.
I don't get it?
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.
Then again Finnish has anyway been a second class citizen when it comes to iOS features.
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