71–80 of 383 posts
Earlier quoted context omitted.
You still had a choice, nowadays being a Web Developer is almost a synonym for Chrome Developer and it was the IE hatting crowd that made it happen.
Except Chrome is still far below the user-base of IE in its heyday. And the most "valuable" users are all on mobile Safari. So it still makes sense to at least test with that.
Plenty of web sites aren't for international consumption.
Explanation from the 'rogue Chromium dev' is linked to in comment 19 of this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=914451... https://bugs.chromium.org/p/chromium/issues/detail?id=468153...
And here I was, all along, thinking that website authors were in control of how their websites behaved. How silly of me!
I guess this will lead to a horrible coding style where instead of having this in the form: We will see stuff like this: Where developers use some type of abstraction that generates a random id for each field and then assigns it to the original value server side or in javascript. Just like they already randomise asset filenames to avoid caching.
Earlier quoted context omitted.
You still had a choice, nowadays being a Web Developer is almost a synonym for Chrome Developer and it was the IE hatting crowd that made it happen.
You didn't have a choice. That was the whole problem!
And there was a choice, back then alternatives like Opera, did actually ship their own engine.
I guess this will lead to a horrible coding style where instead of having this in the form: We will see stuff like this: Where developers use some type of abstraction that generates a random id for each field and then assigns it to the original value server side or in javascript. Just like they already randomise asset filenames to avoid caching.
lol, years and years ago (like 2005) as an attempt at stopping XSS and CSRF attacks and bots I came up with a system that named all the inputs a salted MD5 of the intended name with the salt randomly generated then stored in the users server side session. It’s still a reasonably effective solution for CSRF, though there are much simpler options, but today’s bots largely have cookie jars so you will likely need a CAPT…
I do not get from where it comes that it is a rogue developer. I have worked in many companies where developers make mistakes. And, it is always the ways of working, giving more priority to features than quality, and similar cultural attributes of the company at fault. The only time I saw this being a rogue developer was a commit and run done by a guy on his last day. It is easy to blame one person when actually is a…
They are just doing their job, and in this case, acting in what they believe is best way for users. Here on HN, it seems most disagree, but that is still no reason to accuse someone of being rogue.
Headline should be "Google Chrome actively ignores HTML5 standard"
It's odd that the linked bug report references and complains about W3C specs when browser/HTML specs have been coming from WHATWG for well over ten years now. W3C has ceased publishing HTML with W3C HTML 5.2 in 2017, and has announced an intent to merely publish WHATWG snapshots going forward; so far, I'm not aware of any actual work under this model by W3C. But OTOH that Chromium interprets form field names heuristi…
Earlier quoted context omitted.
Ok, but how is that abuse? And if autocomplete=off is part of the html standard, how are the password managers spec compliant if they can't deal with it? Are people doing this just to annoy users who prefer password managers?
>Are people doing this just to annoy users who prefer password managers? People are doing it because they don't understand password managers, and think blocking them makes people more secure. They believe that if a password is in a manager, that password is less secure than if that password was purely in the user's head.
Yet the bank also doesn't want to take on security audits for code entirely outside their control.
I would love it if someone explained how 'autocomplete=off' can lead to abuse of some kind. It seems to reduce the potential for security leaks.
> It seems to reduce the potential for security leaks Misguided views like this are exactly how. Turning off autocomplete doesn't improve any sort of security, since the site already needs to trust the browser. It serves no purpose other than to frustrate the user, and might even reduce security if it prevents the user from easily making use of a password manager.
When chrome devs believe it is their role to alter ux, they are backseat driving.
Overall, I still believe that neither of the extreme strategies ("always honor autocomplete=off" Is it “extreme” now for a computer to do what the user wants and not what a random Google employee wants? How does this differ from malware?
People might not like the spec or it might be incomplete, but adhering to it is a very important part of improving it until it's a good one.
Now I'm no webdev, but I could very well imagine that the spec is already a good one. So the situation might be even worse.