Apple reportedly rejecting apps that access UDIDs - Page 2

That's what they all say...

Seems like there would be some difference (?) Otherwise, why wouldn't they have been using MAC addresses, just as any technology interests have for many years, already?

"Were trying to be proactive and weve already moved to an alternative scheme"

Perfect choice of words.

Who spend tens of thousands of dollars collectively on crap shoved in my face that I either simply block outright or completely and utterly ignore if I can't.

Seriously, do people actually buy from ads? They must, otherwise they wouldn't still be around. And that's just sort of sad when you really think about what that implies.

You don't buy based on ads, you buy based on quality, history, and utility tailored to you. If a product being advertised isn't one for you, you don't buy it. The most I've ever used an ad for is a window into a new market. "Oh, hey, they make these now?" And then I go look up what one is actually the best.

Now if you'll excuse me, I've had a sudden urge to go sign up a new contract with AT&T and grab one of their neat Samsung phones

No, I mean't 'opt-in' for the consumer.

I worked on a voucher app. Tying vouchers to the phone using UDID was the best solution for our needs. A legitimate use.

Do apps not have access to the MAC address of the device? Or would tying the vouchers to a specific account be possible, or is that not narrow enough for that use?

I can honestly say I know exactly how many adverts I have clicked since practically the beginning of the web, and that's 2! I have clicked twice in over 20 years. Nobody got rich in the ad world from me that's for sure.

I'm not a network engineer but I thought that the MAC address is embedded in the wifi hardware. When you are on the cell network you are using different network hardware. I'm not sure how it can read the MAC address embedded in a separate component. The UDID is unique to the entire system.

It's been a while since I worked on the app, but I believe comparative ease of spoofing MAC address was the reasoning at the time.

But you gave Apple and the carriers permission. It's in the terms of usage.
Don't like it? Don't use it.

But each MAC address is unique to each device that can access the Internet. The only time you'd have a different identifier is on a full-blown Mac where you'd have an Ethernet ID, too (or a Mac Pro where you could have all three), and that's outside the use case here.

MAC addresses are the logical representation of the BIA (Burned-In Address) for IEEE 802 technologies, such as WiFi and ethernet. As you say, when you are on a mobile network you are being identified in a different way.

However, it's my understanding that apps can easily pull any one of these unique identifiers since they are installed locally so my confusion is why does it matter what "virtually unique" identifier is used to register the device to the developer's servers?

Isn't that an argument for targeted ads? If they can show ads that are relevant to you then ads become more useful to you as they will be for things you are interested in. This results in increasing ad revenue for developers as you are more likely to click on the ad.

There was an interesting example recently where it was revealed the Target can tell if a woman is pregnant and what her due date is by changes in what she buys each week. Target then mails vouchers for things like diapers. Big retailers do even more tracking than online ad companies.

Of course there is also the creepy side where Target knew a teenage girl was pregnant before her own father.

Random number generators are free and easy.
Credit card numbers are widely available.
MAC addresses have been around for an eternity.

But people generally don't seem to want to be tracked without their permission, UDIDs included.
Why do mobile ad agencies think otherwise?
Why do developers think they should get special treatment (allowing them to grab UDIDs and share them with ad agencies without permission)?

As far as I know you can spoof the MAC address, UDID, IMEI and ICCID and serial number. Anything that is represented logically can technically be spoofed.

That wouldn't be such a bad system.


In itself, not much of an argument. Also, no verifiable number.


Often not a selling point for the user.



Maybe, but if there's no proof, not much of an argument. If it's easy for third parties to analyze code for UDID use, whether the code is by Apple or a third party doesn't matter, it would be possible to figure out how it's being used. I'm a lot more comfortable with just the handset maker and the carrier accessing it (two companies), and they have a clearly more legitimate need to have that data in order to properly operate on the network, among other things. The possibility of every dev having access to it, possibly hundreds, is not something I am comfortable with.


What profiles do you mean?


They are fixing that too, aren't they? I don't think addressing that issue means this issue can't be addressed too.


The MAC address is probably as accessible to the software as a UDID. It might be a different call, but I don't see it being more difficult to get.

Sorry that just sounds like layman speculation and vague nomenclature. Where exactly is the MAC address? Perhaps the OS reads it saves it in memory where it becomes accessible but I would rather have a technical explanation than an abstract speculation. I have also been told that in a device such as a Mac Pro where you have two Ethernet ports, the MAC address that the machine reports is the card in the first slot even though technically there are two separate MAC addresses.

What happens when you turn wifi off.

Sure but, "comparative" ease, for your average joe. Comparative lack of results on google for 'UDID spoof' does add a level of security, security by obscurity. Granted not the biggest of deterrents.

I have read almost all the posts here and it seems that some of the argument is that apple will be able to use UDIDs all by themselves while cutting the developers out, which in my mind is a poor idea for reasoning that developers should be able to use them too. Cell networks identify your ID through the UDID on the network and have to for obvious reason to be attached to the cell network.
Developers do not need to use UDID to track. As was said in the article one of the developers said they were already working around the issue by building there own tracking code.

