Live data from Hacker News

Chrome breaks the Web

tonsky.me

441–450 of 473 posts

Re: Chrome breaks the Web

#441

Earlier quoted context omitted.

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.

Disabling autofill seems like the wrong way to handle the problem, though. Autofill does not necessarily mean that passwords are being shared; it just means that the user isn't typing them in. Strong policies on the machines in question and ensuring that users aren't sharing each others environments seems like a considerably more complete solution to me. This can be facilitated by tools like https://www.imprivata.com/single-sign-on-sso. Ironically enough, disabling autofill may actually prevent this tool from providing some of the benefits it's intended to provide.

Re: Chrome breaks the Web

#442
post #10

> Turned out, Google wasn’t concerned about your websites at all. It was more concerned about its own product performance, Google Chrome Mobile. As a web developer, I see this attitude a lot and it annoys me immensely. Another way of phrasing it: Google is putting users first, ahead of developers. This is as it should be. "your" website exists to serve users, if you're doing a bad job at it then maybe it's an opportu…

No, it's not to serve users. Users don't want broken webpages either. It's to make their own browser look faster at the expense of webpage authors. Because users will blame webpage authors for their webpage being broken. Would they know that they could have this same page unbroken with slightly worse performance, no one would choose the better performance.

Sure, there's something to be said about webpage authors getting off their butts quicker, if their webpage is actually broken, rather than just not quite as fast as it could be, but the majority of webpages are not actively maintained. Chrome is simply breaking those. With only 8 months of a transitional period, there's no two sides to this argument. What they've done is unresponsible in every way.

Re: Chrome breaks the Web

#443

Earlier quoted context omitted.

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.

Disabling autofill seems like the wrong way to handle the problem, though. Autofill does not necessarily mean that passwords are being shared; it just means that the user isn't typing them in. Strong policies on the machines in question and ensuring that users aren't sharing each others environments seems like a considerably more complete solution to me. This can be facilitated by tools like https://www.imprivata.com…

While I agree that autofill on its own is not a complete solution to GP's scenario, it's certainly a potential point-of-failure, and I understand their need to eliminate as much risk as possible. While the most significant aspect to be improved is the security habits of the clients themselves, that doesn't mean that GP and their company should be prevented from doing what little they can just because Google wanted things to work their way.

Re: Chrome breaks the Web

#444

Reading the comments here make me feel Chrome is like Uber. They may be right in that the standards are outdated and force change. Yet, it breaks all rules and regulations which they shrug off saying the rules have to change. Again, this is not a comment to choose sides. Just an observation. As with Uber I can’t say if I’m in favor or against. By law, they are wrong. In time, it may turn out they have led change. Fun…

Reading the comments here makes me feel like Google's PR team made its round.

The performance benefit in this has to be miniscule, the number of unmaintained webpages which are irrevocably broken by this has to be huge and the time period from introducing this feature to breaking webpages, which have not yet correctly implemented it, was simply far too short.

Even if you agree with having to enforce this somehow, this rushed execution of that was by all means irresponsible.

Despite that, it seems like 8 out of 10 highly upvoted comments here make no mention of this maybe not having been ideally executed or it maybe not necesseralily being advantageous to users either.

Re: Chrome breaks the Web

#445

I agree with everyone else that this change is for the better. What will we do when they decide to make a change that isn't?

Make up even more ridiculous excuses for why this is clearly for the better of all of us and could not have been handled better.

Re: Chrome breaks the Web

#446
post #89

Earlier quoted context omitted.

You don't necessarily have to convince IT. If you instead convince their legal department that by not following the NIST standards for passwords they are opening their company to a lawsuit, that could get results a lot faster. When IT is convinced they have to decide when to put it into the budget. If they think their policy is not okay, just not perfect the fix will probably be buried in the bottom of the budget pil…

Do you have any references to instances where this strategy was successful?

No, it is an idea. The NIST standard is new enough that I wouldn't expect anything yet. Going to court takes years.IF they settle out of court they probably make not talking a part of the settlement.

Re: Chrome breaks the Web

#447
post #112

Earlier quoted context omitted.

Not all websites are operated by US companies. Would that still work for, say UBS (a big bank) in Switzerland?

NIST is recognized worldwide in a similar vein to the IEEE, IETF or ISO. It's a regulation organization important enough to get to move banks, large companies and outsourcing firms. A recommendation won't allow you to sue a company contrary to what the other commenters seem to think, but it's enough for any internal employee who works on something to call for and justify a change.

You can sue anyone for anything. Winning is different matter. Even if you can't win though, the cost of defending a trial is expensive.

Re: Chrome breaks the Web

#448
post #359

Earlier quoted context omitted.

Choosing to use Chrome is also opt-in. Its the same concept. Its not ideal , but it is what it is.

I believe Chrome on mobile is the default (only?) browser. So it is opt-out, and a very painful opt-out that requires technical knowledge. You ship an experience like that, you end up not only breaking old websites but shift the emphasis on regularly updated websites that work on mobile. That was the intent! But it is not the web we know and love.

> I believe Chrome on mobile is the default (only?) browser.

It's default on a lot of Android phones, but far from the only one available. I use Firefox on mine. Opting to use a non-Chrome browser on an Android phone is about as technical as using a non-Microsoft browser under Windows.

Re: Chrome breaks the Web

#449

Earlier quoted context omitted.

this is such an obvious use case, they basically threw a ton of web-apps/crms under the bus.

While I dislike this behavior of chrome, you should never be able to set a users password.

It is arrogant to assume this is true of every single use case.

Re: Chrome breaks the Web

#450

Earlier quoted context omitted.

You never use or benefit from any web apps that take advantage of javascript?

I almost never use web apps that couldn't be done without JavaScript.

I'm with you.

A UI markup language could define forms that are "desktop-like" without involving a Turing complete language.

The paradigm of the HTML form with controls and a submit action has not been developed to its full potential, because it was basically derailed by JS.

It could have a lot more widgets, and there could be some standard way they exchange and validate data, without a full-blown client-side programming language.

For instance, say you want the user to pick a date. There could be a standard widget in HTML for doing that that could be dropped into a form, and it could be configured to communicate its value bi-directionally with some other field. (Perhaps like cells in a spreadsheet or that sort of reactive thing.) A rich set of standard widgets with flexible styling and layout, communicating the content of the data model to and from the server. Something like that.

Post reply on HN