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.
Apple’s Anti-Tracking Plans for iPhone
341–350 of 403 posts
Re: Apple’s Anti-Tracking Plans for iPhone
#342Why 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.
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
#343Earlier 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.
EDIT: I believe Apple's DeviceCheck API is what the parent refers to. Thank you!
Re: Apple’s Anti-Tracking Plans for iPhone
#344In 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.
Re: Apple’s Anti-Tracking Plans for iPhone
#345Earlier 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.
Re: Apple’s Anti-Tracking Plans for iPhone
#346Earlier 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.
Re: Apple’s Anti-Tracking Plans for iPhone
#347Earlier 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.
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
#348Earlier 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!
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
#349Earlier 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.
Re: Apple’s Anti-Tracking Plans for iPhone
#350Earlier 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…