Hacker News Reader

Comment by killface | Hacker News Reader

That seems like an incredibly petty way to view it.

Apple's not out to get you. In fact, I'm glad they did this. That iHasApp looks creepy as hell, and it pisses me off that other devs were using it to basically spy on me. It reduces my trust in all apps.

View on HN

Yeah, this reminds me of the recent(ish) realization that a javascript could check a link's applied style to determine if it had :visitied, letting advertisers trivially run test a very large list of links to fingerprint and profile anybody who visits a webpage.

Mozilla patched that information leak. I don't remember anyone accusing them of "contempt for web developers."

I'm no longer using iOS regularly, but the fact that Apple can and does police apps that violate a user's expectation of privacy is one of the strong points of the platform.

Mozilla didn't start white-listing web sites which it determined didn't snoop on the :visited property, and black list all other sites. Instead, it fixed the API.

Right, they did it by blocking javascript access to computed CSS styles so that it doesn't return :visited rules.

In Apple's case, the more secure options would either be "an app must include a perapproved list of which other apps are authorized to see that it is installed", or popups for permissions like "Image Editor wants to know if you have Dropbox."

Since Apple has both the authority and the manpower to approve or disapprove of apps, they chose to not take either and to stick with the version that gives the best user experience, while also allowing devs to continue checking installed apps when they need to as appropriate for cross-app interaction.

I guess it sucks from iHasApp's perspective, but I don't have any more sympathy for them than any other spyware developer. Just because Win32 apps aren't sandboxed and can read arbitrary data out of my home folder doesn't mean it's an OK thing to do.

To be fair I think there is an easy workaround on blocking the javascript from reading computed CSS styles. I wrote a potential hack around that here: http://ckluis.com/black-hat-badassery/

To be clear - I have no problem with this service getting shut down, as it's clearly intended to violate the user's privacy. But to say you must use APIs as "prescribed" by Apple is way too broad and subjective.

I'm sure the iOS developer Terms of Service forbids this at some level. If not, then update it. Then say you're shutting this down because it violates the TOS.

That's a good way to get a million page TOS.

https://developer.apple.com/app-store/review/guidelines/

> We will reject Apps for any content or behavior that we believe is over the line. What line, you ask? Well, as a Supreme Court Justice once said, "I'll know it when I see it". And we think that you will also know it when you cross it.

What would you think of "don't use our APIs in such a way that, if your users found out you had used them that way, they'd want that API removed to force you to stop"? That's essentially what's being discussed here.

Technical people are accustomed to looking at the technical limitations of a problem space and then coming up with a solution. If the person managing the game then says "rule violation: you can't do stuff I don't like" it seems unfair.

The better way is to design the API in such a way that it can't be "abused". It's Apple's fault that iHasApp was able to do what it did, and it's Apple's fault that Facebook continues to do what iHasApp did.

While I'll agree with your second point about designing the API in a more safe way, the first one I'm not as sure about. You could make that same argument in favor of malware authors against Big Bad Microsoft walling them out with new Windows Defender definitions.

If something is stealing my personal information and sending it off to advertisers, I'm entirely happy to have the OS vendor give them the boot.

Reply on news.ycombinator.com