Then the costa ricans are free to make their own movies, write their own books, create their own software and invent their own technologies.... I love how the summary spins it as IP violation being essential to education. Maybe a tiny fraction of all US IP would be of assistance to costa rican education, in which case - they can buy it with sugar!
Well, that's what Apple claim. There are two problems with this.
The first one is, how does Apple know what other companies are required to pay? This article claims the agreements are secret and I see no reason to disbelieve that, it'd be standard for this sort of thing.
The second problem is that Apple have sadly established a track record in the last few years of being flexible with the truth, whereas Nokia have not. For example, covering up issues with Jobs' health and playing cute with the FCC over Google iPhone apps. In constrast the only time I read about Nokia in the news is when they've done something cool, like launching a new product.
Simply put, some companies have more credibility than others, and Apple is on the losing side in this one.
Well, people have created thousands of spam apps, apps that upload your phone number to the internet (and those companies then abused them), and it's possible for iPhone apps to also steal a complete keylog of stuff you recently typed in along with all your contacts. Given that Apple frequently pull bad apps only when they are pointed out by third parties, it's quite likely that there ARE phishing apps on the iPhone!
Well here we have a wildly popular mobile platform. Yet the most egregious exploit in an app to date is something that sent your address book somewhere without permission (something that's explicitly allowed by the API).
Um yes, and why is that allowed exactly? Anyway, it's guaranteed that there's all kinds of crap on the App Store. I mean, Apple have nuked 2000 apps (2% of their total) for being basically spam (one example) so it's not like their approval process is that great.
What would a malicious app really do anyway?
I suggest you read this presentation detailed exactly what things an iPhone app can do without you knowing. It's a pretty staggering list.
Furthermore, because you have to go through some paperwork to be a registered developer in the first place, you have a lot more exposure to liability if you try something. Apple the has valid bank account details for you (if you registered to sell paid apps)
You have to pay a small fee to list your app on the Android market too. So, I'm not sure where you think the difference is.
The rest of your post, well, I don't feel like responding to each point right now. Suffice it to say, if you want to argue with your users on the market, you're doing it wrong (I say this as somebody who has published his own quite popular Android app last year). I've seen a lot of developers who somehow believe that if users say their app crashes or doesn't work, it's Androids fault! And as an Android user, I've experienced exactly zero app compatibility issues. Maybe you think Android development is some kind of major headache but having done it myself, I strongly disagree.
So your rebuttal is that "musician" as a category of job shouldn't exist? What about fans of drum'n'bass like myself? Doesn't exactly lend itself to live performance.... I guess we're just screwed.
Maybe he doesn't mention it because it's irrelevant? Exposure doesn't matter unless that exposure leads to sales and if people just download stuff, there are no sales. The vast majority of musicians don't play to sold out arenas, right?
From the paragraph just before the Slashdot summary quote:
A decade’s worth of music file-sharing and swiping has made clear that the people it hurts are the creators — in this case, the young, fledgling songwriters who can’t live off ticket and T-shirt sales like the least sympathetic among us — and the people this reverse Robin Hooding benefits are rich service providers, whose swollen profits perfectly mirror the lost receipts of the music business.
... and the sentence immediately after it...
Note to self: Don’t get over-rewarded rock stars on this bully pulpit, or famous actors; find the next Cole Porter, if he/she hasn’t already left to write jingles.
So he's worried about the new guys who haven't made it yet, not himself. If you'd bothered to RTFA you'd know that, but hey, somebody is expressing concern for a future in which the next Bono never makes it thanks to rampant piracy. Obviously he must be an idiot!
Brian Krebs now has a blog. He has written some of the most consistently interesting, unique and accurate coverage of the internet [in]security world in the past few years. Subscribed.
There are Android phones (like the developer phones) that let you do that as well. The consumer phones most people buy don't, because the operators are scared of selling completely unlocked devices, but lacking root access is certainly not inherent to Android.
I'm not sure what the big deal is, really. Dealing with users who have older platform versions is a fundamental part of software engineering. Apple certainly isn't immune to that, look at MacOS X. If the iPhone has less of a problem with it, that's only because it's been introducing new APIs at a far slower rate.
But I'm not convinced there really is a problem. All the "Android Fragmentation" stories I read are coming from bloggers who are not active mobile software developers. Android is pretty darn backwards compatible - issues with app incompatibilities are rare, and when they occur tend to be due to Android getting a bit stricter with API usage so the fixes are easy. What's more, the Android system makes it pretty easy to write apps that gracefully degrade down to old platform versions if your app needs newer features, and the emulator lets you easily test each version. There's also a pretty rigorous compatibility suite for people making customized versions of Android.
I'm sure that compared to the iPhone, Android will have more issues with compatibility bugs and general fragmentation, but then Android is also more likely to produce devices that appeal to everyone - that's the cost:benefit of openness. There's a historical precedent to this with the Mac vs PC market in the 80s/ early 90s. Apple lost, remember.
Firstly, Apple examine binaries not source code. Secondly, they're looking for non-malicious usage of private APIs. It's quite easy to build dynamic/obfuscated code that their simple symbol dump process can't detect. Thirdly, as the presentation notes, nothing stops an app from changing its behavior after it was reviewed based on an internet fetch, or date. Fourthly, I don't know how you can think data transfers are "monitored". It's easy to hide data such that it looks boring (like a database lookup) but is actually holding encrypted data.
If you really think overworked humans who review many apps every day can do a useful analysis of natively compiled code, I have a bridge I'd like to sell you....
The problem is that nobody knows if it's really just "a few apps that have sprung up" or if there is actually a systematic problem with apps harvesting your personal details. The companies you're thinking of were busted because they actually phoned the users up themselves en-masse rather than simply (eg) selling the data. The Android approach is far more trustable because it doesn't rely on (very) fallible humans trying to inspect binary blobs.
The first is that yes, some users will not read what is in front of them no matter what you do. Such is life.
The second is that Androids implementation of this dialog is about as good as you'll ever get. I wrote an Android app and was very surprised at how many queries I got regarding permissions. There have been several cases whereby app devs shipped apps that listed permissions they clearly didn't need, and then uploaded fixed versions with minimized privileges (usually it was just a mistake). So social pressure from the people who do read the permissions dialog works surprisingly well.
Androids design is actually really clever. It seemed over complicated to me at first, but as time goes by I appreciate it more. The way intents and activities work makes it easy to build "power boxes", ie, re-usable components that are sandboxed differently to the app itself. For instance, maybe your app would like the ability to dial tech support if the user gets stuck and requests help. But you don't want to list "dial phone numbers (costs you money)" permission in your perms dialog. No problem. You can seamlessly invoke the dialer with your chosen phone number, so the user must confirm to dial. Meanwhile, replacement dialer apps can still be written.
In the case of the iPhone I think the dialer example holds too, except of course you can't replace the built in app. But it doesn't generalize, the iPhone security system is clearly full of holes, and Apples approval process is notorious for being bizarre and unpredictable. It has let through apps that violated users privacy unexpectedly before, several times. So all in all it seems like the Android approach is superior - security holes in the system can be OTA updated within days of being discovered, the OS enforces the declared permission set, and social pressure/market ratings are used by a sufficiently large number of users that devs feel pressure to minimize their requested permissions.
In fairness to Craigslist, they have a pretty thorough anti-abuse system. If you read spammer forums (I do) you'll see that they learn reputation on IP blocks, ad content, links, and force phone [re]verification on anything that looks suspicious. The bar has been raised dramatically over the last 6-8 months, so, they are trying. Beneath the humble covers is a pretty sophisticated anti-abuse operation.
Uh, most languages provide a string type that has methods which could be implemented by the user. Many of them in only one line of code. The point is that foo.trim() is clear to everyone, whereas your construction looks like an ASCII table vomited all over your text editor. If I saw that without any comments, I'd have to take a moment to study what it did and figure out that it's a trim.
The problem is spammers abusing hosted content services to display spam or redirects to spam sites. They do this because spam filters learn what URLs often appear in spam. Anything hosted by Google is going to have a lot of legit users sending URLs around so it's a good place to "hide" the spam.
Their data is just fine. The problems start when people try to share documents that are mis-identified as spam. Non-cloud based word processors don't even offer such a feature, so, I'm not sure you can draw any conclusions about the virtue of the cloud vs other systems from this story.
Slashdot Mirror
Then the costa ricans are free to make their own movies, write their own books, create their own software and invent their own technologies .... I love how the summary spins it as IP violation being essential to education. Maybe a tiny fraction of all US IP would be of assistance to costa rican education, in which case - they can buy it with sugar!
Well, that's what Apple claim. There are two problems with this.
The first one is, how does Apple know what other companies are required to pay? This article claims the agreements are secret and I see no reason to disbelieve that, it'd be standard for this sort of thing.
The second problem is that Apple have sadly established a track record in the last few years of being flexible with the truth, whereas Nokia have not. For example, covering up issues with Jobs' health and playing cute with the FCC over Google iPhone apps. In constrast the only time I read about Nokia in the news is when they've done something cool, like launching a new product.
Simply put, some companies have more credibility than others, and Apple is on the losing side in this one.
Well, people have created thousands of spam apps, apps that upload your phone number to the internet (and those companies then abused them), and it's possible for iPhone apps to also steal a complete keylog of stuff you recently typed in along with all your contacts. Given that Apple frequently pull bad apps only when they are pointed out by third parties, it's quite likely that there ARE phishing apps on the iPhone!
The days when you needed to poke open ports to build a nice botnet died back in 2001. Read this tutorial and tell me that MacOS X isn't vulnerable.
Um yes, and why is that allowed exactly? Anyway, it's guaranteed that there's all kinds of crap on the App Store. I mean, Apple have nuked 2000 apps (2% of their total) for being basically spam (one example) so it's not like their approval process is that great.
I suggest you read this presentation detailed exactly what things an iPhone app can do without you knowing. It's a pretty staggering list.
You have to pay a small fee to list your app on the Android market too. So, I'm not sure where you think the difference is.
No, that's not quite accurate.
The rest of your post, well, I don't feel like responding to each point right now. Suffice it to say, if you want to argue with your users on the market, you're doing it wrong (I say this as somebody who has published his own quite popular Android app last year). I've seen a lot of developers who somehow believe that if users say their app crashes or doesn't work, it's Androids fault! And as an Android user, I've experienced exactly zero app compatibility issues. Maybe you think Android development is some kind of major headache but having done it myself, I strongly disagree.
So your rebuttal is that "musician" as a category of job shouldn't exist? What about fans of drum'n'bass like myself? Doesn't exactly lend itself to live performance .... I guess we're just screwed.
Maybe he doesn't mention it because it's irrelevant? Exposure doesn't matter unless that exposure leads to sales and if people just download stuff, there are no sales. The vast majority of musicians don't play to sold out arenas, right?
From the paragraph just before the Slashdot summary quote:
... and the sentence immediately after it ...
So he's worried about the new guys who haven't made it yet, not himself. If you'd bothered to RTFA you'd know that, but hey, somebody is expressing concern for a future in which the next Bono never makes it thanks to rampant piracy. Obviously he must be an idiot!
Brian Krebs now has a blog. He has written some of the most consistently interesting, unique and accurate coverage of the internet [in]security world in the past few years. Subscribed.
You're talking garbage and have no idea what TXT is or how it works.
Citation please?
There are Android phones (like the developer phones) that let you do that as well. The consumer phones most people buy don't, because the operators are scared of selling completely unlocked devices, but lacking root access is certainly not inherent to Android.
There is a reference phone, it's the G1.
I'm not sure what the big deal is, really. Dealing with users who have older platform versions is a fundamental part of software engineering. Apple certainly isn't immune to that, look at MacOS X. If the iPhone has less of a problem with it, that's only because it's been introducing new APIs at a far slower rate.
But I'm not convinced there really is a problem. All the "Android Fragmentation" stories I read are coming from bloggers who are not active mobile software developers. Android is pretty darn backwards compatible - issues with app incompatibilities are rare, and when they occur tend to be due to Android getting a bit stricter with API usage so the fixes are easy. What's more, the Android system makes it pretty easy to write apps that gracefully degrade down to old platform versions if your app needs newer features, and the emulator lets you easily test each version. There's also a pretty rigorous compatibility suite for people making customized versions of Android.
I'm sure that compared to the iPhone, Android will have more issues with compatibility bugs and general fragmentation, but then Android is also more likely to produce devices that appeal to everyone - that's the cost:benefit of openness. There's a historical precedent to this with the Mac vs PC market in the 80s/ early 90s. Apple lost, remember.
It is not stored indefinitely.
bassdrive.com - 24 hour tuneful drum and bass. It is my aural elixir of programming .
No, what you say is wrong.
Firstly, Apple examine binaries not source code. Secondly, they're looking for non-malicious usage of private APIs. It's quite easy to build dynamic/obfuscated code that their simple symbol dump process can't detect. Thirdly, as the presentation notes, nothing stops an app from changing its behavior after it was reviewed based on an internet fetch, or date. Fourthly, I don't know how you can think data transfers are "monitored". It's easy to hide data such that it looks boring (like a database lookup) but is actually holding encrypted data.
If you really think overworked humans who review many apps every day can do a useful analysis of natively compiled code, I have a bridge I'd like to sell you ....
Why are your goals so low? Shouldn't Apple be showing the rest of the industry how it's done?
MMU based app sandboxing has been adopted on the mobile platform. That's how Android works (and iphone too actually - it just sucks at it).
The problem is that nobody knows if it's really just "a few apps that have sprung up" or if there is actually a systematic problem with apps harvesting your personal details. The companies you're thinking of were busted because they actually phoned the users up themselves en-masse rather than simply (eg) selling the data. The Android approach is far more trustable because it doesn't rely on (very) fallible humans trying to inspect binary blobs.
Well, there are a couple of things to note here.
The first is that yes, some users will not read what is in front of them no matter what you do. Such is life.
The second is that Androids implementation of this dialog is about as good as you'll ever get. I wrote an Android app and was very surprised at how many queries I got regarding permissions. There have been several cases whereby app devs shipped apps that listed permissions they clearly didn't need, and then uploaded fixed versions with minimized privileges (usually it was just a mistake). So social pressure from the people who do read the permissions dialog works surprisingly well.
Androids design is actually really clever. It seemed over complicated to me at first, but as time goes by I appreciate it more. The way intents and activities work makes it easy to build "power boxes", ie, re-usable components that are sandboxed differently to the app itself. For instance, maybe your app would like the ability to dial tech support if the user gets stuck and requests help. But you don't want to list "dial phone numbers (costs you money)" permission in your perms dialog. No problem. You can seamlessly invoke the dialer with your chosen phone number, so the user must confirm to dial. Meanwhile, replacement dialer apps can still be written.
In the case of the iPhone I think the dialer example holds too, except of course you can't replace the built in app. But it doesn't generalize, the iPhone security system is clearly full of holes, and Apples approval process is notorious for being bizarre and unpredictable. It has let through apps that violated users privacy unexpectedly before, several times. So all in all it seems like the Android approach is superior - security holes in the system can be OTA updated within days of being discovered, the OS enforces the declared permission set, and social pressure/market ratings are used by a sufficiently large number of users that devs feel pressure to minimize their requested permissions.
In fairness to Craigslist, they have a pretty thorough anti-abuse system. If you read spammer forums (I do) you'll see that they learn reputation on IP blocks, ad content, links, and force phone [re]verification on anything that looks suspicious. The bar has been raised dramatically over the last 6-8 months, so, they are trying. Beneath the humble covers is a pretty sophisticated anti-abuse operation.
Uh, most languages provide a string type that has methods which could be implemented by the user. Many of them in only one line of code. The point is that foo.trim() is clear to everyone, whereas your construction looks like an ASCII table vomited all over your text editor. If I saw that without any comments, I'd have to take a moment to study what it did and figure out that it's a trim.
The problem is spammers abusing hosted content services to display spam or redirects to spam sites. They do this because spam filters learn what URLs often appear in spam. Anything hosted by Google is going to have a lot of legit users sending URLs around so it's a good place to "hide" the spam.
Their data is just fine. The problems start when people try to share documents that are mis-identified as spam. Non-cloud based word processors don't even offer such a feature, so, I'm not sure you can draw any conclusions about the virtue of the cloud vs other systems from this story.