Live data from Hacker News

Chrome is Not the Standard

chriskrycho.com

281–290 of 465 posts

Re: Chrome is Not the Standard

#281
"Safari ships new features on a much slower cadence, but they’re usually solid and always perform incredibly well" - Also came with a torch and pitchfork to say that this is the most wrong statement ever. Flex is still barely supported. Transforms that are mixed together still cause the pages to flicker and screw up.

Safari is a joke. The development experience is a joke. I wish it would just disappear.

Re: Chrome is Not the Standard

#282

Earlier quoted context omitted.

Yeah, they use Blink which is a fork of WebKit and open source as well. So I guess it is great, isn't it?

You missed the point. Your position is that there should be only one browser engine. But you're trying to use two browser engines, which are very different, to support your argument.

No, you missed the points. My major point was that we have the source code and nothing changes that. My second point was that I would rather all browser engines work the same and if they can’t then I’d rather just have one popular browser engine.

Re: Chrome is Not the Standard

#283
post #179

Earlier quoted context omitted.

Mozilla is fighting an uphill battle, but that doesn't give them a free pass. The Pocket, Cliqz, and Mr. Robot controversies undermine Mozilla's core message. Whether or not they are simply failures of marketing and branding doesn't change the fact that they hurt the company. That being said, a lot of people will never know about these issues so the damage is not catastrophic. I would also argue that "just being bett…

Am I the only one looking at this and thinking that the so-called controversies are absurdly tame in comparison with the outcry associated with them? They're missteps, not trust breakers. Quantum was a massive step in the right direction. The Mr. Robot Easter Egg was non-malicious poor execution. I don't think it's a free pass to just contextualize how small their missteps have been in the grand scheme of things.

Despite the non-maliciousness of the easter egg, I do think the act of just installing an extension into a browser could be viewed as a trust-breaker. I think the other "controversies" are overblown, but them remotely installing an extension like that doesn't sit right with me.

Re: Chrome is Not the Standard

#284
post #139

Earlier quoted context omitted.

Not all incentives are direct financial incentives. It's free marketing. It increases market penetration. It encourages people who only use Chrome to try Firefox. It was absolutely the wrong thing to do, but it's not like they stood nothing to gain from it.

Is this based on any fact or is it hyperbole?

I don't thing that word means what you think it means.

Re: Chrome is Not the Standard

#285
It's interesting that the author chose PWA's as their example.

The "Progressive" in Progressive Web Application means that web sites progressively become more app-like as they use certain APIs like Service Workers, but it also means that PWAs progressively become more app-like on browsers that support those APIs.

A site can go all-in on the PWA-related APIs and cause absolutely no degradation in experience on browsers like Safari. Safari doesn't support Service Workers, ignores parts of the manifest, doesn't allow PWA installation? It's fine, your app is just a normal website on Safari.

Re: Chrome is Not the Standard

#286

Earlier quoted context omitted.

You missed the point. Your position is that there should be only one browser engine. But you're trying to use two browser engines, which are very different, to support your argument.

No, you missed the points. My major point was that we have the source code and nothing changes that. My second point was that I would rather all browser engines work the same and if they can’t then I’d rather just have one popular browser engine.

> My second point was that I would rather all browser engines work the same and if they can’t then I’d rather just have one popular browser engine.

Would you be willing to give up, for example, Rust's parallelism and security for that future?

Why do you think this would work better than it did in the past, when Google and Apple tried to collaborate on the same engine and it ended in a fork?

Re: Chrome is Not the Standard

#287
post #188

Chrome just screwed the pooch, at least for me... blocking .dev domains ended my use. I'm not going to setup ssl on all my development environments for all the sites I have. I'll just dev in firefox, and move to firefox completely.

According to this recent post Google is in charge of the master list that all the other browsers use. Expect the .dev domains to stop working on those other browsers shortly. https://medium.engineering/use-a-dev-domain-not-anymore-9521...

I'm the tech lead of Google Registry and the reason our TLDs ended up on that list, and I'd like to add a clarification here.

Google isn't "in charge of" the HSTS preload list per se. The owner of each individual website is in charge of whether or not they are on the list. It is true that the Chrome team happens to manage the list, but the contents of the list wouldn't be any different were it to be managed by anyone else who operated it under the same principle.

