Mikey Campbell
Scattered tips sent to MacRumors from unnamed app developers claim the iPhone maker's latest step against the in-app purchasing workaround involves either a proprietary identification system or unique device identifier data (UDID), the unique number assigned to every wireless iDevice.
Developers have been seeing a new receipt field on in-app purchase invoices titled "unique_identifier" which appears to be a device's UDID. While the reports are consistent, it is unclear whether Apple is using actual UDID data or a new form identification as the company has instituted protocols against apps using the sensitive information.
The reported hack was first made public last Friday and involves sending forged digital certificates to a unique DNS server which then sends back spoofed code receipts, effectively validating a "purchase" as legitimate. Russian hacker Alexey V. Borodin who discovered the workaround said Apple's purchasing process was easy to replicate as the digital receipts were generic and contained no unique user data.
Wednesday's news comes on the heels of Apple's move to block access to IP addresses used by the Russian hacker which itself was reportedly followed by a request to take down the servers involved in the sidestepping process.
UDID access has been a topic of debate recently as consumer advocacy groups and government bodies called for Apple to impose usage restrictions of the unique device data which could be used nefariously. Mobile ad agencies rely on metrics calculated from reportedly anonymous UDID metrics to monetize advertisements and are pushing hard against the access blockage on claims that it would hurt revenues.
Apple has taken steps to ensure developers no longer use UDID data and is reportedly denying App Store submissions which use the identifiers. Apps that previously used UDID information before the Apple crackdown, however, retain access to the data and can only be changed when an update is submitted.
While Apple has remained mum on the new system it is unlikely the company would allow unrestricted access to the unique identifiers.
Andrew Orr
Christine McKee
Sponsored Content
Wesley Hilliard
AppleInsider Staff
Amber Neely
7 Comments
I thought they told developers that they weren't allowed to have access to the UDID. If Apple is putting UDID's on in-app purchase receipts back to the developer, that kind of defeats the purpose. Perhaps the UDID on the receipt cannot be traced back to the user.
[quote name="GadgetCanada" url="/t/151365/apple-leverages-unique-identifier-to-thwart-in-app-purchasing-hack#post_2149597"]I thought they told developers that they weren't allowed to have access to the UDID. If Apple is putting UDID's on in-app purchase receipts back to the developer, that kind of defeats the purpose. Perhaps the UDID on the receipt cannot be traced back to the user. [/quote] I'd guess it's not the same or it wouldn't make sense. If it's not the same I do wonder if it's generated based on the UDID value and easily breakable so devs can then track by UDID without Apple even being aware. This is the sort of the thing Apple usually doesn't get right away so I wouldn't be surprised.
[quote name="GadgetCanada" url="/t/151365/apple-leverages-unique-identifier-to-thwart-in-app-purchasing-hack#post_2149597"]I thought they told developers that they weren't allowed to have access to the UDID. If Apple is putting UDID's on in-app purchase receipts back to the developer, that kind of defeats the purpose. Perhaps the UDID on the receipt cannot be traced back to the user. [/quote] It's not likely the same. I believe Apple issues a randomly made id on subscriptions through the store already and they likely just extended that to all purchases. Or will if the developers wants to code for it.
It looks like AI is keeping track of negative comments now:
Although Apple doesn't allow any new apps to use the UDID, it's still there; and if Apple chooses to use it as part of a receipt/hash it's their choice. Even if the devs have a a list of UDIDs, they would not be able to track that because they can't write it into their code.