Hacker News new | ask | show | jobs
by Osyris 871 days ago
I don't understand why. I thought users will just see a list of options upfront instead of having to install them and select one later.

This seems like more of an awareness thing than an actual change in functionality.

1 comments

They probably just saw the title of the article and assumed that it was talking about allowing alternate browser engines on iOS.

Can’t blame them, the title is rather misleading. I originally thought the same thing until I read the actual article.

The article in this context of additional browser engines being allowed.

I do however recognize web developers looking forward to just saying “you must use chrome”, just as they spent decades saying you have to use IE.

I've been working on a small side project and I can totally sympathise with this. Chrome has 2 features right now, and has had them for more than a year, that Firefox hasn't yet implemented. One of those is the new navigation API. There's a polyfill but it's complex and can't 100% fill the gap.

I don't want to rely on blink browsers only but when you look at being able to implement a feature in 3 lines Vs many or not at all then...

Yeah, but you can also point to features in Safari or Firefox that chrome doesn't have (weirdly often CSS features?) and make the same argument.

But if you say "only supporting chrome is the easiest option" you're also saying "I want to force my users to use the browser with the least privacy protection made by one of the biggest advertising companies on the planet with a long history of gross privacy violations".

There are also a number of features the google has put into chrome that Firefox and WebKit don't support because they have severe privacy issues. Because if a spec compromises user privacy that's a deal breaker for every engine other than chrome, because chrome's privacy model is "the bare minimum possible".

Google is literally only just talking about blocking third party cookies in chrome this year, despite that being the default behaviour of webkit from day 1. To try and divert attention from chrome intentionally disabling that privacy feature until now (because they've now got sufficient work arounds for third party cookie blocking) they're using the same terminology ("tracking protection" or some such) to describe re-enabling a basic privacy feature as Firefox and Safari use for the various technologies that protect against google's work arounds for third party cookie blocking.

If you say "I only want to support chrome" that means you're also saying "I don't care about user privacy".

Well for my example what I want to support is me to begin with, which means Brave, which just so happens to use the same engine as Chrome. Which is helpful because most folks use Chrome. I might not like that, but that is the way of things.

If I had paying customers then I would likely support Firefox. But I don't think you can appeal to companies to do so on moral grounds, which is what most of the comments appear to be saying. If the cost of compatibility is more than the benefit then it won't happen. The only moral appeal you can make is to the end users: use Firefox, it has these benefits over other browsers. Then once that happens compatible support is a no-brainer for devs.

But that hasn't happened. You can get user privacy with the blink engine with various browsers. You can argue that X isn't as good as Y in this area, but honestly, Mozilla hasn't had a great track record either, and imo they've been a very poor steward for Firefox in recent years. I used Firefox from when it was named Phoenix until around 2020 but now I feel pretty meh about it.

But see that's exactly the point. It's much easier for developers to support the majority browser, and that's what they do. MS did lots of shitty things to ensure that once IE was the majority browser it stayed there, but no one seems to remember that it was in the IE4+5 era a faster and more capable browser than netscape. It was only once they got there, and once people started making IE only sites that they were able to then leverage that position to ensure they remained there.

Saying you can use non-chrome versions of blink is entirely moot: if every site requires and is only tested in chrome, then privacy filters in literally every non-chrome engine or blink wrapper is moot because sites will break (cynically I'd guess first breakage would be blink based engines - or UA strings - on google sites). Saying "they're the same engine so they're equivalent" is nonsense. If you use a privacy-preserving blink wrapper then it's disabling a bunch of the chrome-only features that webkit and gecko don't implement, and it's blocking a bunch of tracking mechanisms that chrome uses to support google's revenue. Both restrictions in a non-chrome blink wrapper will cause sites to fail, and we know this is the case because there are already sites that fail in safari and Firefox due to those privacy protections, even though developers know there's a major (? still not sure if this is actually true in the EU) platform where testing a non-chrome browser should be required.

A very small proportion of websites/webapps actually need those new features though (or should anyway..)
My site doesn't need either of these features. What they've implemented are nice APIs for things developers were previously doing with much more overhead. If you're making something by yourself and only have a small number of users right now then those times saving shortcuts are incredibly helpful.

If someone came to me and said they want to use it but it doesn't work in Firefox then I'd... think about it. Hasn't happened yet.

> They probably just saw the title of the article and assumed that it was talking about allowing alternate browser engines on iOS.

there was an article posted yesterday that claimed that they would be forced to do just that.