We, the Google Registry, the group that operates the TLDs that Google owns, have decided to start putting our private, closed, and not-yet-launched TLDs on the HSTS preload list. We can and would be doing this regardless of whether the list were managed by Chrome, Mozilaa, Microsoft, Apple, etc. More information on our motivations for doing so can be found here: https://security.googleblog.com/2017/09/broadening-hsts-to-s...

Re: Chrome is Not the Standard

#288
post #4

I know they screwed up recently with the Mr. Robot malware, but I think it's really important for developers to get behind Firefox again. As the American government fails to provide any sort of check on its behemoth corporations (Apple, Google, and Microsoft) and to protect consumer privacy, Firefox is basically the last contender for real consumer protection standing.

Please tell me how Safari or Apple in general works against consumer privacy protection? This is yet again a too-simplistic view of things that seems very common with Americans. Some big companies do unethical things, and you translate that to "all big companies hate consumers and want to eat their children"

Safari is nonfree software. The reasonable objection for software has nothing to do with corporations (despite that corporate power is too great and obviously hurts people). Users, no matter how willing or capable, aren't allowed to inspect what Safari does, not allowed to modify Safari to suit their needs, or share copies of Safari (modified or not) with others. This removes users' ability to help themselves or their community. All of these things are harmful in themselves not only for privacy protection but for self-determination and full control over one's own computer, something every computer user deserves.

This lack of respect for a user's freedom makes Firefox objectively different and superior to Safari or any other nonfree browser. With Safari we can only guess if it's doing something to not protect a user's privacy whether on-accident, as all complex programs have bugs, or on-purpose. With Firefox we don't have to guess. We are allowed to verify what Firefox does and show what problems Firefox has, fix Firefox's problems, and make Firefox protect one's privacy. Firefox users can even disagree about precisely how to implement that protection and each user can choose how to do that for themselves in the way they find appropriate.

Firefox being free software means we don't have to trust Mozilla's reputation. But since Safari is nonfree software we never really know if it is trustworthy until someone discovers it wasn't and we have only Apple's reputation to go on. There are many reasons to avoid doing business with Apple (see https://stallman.org/apple.html for a list) and Apple has a reputation for distributing malware (as https://www.gnu.org/proprietary/malware-apple.html gets into). One particular remotely exploitable problem with iTunes persisted for years and only Apple had permission to fix the problem because iTunes, like Safari, is nonfree (see http://www.telegraph.co.uk/technology/apple/8912714/Apple-iT... for details). I can't be sure what state Safari is in or was in in past versions. That lack of information, combined with no good reason to trust software proprietors in general or Apple in particular, leads me to conclude that one should not trust Safari. A wiser way to protect one's privacy is to run a free software browser such as Firefox with no nonfree plugins/add-ons installed, on top of a completely free software system. This way the user has more control over their system and it's up to the user to determine whether and how to use that respect for their software freedom.

Re: Chrome is Not the Standard

#289

It's interesting that the author chose PWA's as their example. The "Progressive" in Progressive Web Application means that web sites progressively become more app-like as they use certain APIs like Service Workers, but it also means that PWAs progressively become more app-like on browsers that support those APIs. A site can go all-in on the PWA-related APIs and cause absolutely no degradation in experience on browser…

Yep, and this is one reason I like the PWA design a lot. It's very web-y in the best ways.

Which is part of why the "Safari is holding back the web b/c no PWA!" response perplexes me. Even independent of the fact that they were in fact getting there – just not as fast as people wanted! – progressive enhancement is still a thing.

Re: Chrome is Not the Standard

#290

Earlier quoted context omitted.

I’ve found a lot of people are quite naively idealistic around browser development. The rendering, JS engines in Firefox and Chrome are state-of-the-art and take small armies to build and maintain. Mozilla has to strike a balance between revenue seeking and consumer protection seeking behavior that I would imagine is quite difficult to maintain. Lots of people here additionally are up in arms their incredibly specifi…

> Lots of people here additionally are up in arms their incredibly specific workflow was upheaveled by a movement to webextensions planned like 2 years in advance. Maybe their incredibly specific workflow involves a piece of multi-million dollar equipment and updating to a new API involves reflashing its firmware for some crazy reason. (alternately, 100 $200 pieces of equipment in hard-to-reach places that must be ma…

Perhaps a multi-million dollar piece of equipment shouldn't depend on a third party to maintain legacy protocols. If such R&D could be put into an embedded device, then a little bit of R&D could be put into a proper REST interface so that it could be properly maintained in the future.
Post reply on HN