So you say the Galaxy Tab 7.7n is the result of Apple R&D ? That's strange, considering it contains AMOLED, Equinoxys CPU and Samsung developed RAM, as well as an OS which might be greatly inspired by the look and feel of iOS, but was engineered from the ground up (with all it's apparent defects in the earlier versions, which can be seen by the results of for instance project Butter). Note : This case relates to design, not technical issues.
Never used SkyDrive ? or Office 365, or the new Office 2013 ? These are not "remarkable new technologies". They are great technologies, as long as you're not locked in, and it's great they are also available in the apple eco-system
Just because they did it all at once... Normally when you write something off, you do this over a certain period. If they had written it off in 5 years this would have meant they had to write off 310mln each quarter. As the net profit this quarter was 6.7billion, with a 5 year write-off this would have been 6.4 billion profit this quarter (Which is up from 5.9billion same quarter last year). To quote engadget : "Even with the aQuantive related hit, Redmond still...
As I've already said in my previous response. When the api validates the in-app process with an apple server (which gets redirected using the custom dns) why does apple allow custom certificates instead of a whitelist of apple certificates... It seems the only security is that it should be ssl (any certificate is valid) and that's not a good idea. You always have to take a man-in-the-middle attack using for instance dns spoofing into account.
I agree, that's why I said the Apple implementation is fundamentally flawed, not the concept of in-app purchases. I've written a lot of 'transaction-based' software with remote servers, and if you're only mean of verification is based on certificates, you should always use a white-list of certificates. I have not analysed this issue in detail, but it seems the process accepts certificates based an common names instead of thumbprints etc.
Post count 36, and still no one is blaming Apple for allowing this loophole in their in-app purchase process.
I know I am, you can blame the hacker for actually showing and using this loophole, but all this does is show that the in-app purchase process is fundamentally flawed in the Apple implementation.
I know an app developer should use the additional verification of in-app purchases, but I don't understand why Apple allows user installed certificates to be...