the station: https://maps.app.goo.gl/Tc2Hs8kdwbFcbaxC6

Could be via other apps using ubers native sdk writing to a common key store. ala Google sharing auth between apps on iOS.

Such key stores are wiped on erase. They more likely used the wifi MAC address.

Keychain used to persist data and are shared, this was a very recent change in iOS to "fix"

It can be backed up to iCloud but in the context of scammers they're likely not using the same iCloud over and over.

Is it against the rules to track via the mac address?

The wifi Mac address is obscured from native code

Didn't used to be and it's unclear what the exact timing is of this code.

Apple made the standard API return garbage in iOS 6, and the API would probably trigger an analysis error iTC, so if they were getting the MAC address it was via much sneakier means.

Can't one simply change the MAC address like you can do on PC?

Maybe if you're jail broken? But if you're not then no way.

I believe I tried long long ago on iOS and couldn't get it to work, but I don't know if I'm remembering correctly.

It's a shame that nearly all of gamequoter's history is gone.

Not sure if this applies to Gamequoter's posts specifically, but for a while there was a site called Waffleimages that was created basically for SA in the same sort of way Imgur was created for Reddit when all the other image hosts sucked. Just about everyone used Waffleimages for a while and when it eventually went away, tons of images went with it.

thanks for that. yeah looks like almost all of his history is gone. the images weren't saved...

This information is currently partially available. Not line by line but definition by definition. It's hidden behind a compiler flag but there are open source tools that consume it and display it for developer consumption.

one example is Popover controls on iPhone. http://marksands.github.io/2014/05/27/how-apple-cheats.html

ComScore is one of the larger providers of these statistics similar to Nielsen ratings they provide a library you setup in your app.

see # 18: https://medium.com/ios-os-x-development/libraries-used-in-th...

there is no way fb let alone any self respecting app would do a cost-benefit analysis of added app size, security and scrutiny - and decide to embed an sdk just to make some marketers happy. i wouldn't be surprised if they made api calls with an extremely high sampling considering 1.5B people use the fb app.

The Swift patterns Emerging definitely favor explicit conversions over implicit. One of the QA questions begins eluding to some issues with this pattern with under and overflows, but the author also doesn't mention safety around Nan's or Infinity. Last thing I want as a consumer of an API is surprises. There are good reasons why these value types are non interchangeable without being explicit.

Good point bringing up over/underflow, I didn't think much about Nan or infinity, but I did consider potential over/underflows. I originally built an overflow/underflow checker(on the github project), but then re-evaluated it and figured it wasn't really necessary since the default action for number types that overflow/underflow in swift is to throw an error runtime. The person asking the question mentioned another series of operators that exist &+, &-, &*,etc that allow for overflow/underflow to occur on number types in swift.. without the error throwing, which is not the default.

Is "Producer" the right word for his job title? Or is psychopath closer to reality?

Talking about other humans in such a disassociated way. At least one armed bandits in vegas don't create fake facebook profiles for some scheme to extract more money from you.

I've always preferred "heroin dealer".

(A few years ago, someone said that social game developers are like heroin dealers and regular game developers are like weed dealers. It's a very apt comparison)

"Producer" has always meant this. Look at "producers" for pop idols.

You have so little basis (beyond your emotional reaction) for even an implication of such a psychiatric diagnosis that I have to call you out on it. The hyperbole serves no one.

If you read the article you would see that it's not a whitelist for specific 3rd party domains. Without knowing every possible 3rd party domain ahead of compilation such a white list is not possible. The recommendation is a white list for connection types. Which removes App Transport Security checks from all outbound URL requests.

ATS is configurable to allow arbitrary loads, but specify which domains you wish to keep secure. The author of the above post failed to document or mention that. Most developers will have known domains that they wish to keep secure, and there are options available to do that.

Correct but most non toy apps don't hard code URL's even for their own services. If my service is getting ddosed/updated I should be able to push a configuration change out to apps and have them request another arbitrary URL. I might not know ahead of time what that URL will be, and ATS should be enforced on those URLs.

Well that's just silly. There are plenty of high profiles apps out there with many users who have a set of known domains that their app will need to connect to. As an example, Facebook, will never push a config update that points their app do a domain other than Facebook. Most big apps will likely have backend mitigation for problems like DDoS. You're right that most apps don't hardcode URLs, but most configs also don't update domains to something completely unexpected on a regular basis. Also, even if you enable ATS on specific domains and you need to point your config elsewhere, following Google's instruction, that will mean your new endpoint no longer enforces ATS, which is still better than having disabled ATS for every URL in your app for all users from the start.