Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome breaks the Web

tonsky.me

Post reply on HN
Print view View original

401–410 of 473 posts

Re: Chrome breaks the Web

#401

Post by another-dave »

Tyr42 wrote: post #358
pas wrote: post #290

Earlier quoted context omitted.

Users don't use thousands of sites. If a site misbehaves and users want autofill on it, they should be able to override autocomplete=off for that site. Google could even make an extension for this to allow users to gather and share a list of sites that behave in a user unfriendly way. But of course, it was much easier to fuck up half of the Web. Public choice and mandates are great for things that require cooperation…

> If a site misbehaves and users want autofill on it, they should be able to override autocomplete=off for that site. How? What do you imagine?

This website has turned off auto-complete, as they believe it may not work effectively for their forms.

* Turn on anyway * Leave disabled for this form

= Remember my choice for this website

Re: Chrome breaks the Web

#402

Post by walterstucco »

013a wrote: post #374
walterstucco wrote: post #370

Earlier quoted context omitted.

developers cannot opt-in

They also can't opt-in to adblock or noscript or me choosing to run Netscape version 4. Developers fundamentally do not get a say on what I choose to run on my system; at best the only control they have is saying "nope we aren't even going to try to run on whatever you've got" but even that isn't a guarantee.

> They also can't opt-in to adblock or noscript or me choosing to run Netscape version 4.

This is a gross oversimplifcation

They also cannot opt-in if you don't have electricity in your house or don't own a computer

DOH!

This is not a real argument

A real argument is obsolescence

Of course there's a point when older versions are not supported anymore

Here we are talking about future versions breaking compatibility, without a shared consent, without a deprecation roadmap, that need to be supported, in a Chrome specific way, making Chrome the new IE for no real benefits to the user and a vendor lock-in by Google

When they users will try a different browser, for whatever reason, they will experience a different web, that for the majority of them being non techy will look like a broken web

Re: Chrome breaks the Web

#403

Post by will_hughes »

desas wrote: post #394
techdragon wrote: post #355

Earlier quoted context omitted.

How about an Administration interface that allows you to set a password to a known value for the user to use so they can log back into their account. So the helpful support person can now go "Your password is now 'foobar' and you will be asked to pick a new one when you login."

That doesn't sound like a safe way of resetting passwords. You should supply them a token they can use to set their own password. Your employees should not know your users passwords.

The token is the new one-time password that must be reset upon login.

Re: Chrome breaks the Web

#404

Post by ben_w »

jrockway wrote: post #399
techdragon wrote: post #355

Earlier quoted context omitted.

How about an Administration interface that allows you to set a password to a known value for the user to use so they can log back into their account. So the helpful support person can now go "Your password is now 'foobar' and you will be asked to pick a new one when you login."

Why would you use input type=password for that?

Because it is, in fact, a password.

Re: Chrome breaks the Web

#405

Post by ivanhoe »

michaelmrose wrote: post #253
ivanhoe wrote: post #148

Earlier quoted context omitted.

There are valid arguments for both sides, but instead of forcing this upon everyone, Chrome team could have added it as a config option. Set the defaults for autocomplete anyway you like, and then let the user change the behaviour only on some sites. Or if you don't wish to pollute the settings with this, extract this behaviour into an extension and let the people choose if it bothers them enough to go and install it…

Either googles solution is better or its not. If it is then google should make it the default even if it provides an option. Then even if they provide the option 99.999% will use the default rendering the option basically worthless. If its not they should probably just work how everyone else works.

If you use that approach on everything then you admittedly get clean and easy to understand configuration, but you also reduce the usefulness of your app and make some of your regular users very unhappy... I stopped using Ubuntu recently for exactly that reason, too many options were cut and hidden away from GUI, and just defaults enforced on you, to the point that Windows Explorer is now far more powerful and customizable tool than Nautilus.

Re: Chrome breaks the Web

#406

Post by TJSomething »

bshacklett wrote: post #389
briandear wrote: post #361

Earlier quoted context omitted.

I have a site that deals with HIPPA protected information. I absolutely don’t want autofill, especially for sign in information. Chrome makes that impossible and just ignores the code.

Could you explain the downside of allowing auto-fill for sign-in information here? I understand that security is a concern, but I don't see how allowing a password manager to handle sign-ins would be harmful.

In a medical setting, most computers are public. Sharing passwords is a HIPAA violation, because HIPAA requires a complete, accurate log of everyone who has looked at or modified a medical record.

My guess is that many medical computers aren't well administrated and leave autofill on, which can easily cause accidental HIPAA violations.

Re: Chrome breaks the Web

#407

Post by jhasse »

jarym wrote: post #367
jhasse wrote: post #341

Earlier quoted context omitted.

Why not? The user knows that the browser remembers field inputs, he wouldnt expect it to be different for your website. So if he really wanted the browser not to remember anything he typed in, he would use private mode or clear his recent history afterwards. Because then there's the teacher who has to put in medical data for a whole class where everyone got the flu. The teacher is happy the browser does it job like a…

'Why not?' you ask? Let's look at HIPAA for starters: https://www.quora.com/Do-current-HIPAA-rules-require-publicl... "In summary, HIPAA does not specifically limit the use of drop down menus or auto-complete, but if patient information was exposed to the public through these features your business would have failed to control access to the protected health information." So now there's a risk that if a user of a medi…

You shouldn't enforce anything, since you can't really anyway: The shared computer might record the screen or have a key-logger installed.

Re: Chrome breaks the Web

#408

Post by ric2b »

notjoemama wrote: post #242
saas_co_de wrote: post #84

Earlier quoted context omitted.

> does assumption on how things "should" be (in a highly subjective way) They claim they are making these decisions based on user data which I have no reason to doubt. > and breaks the web. Breaks crap websites that are broken already from performance and usability perspective. I personally think this is exactly what is needed to make the web better as a whole. Individual developers working for individual companies a…

Woah woah woah. Let me recount/nutshell the crux of conversations I've had with my product manager(s) about things like this. Me: Hey, I'd like to add a work-item to our current sprint that reworks semantic attributes into our site. Them: What would that do? Me: It improves the underlying architecture making the markup more usable and extensible. Them: How does that benefit the users? Me: Over time it will reduce the…

Try to make those requests via e-mail, so you have something to show when it breaks or becomes hard to maintain.

Re: Chrome breaks the Web

#409

Post by jarym »

jhasse wrote: post #407
jarym wrote: post #367

Earlier quoted context omitted.

'Why not?' you ask? Let's look at HIPAA for starters: https://www.quora.com/Do-current-HIPAA-rules-require-publicl... "In summary, HIPAA does not specifically limit the use of drop down menus or auto-complete, but if patient information was exposed to the public through these features your business would have failed to control access to the protected health information." So now there's a risk that if a user of a medi…

You shouldn't enforce anything, since you can't really anyway: The shared computer might record the screen or have a key-logger installed.

Well then let's just throw away any kind of data entry then since any computer might have a key logger installed.... sigh

Re: Chrome breaks the Web

#410

Post by sdoering »

will_hughes wrote: post #403
desas wrote: post #394

Earlier quoted context omitted.

That doesn't sound like a safe way of resetting passwords. You should supply them a token they can use to set their own password. Your employees should not know your users passwords.

The token is the new one-time password that must be reset upon login.

Exactly that. I use this feature as an Admin relatively often in Adobe Analytics. I never am able to know the "real" password a user provides on first login after reset.

A one time password is nothing but a token - maybe not ideally named.

Post reply on HN