171–180 of 356 posts
Earlier quoted context omitted.
The point is that Google can't dictate what browser behavior the forks ('clones') choose to enable.
The point is they can make the forks useless, unless sufficiently many users choose to use forks, which isn't a very likely scenario.
Earlier quoted context omitted.
You fail to mention that IE was closed source while Chromium is open source. That's a completely different situation. We already have a number of Chromium based browsers that go against some of Google's most fundamental interests (e.g Brave).
That's exactly where F/OSS has failed us big time. Just because it's "open source" doesn't mean browsers have to aggregate to whole operating systems. There was once this idea, you know, of exchanging documents and links via TCP/IP, and it was good. Then came platforms and browser wars, and the piece of crap that is JS and CSS along with them. In the end our only way out of this is to start over with a decentralized/…
We don't have to speculate, we've been through this already during the IE4 to IE6 era. Microsoft just did whatever they wanted with the web "platform", and so will Google. In Microsoft's case what they wanted was nothing . They weren't a web business, saw it as a threat to their platform leverage, and so just left it abandoned and stagnant for years. Google is simultaneously better and worse: they won't leave it stag…
You fail to mention that IE was closed source while Chromium is open source. That's a completely different situation. We already have a number of Chromium based browsers that go against some of Google's most fundamental interests (e.g Brave).
Earlier quoted context omitted.
> The only reason they disallow Chromium and Mozilla is they want their users locked into their environment and they want to leverage that substantial locked-in user base to dictate terms That's one reason, but not the only reason. Security is another big one in that the WebKit process is running with privileges that Apple does not want to award to any other app process on the platform, much less a third-party one. T…
"Security is another big one in that the WebKit process is running with privileges that Apple does not want to award to any other app process on the platform, much less a third-party one." If they really cared about security then they could subject their browser to an independent security audit, and require the same audit be passed for any other browser that's allowed on their platform. Why don't they do this?
As it stands now, WebKit and the processes hosting it (Safari, WKWebView) are probably the most complex piece of software running on our iOS devices and as we can see, they are full of security flaws.
But so are the engines of all other browser makers.
Audits is not what uncovers security flaws. Detailed research, fuzzing and effectively unlimited time to do both on the side of white-hat hackers and unlimited budget and criminal energy on the side of black-hats is what does.
Same is true for other engines of course.
But being restricted to a single engine shipped and updated as part of the OS with tailor-made support by the OS for sandboxing and JIT restrictions for this one engine does help to reduce attack surface.
Also, my initial concern isn't as much about third parties shipping their browsers (though, consider how many third party browsers exist and how many are well-maintained), but much more about apps embedding a vulnerable version of an engine and never updating it ("it works fine for us - no need to change a running system")
Earlier quoted context omitted.
"Security is another big one in that the WebKit process is running with privileges that Apple does not want to award to any other app process on the platform, much less a third-party one." If they really cared about security then they could subject their browser to an independent security audit, and require the same audit be passed for any other browser that's allowed on their platform. Why don't they do this?
I don't think an audit will be able to even coming close to validate the security of a piece of software with the complexity of a browser. As it stands now, WebKit and the processes hosting it (Safari, WKWebView) are probably the most complex piece of software running on our iOS devices and as we can see, they are full of security flaws. But so are the engines of all other browser makers. Audits is not what uncovers…
Audits aren't supposed to be an ultimate guarantee of security, but provide a minimum, independently judged hurdle that has to be passed to get on the platform.
If there's a better, independent way to judge what browsers are "secure enough" to be on the platform (ie. not just "Apple says no"), I'd love to hear about it.
We don't have to speculate, we've been through this already during the IE4 to IE6 era. Microsoft just did whatever they wanted with the web "platform", and so will Google. In Microsoft's case what they wanted was nothing . They weren't a web business, saw it as a threat to their platform leverage, and so just left it abandoned and stagnant for years. Google is simultaneously better and worse: they won't leave it stag…
Personally, I think Google already does whatever it wants similar to what Microsoft did. They do offer standards for discussion but it will implemented and expect other vendors to follow suit.
Where things went off the rails was the things Microsoft refused to implement due to their monopoly position. They had a binary component architecture, but it wasn't sufficient to run Java. They had Java, but it was a vestigial and crippled version. Their HTML/CSS engine was just "odd", incompatible not only with emerging standards but with any published standard at all.
Basically "the problem" with IE wasn't that Microsoft "did whatever it wants", it was that it did (or didn't do) very specific things intended to prevent users from wanting to use IE at all, in a vain attempt to favor desktop applications or IE-specific implementations.
Earlier quoted context omitted.
The problem is that Google controls both the overwhelmingly dominant browser and the standard. MSIE was bypassed not by a code fork of MSIE (itself originally based on the Spyglass browser, which was a fork of the NSCA's Mosaic codebase), but by independent implementations of an HTML-standard parser . Microsoft had some influence over Web development (noteably through ActiveX) but far less than Google has now. My poi…
>My point is that Open Source of itself is not sufficient And I didn't claim that it was. My point was merely that Chromium being open source changes the equation pretty fundamentally compared to the IE situation. Whether it's enough to make a Chromium monopoly consistent with an open web, I really don't know. There are very good reasons to be sceptical.
So you’re not claiming open source is sufficient but you are seemingly defending it is a better situation.
While I and some other commenters are signaling we don’t think the situation is better.
To me the fundamental part of the equation is outsized power and influence. Being open source or not is part of the equation, but not as close to as fundamental as the core issues with this. This is made much much worse now than 20 years ago with the costs to get your own browser going so much higher. Which leads back to the outsized power being the fundamental issue.
Open source can even be argued to be a benefit to Google retaining power. Having enough attention diverted to the possibilities of open source when Google has only monumentally gained from open source with paltry benefits that are usually brought up as defenses against its power. Like AOSP mattering because China doesn’t use Google’s Android and some other irrelevant projects.
Any fundamental differences so far are giving Google and any other major central powers more power.
Earlier quoted context omitted.
https://blog.pwabuilder.com/posts/publish-your-pwa-to-the-io... > While WebKit is making progress on PWA support, at the time of this writing, PWAs remain a second-class citizen on iOS. The iOS App Store’s support for PWAs is non-existent, requiring a web view-based solution like PWABuilder’s. > Additionally, because iOS doesn’t allow 3rd party browser engines, your PWA is limited to WebKit’s PWA capabilities, which…
I can take a mobile web site, wrap it in a browser component and publish it to the App Store. Now I will lose one of the advantages of PWA e.g. remote updates but everything else I can do e.g. push notifications, access device APIs. This has been available for close to a decade. Guess what. Users hate it. They hate mobile web apps and their slow, clunky, feature-poor, non-native interfaces and for that reason they wi…
Earlier quoted context omitted.
It's like confusing "open-source" Android, AOSP and Play Services: https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on... >While Android is open, it's more of a "look but don't touch" kind of open. You're allowed to contribute to Android and allowed to use it for little hobbies, but in nearly every area, the deck is stacked against anyone trying to use Android without Google's blessing. The second you try to…
The difference is, AOSP on its own is unusable, but Chromium Is.
Earlier quoted context omitted.
I don't think an audit will be able to even coming close to validate the security of a piece of software with the complexity of a browser. As it stands now, WebKit and the processes hosting it (Safari, WKWebView) are probably the most complex piece of software running on our iOS devices and as we can see, they are full of security flaws. But so are the engines of all other browser makers. Audits is not what uncovers…
"Audits is not what uncovers security flaws. Detailed research, fuzzing and effectively unlimited time to do both on the side of white-hat hackers and unlimited budget and criminal energy on the side of black-hats is what does." Audits aren't supposed to be an ultimate guarantee of security, but provide a minimum, independently judged hurdle that has to be passed to get on the platform. If there's a better, independe…