Live data from Hacker News

Apple’s Anti-Tracking Plans for iPhone

foundation.mozilla.org

341–350 of 403 posts

Re: Apple’s Anti-Tracking Plans for iPhone

#341

Earlier quoted context omitted.

Can someone (only) use IMEI plus account instead of IDFA for uniqueness? So if you want to exclude/ban a user, you can use the IMEI+account, but outside of excluding a user from using your service, you cannot access IMEI+account. User privacy is preserved because there's no singular ID for advertisers, and services can still ban fraud because if it's present they can use the IMEI+account to ban a user. Maybe even hav…

The IMEA is worse than the IDFA and neither is needed for this use case.

It could be. In that case, let the OS handle whether the phone/account are unique, and the app can ban that phone/account without having that unique identifier to ID the person in other cases, like advertising.

Re: Apple’s Anti-Tracking Plans for iPhone

#342
post #2

Why the IDFA was a thing in the first place? What I heard was that at some point of time, Apple had an ambition for own advertising business.

> What I heard was that at some point of time, Apple had an ambition for own advertising business.

Yes. Let's not forget about iAd and iBeacon, where Apple was traveling down the same road as FB and Google.

Re: Apple’s Anti-Tracking Plans for iPhone

#343
post #340

Earlier quoted context omitted.

This completely changes the game on all kinds of fraud, not just ad fraud. Currently when you get caught, the service you’re abusing bans your device. To keep trying you need new hardware; attacks have a real monetary cost for the attacker. When your iPhone can present itself as infinitely many iPhones, this is neutered, and services will need different (probably more invasive) techniques to keep banned users away.

This is an incomplete understanding of iOS. You can hardware ban an iPhone by flipping an app-reserved bit.

Can you please elaborate? How does this work? Have never heard of such a thing.

EDIT: I believe Apple's DeviceCheck API is what the parent refers to. Thank you!

Re: Apple’s Anti-Tracking Plans for iPhone

#344

In Europe, cross-app, cross-browser & cross-device tracking is on very thin ice legally under the GDPR, so I'm not surprised Apple finally curbs the use of "sticky" identifiers on their devices. Honestly, it's a bit shameful that a device that is marketed as the gold standard in privacy would even support such an identifier in the first place, it has literally no purpose beyond mining peoples' data. Now that the thir…

Having been on both sides of the table, I would slightly disagree here. Fraud prevention for example will get an order of magnitude harder, plus this move will further skew the playing field towards FAANG who have the resources to puzzle the scraps back together for decent conversion tracking with the help of logins, IPs, SDKs with First Party IDs and a massive dose of machine learning.

“Fraudsters” can already reset the IDFA from the iOS Settings by turning off personalized ads in the Privacy section.

Re: Apple’s Anti-Tracking Plans for iPhone

#345
post #144
post #74

Earlier quoted context omitted.

Technically speaking, their income is from selling services to the people the’ve sold physical devices. It’s also a good way to combat the push from companies like Google to bring down the prices of devices to allow for better tracking.

They're pivoting to selling services now. That's why iCloud is so integrated into the phone while the free version is so crappy.

I wouldn’t call iTunes or the appstore “now”

Re: Apple’s Anti-Tracking Plans for iPhone

#346
post #322

Earlier quoted context omitted.

This completely changes the game on all kinds of fraud, not just ad fraud. Currently when you get caught, the service you’re abusing bans your device. To keep trying you need new hardware; attacks have a real monetary cost for the attacker. When your iPhone can present itself as infinitely many iPhones, this is neutered, and services will need different (probably more invasive) techniques to keep banned users away.

>This completely changes the game on all kinds of fraud, not just ad fraud. As someone alt-tabbing in from real fraud investigation work, no, it doesn't. Banning burner phones and reducing banking privacy regulations would move the needle there, but those aren't even on the radar. "Someone's script opened a page" isn't fraud. Someone built a script specifically to spam click a competitor's ads, by contrast, is.

Banning devices and identifying groups of accounts which are linked by common devices are two of the most powerful tools that my company’s fraud team talks about. We have nothing to do with advertising. YMMV.

Re: Apple’s Anti-Tracking Plans for iPhone

#347

Earlier quoted context omitted.

The IMEA is worse than the IDFA and neither is needed for this use case.

It could be. In that case, let the OS handle whether the phone/account are unique, and the app can ban that phone/account without having that unique identifier to ID the person in other cases, like advertising.

There are already ways you can do this.

https://nshipster.com/uuid-udid-unique-identifier/

The easiest is with the identifierForVendor property of [UIDevice] which identifies that specific device for your software, but is not shared with other vendors. So you can ban Bob's iPhone across all your apps, but that ID isn't useful to other vendors.

Re: Apple’s Anti-Tracking Plans for iPhone

#348
post #340

Earlier quoted context omitted.

This is an incomplete understanding of iOS. You can hardware ban an iPhone by flipping an app-reserved bit.

Can you please elaborate? How does this work? Have never heard of such a thing. EDIT: I believe Apple's DeviceCheck API is what the parent refers to. Thank you!

https://nshipster.com/uuid-udid-unique-identifier/

Not his solution, but just grab the identifierForVendor off UIDevice and ban that.

Alternatively:

> "Using DeviceCheck API’s, in combination with a server-to-server APIs, developer can set and query two bits of data per device. It will also maintain the user privacy, by not disclosing any user or device information, which is the priority point for every Apple user and most point of concern of every mobile user."

https://codeburst.io/unique-identifier-for-the-ios-devices-5...

Re: Apple’s Anti-Tracking Plans for iPhone

#349
post #322

Earlier quoted context omitted.

>This completely changes the game on all kinds of fraud, not just ad fraud. As someone alt-tabbing in from real fraud investigation work, no, it doesn't. Banning burner phones and reducing banking privacy regulations would move the needle there, but those aren't even on the radar. "Someone's script opened a page" isn't fraud. Someone built a script specifically to spam click a competitor's ads, by contrast, is.

Banning devices and identifying groups of accounts which are linked by common devices are two of the most powerful tools that my company’s fraud team talks about. We have nothing to do with advertising. YMMV.

The advertising identifier is a crappy way to do this though. There are multiple more privacy respecting ways to ban users which work much better. The IDFA can be blanked or reset where other methods like identifierForVendor cannot be reset or bypassed.

Re: Apple’s Anti-Tracking Plans for iPhone

#350

Earlier quoted context omitted.

Can you please elaborate? How does this work? Have never heard of such a thing. EDIT: I believe Apple's DeviceCheck API is what the parent refers to. Thank you!

https://nshipster.com/uuid-udid-unique-identifier/ Not his solution, but just grab the identifierForVendor off UIDevice and ban that. Alternatively: > "Using DeviceCheck API’s, in combination with a server-to-server APIs, developer can set and query two bits of data per device. It will also maintain the user privacy, by not disclosing any user or device information, which is the priority point for every Apple user an…

Very nice, thank you!
Post reply on HN