Comment by drewcrawford | Hacker News Reader

Comment by drewcrawford | Hacker News Reader

Parent Full thread

What if I told you there was a valid technical reason not to allow alternate browsers on iOS?

If you're on a Mac, paste this into Terminal:

    find /Applications/ -perm +111 -type f |while read fname; do otool -L "$fname" | grep WebKit && echo "$fname"; done

With those results in mind (500 binaries for me, if you're not in the habit of blindly pasting things into terminal), ask yourself the following questions:

1. What percentage of these vendors do I trust to rapidly respond to zero-day attacks in their embedded browsing engine?

2. What percentage of these applications have I updated in the last year?

3. What percentage of these vendors do I want to grant the authority to download arbitrary untrusted internet code, compile it to machine code, and jump to it? This is what all modern JS engines do, and (other than system WebKit) absolutely forbidden on iOS.

4. Given that applications can ship "homegrown" WebKit on OSX, what percentage of programs I have installed actually do so, instead of linking /System/Library/WebKit.framework? And what does that say about the real demand for special browsing engines?

Every rant I read about how "the web is in bad shape" jumps straight into conspiracy theories about Apple the monopolist (somehow with 30% US marketshare) without solving, addressing, or even mentioning the actual technical issues.

If you're a person who does not like the way things are going, you should A) talk to people on the other team to discover what is the real, legitimate, technical concern behind our position, and B) work with us on finding solutions to that issue, and C) go out for beer afterward.

Characterizing Apple as some villain "locking up untold billions in economic value" for prioritizing security over software freedom accomplishes nothing beyond creating animosity between engineers who share many of the same goals.

This is the correct answer. Whereas Android is a malware cesspool and 0-days are de rigour on general purpose machines, Apple's managed to have about as secure an ecosystem as you can hope to get to (bugs happen. architecture is what matters)

If we want common people to use their devices and not get ransomware'd to death, the iOS model is the way to do it.

It appears these restrictions haven't done a great deal to stave off exploits.

http://venturebeat.com/2015/12/31/software-with-the-most-vul...

The citation doesn't shed any light on whether the restrictions have been effective.

It does shed light on Darwin having more overall vulnerabilities than Linux and less overall than MS, but unless you believe that browser policy specifically dominates These figures, (and can support that view) the overall vulnerability count is not relevant to browser policy.

Also wanted to come back and note that this data doesn't indicate whether bugs were found and patched internally, or were actually exposed first by malware.

I was wrong to make a judgement on it.

What if Microsoft had "valid technical reasons" not to allow any other browser on windows besides IE? Villains? Heroes?

The situation with Microsoft in the 90s was substantially different. Go read all of https://www.justice.gov/atr/us-v-microsoft-courts-findings-f..., but here's a random paragraph:

> 35. Microsoft possesses a dominant, persistent, and increasing share of the world- wide market for Intel-compatible PC operating systems. Every year for the last decade, Microsoft's share of the market for Intel-compatible PC operating systems has stood above ninety percent. For the last couple of years the figure has been at least ninety-five percent, and analysts project that the share will climb even higher over the next few years.

Other than the surface similarity that they both involve browsers, the situation in that order and the present day could not be more different.

Thanks for the link. I only see two different approaches to the same goal.

I don't mind being stuck with WebKit, but what I do mind is being hold back by limiting browser features and not implementing APIs that other engines already provide for a long time. Currently our biggest issue is not being allowed to play videos inline on a page. But the missing Fullscreen API also costs us additional development time.

Reply on news.ycombinator.com