It seems to me that the biggest problem here is the fact that developers are wanting to use something that is already there without having to build there own. Less work for them and I can't blame them for wanting to use it. It saves them money and time.

But the alternative is far worse. Apple is being investigated heavily by congress and is being told right now that if they don't do something about this that they (congress) will and make it legislated law. I don't know about you but I would rather have Apple be proactive about this and take care of it on there own than have the idiots on capitol hill decide it for us. They legislate too much of our lives already and have done a piss poor job of it already. Just look at social security for one example of how well they have done.

Also google and microsoft will go through and are going through the same process right now. Google specifically is being investigated by the DOJ right now for privacy violations and the in EU too.

As for the MAC address vs UDID argument both are unique to the device but MAC is not used by the carriers to track like UDID is. It could be but it is not. Your ID on a cell is not attached to the MAC address, it is attached to the UDID.
My nephew works for Verizon as a network engineer and tells my that MAC addresses are not attached to a name UDID's are.

Here's the article http://www.nytimes.com/2012/02/19/ma...ng-habits.html
What the article doesn't really describe is how Target identified the woman.

I like this line: "The reason [emphasis added] Target can snoop on our shopping habits is that, over the past two decades, the science of habit formation has become a major field of research in neurology and psychology departments at hundreds of major medical centers and universities, as well as inside extremely well financed corporate labs."
No mention of what information is actually available and shared, nor from what sources. No mention of the laws.
In other words, the reason isn't actually provided.

But isn't that the exact thing Apple asks developers not to do in their documentation? Apple recommends that the UDID be used in combination with a user login. The problem with UDID is that it tracks the device not the users. I think Apple is blocking UDID usage because it is being abused. It is being abused in a way that causes ranking issues in the app store with developers using "buy other apps to get in app credit". If a developer want to track a user then they can create a token/cookie when the user first use the app. The only disadvantage is that developers can no longer track users outside the app.

What do you mean by "where"? It's pulled from the BIA on the Physical Later (OSI Layer 1) and then represented virtually on the Link layer (OSI Layer 2). Is that what you meant? This is where it can be altered if you want to hide your true MAC address from a network or pretend to be someone else's MAC address


Sure, systems that simply need a unique network identifier will likely call for slot 0 of an IEEE 802 port. No use in grabbing all MAC addresses for the


Unless you remove the HW or the driver so it no longer exists to the OS then you'll have a MAC address in the system for WiFi.

Here's a test. Go to Airplane Mode on an iDevice and then to General » About. You'll still see the WiFi and Bluetooh MAC addresses listed.

Fairly simple...
http://iphonedevelopertips.com/devic...c-address.html

We had to tie the voucher to a device, and prevent a user opening multiple accounts to take advantage of limited offers such as '20% off your first 5 meals at mcdonalds'. Sure this could be done in other ways, but none that were as simple from a user experience point of view.

You're making that number up. Even if most developers use this, which is not known, as we can see from the article, they can work out other ways of doing much if this, hopefully in ways that aren't as much of a problem.

I trust Apple much more than these unknown developers. Besides, it's not the ones who are honestly using information, but the ones who might not. It's the question of malware. If anyone can get certain kinds of info, then there will be some few who use it maliciously.

I admit that I'm not as familiar with the uses and info integrity assocciated with this as some, but there must be some issue that you don't understand, or are ignoring, for it to have come up.

It's far more important that Apple maintain its reputation than some developers have it easy. Even if a few leave the platform because of it. Google is their main competitor in mobile OS's right now, and advertising is, according to their own financial reports, 96% of their sales and profits. This means little to Apple financially, one way or the other. But it means a lot to Google. So with Congress getting involved in privacy issues, as they should, this could give Apple a big advantage. If Apple can say, that they've got these issues locked up, and Google is using them, then the guns will be pointed at them instead.

I hope Apple is looking at other holes in their armor.

Where as in which hardware component is it embedded? I believe it is in the wifi hardware.

I do see your point about it still being available even in airplane mode so that apparently supports my earlier speculation that it is read by the OS on boot and the OS reports it to requests rather than the hardware itself reporting it directly. So in that regard perhaps an app could use the MAC address as an alternate unique id.

As previously stated MAC addresses are part of all IEEE 802 technologies. That's why you see a MAC address for Bluetooth, too.


There are plenty of unique identifiers that can used. From what I'm reading the UDID was simply the easiest to grab. monstrosity's link to getting the MAC address from iOS seems rather complex but not being a coder pretty much all code looks rather complex to me.

They've closed down the ability to use contacts without asking.

Unlike you, I think that Apple is doing whatever they can to protect their customers, which unlike in Google's case, is us, not the advertisers. Some things slip through. I also believe that those running Apple can be a bit naive, they have actually thought that by issuing guidelines as to what should, and what shouldn't be done, developers would always follow those guidelines without being restrained from doing so. They are finding out that developers, good and bad, will poke around the API's and use whatever they want, even though Apple specifically says not to.

