I don't understand where Rogue Amoeba is coming from here.
They don't have a "right" to be on the App Store. It's Apple's store ergo their rules. And everybody knows that the rules are more guidelines and Apple can and will change their mind about them at any time. Especially if you try and undermine them e.g. by using their private encryption key.
Does it suck. Absolutely. Is it unfair. Probably. But this has been the game for the last 3 years and Rogue Amoeba should not act surprised.
Removing an app from the store is one thing. Bending the truth or outright lying to your own customers in order to deflect blame for a decision that you made arbitrarily is entirely another. The fact that this nonsense is coming from a high-level Apple employee and not some customer service rep who can claim not to have known the truth makes it worse.
I agree that it is ridiculous the way Apple basically changes the rules as it goes along. I just don't understand the outrage or surprise. There has been 3 years of developers trying to bend the rules and posting complaints like this.
FACT: They reverse engineered Apple's proprietary technology and want Apple to help sell their app.
MY POINT: You must be nuts if you think that will happen.
I just don't understand the outrage or surprise.
The moment we get complacent is the moment we lose. What's the worst that can happen from trying or speaking up? At worst Apple says "no", and maybe the public becomes more aware of the situation and thus might feel compelled to apply pressure to Apple. This is the reason for the outrage.
One interesting question is whether or not this sort of thing will be grounds for revoking a Gatekeeper certificate. Apple certainly could argue that accessing AirPlay streams without proper authorization is a form of malware / something they have to police because of agreements with content providers / etc
I know commenting just for the sake of agreeing is advised against, but this time I had to. If there's an outrage over app store rejection for these reasons, then imagine the reaction to gatekeeper cert revocation for the same reasons.
That's the thing. To me the level of outrage seems startlingly low, plus Apple seems generally impervious to outrage in general. In my opinion, this does not bode well for the future.
What? Schiller lays out the reasons the app was rejected quite clearly. Rogue's response is to suggest that these issues are ambiguous because it hasn't been clearly defined by Apple. Well, guess what, now it has. Rogue should've just let it go.
I don't know how you can come to the conclusion that this is an arbitrary decision by Apple, or that Apple is lying about something in the matter. It seems clear to me that even though Apple keeps using the term "approved API" what they mean is "the AirPlay encryption key that you don't have a license for". It's an odd use (or misuse) of terminology but it doesn't change the facts.
"We have an Airplay licensing program explicitly to assist companies in creating AirPlay capable products. Apple never said that we would pull the rug out from anyone, we in fact worked with this developer to ensure they update their app and remain on the App Store"
The clear implication there is that Apple had procedures available for getting this to work and RA just ignored them. RA's response directly contradicts this.
RA did state that they inquired as to licensing it for a software product and were told that there were no plans to make that available. So, they didn't ignore the procedures as much as they ignored the response.
In the end it's Apple's store with Apple's rules. The rules have changed without warning in the past and will likely do so countless times in the future. The tradeoff for this is what is likely one of the most lucrative app stores to date for developers.
Except if you build a system to which millions (yes, millions) of people contribute in one way or another, pretend everyone's invited, and then decide to do something very self-righteous against the good of nearly anyone else involved just in order to feed your fat butt, then you are labelled an oppressive, opportunistic sociopath, and very rightly so.
Sadly, that's not the way it's being marketed to the masses of developers. You're talking about what seems to be a technical detail to someone who's been corporate-brainwashed by the apple reality distortion field (maybe they're keeping Jobs in stasis in order not to lose it?). Then, SURPRISE!!! it's not such a technical detail after all, apple has tricked you so! It's like a surprise birthday party, except your gift is a burning bag of dog poo.
Typical corporate trickery. The reason a lot of people fall for it is because they have an open mind (definitely advocated by Apple) and therefore are gullible (definitely wanted by AAPL).
Having written something somewhere doesn't make you less of an asshole for handling in a dirty, asocial way.
> Bending the truth or outright lying to your own customers in order to deflect blame for a decision that you made arbitrarily is entirely another.
This entire sentence applies to Rogue Amoeba. The Airplay protocol has been reverse engineered years ago: it's basically RTSP with an encrypted stream. Creating an AirPlay audio receiver is currently subject to a license, and requires a private key. This key has been extracted from a dumped AirPort Express ROM. Rogue Amoeba can say what they want about reimplementing the whole AirPlay protocol on their own, the clef-de-voûte is this private key, only available through licensing. When Schiller mentions private APIs, I believe he is not talking about an iPhone private API (which I'm positively sure Rogue Amoeba took great care of not using) but the remote AirPlay API, which they have no right to use without licensing.
The key point here is that there's a key virtually locking the API. I think it's perfectly apt to say now that — thanks to the Google/Oracle case — implementing an API is licit, but you would subsequently have to use your own public/private keys. Yet existing AirPlay sources encrypt the stream with Apple's public key, hence the content is at the sole destination of Apple's private key.
Compare this to the following situation: you publish you PGP public key and someone writes you an email and encrypts it with your public key. If someone steals your private key, that does not entitle him to decrypt and read the message whose sole intended recipient is you. This is, I believe, the crux of Apple's AirPlay licensing.
I generally don't like Apple's silent hammer, and I really like Rogue Amoeba and their software (which I bought multiple times), but — since I knew what was in play technically — when reading the last status report of Rogue Amoeba, it was obvious to me that they were concealing information with the goal of bending the truth to support their side of the argument.
Exactly. Despite Apple's schizophrenic application of their guidelines, Rogue Amoeba simply needs to take responsibility for everything you pointed out here. To continue to do otherwise is unprofessional and only hurts them in the end. Apple will continue to make billions.
P.S. Who else had to Google clef-de-voûte? FYI: It basically means "most important component" or "key element." (via bab.la)
Why is it that in every thread discussing Apple's potential misbehavior, people bring up their extreme profitability as if that were somehow relevant to the question of right and wrong? Drives me nuts.
I guess the argument(I don't really agree) is that ~99% of their customers don't know about all this and don't care, thus Apple need not care about some random developers because it doesn't hurt sales in the least and that Apple exists to make money for their shareholders and not to foster openness and innovation or necessarily doing what's right for their users.
> When Schiller mentions private APIs, I believe he is not talking about an iPhone private API (which I'm positively sure Rogue Amoeba took great care of not using) but the remote AirPlay API, which they have no right to use without licensing.
A key is not an API. AirPlay is not an API. Full-stop.
Whether Rogue Amoeba was wrong to do this or whether Apple was right to ban them or whether reasonable observers could have predicted the banhammer is not at issue in this thread.
The issue is--Phil Schiller mislead a customer by describing Rogue Amoeba's behavior in a factually inaccurate way. Rogue Amoeba's blog post picks apart these inaccuracies like shooting fish in a barrel. I studied Phil's e-mail and I found exactly one sentence that I thought was accurate.
Sure, Apple can remove this app from the store. They should either just say that, or not respond to the customer at all. Somebody who has made a decision that he/she feels confident about has no need to slant the facts and make misleading statements. Whether or not Apple was right to do this independent of the fact that they were wrong to discredit Rogue Amoeba in an inaccurate way.
AirPlay is a remote interface allowing a local application to control software on a remote device and stream data to it. I could implement it over HTTP as a RESTful API or whatever way I see fit and however simple and thin it would be†, it is still a way for applications to programmatically interact through an interface, hence, an API.
But again, this is not a problem since we can now safely implement interfaces without fear.
> Rogue Amoeba's blog post picks apart these inaccuracies like shooting fish in a barrel
... and (assuming that one thinks they scored) misses the elephant in the room. encrypted AirPlay audio streams. Rogue Amoeba knows about this. Apple knows about this. The only party concealing that fact is Rogue Amoeba, and they're entirely disingenuous about it. Since the very first developments (and really, since their announcement of the feature upon release) people have been wondering about the inclusion of the Apple private key; yet Rogue Amoeba stayed quiet on the subject. What I expected of them was at some point to directly answer the question "did we use the Apple private key?" with "yes" or "no".
Again, whether I put a license or not to use my PGP private key, no one has the right to pick up content encrypted for me. They basically created an eavesdropping piece of code.
And this is true for any licensing scheme. If there's no license satisfying my will, I have no right to take it anyway. Rogue Amoeba even goes to admit:
> While Apple licenses the ability for hardware manufacturers to play AirPlay audio, there is no such licensing program for software. When we inquired as to the possibility of this type of licensing being available for software manufacturers in the future, we were informed that it was unlikely.
Then they decided that since there's no license covering that case, they have the rights to build something respecting the AirPlay API (they do) and decrypt data with a stolen private key (they don't). And went on to build it and sell it, get kicked out, complain (rightfully so regarding opacity, laconic answers, and delays), and ignore the most critical part in all subsequent communications. How cool is that?
Now the fact that Apple has no explicit licensing scheme for software manufacturers is a blind spot of their part, but who honestly believes that hardware manufacturers implement their AirPlay receiving devices as pure hardware? I bet the licensing terms could apply just as well to pure software endpoints.
> Whether or not Apple was right to do this independent of the fact that they were wrong to discredit Rogue Amoeba in an inaccurate way.
And the same applies to Rogue Amoeba.
† AirTunes has a HTTP control channel used to negotiate details, AES key exchange via RSA encryption, a remote volume knob, metadata transmission, progress information, and a data channel for audio streaming that can be suspended without closing the stream. http://git.zx2c4.com/Airtunes2/about/
> AirPlay is a remote interface allowing a local application to control software on a remote device and stream data to it.
The first issue with calling this "using a private API" is that the part of the application under dispute doesn't open a connection to any remote service--but accepts connections from incoming Apple hardware. It is much more correct to say that Apple is "using a private API" in this case.
The second part of the problem is that even if Rogue Amoeba was initiating connections to AirPlay clients (which they are not, at least not the part of the program under dispute), this would not be an "API" as it is usually defined.
For example, OED calls an API:
> a system of tools and resources in an operating system, enabling developers to create software applications.
Wikipedia says:
> In general the difference between an API and a protocol is that the protocol defines a standard way to exchange requests and responses based on a common transport and agreeing on a data/message exchange format, while an API (not implementing a protocol) is usually implemented as a library to be used directly: hence there can be no transport involved (no information physically transferred from/to some remote machine), but rather only simple information exchange via function calls (local to the machine where the elaboration takes place) and data is exchanged in formats expressed in a specific language.
The rest of your post deals with whether Apple is right to do what they did or whether Rogue Amoeba is right to do what they did. Did you even read my reply? In this thread, neither of those two positions are relevant. If Rogue Amoeba had broken into Apple Headquarters and personally tortured Steve Jobs to extract the private key, that would not be relevant. What is relevant is whether Phil Schiller lied and misrepresented Apple's position in a dishonest way.
Let me break down, specifically, the misrepresentations, in numerical form for easy reference:
1. "not accurately recounted on Rogue Amoeba’s website." In what sense exactly is Rogue Amoeba's website inaccurate?
2. "accessed encrypted AirPlay audio streams without using approved APIs" this implies that there exists some approved APIs that RA could have used. Again, whether Apple should or should not provide these APIs is not relevant, what is relevant is that Phil implies that usable APIs exist when they do not
3. "or a proper license" This implies that a proper license exists, see 2. Again, not relevant whether or not Apple should or should not provide a license to RA, only relevant that they imply RA had the option to use it and did not
4. "in violation of Apple’s agreements" This may be in violation of agreements that Apple has with various hardware manufacturers, but this statement implies that RA is bound by these agreements or even knows or can find out what is in them. They cannot. Essentially, Phil is holding RA to a secret standard.
5. "Apple asked Rogue Amoeba to update their app to remain in compliance with our terms and conditions" According to RA, Apple ignored RA's questions for clarification for several weeks.
6. "We have an Airplay licensing program explicitly to assist companies in creating AirPlay capable products." - This implies that RA could have taken advantage of the licensing program and did not. In fact RA could not have taken advantage of the licensing program. Whether this is good or bad is not at issue; the issue is Phil is misleading the customer.
7. "Apple never said that we would pull the rug out from anyone" - iOS guideline 2.20, 3.10, 6.3, 22.7, and others explicitly say that Apple will pull the rug out from under developers. Whether or not these are reasonable or unreasonable guidelines is not at issue in this thread; the issue is that Apple does in fact say they will do it and Phil claims they will not.
8. "we in fact worked with this developer to ensure they update their app and remain on the App Store" For some definition of time e...
> this would not be an "API" as it is usually defined.
I beg to differ, and consider both definitions you subsequently give as incredibly restrictive as it would exclude some of the most used APIs in the wild. Everyone in the field will call the Twitter API an API, and everyone will agree that StatusNet implements the Twitter API.
That said, the consumer of the API is indeed AirPlay clients while the API is being served by Apple TV, Airport Express and AirFoil Speakers (Touch). But again this does not matter (and even if we called it a protocol, and really here we have multiple protocols at hand) and RA would have every right to implement it (just as Google implements the Java API, or Wine the Windows API, or StatusNet the Twitter API).
1. It is inaccurate in that it misses one of the most critical points of the discussion.
2. I agree that RA (probably) did not use any non-approved iOS API and that they have every right to implement the AirPlay API/Protocol. I maintain though that they can not make their implementation interoperate with existing AirPlay clients that encrypt the stream. Whether that falls under the "approv[able] API" wording is a stretch, but nonetheless possible. Even RA considered that case in their May 29th post. But this does not matter, since the rest of the phrase is linked to this one with "or".
3. No this does not. This says: "you do not have a license to do that". The fact that no such licensing scheme exists is relevant only in implying that they simply can't do that at all.
4. Apple's iOS developer agreement being quite vague, I'm pretty sure they could fit almost anything they want under this agreement, and this is bad.
5. According to RA, Apple rejected the app because they deemed it non compliant, and as such they "asked Rogue Amoeba to update their app to remain in compliance with our terms and conditions". Not detailing what was not compliant, however rough, does not make the previous statement false. The first Apple answer seems like the usual preset, generic and despicable answer. If anyone takes time to analyze and invalidate an application to such levels of detail, they should disclose their full process and reasons to reject the app together with the app rejection.
6. They do have a program, and it appears to exclude software makers. I find it very sad that it comes to such an escalating situation to at least extend the current licensing scheme to software manufacturers.
7. Agreed.
8. Both the part you cite and the point you make are entirely true, and the second part is simply outrageous. Apple definitely has to improve on that front.
So, did Schiller wrote an inaccurately worded letter? Sure it did. And while they handled the case in a heavy handed and awkward manner, can we call those purposeful lies? It might be, but I'm really not convinced. In the meantime Rogue Amoeba recognizes they "inquired as to the possibility of this type of licensing being available for software manufacturers in the future, [and being] informed that it was unlikely" yet still trying to push the update through approval.
What's more they go on to say, regarding accessing the encrypted content:
> "Quite simply, it is not. While there are multiple layers of encryption involved in the AirPlay audio streaming protocol, their primary purpose appears to be preventing third parties from building applications which interoperate with AirPlay."
In a word, they assumed they had the right to circumvent a mechanism protecting Apple's licensing scheme (however vile we think it is WRT interoperability), made a run for it, were caught red handed, and called out the web regarding the injustice. Maybe they genuinely believe they're right, but that does not make them the good guys.
To sum this up, I believe both sides are at fault, but I'm much more inclined to say that they are all acting in good faith, and that such matters would resolve with much less friction if there was not so much tension (mainly due to delay and opacity, which only increase t...
> I beg to differ, and consider both definitions you subsequently give as incredibly restrictive as it would exclude some of the most used APIs in the wild.
You'll have to take that up with OED and Wikipedia. I think it's fair to say that at the point that they agree with each other and disagree with us that we're the ones using the words wrong rather than them, and it's us who need to invent new words rather than they. That's what it means to be a language authority.
#1 seems like an overall summary statement so my response is implied by the below
#2 I can't detect any disagreement
#3 - "you do not have a license to do that" - They also don't have a license to rent a bouncy castle. Phil isn't listing things that they don't have a license to do, he's (attempting to) explain why Apple rejected the application. He's implying that a license exists.
4. The word "violation" has a specific legal meaning. In this case, I can tell you for sure that he's specifically referring to agreements that Apple has with hardware manufacturers (which actually say you cannot do this explicitly), which RA has never read
5. I will concede that Phil's statement is technically correct, but when you consider how the average customer would interpret this statement, it leads them to an incorrect conclusion.
6 & 7 - No point of disagreement that I can detect.
8. No point of disagreement that I can detect.
> can we call those purposeful lies?
Phil is on the board of directors of a publicly traded company and society holds such people to an extremely high standard of honesty. I'm not sure why the word purposeful is of any relevance, but they're certainly misleading statements and Phil Schiller is not employed by Apple to blab whatever he thinks of to say to random customers.
> In a word, they assumed they had the right to circumvent a mechanism protecting Apple's licensing scheme (however vile we think it is WRT interoperability), made a run for it, were caught red handed, and called out the web regarding the injustice. Maybe they genuinely believe they're right, but that does not make them the good guys.
The following set of words: {right, vile, made a run for it, red handed, called out, injustice, good guys} ascribe a certain moral narrative to this situation that I do not subscribe to at all. There are a lot of very worldviewish questions in here (e.g. what it means for a software company to be moral, whether morality can be meaningfully ascribed to a company, etc.)
I don't mean to dissuade you of these views, because I imagine that if we take the time to wade through it, we will discover that each other's positions are pretty reasonable. But that would require us to wade through a lot of psychology, philosophy, religion and ethics to arrive at that point, and so in the interests of time I would recommend steering clear of ascribing particular ethical conclusions to the actions of actors except in the narrow cases where it is actually important, in which case we must be willing to defend it at some length.
One such area (of valuable exploration) is whether, assuming Phil made misstatements in his e-mail, it was morally correct to send. I think we agree on enough of the points to conclude that these misstatements did exist, and so the problem reduces to whether a corporate director sending misstatements to a customer is immoral. From your reply, the operative test seems to be whether they constituted a purposeful lie which is, at the very least, an interesting test.
I don't think they're making the right case in that response. It should be focused solely on the "this should be allowed by Apple" argument, because telling users that it's not illegal doesn't matter when it's Apple's store and Apple's rules, for better or for worse. They say that the encryption around AirPlay streams appears to primarily be there to prevent third parties from creating applications that work with AirPlay—so it's easy to assume that Apple wouldn't approve of something they tried to prevent.
Is releasing something you know will get kicked out the best approach to take when you can't provide an approved solution? Maybe, if you think the resulting discussion and PR is your best chance at getting things changed... but then, again, you need to keep your message perfectly focused. Claiming that they didn't violate any agreements feels too defensive to me.
EDIT: and it's not just this response... initially they professed something much closer to ignorance/surprised innocence over the removal, while it now looks like there wasn't much reason for any surprise.
> "... Reverse engineering is, among other things, largely responsible for the PC revolution and the computing landscape we enjoy today. Should we stop providing users with products that work together simply because other vendors dislike competition?"
We all know Apple loves reverse-engineering of its products, so I'm sure this kind of reasoning helps your case.
Bear in mind, however, that reverse engineering is also respected at Apple (or it used to be, a couple years ago). I remember reading a story where Steve Jobs personally visited and tried to buy Dropbox, because they reverse engineered Apple's file system, or something like that.
Don't know why they'd need to do that, what i suspect it could be would be reverse engineering the kernel interface to add their own. That way they can do a very much nicer automatic sync with their service that won't have as many issues. I believe they do it that way on linux with FUSE and with IFS on windows.
Reverse engineering for interoperability is protected by law, regardless of Apple's wishes. So it helps their case for legal purposes, just not in the app store court run by Apple.
The problem here is that Apple's wishes can be and are regularly applied in the app store regardless of whether they're actually good for the users(disallowing malware is good). This is a nasty side effect of the app store model and we'll be seeing more of such issues in the future with the Windows 8 Metro app store.
This is going to backfire on Apple. It is absurd the lengths they are going to. Imagine if when you bought a car the manufacturer tried to control what stereo you could install. "We made this car, and you have to play by our rules." Insane.
Actually, controlling aftermarket parts is crucial to automakers. Add nitrous, void your warranty. Modify chip, void your warranty. Make a cosmetic change, no problem.
Is the warranty the issue here? Isn't it the right to add some functionality to the device? I could see your point if there was an argument between Amoeba and Apple about voiding warranties. But I don't see that being the issue.
A warranty is just a contract, much like the contract put in place that allows Rogue Amoeba to sell software on the iOS and Mac platforms.
Adding in support for AirPlay to an app and selling that won't void your or my iPhone's Warranty if we were to install it, but it can void the contract put in place between Rogue Amoeba and Apple, if even just for that singular app. Here is the real reason Apple threw this app out of the store: http://news.ycombinator.com/item?id=4087666 RA was using a private key derived from a firmware update for the Apple Airport Basestations in order to encrypt the audio stream in accordance of the AirPlay protocol.
That reason makes Apple look worse. The example of PGP is silly. PGP is an open protocol. The user can control their own encryption. Apple like Adobe wants to take an open protocol for streaming, in Apple's case RTSP, and make it proprietary. And like Adobe they are finding this is not so easy. The more they seek to exert unreasonable control over how people use devices they have already paid for, the more motivation they give for people to find workarounds. There are benefits to everyone in having open protocols, as the thousands of examples in the RFC's demonstrate, but the only benefit of the "AirPlay" protocol is to Apple. Making devices that can only communicate with other devices you make is dubious business where networking is concerned. It just make everyone's life more difficult- except Apple's. You can't blame people for trying to get devices and accessories made by different manufacturers to work together. RA should not even have to jump through these hoops. These devices that Apple makes should be able to network with devices from other manufacturers. We do not need an "AirPlay" protocol controlled by one company.
Well, car manufacturers have certainly not been very aftermarket-friendly with their center stack over the past decade. It might actually be fairly similar after all:
Want a custom stereo in your new car with a fancy center stack setup with a non-standard-size stereo and possibly even integrated AC/heater controls? You're going to have to jump through a lot of hoops. Want software with more functionality than Apple exposes to developers? There's always jailbreaking...
In neither case has there been a substantial consumer backlash.
What hoops? If the purchaser wants to install a stereo he can choose to do it himself or take the car to a shop that installs stereos. What's happening in this case is, roughly, by analogy, the car manufacturer is trying to exercise control over a shop that is selling stereos that can be installed in the car. Is that overreaching? Would consumers complain if a car manufacturer actually tried to do that? The factory installed stereo better be very good.
Go look at a car from the 90s with a DIN or double-DIN stereo, then go look at one from the past five years, where the prevalence of nonstandard sized stereos has gone way up, as has the complexity of how tightly coupled they are to the rest of the car. Those are the hoops. I don't think the manufacturers are upset at all that one of the side effects of this trend has been to make aftermarket head unit installs a lot less convenient.
And I don't know any manufacturer that will sell you someone else's head unit as an aftermarket piece. It's up to you to find out how to take everything apart and fit something else in there on your own, or to find someone who knows—basically, jailbreaking your dashboard. Except you generally lose stuff (like steering wheel controls), while I hear jailbreaking is pretty painless these days.
Edit: Apple's app store isn't some third party stereo store, it's a store owned by the manufacturer itself. And car manufacturers are famous for having highly priced proprietary replacement parts, especially when it comes to electronics like stereos, if you aren't willing to deal with an outside store/brand. I really don't see any way Apple's less flexible with the iPhone than a car manufacturer is with their cars.
Agreed. I simply wanted to point out that the car manufacturer does not actively try to prevent the car owner or the installation shop from installing a stereo. However Apple does this with their devices. Everything must pass through Apple even after the sale is complete and the user owns the device, and that is just absurd. I can't imagine what older Macs that we used for audio applications would have been like if all software had to be approved by Apple. Apple does not have the expertise to write all that software. When I say Apple's strategy will backfire I mean that the more tightly they try to exercise control, the easier jailbreaking is going to get. The auto manufacturers may have made it very difficult to do stereo installations on newer models but they are not actively trying to interfere with stereo makers and installers after the car is sold. And why should they? The buyer made his choice when he bought the car whether he wanted any factory installed audio options or not. If after the sale the buyer wants to buy parts, or get service from an authorized dealer, she can do so. But the manufacturer does not try to interfere with her choice to get service (e.g. stereo installation) elsewhere. Imagine if every car stereo maker had to get approval from car manufacturers and could only sell their products in the manufacturer's distribution centers.
Bought a Jetta in 2000. Best car I've ever owned. Didn't like the stereo though. Tried to replace it with an aftermarket system and was told that doing so would void the warranty on the door locks, the car alarm, everything wired into that cabling system. I lived with it for ten years til I sold the car, but it's one of the first things I ask about when researching a new car purchase.
It's one thing to make the center console non-standard, it's another to prevent the installation through warranty restrictions.
I'm reluctantly siding with Apple on this one. Rogue's response is pretty pathetic. Hijacking audio streams is obviously something Apple might have a problem with.
The hypothesis that it has to do with Apple preparing to bring out a competitive offering is laughable. Airfoil would not have a gram of impact on anything Apple does in this realm.
Rogue conspicuously makes no mention of this part: "Apple asked Rogue Amoeba to update their app to remain in compliance with our terms and conditions."
"Hijacking audio streams is obviously something Apple might have a problem with."
But it's not Apple's audio stream, it's the user's audio stream. I don't think it's particularly unreasonable to expect that user should be able to decrypt his or her own data (assuming we're talking about data that isn't under DRM; DRM is another issue).
assuming we're talking about data that isn't under DRM; DRM is another issue
Though AirPlay does work on DRM'ed streams, there's little advantage to using that over simply recording from the audio out from your computer and no advantage over using something like Audio Hijack Pro (another Rogue Amoeba product) or Soundflower to record the audio output of your computer.
Please entertain my crazy analogous thought processes for a minute...
Imagine you were eating out at KFC one night, and using taste alone, you managed to work out their secret recipe. You then decided you wanted to get into the fried chicken business, but you didn't want the overhead of renting commercial space, or buying the kitchen/service equipment you need to run your own business. So you choose to walk into your local KFC, use their kitchen to fry your chickens, wrap them up in all the KFC packaging and branding, and begin to sell them at their counter. This goes unnoticed for a few hours, but then the manager notices what you're doing, and points you towards the exit.
Surely you'd understand why KFC wouldn't let this behaviour continue. You didn't steal their recipe; you worked it out on your own. You're perfectly within your right to sell chicken based on this recipe, but you'd better do it at your store, and put your own label on it. If KFC don't want you selling products based on their recipe (however legally you discovered it), you can't wrap them in KFC packaging, and you certainly can't sell them at KFC.
The analogy doesn't work. iPhone users can only get apps from the Apple store.* Also, Rogue Amoeba isn't deceiving users. People who buy Airfoil know that it's not made by Apple.
*I know someone will bring up jailbreaking. Jailbreaking is not a solution. It's difficult, voids the warranty, and can cause issues with stability and software updates. It's a non-starter for the vast majority of users. By limiting Airfoil to jailbroken phones, Apple kills 90% of Rogue Amoeba's revenue.
The analogy still fits. I was suggesting that they don't build apps for iPhones, Apple TVs, Macs, etc. You can't put your chicken in a KFC bucket, even though you worked out the secret recipe. You can't put your app in an iPhone, just because you reverse-engineered a piece of technology.
> By limiting Airfoil to jailbroken phones, Apple kills 90% of Rogue Amoeba's revenue.
Although you're right in saying this, it's only because 100% of Airfoil's revenue comes from the App Store. If they had revenue streams outside of the App Store (by choosing a different platform or devices), Apple wouldn't be able to block a cent of that income.
While I agree his analogy stretches it way to far, being in the app store says Apple approves of what you are doing(you know that whole approval process thing.) Apple doesn't approve so it isn't there anymore.
Note: Just to make things clear, I support Apple's decision here.
You're ignoring the fact that according to your analogy, our hypothetical KFC is already allowing people to make and sell different sorts of food with KFC branding from within their store (as long as you give them some of the proceeds and pay an annual fee, which was the case). In fact, a lot of people come to KFC precisely because they have an unmatched breadth of delicious and affordable dishes, and many people want to sell their wares at KFC because of their large clientele - KFC has successfully transformed into a food-court.
The hero of your post devised a delicious dish that would lose its flavor without the KFC secret sauce, but unfortunately for him, KFC only allows condiment manufacturers to use their secret sauce, and then only after a certification process to make sure they get the unique taste just right. Of course, they could, say, taste the delicious dish, realize that it's providing them with direct revenue, as well as satisfying consumers and increasing the odds they'll return to the food-court and spend more money.
Analogies aside, I understand why Apple does these sorts of things - first of all, they want consistency in UX since there really was no certification process. Also, keeping the ecosystem tightly under their control is much easier when you're very consistent about being draconian from the moment the platform was created (you go to the app-store, you play by their rules).
As a side-note, I'm surprised that there's so much support for Apple with these sorts of things when 15-20 years ago the same crowd would have been up in arms if Microsoft were to, say, send cease & desists to Samba or Wine (and still is criticizing Microsoft for disallowing other OSes in WinRT ARM devices).
I thought hard about the point you raised when I was putting together my original post. I tried to think about the hero as someone standing on the same footing as condiment/drinks manufacturers, who unlike the hero, play by the rules. They can sell their wares in KFC without needing to know the secret recipe. Airfoil used the secret recipe, and was punished for it.
Perhaps I got a bit lost when I chose to have the hero sneaking around, using equipment and service counters without the knowledge of the management, as that doesn't exactly parallel the App Store approval process. Although, seeing as Apple regularly approve apps only to pull them at a later date because of undetected features/activities, our hero's actions aren't too far-fetched.
P.S. I love that you played along with the analogy. In hindsight, KFC was a terrible choice, but I'm glad it opened up a bit of discussion.
I was never on Rogue Amoeba's side. Phil Schiller's response totally the reasoning and response that I felt was correct.
Not letting this issue drop just paints Rogue Amoeba in a bad light and confirms their immaturity to people like me who already thought they were in the wrong. Add to the fact that the feature is still in the app (you just need to upload a plist file) and I won't be surprised if Apple totally bans the app and takes further action with the developers and suspends their account.
Rogue Amoeba wrote code that implemented a network protocol. Apple pulled their app because they did not ask Apple to license that network protocol. Which protocol will Apple claim you need a license for next? HTTP?
The fact that encryption is involved is completely irrelevant.
AirPlay is a proprietary protocol stack/suite. Apple chooses to license this on their terms. This is their technology to for their competitive advantage to use against companies products such as say your company, Google.
Apple does not want an unlicensed and unauthorized app to use AirPlay on their app store. Case closed.
AirPlay isn't HTTP so don't compare the 2. Your comment about encryption is moot.
It was at one point. But then The Internets figured out how it worked, and now it's as easy for someone to implement as any other open protocol.
Remember: no particular legal protection applies to protocols. Apple is kicking Rogue Amoeba out of the app store out of pure malice, not because of any law that was violated. ("We'd like to sell you this product, but you figured out how to make it yourself, so you're gone.")
Well said. iOS is Apple's best achievement, but it is also his own toy and he don't really want to share it with you. Face it, he's not going to change, and we should really leave him alone with his own balls.
We, the hackers, can do anything we like with Apple's gear.
At the same time, Apple is under no obligation to make it easy for us to trample on their licensing deals for technologies that form part of Apple's unique selling proposition in a consumer's mind. AirPlay is so well implemented, consumers find it magical. To keep that mystique, Apple has a right to review and license AirPlay to those vendors that it finds aligned with its long term goals. If you want Apple to be forced to do something different, you're not a "hacker", you're on the side of big government and "Big Brother" demanding to oversee and meddle in a company's right to sell the product it wants that works in the way that it wants.
Finally, I personally want to encourage the hell out of a computing environment that makes everyday people find computing approachable and fun. Just as you don't want a power outlet that needs constant tweaking before you can plug something in, normals don't want a computer or smartphone that requires maintenance just to be able to have fun and get things done.
Apple's forced the mainstream computing industry to stop designing for ourselves, and start thinking about everyone else. This is why computing has finally gone viral.
Did you use that first Mac? It was never about "open" or "hackable", it was about appliance computing that gets the computer out of the user's way.
Nothing has changed since Apple's 1984 when Apple adopted the slogan, "The computer for the rest of us."
Nobody is suggesting that Apple should be forced to make their devices open.
Nobody is forcing you to buy Apple's products either. The solution is perfectly laissez-faire: Stop buying them. There are plenty of hacker-friendly alternatives to Apple products which, while not quite as pretty, are still fun to use - and often enable "magical" features like the ability to use an international SIM or free WiFi tethering.
>Once more, a reminder that we - the hackers - should stop giving Apple our money. This is not the kind of computing environment we want to encourage.
And hackerism is not the computing environment Apple wants to encourage. Besides the obvious benefit of more control = better stronghold of their market, Apple is also philosophically in favor of closed, well defined systems and minimal end user confusion, not pro open-ended, experimentation lands, "we give you the building blocks, you make it whatever you want".
And, as much as I like the notion of open systems and hacking, there should be room for the other side too, systems that are designed top-to-bottom and sold "as is".
I believe that history has proved that while it is possible to get quality UIs from open ended/open source style development projects, you get them with LESS consistency that you get them from an Apple-like process, and you also get more competing stuff/chaos/design by committee, unless you coordinate the whole process, from the kernel, to the end user apps.
Open source projects are mostly islands, so you don't get to have that long term vision / whole stack co-ordination.
To put it another way, an OS called OS X exists as ONE thing where one person had ultimate responsibility for what's included and in what shape to ship it. An OS called Linux does not: it only exists as disparate things collected and distributed together (a distro). The Gnome desktop environment, for example, is not produced for a specific OS: it's produced for whoever wants to use it, from various flavors of Linux, to FreeBSD, its apps even run on OS X.
>It's time for someone to re-edit Apple's 1984 commercial and swap the logos.
Why, did Apple ever changed course? The Mac was about a "computer for the rest of us" (ie simple users), and it remains the same now. Neither Mac, nor the 1984 ad was about tinkering. It was about empowering people with simple technology (a simple spreadsheet, a simple text editor, etc), not about empowering hackers to build things.
Actually, now, with the Unix underpinnings, the Mac is also a computer that lures tons of hackers (prevalent in any programming convention and most alpha hackers use a Mac, --even Linus, although he runs Linux on it), but the main market for Apple was an is the common user.
"Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently. They’re not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them. About the only thing you can’t do is ignore them. Because they change things. They push the human race forward. While some may see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do. - Apple Inc."
This wasn't just a single marketing campaign. It was THE marketing campaign. They even played the Steve Jobs narrated version at the Celebrating Steve event. After reading the Steve Jobs biography, I'm pretty sure that he and the others at Apple truly believe that this campaign represents Apples values.
Is worth remembering that usually the people who are crazy enough to think they can change the world, are also actually crazy and it isn't always good when they succeed.
If anything, I think it's truly sad that, given all the great things Apple has made, their legacy seems to be that closed and proprietary is better. It's the IT equivalent of "greed is good".
iOS would be just as integrated and nice if Apple released it as Open Source. But it would give people more choice, Apple would make make less money from it, and they would then be at a disadvantage compared to other companies that did control their entire ecosystem.
The problem is that closed, proprietary systems tend to create monopolies, and while the initial products may be great, monopolies are seldom good for customers.
The other mistake people make is thinking that closed or open is an either-or proposition.
Apples nice iOS ecosystem wouldn't be destroyed overnight if they had a settings option marked "allow unsigned third party apps". Would that compromise their long term / whole stack vision? No.
What I'm hearing from this comment and all sentiment that agrees with it:
My mother should never experience the benefits a computer can bring to her life because the only device she could understand how to use would be something like an iPad—and since the iPad is made by a company that isn't 100% open, it shouldn't exist at all. Everyone should use Ubuntu, and if you can't use it, it's because you're too stupid and thus don't deserve to have a computing device in your life. Open source principals are more important than anything else, and they must be applied in a binary fashion, scaled across all approaches to computing in the world.
----
A pet peeve of mine is "hackers" ignoring design, and showing zero empathy towards humans [1]. Perhaps we need more designers in the world and not more hackers who stick tight to principals, often completely blinded by these binary maxims they drum up to the real end goal: enabling our species to advance.
This is a false dichotomy. Just because your mother uses iOS devices (and probably a lot of other closed devices) doesn't mean you should.
You, presumably, are a hacker. While hackers represent a small part of the population, they represent a very important part of the market - the part that builds the wider ecosystem. We have a disproportionate effect on the evolution of technology. Use devices that advance an agenda that should be important to you - the ability to make devices do what you want, not what its manufacturer wants them to do.
Besides, you make the non-Apple world sound more bleak than it is. While Android is not quite as polished as iOS, it's perfectly usable by nontechies.
It's plausible that Apple has agreed not to distribute AirPlay client software in agreements with AirPlay hardware licensees, and (unfortunately) also plausible that the details of these agreements are under mutual NDA.
In other words, it's (disconcertingly) conceivable that Apple is contractually obligated to reject Rogue Amoeba's feature without a good explanation.
The talk about the DMCA and reverse engineering is a red herring - Apple is not taking legal action against Rogue Amoeba.
You're seeing the full power of Apple's control over the app store, though - they can stop distributing apps they don't like for any reason. The same power that Barnes & Noble has over the book market, and your cable provider has over your local TV market.
would this guy be ok if someone 'reverse engineered' his email password.
Every product wants to protect its IP in some sense...google won't like if someone reverse engineered their search ranking, apple won't obviously like if someone hacked the iphone to run android, intel won't like if someone was able to reverse engineer the chip design and then sell it for a tenth of the cost..heck would these guys like if I was able to hack their app and bypass the license check?
Certain internal software API's are as much intellectual property as is the physical hardware design.
96 comments
[ 1.7 ms ] story [ 169 ms ] threadThey don't have a "right" to be on the App Store. It's Apple's store ergo their rules. And everybody knows that the rules are more guidelines and Apple can and will change their mind about them at any time. Especially if you try and undermine them e.g. by using their private encryption key.
Does it suck. Absolutely. Is it unfair. Probably. But this has been the game for the last 3 years and Rogue Amoeba should not act surprised.
FACT: They reverse engineered Apple's proprietary technology and want Apple to help sell their app.
MY POINT: You must be nuts if you think that will happen.
"We have an Airplay licensing program explicitly to assist companies in creating AirPlay capable products. Apple never said that we would pull the rug out from anyone, we in fact worked with this developer to ensure they update their app and remain on the App Store"
The clear implication there is that Apple had procedures available for getting this to work and RA just ignored them. RA's response directly contradicts this.
P.S. thanks for the unexplained downvotes.
In the end it's Apple's store with Apple's rules. The rules have changed without warning in the past and will likely do so countless times in the future. The tradeoff for this is what is likely one of the most lucrative app stores to date for developers.
In fact, the first iOS didn't have third-party apps, and when the API finally appeared, it had very clear restrictions and a $99/year fee attached.
Typical corporate trickery. The reason a lot of people fall for it is because they have an open mind (definitely advocated by Apple) and therefore are gullible (definitely wanted by AAPL).
Having written something somewhere doesn't make you less of an asshole for handling in a dirty, asocial way.
This entire sentence applies to Rogue Amoeba. The Airplay protocol has been reverse engineered years ago: it's basically RTSP with an encrypted stream. Creating an AirPlay audio receiver is currently subject to a license, and requires a private key. This key has been extracted from a dumped AirPort Express ROM. Rogue Amoeba can say what they want about reimplementing the whole AirPlay protocol on their own, the clef-de-voûte is this private key, only available through licensing. When Schiller mentions private APIs, I believe he is not talking about an iPhone private API (which I'm positively sure Rogue Amoeba took great care of not using) but the remote AirPlay API, which they have no right to use without licensing.
The key point here is that there's a key virtually locking the API. I think it's perfectly apt to say now that — thanks to the Google/Oracle case — implementing an API is licit, but you would subsequently have to use your own public/private keys. Yet existing AirPlay sources encrypt the stream with Apple's public key, hence the content is at the sole destination of Apple's private key.
Compare this to the following situation: you publish you PGP public key and someone writes you an email and encrypts it with your public key. If someone steals your private key, that does not entitle him to decrypt and read the message whose sole intended recipient is you. This is, I believe, the crux of Apple's AirPlay licensing.
I generally don't like Apple's silent hammer, and I really like Rogue Amoeba and their software (which I bought multiple times), but — since I knew what was in play technically — when reading the last status report of Rogue Amoeba, it was obvious to me that they were concealing information with the goal of bending the truth to support their side of the argument.
P.S. Who else had to Google clef-de-voûte? FYI: It basically means "most important component" or "key element." (via bab.la)
Without it everything falls appart.
Also see http://daringfireball.net/2011/03/dirty_percent
A key is not an API. AirPlay is not an API. Full-stop.
Whether Rogue Amoeba was wrong to do this or whether Apple was right to ban them or whether reasonable observers could have predicted the banhammer is not at issue in this thread.
The issue is--Phil Schiller mislead a customer by describing Rogue Amoeba's behavior in a factually inaccurate way. Rogue Amoeba's blog post picks apart these inaccuracies like shooting fish in a barrel. I studied Phil's e-mail and I found exactly one sentence that I thought was accurate.
Sure, Apple can remove this app from the store. They should either just say that, or not respond to the customer at all. Somebody who has made a decision that he/she feels confident about has no need to slant the facts and make misleading statements. Whether or not Apple was right to do this independent of the fact that they were wrong to discredit Rogue Amoeba in an inaccurate way.
I never said that.
> AirPlay is not an API.
AirPlay is a remote interface allowing a local application to control software on a remote device and stream data to it. I could implement it over HTTP as a RESTful API or whatever way I see fit and however simple and thin it would be†, it is still a way for applications to programmatically interact through an interface, hence, an API.
But again, this is not a problem since we can now safely implement interfaces without fear.
> Rogue Amoeba's blog post picks apart these inaccuracies like shooting fish in a barrel
... and (assuming that one thinks they scored) misses the elephant in the room. encrypted AirPlay audio streams. Rogue Amoeba knows about this. Apple knows about this. The only party concealing that fact is Rogue Amoeba, and they're entirely disingenuous about it. Since the very first developments (and really, since their announcement of the feature upon release) people have been wondering about the inclusion of the Apple private key; yet Rogue Amoeba stayed quiet on the subject. What I expected of them was at some point to directly answer the question "did we use the Apple private key?" with "yes" or "no".
Again, whether I put a license or not to use my PGP private key, no one has the right to pick up content encrypted for me. They basically created an eavesdropping piece of code.
And this is true for any licensing scheme. If there's no license satisfying my will, I have no right to take it anyway. Rogue Amoeba even goes to admit:
> While Apple licenses the ability for hardware manufacturers to play AirPlay audio, there is no such licensing program for software. When we inquired as to the possibility of this type of licensing being available for software manufacturers in the future, we were informed that it was unlikely.
Then they decided that since there's no license covering that case, they have the rights to build something respecting the AirPlay API (they do) and decrypt data with a stolen private key (they don't). And went on to build it and sell it, get kicked out, complain (rightfully so regarding opacity, laconic answers, and delays), and ignore the most critical part in all subsequent communications. How cool is that?
Now the fact that Apple has no explicit licensing scheme for software manufacturers is a blind spot of their part, but who honestly believes that hardware manufacturers implement their AirPlay receiving devices as pure hardware? I bet the licensing terms could apply just as well to pure software endpoints.
> Whether or not Apple was right to do this independent of the fact that they were wrong to discredit Rogue Amoeba in an inaccurate way.
And the same applies to Rogue Amoeba.
† AirTunes has a HTTP control channel used to negotiate details, AES key exchange via RSA encryption, a remote volume knob, metadata transmission, progress information, and a data channel for audio streaming that can be suspended without closing the stream. http://git.zx2c4.com/Airtunes2/about/
The first issue with calling this "using a private API" is that the part of the application under dispute doesn't open a connection to any remote service--but accepts connections from incoming Apple hardware. It is much more correct to say that Apple is "using a private API" in this case.
The second part of the problem is that even if Rogue Amoeba was initiating connections to AirPlay clients (which they are not, at least not the part of the program under dispute), this would not be an "API" as it is usually defined.
For example, OED calls an API:
> a system of tools and resources in an operating system, enabling developers to create software applications.
Wikipedia says:
> In general the difference between an API and a protocol is that the protocol defines a standard way to exchange requests and responses based on a common transport and agreeing on a data/message exchange format, while an API (not implementing a protocol) is usually implemented as a library to be used directly: hence there can be no transport involved (no information physically transferred from/to some remote machine), but rather only simple information exchange via function calls (local to the machine where the elaboration takes place) and data is exchanged in formats expressed in a specific language.
The rest of your post deals with whether Apple is right to do what they did or whether Rogue Amoeba is right to do what they did. Did you even read my reply? In this thread, neither of those two positions are relevant. If Rogue Amoeba had broken into Apple Headquarters and personally tortured Steve Jobs to extract the private key, that would not be relevant. What is relevant is whether Phil Schiller lied and misrepresented Apple's position in a dishonest way.
Let me break down, specifically, the misrepresentations, in numerical form for easy reference:
1. "not accurately recounted on Rogue Amoeba’s website." In what sense exactly is Rogue Amoeba's website inaccurate?
2. "accessed encrypted AirPlay audio streams without using approved APIs" this implies that there exists some approved APIs that RA could have used. Again, whether Apple should or should not provide these APIs is not relevant, what is relevant is that Phil implies that usable APIs exist when they do not
3. "or a proper license" This implies that a proper license exists, see 2. Again, not relevant whether or not Apple should or should not provide a license to RA, only relevant that they imply RA had the option to use it and did not
4. "in violation of Apple’s agreements" This may be in violation of agreements that Apple has with various hardware manufacturers, but this statement implies that RA is bound by these agreements or even knows or can find out what is in them. They cannot. Essentially, Phil is holding RA to a secret standard.
5. "Apple asked Rogue Amoeba to update their app to remain in compliance with our terms and conditions" According to RA, Apple ignored RA's questions for clarification for several weeks.
6. "We have an Airplay licensing program explicitly to assist companies in creating AirPlay capable products." - This implies that RA could have taken advantage of the licensing program and did not. In fact RA could not have taken advantage of the licensing program. Whether this is good or bad is not at issue; the issue is Phil is misleading the customer.
7. "Apple never said that we would pull the rug out from anyone" - iOS guideline 2.20, 3.10, 6.3, 22.7, and others explicitly say that Apple will pull the rug out from under developers. Whether or not these are reasonable or unreasonable guidelines is not at issue in this thread; the issue is that Apple does in fact say they will do it and Phil claims they will not.
8. "we in fact worked with this developer to ensure they update their app and remain on the App Store" For some definition of time e...
I beg to differ, and consider both definitions you subsequently give as incredibly restrictive as it would exclude some of the most used APIs in the wild. Everyone in the field will call the Twitter API an API, and everyone will agree that StatusNet implements the Twitter API.
That said, the consumer of the API is indeed AirPlay clients while the API is being served by Apple TV, Airport Express and AirFoil Speakers (Touch). But again this does not matter (and even if we called it a protocol, and really here we have multiple protocols at hand) and RA would have every right to implement it (just as Google implements the Java API, or Wine the Windows API, or StatusNet the Twitter API).
1. It is inaccurate in that it misses one of the most critical points of the discussion.
2. I agree that RA (probably) did not use any non-approved iOS API and that they have every right to implement the AirPlay API/Protocol. I maintain though that they can not make their implementation interoperate with existing AirPlay clients that encrypt the stream. Whether that falls under the "approv[able] API" wording is a stretch, but nonetheless possible. Even RA considered that case in their May 29th post. But this does not matter, since the rest of the phrase is linked to this one with "or".
3. No this does not. This says: "you do not have a license to do that". The fact that no such licensing scheme exists is relevant only in implying that they simply can't do that at all.
4. Apple's iOS developer agreement being quite vague, I'm pretty sure they could fit almost anything they want under this agreement, and this is bad.
5. According to RA, Apple rejected the app because they deemed it non compliant, and as such they "asked Rogue Amoeba to update their app to remain in compliance with our terms and conditions". Not detailing what was not compliant, however rough, does not make the previous statement false. The first Apple answer seems like the usual preset, generic and despicable answer. If anyone takes time to analyze and invalidate an application to such levels of detail, they should disclose their full process and reasons to reject the app together with the app rejection.
6. They do have a program, and it appears to exclude software makers. I find it very sad that it comes to such an escalating situation to at least extend the current licensing scheme to software manufacturers.
7. Agreed.
8. Both the part you cite and the point you make are entirely true, and the second part is simply outrageous. Apple definitely has to improve on that front.
So, did Schiller wrote an inaccurately worded letter? Sure it did. And while they handled the case in a heavy handed and awkward manner, can we call those purposeful lies? It might be, but I'm really not convinced. In the meantime Rogue Amoeba recognizes they "inquired as to the possibility of this type of licensing being available for software manufacturers in the future, [and being] informed that it was unlikely" yet still trying to push the update through approval.
What's more they go on to say, regarding accessing the encrypted content:
> "Quite simply, it is not. While there are multiple layers of encryption involved in the AirPlay audio streaming protocol, their primary purpose appears to be preventing third parties from building applications which interoperate with AirPlay."
In a word, they assumed they had the right to circumvent a mechanism protecting Apple's licensing scheme (however vile we think it is WRT interoperability), made a run for it, were caught red handed, and called out the web regarding the injustice. Maybe they genuinely believe they're right, but that does not make them the good guys.
To sum this up, I believe both sides are at fault, but I'm much more inclined to say that they are all acting in good faith, and that such matters would resolve with much less friction if there was not so much tension (mainly due to delay and opacity, which only increase t...
You'll have to take that up with OED and Wikipedia. I think it's fair to say that at the point that they agree with each other and disagree with us that we're the ones using the words wrong rather than them, and it's us who need to invent new words rather than they. That's what it means to be a language authority.
#1 seems like an overall summary statement so my response is implied by the below
#2 I can't detect any disagreement
#3 - "you do not have a license to do that" - They also don't have a license to rent a bouncy castle. Phil isn't listing things that they don't have a license to do, he's (attempting to) explain why Apple rejected the application. He's implying that a license exists.
4. The word "violation" has a specific legal meaning. In this case, I can tell you for sure that he's specifically referring to agreements that Apple has with hardware manufacturers (which actually say you cannot do this explicitly), which RA has never read
5. I will concede that Phil's statement is technically correct, but when you consider how the average customer would interpret this statement, it leads them to an incorrect conclusion.
6 & 7 - No point of disagreement that I can detect.
8. No point of disagreement that I can detect.
> can we call those purposeful lies?
Phil is on the board of directors of a publicly traded company and society holds such people to an extremely high standard of honesty. I'm not sure why the word purposeful is of any relevance, but they're certainly misleading statements and Phil Schiller is not employed by Apple to blab whatever he thinks of to say to random customers.
> In a word, they assumed they had the right to circumvent a mechanism protecting Apple's licensing scheme (however vile we think it is WRT interoperability), made a run for it, were caught red handed, and called out the web regarding the injustice. Maybe they genuinely believe they're right, but that does not make them the good guys.
The following set of words: {right, vile, made a run for it, red handed, called out, injustice, good guys} ascribe a certain moral narrative to this situation that I do not subscribe to at all. There are a lot of very worldviewish questions in here (e.g. what it means for a software company to be moral, whether morality can be meaningfully ascribed to a company, etc.)
I don't mean to dissuade you of these views, because I imagine that if we take the time to wade through it, we will discover that each other's positions are pretty reasonable. But that would require us to wade through a lot of psychology, philosophy, religion and ethics to arrive at that point, and so in the interests of time I would recommend steering clear of ascribing particular ethical conclusions to the actions of actors except in the narrow cases where it is actually important, in which case we must be willing to defend it at some length.
One such area (of valuable exploration) is whether, assuming Phil made misstatements in his e-mail, it was morally correct to send. I think we agree on enough of the points to conclude that these misstatements did exist, and so the problem reduces to whether a corporate director sending misstatements to a customer is immoral. From your reply, the operative test seems to be whether they constituted a purposeful lie which is, at the very least, an interesting test.
Subject to the rule of law, of course.
Is releasing something you know will get kicked out the best approach to take when you can't provide an approved solution? Maybe, if you think the resulting discussion and PR is your best chance at getting things changed... but then, again, you need to keep your message perfectly focused. Claiming that they didn't violate any agreements feels too defensive to me.
EDIT: and it's not just this response... initially they professed something much closer to ignorance/surprised innocence over the removal, while it now looks like there wasn't much reason for any surprise.
> "... Reverse engineering is, among other things, largely responsible for the PC revolution and the computing landscape we enjoy today. Should we stop providing users with products that work together simply because other vendors dislike competition?"
We all know Apple loves reverse-engineering of its products, so I'm sure this kind of reasoning helps your case.
The problem here is that Apple's wishes can be and are regularly applied in the app store regardless of whether they're actually good for the users(disallowing malware is good). This is a nasty side effect of the app store model and we'll be seeing more of such issues in the future with the Windows 8 Metro app store.
Adding in support for AirPlay to an app and selling that won't void your or my iPhone's Warranty if we were to install it, but it can void the contract put in place between Rogue Amoeba and Apple, if even just for that singular app. Here is the real reason Apple threw this app out of the store: http://news.ycombinator.com/item?id=4087666 RA was using a private key derived from a firmware update for the Apple Airport Basestations in order to encrypt the audio stream in accordance of the AirPlay protocol.
Want a custom stereo in your new car with a fancy center stack setup with a non-standard-size stereo and possibly even integrated AC/heater controls? You're going to have to jump through a lot of hoops. Want software with more functionality than Apple exposes to developers? There's always jailbreaking...
In neither case has there been a substantial consumer backlash.
And I don't know any manufacturer that will sell you someone else's head unit as an aftermarket piece. It's up to you to find out how to take everything apart and fit something else in there on your own, or to find someone who knows—basically, jailbreaking your dashboard. Except you generally lose stuff (like steering wheel controls), while I hear jailbreaking is pretty painless these days.
Edit: Apple's app store isn't some third party stereo store, it's a store owned by the manufacturer itself. And car manufacturers are famous for having highly priced proprietary replacement parts, especially when it comes to electronics like stereos, if you aren't willing to deal with an outside store/brand. I really don't see any way Apple's less flexible with the iPhone than a car manufacturer is with their cars.
It's one thing to make the center console non-standard, it's another to prevent the installation through warranty restrictions.
The hypothesis that it has to do with Apple preparing to bring out a competitive offering is laughable. Airfoil would not have a gram of impact on anything Apple does in this realm.
Rogue conspicuously makes no mention of this part: "Apple asked Rogue Amoeba to update their app to remain in compliance with our terms and conditions."
But it's not Apple's audio stream, it's the user's audio stream. I don't think it's particularly unreasonable to expect that user should be able to decrypt his or her own data (assuming we're talking about data that isn't under DRM; DRM is another issue).
Though AirPlay does work on DRM'ed streams, there's little advantage to using that over simply recording from the audio out from your computer and no advantage over using something like Audio Hijack Pro (another Rogue Amoeba product) or Soundflower to record the audio output of your computer.
If an authorized user initiates playing the content, DRM shouldn't prevent it from occurring.
On paper, yes. In practice, "unauthorized people" don't have to deal with it, and only "authorized people" have to struggle.
Imagine you were eating out at KFC one night, and using taste alone, you managed to work out their secret recipe. You then decided you wanted to get into the fried chicken business, but you didn't want the overhead of renting commercial space, or buying the kitchen/service equipment you need to run your own business. So you choose to walk into your local KFC, use their kitchen to fry your chickens, wrap them up in all the KFC packaging and branding, and begin to sell them at their counter. This goes unnoticed for a few hours, but then the manager notices what you're doing, and points you towards the exit.
Surely you'd understand why KFC wouldn't let this behaviour continue. You didn't steal their recipe; you worked it out on your own. You're perfectly within your right to sell chicken based on this recipe, but you'd better do it at your store, and put your own label on it. If KFC don't want you selling products based on their recipe (however legally you discovered it), you can't wrap them in KFC packaging, and you certainly can't sell them at KFC.
*I know someone will bring up jailbreaking. Jailbreaking is not a solution. It's difficult, voids the warranty, and can cause issues with stability and software updates. It's a non-starter for the vast majority of users. By limiting Airfoil to jailbroken phones, Apple kills 90% of Rogue Amoeba's revenue.
> By limiting Airfoil to jailbroken phones, Apple kills 90% of Rogue Amoeba's revenue.
Although you're right in saying this, it's only because 100% of Airfoil's revenue comes from the App Store. If they had revenue streams outside of the App Store (by choosing a different platform or devices), Apple wouldn't be able to block a cent of that income.
You're ignoring the fact that according to your analogy, our hypothetical KFC is already allowing people to make and sell different sorts of food with KFC branding from within their store (as long as you give them some of the proceeds and pay an annual fee, which was the case). In fact, a lot of people come to KFC precisely because they have an unmatched breadth of delicious and affordable dishes, and many people want to sell their wares at KFC because of their large clientele - KFC has successfully transformed into a food-court.
The hero of your post devised a delicious dish that would lose its flavor without the KFC secret sauce, but unfortunately for him, KFC only allows condiment manufacturers to use their secret sauce, and then only after a certification process to make sure they get the unique taste just right. Of course, they could, say, taste the delicious dish, realize that it's providing them with direct revenue, as well as satisfying consumers and increasing the odds they'll return to the food-court and spend more money.
Analogies aside, I understand why Apple does these sorts of things - first of all, they want consistency in UX since there really was no certification process. Also, keeping the ecosystem tightly under their control is much easier when you're very consistent about being draconian from the moment the platform was created (you go to the app-store, you play by their rules).
As a side-note, I'm surprised that there's so much support for Apple with these sorts of things when 15-20 years ago the same crowd would have been up in arms if Microsoft were to, say, send cease & desists to Samba or Wine (and still is criticizing Microsoft for disallowing other OSes in WinRT ARM devices).
Perhaps I got a bit lost when I chose to have the hero sneaking around, using equipment and service counters without the knowledge of the management, as that doesn't exactly parallel the App Store approval process. Although, seeing as Apple regularly approve apps only to pull them at a later date because of undetected features/activities, our hero's actions aren't too far-fetched.
P.S. I love that you played along with the analogy. In hindsight, KFC was a terrible choice, but I'm glad it opened up a bit of discussion.
Not letting this issue drop just paints Rogue Amoeba in a bad light and confirms their immaturity to people like me who already thought they were in the wrong. Add to the fact that the feature is still in the app (you just need to upload a plist file) and I won't be surprised if Apple totally bans the app and takes further action with the developers and suspends their account.
The fact that encryption is involved is completely irrelevant.
Apple does not want an unlicensed and unauthorized app to use AirPlay on their app store. Case closed.
AirPlay isn't HTTP so don't compare the 2. Your comment about encryption is moot.
It was at one point. But then The Internets figured out how it worked, and now it's as easy for someone to implement as any other open protocol.
Remember: no particular legal protection applies to protocols. Apple is kicking Rogue Amoeba out of the app store out of pure malice, not because of any law that was violated. ("We'd like to sell you this product, but you figured out how to make it yourself, so you're gone.")
Two things no law broken, no charges filed no lawsuits presented. Pure maliace, hardly more like appropriate response to broken contract.
It's time for someone to re-edit Apple's 1984 commercial and swap the logos.
Which would be pretty nice irony too.
At the same time, Apple is under no obligation to make it easy for us to trample on their licensing deals for technologies that form part of Apple's unique selling proposition in a consumer's mind. AirPlay is so well implemented, consumers find it magical. To keep that mystique, Apple has a right to review and license AirPlay to those vendors that it finds aligned with its long term goals. If you want Apple to be forced to do something different, you're not a "hacker", you're on the side of big government and "Big Brother" demanding to oversee and meddle in a company's right to sell the product it wants that works in the way that it wants.
Finally, I personally want to encourage the hell out of a computing environment that makes everyday people find computing approachable and fun. Just as you don't want a power outlet that needs constant tweaking before you can plug something in, normals don't want a computer or smartphone that requires maintenance just to be able to have fun and get things done.
Apple's forced the mainstream computing industry to stop designing for ourselves, and start thinking about everyone else. This is why computing has finally gone viral.
Did you use that first Mac? It was never about "open" or "hackable", it was about appliance computing that gets the computer out of the user's way.
Nothing has changed since Apple's 1984 when Apple adopted the slogan, "The computer for the rest of us."
Nobody is forcing you to buy Apple's products either. The solution is perfectly laissez-faire: Stop buying them. There are plenty of hacker-friendly alternatives to Apple products which, while not quite as pretty, are still fun to use - and often enable "magical" features like the ability to use an international SIM or free WiFi tethering.
And hackerism is not the computing environment Apple wants to encourage. Besides the obvious benefit of more control = better stronghold of their market, Apple is also philosophically in favor of closed, well defined systems and minimal end user confusion, not pro open-ended, experimentation lands, "we give you the building blocks, you make it whatever you want".
And, as much as I like the notion of open systems and hacking, there should be room for the other side too, systems that are designed top-to-bottom and sold "as is".
I believe that history has proved that while it is possible to get quality UIs from open ended/open source style development projects, you get them with LESS consistency that you get them from an Apple-like process, and you also get more competing stuff/chaos/design by committee, unless you coordinate the whole process, from the kernel, to the end user apps.
Open source projects are mostly islands, so you don't get to have that long term vision / whole stack co-ordination.
To put it another way, an OS called OS X exists as ONE thing where one person had ultimate responsibility for what's included and in what shape to ship it. An OS called Linux does not: it only exists as disparate things collected and distributed together (a distro). The Gnome desktop environment, for example, is not produced for a specific OS: it's produced for whoever wants to use it, from various flavors of Linux, to FreeBSD, its apps even run on OS X.
>It's time for someone to re-edit Apple's 1984 commercial and swap the logos.
Why, did Apple ever changed course? The Mac was about a "computer for the rest of us" (ie simple users), and it remains the same now. Neither Mac, nor the 1984 ad was about tinkering. It was about empowering people with simple technology (a simple spreadsheet, a simple text editor, etc), not about empowering hackers to build things.
Actually, now, with the Unix underpinnings, the Mac is also a computer that lures tons of hackers (prevalent in any programming convention and most alpha hackers use a Mac, --even Linus, although he runs Linux on it), but the main market for Apple was an is the common user.
Perhaps you missed this?
http://www.youtube.com/watch?v=No1MxAnHuJM http://en.wikipedia.org/wiki/Think_Different
"Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently. They’re not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them. About the only thing you can’t do is ignore them. Because they change things. They push the human race forward. While some may see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do. - Apple Inc."
Whereas Apple's focus of making simple computers/software for common people to use was a constant in their corporate story.
This wasn't just a single marketing campaign. It was THE marketing campaign. They even played the Steve Jobs narrated version at the Celebrating Steve event. After reading the Steve Jobs biography, I'm pretty sure that he and the others at Apple truly believe that this campaign represents Apples values.
Yeah, only it was only played once, decades ago, and nothing similar ever appeared in Apple ads since then.
The Think Different campaign was created in 1997 and ended in 2002, and I'm having a hard time believing they played that ad _once_.
iOS would be just as integrated and nice if Apple released it as Open Source. But it would give people more choice, Apple would make make less money from it, and they would then be at a disadvantage compared to other companies that did control their entire ecosystem.
The problem is that closed, proprietary systems tend to create monopolies, and while the initial products may be great, monopolies are seldom good for customers.
The other mistake people make is thinking that closed or open is an either-or proposition. Apples nice iOS ecosystem wouldn't be destroyed overnight if they had a settings option marked "allow unsigned third party apps". Would that compromise their long term / whole stack vision? No.
My mother should never experience the benefits a computer can bring to her life because the only device she could understand how to use would be something like an iPad—and since the iPad is made by a company that isn't 100% open, it shouldn't exist at all. Everyone should use Ubuntu, and if you can't use it, it's because you're too stupid and thus don't deserve to have a computing device in your life. Open source principals are more important than anything else, and they must be applied in a binary fashion, scaled across all approaches to computing in the world.
----
A pet peeve of mine is "hackers" ignoring design, and showing zero empathy towards humans [1]. Perhaps we need more designers in the world and not more hackers who stick tight to principals, often completely blinded by these binary maxims they drum up to the real end goal: enabling our species to advance.
[1] http://krisgosser.com/journal/2011/08/empathy-is-most-import...
You, presumably, are a hacker. While hackers represent a small part of the population, they represent a very important part of the market - the part that builds the wider ecosystem. We have a disproportionate effect on the evolution of technology. Use devices that advance an agenda that should be important to you - the ability to make devices do what you want, not what its manufacturer wants them to do.
Besides, you make the non-Apple world sound more bleak than it is. While Android is not quite as polished as iOS, it's perfectly usable by nontechies.
In other words, it's (disconcertingly) conceivable that Apple is contractually obligated to reject Rogue Amoeba's feature without a good explanation.
You're seeing the full power of Apple's control over the app store, though - they can stop distributing apps they don't like for any reason. The same power that Barnes & Noble has over the book market, and your cable provider has over your local TV market.
Until Apple stops their stupid policies and starts communicating openly, they will embarrass themselves again and again.
They may have re-implemented that work, but they did not reverse-engineer.
Certain internal software API's are as much intellectual property as is the physical hardware design.