Submitters: the HN guidelines ask you to please submit original sources (https://news.ycombinator.com/newsguidelines.html). Articles that cherry-pick a sensational detail, wrap that in fresh bait, and hawk it for page views are not original sources.
On the other hand, had Apple actually banned Uber from the App Store the outrage would have been insane - even right here in Hacker News. IMHO, Apple didn't have a choice but to let them go scot-free.
I read this story over the weekend, about Kalanick getting a meeting with Cook and discussing this issue. In stark contrast, I'm sure that anyone else would have their app removed and receive automated responses from apple support at best.
No, I don't think Cook needs to find time for everyone. I just find this contrast fascinating.
Apple usually provides warning before removal. For example, when they decided portions of Transmit were unacceptable, they asked Panic to change them before deleting the app.
Panic by far and away isn't an "indie developer". In the Mac dev space, they're pretty big.
There have been countless posts on HN from smaller devs getting their apps immediately pulled upon an update review for something they got no warning for.
Panic isn't a tiny player, I agree, but they're not Uber. there's a possibility the human reviewer assigned to its case hadn't heard of the company. If I were a reviewer and I had no personal experience with the app or did not immediately recognize the name, I'd be inclined to treat them just like anyone else.
I would not be surprised if the big hitters are not already tagged as such when the reviews get sent in. Whether there's something as small as a tag for the reviewer to know, or even a separate queue, I sure as hell can bet they go through an expedited and streamlined review process for their updates and such. They're the bread and butter of the App Store, so it's in Apple's best interest to treat them well.
Panic's warnings were in good faith. Cabel's team clearly thought something was permitted, and was simply told "no, you misunderstood" by the review team at Apple.
Dash might be a better example. The account generating fraudulent reviews was contacted before apps were removed from the store. It's entirely possible that Apple screwed up by not communicating with the account used to publish Dash, but that's not what I'm arguing here -- I'm saying that even in clear cases of fraud, Apple usually talks to the developer first.
I find this article's title to be clickbait. What Uber was doing by "fingerprinting" although supposedly breaking Apple's rules is definitely not what I would consider spying.
Any app can do that without violating Apple's rules. They can tell whenever a user signs in to the app on a fresh install and the device model/software version is easily accessible.
Usually I am not an uber defender, but in this case it seems like the articles only goal is to boost page clicks.
Any app can do that without violating Apple's rules.
Actually, no, doing so specifically violates Apple's rules. That's the entire point.
That "any app can do that" is tautological... it's not like Uber's app is special in this regard.
There are many things an app can do that violate the ToS. Normally that stuff is caught during app acceptance... Unless the vendor sneakily bypasses the rules by disguising the functionality, as Uber did here.
Granted, Apple should probably expose an API for identifying unique hardware to avoid fraud. Perhaps a hardware secret hashed with the App name encrypted with the App provisioner's public key, such that the ID is only identifiable/useful to a specific App developer.
There doesn't seem to be an easy workaround for jailbroken apps, though, unless you were doing the fingerprinting secretly, like Uber did.
The plethora of $20 off promo codes certainly amplifies this problem, though. Lyft did it better by only allowing $5 off per ride, but with more rides.
That'd be the IDFV [1], no? The problem is that the customer is supposed to be able to reset that by deleting all of a vendor's apps from their device.
If there's a fraud problem, I think it's reasonable to require the developer to handle it in their account system. Yes, this makes it somewhat harder to detect fraud because you lose one important piece of information, but privacy is worth it.
Didn't know about that, thanks! Curious why they invented their own system (maybe jailbreaking was still a problem, because people knew about it).
But yes, a strong account system is the best way to go. For a company this mature, it should be feasible to require phone number/email/payment authentication for new users prior to providing services.
Apple removed access to the UDID because it was being used to target advertising and correlate users across different publishers -- basically privacy issues. For a while there was a slew of third party solutions which involved hashes of MAC addresses. Some time thereafter Apple created IDFV and the companion, IDFA (For Advertiser) and really cracked down on cross-vendor correlation.
My understanding is that's standard procedure for Apple. If you violate the TOS, they'll block app updates, but it would have to be egregious for them to remove the app. At a company I worked at previously, we got hit with a copyright issue, and they just wouldn't let us push through a new version until we resolved it.
Also, for a company the size of Uber, having your app blocked for a month, and not being able to get new features or bug fixes out, is probably a sizable cost, when you factor in lost developer time.
Submitters: the HN guidelines ask you to please submit original sources (https://news.ycombinator.com/newsguidelines.html). Articles that cherry-pick a sensational detail, wrap that in fresh bait, and hawk it for page views are not original sources.