4 ms·

> 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 us

> 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.

lloeki 14y ago
> A key is not an API. 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/ http://git.zx2c4.com/Airtunes2/about/
- drewcrawford 14y ago
  > 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 elapsed and public outcry; see #5. I hope this clarifies the issue. Whether RA was right or wrong to extract the private key in the way that they did (or use a private key they got from another source) is not an issue. The issue is: did Phil Schiller lie to a customer? I think I've made a pretty convincing case.

lloeki 14y ago

> A key is not an API. 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/ http://git.zx2c4.com/Airtunes2/about/

drewcrawford 14y ago
> 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 elapsed and public outcry; see #5. I hope this clarifies the issue. Whether RA was right or wrong to extract the private key in the way that they did (or use a private key they got from another source) is not an issue. The issue is: did Phil Schiller lie to a customer? I think I've made a pretty convincing case.