Apple is now understanding that guidelines aren't enough. They must make it impossible to do these things. If they must give up an imperceptible amount of income (imperceptible to Apple, that is), they they will do so.

Unfortunately, as always happens, and we've seen this with DRM, those who intend nothing bad get hit by the restrictions as well. That's too bad, but it's the way the world works. Remember in school when someone did something, and the teacher said that if that person didn't stand up, the entire class would get punished? Well, that's often the way it works.

Traditionally the network card is the considered the MAC address since back in the Sun OS days used for software authorization. I also remember when Intel and Windows tried to implement a UDID detection system where the id found on the pentium CPU was used. That was met with a lot of criticism from a privacy concern as the Id could be detected through the browser over the Internet.

I agree. With that. We get plenty of mailings, occasionally, something looks interesting, and I will look at it. Usually, it is interesting, but not something I've going to bother will. But just one in a while, something comes in that I am interested in. There might never have been a way that I would have known about it if not for the advertising. They buy targeted lists, so if you're subscribing to a magazine, or are on a list of customers for some store, or whatever, advertising it sent to you that you might have a better chance of responding to. The telling phone marketeers to send something is something I've been doing for years, especially charities. Most are somewhat legit, and I'll give to some. But others aren't really official, and they are the worst offenders.

I have nothing against targetted mailings. I have nothing against advertising as a whole.

But I don't like calls when I've told them not to do that. I don't like getting faxes that are poor attempts at pretending to be sent to some employee list, or otherwise, giving supposed deals, etc. I don't mind Ads at the bottom of the Bloomberg app, for example, or the way the NY Times has them in their app.

Whether or not people like the idea, advertising is very important to companies. Without it, many products and services would never be known. But giving up personal info without knowing you are doing so is too invasive. All of these should be opt-in. I know that Google has fought against this, as have others. Opt-in tends to get far fewer people than does opt-out. Whatever forces the user to do the least, and require the least effort, will always produce more people for the initiative.

I continue to mention Google, because they are the worst major company involved in this, because their entire existence depends on getting as much of out private info as possible, and selling it.

Where do you get the 90% number? I very much doubt that it affects that many developers. I develop for iOS and have never once needed to access the UDID. It's not like something you're forced to do to develop for iOS. I can't imagine that it really affects that many apps.

And frankly, for every developer it pisses off, there's going to be a developer who is thrilled to get a strategic opening for his app against a competing app. The faster you one-up the competition getting your own app in compliance and re-submitted, the better. The lazy ones will get a much-deserved kick in the ass. The others will go on doing what they do.

I think you're greatly overstating the negative impact on developers.

I'm not sure we're looking at this in same way. When Xerox invented this unique identifier it was first for ethernet but then it was quickly adopted by other wired networking technologies. WiFi and bluetooth had if from the start but "back in the Sun OS days" they hadn't been invented yet.


edit:
So I guess it's not a required part of IEEE 802 as I thought, just a very useful way to identify a node.

And that's the bottom line. You're using something with major security implications because you're too lazy to create a different system.

I think Internet security should be far more stringent. I'd like to see laws put into place so that people who steal or sell confidential information go to jail.

Of course, strict privacy laws would pretty much put Google out of business, but I"m OK with that.

I really don't care that Apple and the carriers can track me. I'm not worried about that at all. Look, the truth is that we're not guaranteed privacy outside of our home, and First Class mail. The Constitution is very specific about that, and our Constitution guarantees us more than most anywhere else.

But we've got to grow up and realize that we can't have what we want in the devices without giving up some of our privacy at the same time. But, I want to know to whom I'm giving it up. If I do something illegal, then I shouldn't complain about law enforcement getting a warrant, and tracking me. If I'm not, then the truth is that no one is going to have an interest in tracking me. That is, in regards to Apple and the phone company.

But these small developers (in comparison to Apple and the carriers) do have an interest in tracking me. Sometimes, I don't care. Sometimes I do. When a weather app asks for permission to use my present location, am I going to say no? Of course not, that would be silly.

But if a game company asked the same question, I would have to wonder at why I should want to give them that info.

UH? As I had already explained: We chose not because it was easier, but for user experience reasons.

Surely, you don't think that Target woud be remotely stupid enough to reveal that?!

I certainly go through the same thought process.

I won't go that far. I don't mind the Ads. So far I don't find them to be too annoying. Sure, they will always be annoying to some extent, but I'm willing to put up with that if an obvious attempt is being made to minimize that. It's much worse on Android, from what I've seen.

I want developers to make money. If they feel that people would want the app to be free, but are willing to accept Ads, then that's fine. Look at Angry Birds. They have their own Ads within the apps. Is it annoying, yup! But it doesn't stop people from buying the apps. And on Android, they couldn't sell the app at all, so they went to the free-with Ads route. And behold! Downloads went up more than a hundred times what it was, maybe more.

Obviously, people don't mind the Ads. So if you are not getting free apps because of the Ads, you aren't changing anything, just missing out on some good apps.