출처 :
http://www.xevious7.com/463 :
아름다운 네트웍 세상 since 1996.
개발로 부터 판매 그리고 수입까지의 프로세스가 거의 완료되어서
포스트합니다.
(아직 10월 금액의 일부만 받은 상태입니다. 좀 느리군요.
계약서에서 보면 파이낸셜레포트 이후에 45일내에 주는것으로 되어있으니
좀더 기다려 보아야 겠습니다. 참조하십시요.)
이글은 앱스토어 관련하여 개발에 관심이 있거나
개발하시는 분들에게 도움이 되고자 쓰는 글입니다.
이 문서는 2008년 10월 기준이며 개인개발자 기준입니다.
단체나 회사인 경우에는 틀립니다. 하지만 보통 회사규모에서는 이런일들을
처리하는 부서도 있을뿐더러 이정도 문서처리는 쉽게 하리라 생각됩니다. :)
물론 개인개발자 분들도 애플의 문서를 꼼꼼히 읽으면 특별히 어렵지 않게
하실수 있는 부분입니다. 이 문서는 다만 그럼에도 불구하고 좀더 편의를
제공하는 목적이라고 해야 될까요 :)
개발자등록을 완료하고 앱 스토어에 프로그램을 올리려면
iTunes Connect 의 계약관련 서류를 모두 완료해서 계약이 유효해야만
앱스토어에 릴리즈할 수 있습니다.
여기서 세금관련 서류를 작성해야 하는데요 .
미국판매에 대해서 세금서류를 작성하지 않을경우는 애플이 가져가는 30%이외에
나머지수익 70%에 대한
원천세 30%을 더 내야 합니다.
이 원천세를 줄이기 위해서 세금서류를 작성해야 합니다.
(한국의 경우 무역협정에 따라 원천세를 10%로 줄일수 있습니다.)
또한 일본에 판매를 할경우 일본국세청 문서형식를 작성하여 제출하여 합니다.
이것도 제출하지 않을 경우에 일본 판매대액에대해서
원천세 20%를 떼셔야 합니다.
먼저 미국의 경우 원천세를 줄이기 위해서 작성해야할 서류는
SS-4 서류와
W8-BEN서류 입니다. 실제로는 W8-BEN이 원천세 감면에 대한 서류인데
이 서류를 작성할떄 필요한 EIN코드(납세자코드)를 위해서 SS-4 서류를
작성해야합니다.
SS-4서류는 미국 국세청에 제출해서 승인을 받으면 EIN코드를 발급해줍니다.
서류는
http://www.irs.gov/ 미국국세청 홈페이지에 들어가시면 다운로드할수
있습니다.
SS-4서류에는 많은 항목이 있지만 EIN코드를 받기 위해서 작성해야 할
항목은 다음항목만 채우시면 됩니다. 일단 인쇄를 하신다음 ,
1. 자신의 이름 항목입니다.
4a 자신의 주소지 (상세)
4b 자신의 주소지 , 도시 , 구 우편번호
9a 항목에 sole proprier 를 체크
10 항목 이유항목에서는 Compliance with IRS withholding rate 를 체크
18 번 이전에 EIN 받은적이 있느냐는 항목이며 자신에 맞게 체크
가장 중요한것은 맨밑에 친필서명하고 날짜적고 전화번호및 팩스번호 기입하시면 됩니다.
작성후 우편으로 보내거나 (우편으로 보내는경우 1달이상 걸립니다.)
팩스로 보내거나(팩스일 경우 1주일정도)
영어와 인내심이 된다면 ,전화를 걸어서 담당자와 직접통화하여 즉시 EIN코드를
딸수 있습니다.
그 코드를 받고나면 다시 W8-BEN서류를 작성하여 사인후 애플사로 우편을
보내야 합니다.(W8-BEN 서류는 애플이 제공하는것을 쓰셔도 되고
또는 미국국세청에서 받을수 있습니다.)
W8-BEN은 서류는 애플가이드를 보시고 작성하라는 부분만 작성하시면 됩니다.
또 일본에 판매하는 경우에는 따로 문서를 작성해서 보내야 합니다.
주의 깊게 안봐서 일본문서는 작성을 하지 않았는데 애플에서 메일을 보내서
일본양식을 보내지 않으면 20%의 원천세를 떼야되니 빨리 보내달라고 메일이
오더군요.
애플 iTunes Connect에서 제공하는 세금서류(일본국세청 양식)를 다운받아
가이드와 양식대로 작성하여 애플사로 우편을 보내야 합니다.
애플의 최종 승인을 받기까지는 1달에서2달이 넘게 걸릴 수 있습니다.
평균 6주정도 인것 같습니다.
Original : http://www.sleberknight.com/blog/sleberkn/entry/iphone_bootcamp_day_4
Posted on December 04, 2008 by Scott Leberknight
Today is Day 4 of the iPhone bootcamp at Big Nerd Ranch, taught by Joe Conway. Unfortunately that means we are closer to the end than to the beginning.
See here for a list of each day's blog entries.
View Transitions
Since we had not completely finished up the Core Graphics lab from Day 3, we spent the first hour completing the lab exercise, which was to build a "Tile Game" application where you take an image, split it into tiles, and the user can move the tiles around and try to arrange them in the correct way to produce the full image. Actually you don't really split the image; you use a grid of custom objects — which are a subclass ofUIControl — and translate the portion of the image being split to the location in the grid where the tile is located. When a user moves the tiles around, each tile still displays its original portion of the image. So, you are using the same image but only displaying a portion of the image in each tile.
After completing the lab, Joe went over view transitions. View transitions allow you to easily add common animations (like the peel and flip animations you see on many iPhone apps) to your applications to create nice visual effects and a good user experience. For example, in our Tile Game app, when you move a tile it abruptly jumps from the old location to the new location with no transition of any kind. Also, when you touch the "info" button to select a new tiled-image there is no animation. It would be better to make the tiles slide from square to square, and to flip the tile over to the image selection screen. View transitions let you do this pretty easily. (Joe mentioned that later we'll be covering Core Animation which is more powerful and lets you perform all kinds of advanced animations.)
So, to reiterate, view transitions are meant for simple transitions like flipping, peeling, and so on. There are several "inherently animatable" properties of a UIView: the view frame, the view bounds, the center of the view, the transform (orientation) of the view, and the alpha (opacity) of the view. For example, to create a pulsing effect you could peform two alpha animations one after the other: the first one would transition the view from completely opaque to completely transparent, and the second animation would transition back from completely transparent to completely opaque. For the View Transition lab we used a "flip" animation to flip between views.
You use class methods of UIView to begin animations, setup view transitions, and commit the transitions. You use beginAnimations to begin animations. Then you define the animations using methods like setAnimationDuration and setAnimationTransition, which set the length of time over which the animation occurs and the type of animation such as peel or flip, respectively. Then you perform actions like add and remove subviews or perform transitions on any of the "inherently animatable" properties in an "animation block." To start the animations on screen you call commitAnimations after the animation block. This seems similar to how transactions work in a relational database, in that you begin a transaction, define what you want done, and then when satisfied you commit those "changes." Joe mentioned that Core Graphics essentially uses a hidden or offscreen view to store the actions and only shows the animations and actions when the animations are committed.
Core Animation
Next up: Core Animation. While view transitions are for simple animations, with Core Animation you can animate almost anything you want. The basic idea here is that when using Core Animation, the animation takes place on a CALayer rather than the UIView. There is one CALayer per UIView, and the CALayer is a cached copy of the content in the UIView. As soon as an animation begins, the UIView and CALayer are interchanged, and all drawing operations during the animation take place on the CALayer; in other words when an animation begins the CALayer becomes visible and handles drawing operations. After the animation ends the UIView is made visible again and the CALayer is no longer visible, at which point the UIView resumes responsibility for drawing.
You create animations using subclasses of CAAnimation and adding them to the CALayer. CABasicAnimation is the most basic form of animation: you can animate a specific property, known as a key path, to perform a linear transition from an original value to a final value. For example, using a key path of "opacity" you can transition an object from opaque to translucent, or vice versa.
You can also combine multiple animations using a CAAnimationGroup, which is itself a subclass of CAAnimation (hey, that's the Composite design pattern for anyone who cares anymore). You can use CAKeyframeAnimation to perform nonlinear animations, in which you have one or more "waypoints" during the animation. In other words, with CAKeyframeAnimation you define transitions for a specific attribute — such as opacity, position, and size — that have different values at the various waypoints. For example, in the Core Animation lab exercise we defined a rotation animation to "jiggle" an element in the Tile Game we created earlier to indicate that a tile cannot be moved. The "jiggle" animation uses the CAKeyframeAnimation to rotate a tile left, then right, then left, then right, and finally back to its original position to give the effect of it jiggling back and forth several times.
To finish up Core Animation, Joe covered how to use Media Timing Functions to create various effects during animations. For example, we used CAMediaTimingFunctionEaseIn while sliding tiles in the Tile Game. Ease-in causes the tile animation to start slowly and speed up as it approaches the final location. Finally, I should mention that, as with most iPhone APIs, you can set up a delegate to respond when an animation ends using animationDidStop. For example, when one animation stops you could start another one and chain several animations together.
Camera
After a cheeseburger and fries lunch, we learned how to use the iPhone's camera. The bad news about the camera is that you can't do much with it: you can take pictures (obviously) and you can choose photos from the photo library. The good news is that using the camera in code is really simple. You use a UIImagePickerController, which is a subclass of UINavigationController, and push it modally onto the top view controller using the presentModalViewController:animated method. Since it is modal, it takes over the application until the user cancels or finishes the operation. Once a user takes a picture or selects one from the photo library, UIImagePickerController returns the resulting image to its delegate.
There are two delegate methods you can implement. One is called when the user finishes picking an image and the other is called if the user cancelled the operation. The delegate method called when a user selects a picture returns the chosen image and some "editingInfo" which allows you to move and scale the image among other things. The lab exercise for the camera involved modifying the Tile Game to allow the user to take a photo which then becomes the game's tiled-image.
Accelerometer
The accelerometer on the iPhone is cool. It measures the G-forces on the iPhone. You use a simple, delegate-based API to handle accelerations. While the API itself is pretty simple, the math involved and thinking about the orientation of the iPhone and figuring out how to get the information you want is the hard part. But you'd kind of expect that transforming acceleration information in 3D space into information your application can use isn't exactly the easiest thing. (Or, maybe it's just that I've been doing web applications too long and don't know how to do math anymore.)
There is one shared instance of the accelerometer, the UIAccelerometer object. As you might have guessed, you use a delegate to respond to acceleration events, specifically the accelerometer:didAccelerate method which provides you the UIAccelerometer and a UIAcceleration object. You need to specify an update interval for the accelerometer, which determines how often the accelerometer:didAccelerate delegate method gets called.
The UIAcceleration object contains the measured G-force along the x, y, and z axes and a time stamp when the measurements were taken. One thing Joe mentioned is that you should not assume a base orientation of the iPhone whenever you receive acceleration events. For example, when your application starts you have no idea what the iPhone's orientation is. To do something like determine if the iPhone is being shaken along the z-axis (which is perpendicular to the screen) you can take an average of the acceleration values over a sample period and look at the standard deviation; if the value exceeds some threshold your application can decide the iPhone is being shaken and you can respond accordingly. For the lab exercise, we modified the Tile Game to use the accelerometer to slide the tiles around as the user tilts the iPhone and to randomize the tiles if the user shakes the iPhone. Pretty cool stuff!
Web Services
Well, I guess the fun had to end at some point. That point was when we covered Web Services, mainly because it reminded me that, no, I'm not going to be programming the iPhone next week for the project I'm on, and instead I'm going to be doing "enterprisey" and "business" stuff. Oh well, if we must, then we must.
Fortunately, Joe is defining web services as "XML over HTTP" and not as WS-Death-*, though of course if you really want to reduce the fun-factor go ahead Darth. To retrieve web resources you can use NSURL to create a URL, NSMutableURLRequest to create a new request, and finally NSURLConnection to make the connection, send the request, and get the response. You could also use NSURLConnection with a delegate to do asynchronous requests, which might be better to prevent your application's UI from locking up until the request completes or times out.
If you have to deal with an XML response, you can use NSXMLParser, which is an event-based (SAX) parser. (By default there is no tree-based (DOM) parser on the iPhone, but apparently you can use libxml to parse XML documents and get back a doubly-linked list which you can use to traverse the nodes of the document.) You give NSXMLParser a delegate which recieves callbacks during the parse, for example parserDidStartDocument and parser:didStartElement:namespaceURI:qualifiedName:attributes. Then it's time to kick it old school, handling the SAX events as they come in, maintaining the stack of elements you've seen, and writing logic to respond to each type of element you care about. For our Web Services lab we wrote a simple application that connected to random.org, which generates random numbers based on atmospheric noise, and made a request for 10 random numbers, received the response as XHTML, extracted the numbers, and finally displayed them to the user.
Address Book
Last up for today was using the iPhone Address Book. There are two ways to use the address book. The first way leverages the standard iPhone Address Book UI. The second uses a lower-level C API in the AddressBook framework.
When you use the Address Book UI, you use the standard iPhone address book interface in your application. It allows the user to select a person or individual items like an email address or phone number. You must have a UIViewController and define a delegate conforming to ABPeoplePickerNavigationControllerDelegate protocol. You then present a modal view controller passing it a ABPeoplePickerNavigationController which then takes over and displays the standard iPhone address book application. You receive callbacks via delegate methods such as peoplePickerNavigationController:shouldContinueAfterSelectingPerson to determine what action(s) to take once a person has been chosen. You, as the caller, are responsible for removing the people picker by calling the dismissModalViewControllerAnimated method. We created a simple app that uses the Address Book UI during the first part of the lab exercise.
Next we covered the AddressBook framework, which is bare-bones, pedal-to-the-metal, C code and a low-level C API. However, you get "toll-free bridging" of certain objects meaning you can treat them as Objective-C objects, for example certain objects can be cast directly to an Objective-C NSString. Another thing to remember is that with the AddresBook framework there is no autorelease pool and you must call CFRelease on objects returned by methods that create or copy values. Why would you ever want to use the AddressBook framework over the Address Book UI? Mainly because it provides more functionality and allows you to directly access and potentially manipulate, via the API, iPhone address book data. For the second part of the Address Book lab, we used the AddressBook API to retrieve specific information, such as the mobile phone number, on selected contacts.
Random Thoughts
Using View Transitions and Core Animation can really spice up your apps and create really a cool user experience. (Of course you could probably also create really bad UIs as well if overused.) The camera is pretty cool, but the most fun today was using the accelerometer to respond to shaking and moving the iPhone. Web services. (Ok, that's enough on the enterprise front.) Last, using the various address book frameworks can certainly be useful in some types of applications where you need to select contacts.
Something in one of the labs we did today was pretty handy, namely that messages to nil objects are ignored in Objective-C. There are a lot of times this feature would be hugely useful, though I can also see how it might cause debugging certain problems to be really difficult! There's even a design pattern named the Null Object Pattern since in languages like Java you get nasty things like null-pointer exceptions if you try to invoke methods on a null object.
Man, we really covered a lot today, and now I am sad that tomorrow is the last day of iPhone bootcamp. I should become a professional Big Nerd Ranch attendee; I think that would be a great job!
Original : http://www.sleberknight.com/blog/sleberkn/entry/iphone_bootcamp_day_3
Posted on December 03, 2008 by Scott Leberknight
Today is Day 3 of the iPhone bootcamp at Big Nerd Ranch, taught by Joe Conway.
See here for a list of each day's blog entries.
Media
Today we started off learning how to play audio and video files by creating a simple application that allows you to play a system sound, an audio file, and a movie. If all you want to do is play .caf, .wav. or .aiff audio files tat are less than 30 seconds in length, you're in luck because you can simply use AudioServicesCreateSystemSoundID to register a sound with the system and then use AudioServicesPlaySystemSound to play the sound. On the other hand, if you want to play almost any type of audio file, you can use the AVAudioPlayer, which really isn't all that much more complicated. You create a AVAudioPlayer and then implement AVAudioPlayerDelegate methods like audioPlayerDidFinishPlaying to respond to audio player events. You simply call start and stop to control playback and you can use isPlaying to check playback status. Recording audio is apparently more difficult, and we didn't really cover it in lecture or lab, though the exercise book has a whole appendix devoted to creating your own voice recorder application.
For movie playback you can use MPMoviePlayerController. It is also pretty easy to use. But, one caveat is that it completely takes over your iPhone application when you call play, and the user has no control until the movie ends or until the user exits your application.
Low Memory Warnings
We next took a (very) short detour talking about low memory warnings. When your application is taking too much memory, the iPhone sends your application the applicationDidReceiveMemoryWarning message. In that method you are supposed to release as much memory as you possibly can. However, according to Joe, the iPhone does not really provide much information about how much memory you need to release, or how much memory will cause a low memory warning in the first place! Joe says to just release as much memory as you possibly can immediately or else the iPhone can simply terminate your application. All your UIViewControllers are sent didReceiveMemoryWarning. The default implementation checks if you have implemented loadView, and if so releases its view instance. The next time the view needs to be shown on screen, it gets reconstructed. One last thing is that the iPhone simulator allows you to simulate a low memory warning via the "Simulate Memory Warning" option on the Hardware menu.
OpenGL
OpenGL ES is the implementation of OpenGL on the iPhone. Basically it is a low-level C API that allows you to draw 2D and 3D graphics on the iPhone in various colors and textures. Triangles, lines, and points comprise the basic geometrical shapes you can use to compose graphics. When coding OpenGL ES you basically need to define all the vertices in two or three dimensional space, then define the color of each vertex, and then, via the EAGLContext, render the graphic. The color of a vertex is defined in RGBA8 format, which allows you to specify red, blue, green color channels and an alpha transparency channel, using 8-bits per channel. The EAGLContext is the bridge between Cocoa Touch and OpenGL ES, and is what allows you to use OpenGL on the iPhone.
When coding OpenGL ES, you use various buffers. The frame buffer describes one frame of drawing. The render buffer contains the pixels created by drawing commands sent to the frame buffer. When you draw to the screen, you really draw to a CAEAGLLayer object, and you use a timer to request drawing updates, e.g. schedule a timer to update the drawing 60 times per second creates a 60 frame per second rendering. Another important thing is that you must call setCurrentContext on the EAGLContext before performing any drawing commands. Last, according to Joe, OpenGL is not at all forgiving if you screw something up, for example if you have an empty buffer or mismatched vertex data in the buffer. When that occurs, your application simply crashes.
The lab exercise for OpenGL was to create a "Fireworks" application that randomly generates "fireworks" using OpenGL and that simulates those fireworks exploding and then burning out. Pretty cool stuff, but man is it a lot of code to just to create relatively simple things because you must fully define all the geometry and colors and then use OpenGL functions to enable various drawing states and draw the geometry. You also of course need to implement logic to change the drawing over time, for example once a firework explodes you need to define the logic to animate the particles using lots of math and even some good old physics equations to compute position, velocity, and acceleration. I bet if they taught physics by having students implement particle engines on the iPhone more people would be into science!
Textures
After various types of pizza, including a really good barbeque pizza, for lunch, we learned about using textures in OpenGL ES. You use per-pixel coloring to spread an image file across geometric primitives (triangles, points, and lines). Textures add depth to a scene and can also be used to create shadow effects and is how you draw text using OpenGL. We extended our Fireworks application by adding texture to each exploding particle. Essentially you pin an image file to your geometry. Since adding textures is still OpenGL coding, it is low level and requires a fair amount of code to define the mapping coordinates for the texture in order to pin it to the scene geometry. But the end result is pretty cool!
Multi-touch Events
Before getting into touch events, we took an afternoon hike. It was really nice and I wished we had done the zip lines at Banning Mills today, since it is supposed to rain tomorrow. When we got back from the hike, we plowed into how to handle touch events on the iPhone. First up, Joe told us all about UIResponder, which is the base class for UIView, UIController, UIWindow, and UIApplication. Because of this inheritance relationship, subclasses gain similar functionality automatically for handling the different phases for UIResponser. The phases of UIResponser are: touchesBegan, touchesMoved, and touchesEnded. These phases allow you to handle all kinds of touch events, including up to five simultaneous touches.
The UITouch object is what you work with when handling touches. By default, multi-touch is not enabled, so you have to enable multi-touch either in code using setMultipleTouchEnabled:YES or you can set the property in Interface Builder. Each of the touch callback methods, for example touchesBegan, sends you the touches as a set of UITouch objects and a UIEvent object. You can use the event object to determine the number of touches and respond appropriately. In the lab exercise we extended the Fireworks application to respond to single touches, touch-and-drag, and multiple-touches. When handling multiple touches you need to use math and geometry to figure out things like how far apart the touches are; in the Fireworks application we made it so the further away the touches the faster we disperse the firework particles.
Core Graphics
Last for today was Core Graphics, which allows drawing in Cocoa Touch. Core Graphics is much simpler to use than OpenGL but is not as powerful. It is not designed to draw super fast animations and games like OpenGL is, and according to Joe should mostly be used for UIs where you need to do drawing.
You use the drawRect method to define your drawing commands. You draw to a CGContext graphics context. The main iPhone run loop, not you, is responsible for creating the graphics context and calling drawRect; you simply need to define what to draw, not when to do it. The basic process you follow to draw is as follows. First, get a reference to a CGContext graphics context. Second, create a CGMutablePathRef path object and then draw points, lines, curves, and shapes to the path. Next, you set the color of the graphics context, and finally you stroke or fill the path object.
During drawing you can save and restore the state of a CGContext. For example, you might perform some drawing commands, then save the context state, change a few drawing attributes and perform several more drawing operations, restore the context state, and continue drawing using the original state. According to Joe, you should not save/restore state a lot or it can really slow down your application.
Core Graphics uses the "Painter's Method" when drawing objects on screen, meaning objects are drawn from back to front. Objects drawn later are drawn over top objects that were drawn earlier, effectively replacing the existing pixels. One other thing to mention is that, using Core Graphics, you can do 2D transforms applied to CGContext to perform rotation, translation, scaling, and skewing of the shapes on screen.
Random Thoughts
My brain is starting to hurt after three days of hardcore learning and coding. Several of us started watching the Bourne Ultimatum after dinner on the nice big flat-screen TV in the Banning Mills lodge to relax a bit.
OpenGL, while powerful, is not what I'd call the most fun API I've ever worked with, and it would probably take a while to learn the ins and outs and become an expert in it. Adding textures using OpenGL can really spice up your application and make it look better. Our Fireworks application went from exploding popcorn before adding texture to looking like real, exploding firework particles after the texture was added to the particles.
Being able to handle multi-touch events is just plain cool.
Original : http://www.sleberknight.com/blog/sleberkn/entry/iphone_bootcamp_day_2
Posted on December 02, 2008 by Scott Leberknight
Today is Day 2 of the iPhone bootcamp at Big Nerd Ranch.
See here for a list of each day's blog entries.
Localization
After a nice french toast breakfast — which my dumbass CEO Chris couldn't eat because he is allergic to eggs and complained a lot and made them give him a separate breakfast — we headed down to the classroom and started off learning about localizing iPhone apps. (UPDATE: The "dumbass CEO" comment was made totally as a joke, since he was sitting right next to me in class as I wrote it. Plus, I've known him for over 12 years so it's all good. So lest you think I don't like him or something, it's just a joke and is not serious!) As with Cocoa, you basically have string tables, localized resources (e.g. images), and a separate XIB file for each different locale you are supporting. (Interface Builder stores the UI layout in an XML format in a XIB file, e.g. MainWindow.xib.) This means that, unlike Java Swing for example, you literally define a separate UI for each locale. We localized our DistanceTracker application that we built on day one for English and German locales. To start you use the genstrings command line utility to generate a localizable string resource and then in Xcode make it localizable; this creates separate string tables for each language which a translator can then edit and do the actual translation. You also need to make the XIB files localized and then redo the UI layout for each locale. Sometimes this might not be too bad, but if the locale uses, for example, a right-to-left language then you'd need to reverse the position of all the UI controls. While having to create essentially a separate UI for each locale seems a bit onerous, it makes a certain amount of sense in that for certain locales the UI might be laid out completely differently, e.g. think about the right-to-left language example. Finally, you use NsLocalizedString in code, which takes a string key and a comment intended for the translator which is put into the string tables for each locale - at runtime the value corresponding to the specified key is looked up based on the user's locale and is displayed. If a value isn't found, the key is displayed as-is which might be useful if you have a situation where all locales use the same string or something like that.
View Controllers
After localization we tackled view controllers. View controllers control a single view, and are used with UITabBarController and UINavigationController. We created a "navigation-based application" which sets up an application containing a UINavigationController. The difference between UITabBarController and UINavigationController is that the tab bar controller stores its views in a list and allows the user to toggle back and forth between views. For example, the "Phone" application on the iPhone has a tab bar at the bottom (which is where it is displayed in apps) containing Favorites, Recents, Contacts, Keypad, and Voicemail tab bar items. Tab bar items are always visible no matter what view is currently visible. As you click the tab bar items, the view switches. So, a UITabBarController is a controller for switching between views in a "horizontal" manner somewhat similar to the cover flow view in Finder. On the other hand you use UINavigationController for stack-based "vertical" navigation through a series of views. For example, the "Contacts" iPhone application lists your contacts; when you touch a contact, a detail view is pushed onto the UINavigationController stack and becomes the visible and "top" view. You can of course create applications that combine these two types of view controllers. In class we created a "To Do List" application having a tab bar with "To Do List" and "Date & Time" tabs. If you touch "To Do List" you are taken to a list of To Do items. Touching one of the To Do items pushes the To Do detail view onto the stack, which allows you to edit the item. Touching "Date & Time" on the tab bar displays the current date and time in a new view.
It took me a while to get my head wrapped around combining the different types of view controllers in the same application and how to connect everything together. Since I am used to web app development, this style of development requires a different way of thinking. I actually like it better since it has a better separation of concerns and is more true to the MVC pattern than web applications are, but I'm sure I'll have to try to build more apps using the various view controllers to get more comfortable.
Table Views
We had a good lunch and after that headed back down to cover table views. Table views are views that contain cells. Each cell contains some data that is loaded from some data source. For example, the "Contacts" application uses a UITableView to display all your contacts. The "To Do List" application we created earlier also uses a UITableView to list the To Do items. Basically, UITableView presents data in a list style.
Table views must have some data source, such as an array, a SQLite database, or a web service. You are responsible for implementing data retrieval methods so that when the table view asks for the contents of a specific cell, you need to offer up a cell containing the data appropriate for the row index. Since the iPhone has limited real estate, UITableView re-uses cells that have been moved off screen, for example if they are scrolled out of view. This way, rather than create new cells every single time UITableView asks for a cell, you instead ask if there are any cells that can be re-used. If so, you populate the cell with new data and return it.
UITableView also provides some basic functionality, like the ability to drag cells, delete them, etc. You only need to implement the logic needed when events, like move or delete, occur. Another thing you typically do with table views is respond when a user touches a cell. For example, in the "To Do List" application a new "detail" view is displayed when you touch a cell in the table view. This is probably the most common usage; table views display aggregate or summary data, and you can implement "drill down" logic when a user touches a cell. For example, when a user touches a To Do item cell, a new view controller is pushed onto the stack of a UINavigationController showing the "detail" view and allowing you to edit the To Do item. Another cool thing you can do with table views is to subclass UITableView in order to lay out subviews in each cell. In the "To Do List" app, we added subviews to each cell to show the To Do item title, part of the longer item description in smaller font, and an image to the left of the title if the item was designated as a "permanent" item. The "Photo Albums" iPhone application also uses subviews; it shows an image representing the album and the album title in each cell.
Saving and Loading Data Using SQLite
By this time, it was already late afternoon, and we hiked out to the old paper mill and back. It stared getting colder on the way back as the sun started to set. When we got back, we learned all about saving and loading data using SQLite. First, we learned about the "Application Sandbox" which can only be read/written by your application, for security reasons. There are several locations that each iPhone application can store data. Within you application's bundle (e.g. <AppName.app>) there is Documents, Library/Preferences, Library/Caches, and tmp folders. Documents contains persistent data, such as a SQLite database, that gets backed up when you sync your iPhone. Library/Preferences contains application preference data that gets backed up when you sync. Library/Caches, which Joe and Brian (the other instructor who is helping Joe this week) just found out about before our hike, is new in version 2.2 of the iPhone software, and stores data cached between launches of your application. The tmp directory is, as you expect, used for temporary files. You as the developer are responsible for cleaning up your mess in the tmp folder, however!
After discussing the sandbox restrictions, we learned how you can locate the Documents directory using the NSSearchPathForDirectoriesInDomains function. Finally, we learned how to use SQLite to add persistence to iPhone applications using SQLite, which I continually misspell with two "L"s even though there is really only one! SQLite supports basic SQL commands like select, insert, update, and delete. The reason you need to know how to find the Documents directory is because you'll need to create a copy of a default SQLite database you ship with your application into Documents. Basically, you supply an empty database with your application's Resources — this is read-only to your app. In order to actually write new data, the database must reside in a location (such as Documents) where you have access to write. So, the first thing to do is copy the default database from Resources to the Documents directory where you can then read and write, and where the database will then automatically be backed up when the user syncs her iPhone.
We then added SQLite persistence to the "To Do List" application. While I think SQLite is cool in theory, actually using it to query, insert, update, and delete data is painful, as you have to handle all the details of connecting, writing and issuing basic CRUD queries, stepping through the results, closing the statements, cleaning up resources, etc. It feels like writing raw JDBC code in Java but possibly worse, if that's possible. Someone told me tonight there is supposedly some object-relational mapping library which makes working with SQLite more palatable, though I don't remember what it was called or if it is even an object-relational mapper in the same sense as say, Hibernate. Regardless, I persisted (ha, ha) and got my "To Do List" application persisting data via SQLite.
WebKit
Joe apparently gave a short lecture on using WebKit in iPhone applications at this point. Unfortunately I decided to go for a run and missed the lecture. In any case, WebKit is the open source rendering engine used in Safari (both desktop and mobile versions) to display web content. You use UIWebView in your application and get all kinds of functionality out-of-the-box for hardly any work at all. UIWebView takes care of all the rendering stuff including HTML, CSS, and JavaScript. You can also hook into events, such as when the web view started and finished loading, via the UIWebViewDelegate protocol. In our lab exercises after dinner, we implemented a simple web browser using UIWebView and used an activity progress indicator to indicate when a page is loading.
In addition to loading HMTL content in UIWebView, you can also load things like images and audio content. It is ridiculously easy to add a UIWebView to your application in order to display web content.
Random Thoughts
Another long day has come and gone. It is amazing how much energy everyone has to basically learn all day and keep going well into the night hours.
Today we learned about localization on the iPhone. The most important thing is that you need to create a separate UI for each locale you are supporting. This means you should not work on localizing until right before you are ready to ship; otherwise you'll spend all your time continually tweaking all the localized UI after every little change you make.
Tab and navigation view controllers are powerful ways to implement application navigation using a tab paradigm or a stack-based, guided navigation scheme, respectively. Combined with table views, you can accomplish a lot with just these three things.
While I think having a relational database available for persistence in your iPhone apps is nice, I really do not want to write the low-level code required to interact with SQLite; once you get used to using an ORM tool like Hibernate or ActiveRecord you really don't want to go back to hand-writing basic CRUD statements, marshaling result sets into objects and vice-versa, and managing database resource manually. Guess I'll need to check into that SQLite library someone mentioned.
It is surprisingly easy to integrate web content directly into an iPhone application using UIWebView!
Tomorrow looks to be really cool, covering things like media and OpenGL. Until then, ciao!
Original :
http://ignorethecode.net/blog/2008/03/08/code-signing-on-the-iphone-and-on-mac-os-x/
Mike Ash of Rogue Amoeba has written a fantastic article about code signing, and about how Apple is using it in Mac OS X and on the iPhone.
if Apple doesn’t sign your iPhone app, it does not run. Even for local development, you need to get the code signed. The iPhone SDK is free, but by itself it won’t let you load apps onto an iPhone. When you pay Apple the $99 to enroll in the program, they send you a certificate which can be used to sign your applications. However, they will only work on iPhones which have been provisioned with this certificate.
Actually, if you haven’t already, stop right here and go read the article. Don’t worry, I’ll wait.
Done? Good.
Personally, I don’t mind Apple signing applications they sell on the iPhone app store. What I do mind is that Apple does not give me a way to write code, run it unsigned or self-signed (with a non-Apple certificate) on my own iPhone, and give it (again, unsigned or self-signed) to my friends who have iPhones. In other words, I want to be able to sign code with a non-Apple certificate, and I want a way to tell the iPhone to accept all code signed with a given certificate, even if that certificate has nothing to do with Apple. There are several reasons for this.
First of all, I recognize that Apple is under no obligation to make it easy for me to run applications on the iPhone. Still, I think it’s wrong for a company to serve as a gatekeeper, imposing its own morals (if a company can even be said to have morals) on the users of its devices. A technology company should enable people, not disable them. Telling its users what applications they are allowed to run is ultimately hurting them, and hurting progress. While I can understand that media companies have an incentive to hurt progress, tech companies should avoid going down the same road; in the end, it will only hurt themselves.1
Second, it hurts the iPhone. Apple’s guidelines effectively disallow many perfectly legal applications. In his article, Mike mentions porn. Porn is an important market force. It’s no coincidence that pornographic web sites make up a huge part of all web sites, and pornography makes up a large amount of all internet traffic. I understand that Apple doesn’t want to sell pornographic material on its store, but by not allowing Apple-unsigned code to run on iPhones, they’re not only keeping porn out of their store, they’re keeping porn out of the iPhone entirely2. And this is not the only genre of applications affected; Apple’s guidelines forbid applications which run in the background, which affects things like social networking software, VOIP clients or chat applications. By keeping these apps out of the store, Apple keeps them out of the iPhone; many groundbreaking applications which could have made the iPhone a rule changer are effectively forbidden because the iPhone only runs code signed by Apple.
Third, it’s bad for application quality. Typically, developers run beta tests to find bugs in their applications. How can a developer run a beta test if running code on a beta tester’s iPhone requires that the code is signed by Apple?
Finally, how do I send review copies to magazines, or free copies of my app to friends?
Requiring code to be signed by Apple is a dangerous path to follow. Unfortunately, Apple already seems to have plans to require signed code on Mac OS X. That, by itself, is quite inconvenient, but not necessarily a bad thing; it gives users the security of knowing where code comes from. However, requiring code to be signed by Apple even on Mac OS X would be a tremendously bad move, and would probably ultimately hurt Apple, its developers, and its users.
Update: Rogue Amoeba has now started filing bugs against these restrictions. Good idea.
March 8th, 2008 / Tags: iphone, sdk, code signing, mac os x, apple, rogue amoeba software, mike ash / Trackback http://ko.wikipedia.org/wiki/%ED%8E%98%EC%96%B4%ED%94%8C%EB%A0%88%EC%9D%B4
페어플레이(FairPlay))는 애플이 소유하고 있는 디지털 권리 관리 (DRM) 기술이다. 애플이 베리디스크(Veridisc) 사의 기술에 기반하여 페어플레이를 개발하였다. 페어플레이는 퀵타임 멀티미디어 소프트웨어에 내장되어 들어가 있다. 페어플레이는 애플 아이폰, 아이팟, 아이튠즈, 아이튠즈 스토어, 앱 스토어 등에 쓰인다. 아이튠즈를 가지고 아이튠즈 스토어에서 구매한 "보호되는" 음악 파일은 모두 페이플레이를 통해 인코딩된다. 페어플레이는 음악 파일인 고급 오디오 부호화(AAC) 파일을 암호화한다. 페어플레이는 사용자로 하여금 인증 안 된 컴퓨터에서 이 파일을 재생할 수 없게 만든다.
시중의 페어플레이로 암호화된 콘텐츠 중 대다수는 아이튠즈 소프트웨어를 사용하여 아이튠즈 스토어에서 사람들이 구매한 콘텐츠들이다. 아이튠즈 소프트웨어는 암호화된 콘텐츠를 재생하기 위하여 애플의 퀵타임 멀티미디어 소프트웨어에 의존한다. 애플의 퀵타임을 이용하면 어떤 플레이어이든지 페어플레이로 암호화된 파일을 재생할 수 있다. 이러한 방법을 사용하는 소프트웨어로서는 리얼플레이어 미디어 플레이어 클래식이 있다.
[편집] 페어플레이의 동작
페어플레이로 보호되는 파일은 일반적인 MP4 콘테이너(MPEG-4 Layer 14를 말한다.) 형식을 가지고 있다. 다만 그 안에 암호화된 AAC 오디오 스트림을 담고 있다. 페어플레이는 오디오 스트림을 고급 암호 표준 (AES) 알고리즘을 써서, 또한 MD5 해쉬도 섞어쓰면서 암호화한다. 암호화된 오디오 스트림을 풀기 위해서는 마스터 키(master key)가 필요하다. 이 마스터 키는 MP4 콘테이너 파일 안에 암호화된 형태로 저장된다. 마스터 키를 해독하기(풀기) 위해 필요한 키는 "사용자 키"(user key)라고 불린다.
사용자가 아이튠즈를 이용하여 곡 한 곡을 살 때마다, 새로운 랜덤 사용자 키(user key)가 생성된다. 이 때 생성된 사용자 키는 마스터 키로 암호화된다. 랜덤 사용자 키는 사용자 계정 정보와 함께 애플의 서버에 저장되며, 또한 아이튠즈로 전송된다. 아이튠즈 스토어는 이들 키를 고유의 암호키 보관소에 저장한다. 나중에 이 암호키 보관소를 찾아가서, 아이튠즈는 마스터 키를 해독할 수 있는 사용자 키를 얻어온다. 마스터 키를 사용하여, 아이튠즈는 AAC 오디오 스트림을 해독하여 재생한다.
사용자가 새로이 자신의 컴퓨터를 인증하면, 아이튠즈는 애플의 서버로 고유한 기기 아이디(machine identifier)를 전송한다. 응답으로서, 아이튠즈는 서버로부터 사용자 계정에 연관된 모든 사용자 키(user keys)를 받는다. 이러한 방법을 통해 애플은 사용자가 한 번에 인증할 수 있는 컴퓨터의 개수를 제한할 수 있었다. 또한, 각각의 인증된 컴퓨터가 구매한 콘텐트를 재생할 수 있는 사용자 키를 갖고 있음을 확실히 할 수 있었다.
사용자가 자신의 컴퓨터를 인증 해제하면, 아이튠즈는 고유한 기기 아이디(machine identifier)를 서버에서 지워줄 것을 애플의 서버에 요청한다. 동시에 암호키 보관소에서 모든 사용자 키를 제거할 것을 요청한다.
애플 아이팟에 대해서는 아이팟 용도로 할당된 암호키 보관소가 있다. 페어플레이로 보호된 음악 파일이 아이팟에 복사될 때마다, 아이튠즈는 사용자 키를 아이튠즈 고유의 암호키 보관소에서 아이팟 용도로 할당된 암호키 보관소로 매번 복사한다. 이렇게 함으로써 보호된 음악 파일을 아이팟에서 재생할 수 있다.
페어플레이는 사용자들이 파일 복사를 하는 것을 막지는 않는다. 다만 파일 안의 오디오 스트림에 대한 암호 해독(풀기)만을 제어한다.
FairPlay
From Wikipedia, the free encyclopedia
This article is about Digital Rights Management system. For other uses, see Fair Play.
FairPlay is a digital rights management (DRM) technology created by Apple Inc., based on technology created by the company Veridisc. FairPlay is built into the QuickTime multimedia software and used by the iPhone, iPod, iTunes, and iTunes Store and the App Store. Any protected song or other form of media purchased from the iTunes Store with iTunes is encoded with FairPlay. FairPlay digitally encrypts AAC audio files and prevents users from playing these files on unauthorized computers.
The majority of FairPlay-encrypted content is purchased through the iTunes Store, using the iTunes software. The iTunes software relies on Apple's Quicktime multimedia software for decoding and playback of the encrypted files. Every media player capable of utilizing QuickTime is capable of playing back FairPlay-encrypted files, including RealPlayer, Media Center, Media Player Classic and Songbird[1].
[edit] How it works
FairPlay-protected files are regular MP4 container files with an encrypted AAC audio stream. The audio stream is encrypted using the AES algorithm in combination with MD5 hashes. The master key required to decrypt the encrypted audio stream is also stored in encrypted form in the MP4 container file. The key required to decrypt the master key is called the "user key."
Each time a customer uses iTunes to buy a track a new random user key is generated and used to encrypt the master key. The random user key is stored, together with the account information, on Apple’s servers, and also sent to iTunes. iTunes stores these keys in its own encrypted key repository. Using this key repository, iTunes is able to retrieve the user key required to decrypt the master key. Using the master key, iTunes is able to decrypt the AAC audio stream and play it.
When a user authorizes a new computer, iTunes sends a unique machine identifier to Apple’s servers. In return it receives all the user keys that are stored with the account information. This ensures that Apple is able to limit the number of computers that are authorized and makes sure that each authorized computer has all the user keys that are needed to play the tracks that it bought.
When a user deauthorizes a computer, iTunes will instruct Apple’s servers to remove the unique machine identifier from their database, and at the same time it will remove all the user keys from its encrypted key repository.
The iPod also has its own encrypted key repository. Every time a FairPlay-protected track is copied onto the iPod, iTunes will copy the user key from its own key repository to the key repository on the iPod. This makes sure that the iPod has everything it needs to play the encrypted AAC audio stream.
FairPlay does not affect the ability of the file itself to be copied. It only manages the decryption of the audio content.
[edit] Restrictions
FairPlay-encrypted audio tracks allow the following:
- The track may be copied to any number of iPod portable music players (including the iPhone).[2] (However, each iPod/iPhone can only have tracks from a maximum of five different iTunes accounts)
- The track may be played on up to five (originally three) authorized computers simultaneously.[2]
- A particular playlist within iTunes containing a FairPlay-encrypted track can be copied to a CD only up to seven times (originally ten times) before the playlist must be changed.[3]
- The track may be copied to a standard Audio CD any number of times.[3]
- The resulting CD has no DRM and may be ripped, encoded and played back like any other CD. However, CDs created by users do not attain first sale rights and cannot be legally leased, lent, sold or distributed to others by the creator.
- The CD audio still bears the artifacts of compression, so converting it back into a lossy format such as MP3 may aggravate the sound artifacts of encoding (see transcoding). When re-ripping such a CD one could use a lossless audio codec such as AIFF, Apple Lossless, FLAC or WAV however such files take up significantly more space than the original .m4p files
At this time, it appears that the restrictions mentioned above are hard-coded into QuickTime and the iTunes application, and not configurable in the protected files themselves.
Fairplay prevents iTunes customers from using the purchased music directly on any portable digital music player other than the Apple iPod, Motorola ROKR E1, Motorola SLVR, Motorola RAZR V3i, and the iPhone.
[edit] Legal issues
On January 3, 2005, an iTunes online music store customer, Thomas Slattery, filed a lawsuit against Apple Inc., alleging the company broke antitrust laws by utilizing FairPlay with iTunes so that purchased music will work only with its own music player, the iPod, freezing out competitors.[4] Though most of the complaints have been dropped, the case has since been combined with two other lawsuits and continues today under the temporary name "The Apple iPod iTunes Antitrust Litigation."[5]
On June 28, 2004, VirginMega filed a complaint with the French Competition Council against Apple regarding its refusal to license Fairplay to VirginMega for use in their own online music commerce store. The French Conseil de la Concurrence rejected the complaint over accused anti-competitive behavior.[6] The Conseil ruled against the notion that FairPlay was an "essential facility" for three distinct reasons: 1) Playing purchased music on portable players was a small part of the market; 2) CD Burning provides an adequate work-around to get purchased music from other vendors onto an iPod; and 3) There is sufficient availability of portable players that support Microsoft's WMA DRM as a viable alternative and choice for consumers.[7]
[edit] Circumventing FairPlay
After the launch of the iTunes Store multiple people attempted to circumvent the encryption of FairPlay-protected files.
[edit] QTFairUse
Jon Johansen – also known for his DeCSS program – was the first to discover a way to circumvent the DRM. The open source application QTFairUse intercepted the decrypted output and wrote it to a raw AAC file. Many media players do not support such raw files and the files had to be processed with a tool like FAAD to create normal files. One of the few media players that is able to play raw AAC files is foobar2000.
The second time around, Johansen reverse engineered the encryption technique used in FairPlay and created an algorithm to completely remove the encryption without re-encoding the encrypted AAC stream. This method was also used by VLC media player in order to play FairPlay-protected tracks until newer version of iTunes and FairPlay broke it.
Only a few days after the release of iTunes 7.0 the experimental version 2.3 of QTFairUse6, a derivative of the python open source QTFairUse, was released which dumps each track to a raw AAC file which then can be converted to any format.
Jon Johansen himself also released a tool to remove the encryption, called DeDRMS. Later he released FairKeys, which uses Apple’s own servers to retrieve the keys needed by DeDRMS.
All these applications have two things in common. First of all, they use the user keys from either the Apple servers, the iTunes key repository, or the iPod key repository, which ensures they can decrypt only files that are legally bought; a user cannot use these applications to decrypt files that another user bought. Second, they keep user specific metadata inside the MP4 container intact, so it is possible to identify the user who originally bought the file after it is decrypted.
In March 2005, it was revealed through a front end of the iTunes Store called PyMusique that the FairPlay DRM was added only as a song was being purchased from the store by the client software itself.
In October 2006, Jon Johansen announced that instead of breaking FairPlay, he had reverse-engineered it so that other companies could play their DRM-protected music and movies on iPods and Apple's new Apple TV. His company, doubleTwist, would license the technology to media companies who wished to have their media playable on the iPod or Apple TV, with the protection of FairPlay DRM, but without having to go through Apple.[8]
[edit] Playfair, Hymn, and JHymn
A software package named PlayFair – created by an anonymous author – also appeared. It can remove the encryption from files using the FairPlay DRM mechanism. The author of Playfair used the source code written by Jon Johansen for VLC. Apple's legal department forced PlayFair to be first removed from SourceForge.net, and then when the Indian open source web site Sarovar.org hosted the project they too were sent a cease and desist by Apple's lawyers. However, Playfair's successor Hymn (a backronym for "Hear Your Music aNywhere") is alive and well and has become JHymn, a Java variant of the program, and iOpener, a Windows variant.
Apple Computer introduced iTunes 6.0 in October 2005, which included changes intended to stop programs like JHymn from decrypting FairPlay encrypted files. Furthermore, once iTunes 6 has been used to purchase songs or authorize a computer with a particular iTMS account, that account will be blocked from making purchases or activations on earlier iTunes versions, thus JHymn can no longer be used.[9]
Apple Computer introduced iTunes 7.0 in September 2006, which once again included changes intended to stop programs similar to JHymn.
[edit] Harmony: RealPlayer Music on the iPod
In July 2004, RealNetworks introduced their Harmony technology. The Harmony technology is built into RealPlayer and allows users of the RealPlayer Music Store to play their songs on the iPod. Before the introduction of Harmony this was not possible, because the RealPlayer Music Store uses a different DRM scheme, called Helix DRM, that was incompatible with that used by Apple. While using RealPlayer to transfer a Helix DRM-restricted song onto the iPod, Harmony transparently converts it to a FairPlay-compatible protected file. Real argued that Harmony was a boon to consumers that "frees" them "from the limitation of being locked into a specific portable device when they buy digital music."[10] Apple responded:
- We are stunned that RealNetworks has adopted the tactics and ethics of a hacker to break into the iPod, and we are investigating the implications of their actions under the DMCA and other laws. We strongly caution Real and their customers that when we update our iPod software from time to time it is highly likely that Real's Harmony technology will cease to work with current and future iPods.
RealNetworks launched an internet petition titled "Hey Apple! Don't break my iPod", encouraging iPod users to sign up to support Real's action. The petition backfired badly. [11] The overwhelming majority of posters reacted negatively. The main points of criticism against Harmony were:
- Many posters accused RealNetworks of astroturfing with the petition they had created.
- RealNetworks was criticised for hypocrisy in keeping its own intellectual property and products closed, while asking Apple to open up the iPod.
- The move was also denounced as an attempt to force Apple into a partnership that would only benefit RealNetworks.
Apple did disable Harmony around the time of the iPod photo launch, and to older versions shortly after in firmware updates. The change makes it so that all music (past and present) purchased through the RealPlayer Music Store will not work on Apple's iPod. In response, Real said they would get it working again.
In August 2005, an SEC filing by RealNetworks disclosed that continued use of the Harmony technology put themselves at considerable risk because of the possibility of a lawsuit from Apple, which would be expensive to defend against, even if the court agreed that the technology is legal. Additionally, the possibility that "Apple will continue to modify its technology to 'break' the interoperability that Harmony provides to consumers" would mean that "Harmony may no longer work with Apple's products, which could harm our business and reputation, or we may be forced to incur additional development costs to refine Harmony to make it interoperate again."[12]
Harmony never resurfaced as an option by RealNetworks.
[edit] Requiem
Requiem was originally released by "Brahms" as version 1.0 in February 2008, and has been recently released in November 2008 as version 1.8.2. Requiem allows a person to decrypt both music and movies that they are authorized to play in iTunes by reverse-engineering Apple's FairPlay algorithm. Requiem does not remove Apple's "Watermark" from the song. The purchaser's e-mail and name are still encoded on the track.
Requiem works by decrypting the iTunes configuration files that are in "/Users/Shared/SC Info". In Mac OS X, the key to decrypt these config files is an obfuscated version of the MAC address of one's computer. In Windows, an amalgamation of hard drive volume information and registry keys are used instead of the MAC address. The initialization variable for this decryption is a hard coded constant. The program then decrypts the keys in the config files as well as the private atoms in the audio/video files and creates unencrypted versions. [13] An updated iTunes 7.6.2 disabled Requiem, however, versions 1.4 and 1.5 again circumvented the protection. Apple again disabled Requiem with iTunes 8, but the author has released version 1.8.2 which circumvents iTunes 8 DRM on Mac OS and Microsoft Windows systems. Apple responded by releasing iTunes 8.0.2, which again disabled Requiem.
Apple has taken steps to remove references to Requiem from the JHymn forums. A post on the JHymn forums explains Apple's cease and desist order against the forum regarding posting information on circumvention technologies like Requiem. Since the C&D order, the author of Requiem has made it available with source code on the anonymous Freenet network, from which it's been copied onto popular BitTorrent public trackers, such as The Pirate Bay.
[edit] Conversion to analog
There are mainly two other methods to bypass the DRM control. The first method is to burn a copy to an audio CD — either real or virtual — and then rip it.
The second method is to use a recording software and sound card, utilizing the so-called "analog hole". For example, Replay Music which records and also identifies and tags the songs using an audio fingerprinting algorithm.
[edit] Steve Jobs Thoughts on Music open letter
On February 6, 2007, Steve Jobs, CEO of Apple Inc., published an open letter entitled Thoughts on Music on the Apple website calling on the "big four" music companies to sell their music without DRM.[14] According to Jobs, Apple does not want to use DRM but is forced by the four major musical labels with whom Apple negotiates contracts for iTunes. Jobs's main points were:
- DRM has never and will never be perfect. Hackers will always find a method to break DRM.
- DRM restrictions only hurt people using music legally. Illegal users aren't affected by DRM.
- The restrictions of DRM encourage users to obtain unrestricted music which is usually only possible via illegal methods.
- The vast majority of music is sold without DRM via CDs which has proven successful.
Jobs's letter was met with some praise but many others criticized Apple's hypocritical approach to DRM. While openly criticizing DRM, Apple has been actively threatening or suing anybody trying to open their own DRM or make it interoperable. Critics claim that this is not because Apple is afraid of illegal copies but because it gives them an advantage in their market position as a leader in both electronic music sales (iTunes) and in music players (iPod), reinforcing each other due to the FairPlay DRM. [15] [16] [17] [18].
[edit] Selected responses to Thoughts on Music
The essay caused ripples across the music industry, prompting replies from other major players. Responses include those from Jon Lech Johansen on February 6, MP3.com founder Michael Robertson on February 8, Warner Music boss Edgar Bronfman and the open DRM Coral Consortium on February 9, head of Yahoo Music Dave Goldberg on February 11, Fred Amoroso of Macrovision on February 16 and the Free Software Foundation on March 7.
[edit] DVD Jon
The famous decoder of the Content Scramble System, Jon Lech Johansen, criticized Jobs' statistical evidence that users are not locked into using the iPod by using the iTunes Store to download music with Apple Computer's FairPlay (DRM).[19]
[edit] Warner Music Group Corp.'s Edgar Bronfman
In a conference call on the earnings of Warner Music Group Corp., CEO Edgar Bronfman argued in favor of DRM, claiming that DRM and interoperability are not mutually exclusive.[20]
[edit] Coral Consortium
A multi-industry group working on creating interoperability between DRM formats, the Coral Consortium responded with an invitation to incorporate their technical specifications for interoperability into the iTunes framework.[21]
[edit] Yahoo's Dave Goldberg
In the Silicon Valley Watcher, Tom Foremski interviewed Yahoo Music head Dave Goldberg, who advocated removing DRM from music altogether.[22]
[edit] Macrovision's Fred Amoroso
CEO and President of Macrovision Corporation, Fred Amoroso posted his own open letter in response to Steve Jobs's. In his reply, Amoroso argued that DRM increases both consumer value and electronic distribution by giving users choices (e.g. rent vs. buy). He also argues in favor of interoperable and open DRM.[23]
[edit] iTunes Store DRM changes
[edit] EMI music made available DRM-free
On April 2, 2007, Steve Jobs and EMI announced DRM free music for EMI's complete music library for a 30¢ premium above the standard price. This began in May 2007. Soon after, Amazon.com began selling unrestricted music files for 99¢ and Apple dropped the price of its DRM free music back to 99¢.
[edit] Announcement of FairPlay restrictions removal
On January 6, 2009, Apple announced at the 2009 Macworld Conference & Expo that it had reached an agreement with major record labels to sell all music on the iTunes Store free of DRM restrictions. Eight million tracks were available with FairPlay restrictions removed from that day,[24] with the remainder of the music store to be DRM-free by the end of March 2009.[25] Apple continues to use a number of DRM restrictions on items sold from the iTunes store. [26]
[edit] References
- ^ "Songbird"
- ^ a b "Apple - Support - iTunes Store - Authorization FAQ". Apple.com. http://www.apple.com/support/itunes/store/authorization/. Retrieved on 2008-09-13.
- ^ a b "Can't burn a CD in iTunes for Windows". Docs.info.apple.com. http://docs.info.apple.com/article.html?artnum=93360. Retrieved on 2008-09-13.
- ^ "InternetNews Realtime IT News – Apple Hit by Lawsuit". Internetnews.com. http://www.internetnews.com/bus-news/article.php/3455431. Retrieved on 2008-09-13.
- ^ "Apple Inc. 10-Q". EDGAR. 2007-05-10. 38. http://sec.gov/Archives/edgar/data/320193/000110465907037745/a07-13266_110q.htm. Retrieved on 2007-06-21.
- ^ Décision n° 04-D-54 du 9 novembre 2004 relative à des pratiques mises en oeuvre par la société Apple Computer, Inc. dans les secteurs du téléchargement de musique sur Internet et des baladeurs numériques
- ^ iTunes, DRM and competition law
- ^ Gannes, Liz (2006-10-02). "DVD Jon Fairplays Apple". GigaOM. Archived from the original on 2007-11-02. http://web.archive.org/web/20071102203847rn_1/gigaom.com/2006/10/02/dvd-jon-fairplays-apple/.
- ^ DRM. "JHymn Info and Help". Hymn-project.org. http://www.hymn-project.org/jhymndoc/. Retrieved on 2008-09-13.
- ^ "RealNetworks Introduces Harmony, Enabling Consumers to Buy Digital Music that Plays on All Popular Devices". Realnetworks.com. http://www.realnetworks.com/company/press/releases/2004/harmony.html. Retrieved on 2008-09-13.
- ^ "Real v Apple music war: iPod freedom petition backfires - Hardware - Breaking Business and Technology News at silicon.com". Hardware.silicon.com. http://hardware.silicon.com/storage/0,39024649,39123271,00.htm. Retrieved on 2008-09-13.
- ^ AppleInsider Staff. "AppleInsider | Real admits risk of Apple lawsuit". Appleinsider.com. http://www.appleinsider.com/article.php?id=1228. Retrieved on 2008-09-13.
- ^ Requiem 1.7.3 README file
- ^ Jobs, Steve (2007-02-06). "Thoughts on Music". http://www.apple.com/hotnews/thoughtsonmusic. Retrieved on 2007-06-21.
- ^ [1]
- ^ [2]
- ^ [3]
- ^ [4]
- ^ "nanocr.eu » Blog Archive » Steve’s misleading statistics". Nanocrew.net. http://nanocrew.net/2007/02/06/steves-misleading-statistics/. Retrieved on 2008-09-13.
- ^ "Warner Music Group F1Q07 (Qtr End 12/31/06) Earnings Call Transcript - Seeking Alpha". Media.seekingalpha.com. http://media.seekingalpha.com/article/26496. Retrieved on 2008-09-13.
- ^ "Welcome to Coral Consortium". Coral-interop.org. http://www.coral-interop.org/20070209_Coral_Letter.html. Retrieved on 2008-09-13.
- ^ "Yahoo exec says removing DRM from music boosts sales". Siliconvalleywatcher.com. http://www.siliconvalleywatcher.com/mt/archives/2007/02/yahoo_exec_says.php. Retrieved on 2008-09-13.
- ^ "Article & Reviews - Macrovision". Macrovision.com. http://www.macrovision.com/company/1430_5331.htm. Retrieved on 2008-09-13.
- ^ Apple to end music restrictions, BBC News, 7 January 2009.
- ^ Cohen, Peter (2009-01-07). "iTunes Store goes DRM-free". Macworld. Mac Publishing. http://www.macworld.com/article/137946/2009/01/itunestore.html. Retrieved on 2009-02-10.
- ^ Apple Shows Us DRM's True Colors
iPhone 2.0 SDK: How Signing Certificates Work
March 18th, 2008 | History, Journal, Markets, Mobiles, Software, Tech, the Media
Daniel Eran Dilger
작년 5월, 필자는 아이폰용 써드파티 소프트웨어에 대해 애플이 어떤 계획을 갖고있는지 확인시켜줄 수 없겠느냐고 스티브 잡스에게 물었었다. 그는 당시, 아이폰용으로 되어있는 웹 플랫폼 이외에도 소프트웨어 시장이 있음을 애플도 깊이 인식하고 있다고 말했지만, 한편 보안과 개방 간의 균형을 맞추기 위해 "노력중"이라 확인시켜 주었다. 잡스는 그 해 여름, All Things D.에서도 유사한 발언을 계속 하였다.
2007년 애플주주총회 참관기
10월달, 잡스는 공식적인 메시지를 전했다. 애플이 네이티브 SDK를 제공하겠다는 내용이다. 또한 노키아의 "Symbian Signed" 디지탈 사인 프로그램과 유사한 프로그램을 채택하겠다는 힌트를 주었다. 바이러스나 악성 소프트웨어, 불법복제 공격을 막으면서, 합법적인 개발자들이 아이폰에 기여할 수 있도록 하기 위해서이다. 현재 이 메시지를 애플 서버에서 찾기는 불가능해 보이지만, 발표된 내용은 다음과 같았다.
"말해 보죠. 아이폰용 네이티브 써드파티 애플리케이션, 저희도 원합니다. 그래서 2월달에 개발자들에게 SDK를 넘길 계획이에요.역동적인 써드파티 개발자 커뮤니티가 아이폰용 애플리케이션을 수 천 가지 만들면 저희도 기쁘겠습니다. 애플의 혁명적인 멀티-터치 인터페이스와 강력한 하드웨어, 진보적인 소프트웨어 아키텍쳐를 갖춘 것이 아이폰입니다. 개발자들을 위해서도 최고의 모바일 플랫폼이리라고 봅니다.
일단은 2월달까지 기다리셔야겠습니다. 완전히 반대되는 일 두 가지를 한꺼번에 처리해야하기 때문이에요. 진보적이고 개방된 플랫폼을 개발자들에게 넘기는 동시에, 아이폰 사용자들을 바이러스와 악성 소프트웨어, 불법복제로부터 보호해야하기 때문입니다. 쉬운 일이 아니에요. 휴대폰에 바이러스와 악성 소프트웨어가 별 문제가 안된다는 주장도 있지만, 그렇지가 않습니다. 이미 심각한 휴대폰용 바이러스가 나와 있어요. 휴대폰과 휴대폰 사이를 통신망을 통해 조용히 퍼지는 종류도 있죠. 휴대폰이 보다 강력해질수록, 이런 악성 프로그램은 보다 위험해질 겁니다. 아이폰은 제일 진보적인 휴대폰이기에, 아이폰 또한 분명한 목표가 될 것이고요.
이미 행동하는 회사들이 있습니다. 가령, 노키아는 개발자가 누구인지 추적할 수 있는 디지탈 사인이 없는 경우, 일부 최신 휴대폰에 해당 애플리케이션 설치를 못하게 막고 있어요. "완전한 개방"과는 거리가 있지만, 이것이 올바르다고 봅니다. 저희는 아이폰의 놀라운 소프트웨어 플랫폼에 네이티브로 접근할 수 있는 시스템을 제공하는 동시에, 사용자들을 악성 프로그램으로부터 지켜주는 작업을 하는 중이에요.
몇 달 더 기다려주시면 감사하겠습니다. 하지만 SDK가 나오면, 안전하고 신뢰성 있는 아이폰에서 돌아가는 훌륭한 써드파티 애플리케이션으로 수 년은 보상받으실 겁니다.
Steve
P.S.: SDK로 아이포드 터치용 애플리케이션도 만들 수 있을 겁니다."
iPhone SDK 개방과 그 의미
What Do Signing Certificates Do?
애플리케이션 사인이 보안과 어떤 관계가 있을까? 컴퓨터 업계에서, 코드 사인은 서류 밑에 하는 사인의
의미보다 더 의미가 크다. 사인된 코드는 옛날, 양피지로 둘둘 만 문서에, 뜨거운 왁스와 함께 반지 도장을 찍었던 것과 더 유사하다. 한 번 뜯으면, 받는이는 이 문서전달 과정에 뭔가 일이 있었다고 생각하게 된다. 이러한 '개입' 증거 증빙용만이 아니다. 디지탈 코드 사인은 누가 코드 사인을 했나 명시적으로 보여준다.
즉, 코드 사인이 주는 장점은 두 가지로 말할 수 있다.
- Authentication - 실제로 누가 보냈는지를 증빙한다.
- Integrity - 사인이 이뤄진 이후로 변경이 이뤄지지 않았음을 증빙한다.
실질적인 의미는 다음과 같다. 스패머와 명의도용 도둑들은 기존 유틸리티를 가져가거나 해킹, 혹은 합법인양 재배포를 할 수 없으며, 스파이웨어나 광고용 소프트웨어를 만든 전적이 있으면, 아이폰용 소프트웨어 제공인증을 통과하지 못할 수 있다는 의미다. 게다가 제 3의 보안성도 말할 수 있다. 발견되는대로 애플이 직접 악성 소프트웨어를 불인증시키고, 확산을 막을 수 있기 때문이다.
He Giveth and Taketh Away.
디지탈 영역에서, 고유 사인 키(key)는 인증기관이 수 만여 개발자들에게 발행한다. (즉, 애플이다.) 더 중요한 점이 있다. 사용자의 아이폰이 각 애플리케이션의 디지탈 인증과, 사인을 확인할뿐만 아니라, 사인한 키가 혹시 무효화된 것인지 애플에게 문의할 수도 있다. 키 사인이 할 수 있는 또 다른 힘이 있다. 원격 무효화이다. 굳이 대리인을 직접 보내서 면허가드를 되돌려받지 않아도, 법원 명령으로 면허를 취소할 수 있는 원리와 같다.
즉, 애플이 개발자들에게 사인 인증을 해주고, 혹은 개발자들로부터 사인 인증을 회수할 수 있다는 의미다. 면허취소될 우려가 없다면, 교통법에 맞게 운전해야 할 이유도 없을 것이다. 현재 데스크톱 PC 영역이 바로 이러하다. 누구나 자동차에 올라타서, 멋대로 운전할 수 있다. 마이크로소프트이건, 애플이건, 그 어느 운영체제 플랫폼 회사도 악성 소프트웨어에 대해, 민감한 빌딩은 우회시킨다든가, 바리케이드를 세운다든가, 등, 이렇다 할 조치를 취할 수 없다.
데스크톱 개발자들은 코딩하려고 면허증을 따지 않는다. 하지만 데스크톱의 경우, 사악한 운전 습관은 대다수 선량한 운전자들에게 막대한 피해를 입히고, 보행자들도 마찬가지이다. 악성 소프트웨어가 맥에서는 그리 큰 문제가 아니지만, 윈도 PC 사용자들은 파이어월을 설치해야 하고, 시스템 퍼포먼스를 크게 갉아먹는 툴이나 안티 바이러스도 관리를 해 주어야 한다. 휴대폰 영역에서 그런 무정부 상태를 막기 위해, 애플은 아이폰 코드 라이센스를 도입하기로 하였다.
SDK 다운로드는 누구나 애플 개발자 프로그램 가입만 하면 할 수 있다. 하지만 이 경우는 테스트 환경에서만으로 제한되어있다. 테스트이건, 배포나 판매이건, 실제 아이폰에 코드를 올리려면, 애플로부터 인증을 받아야 한다. 원칙을 따르지 않거나, 악성 코드를 사인받기 위해 남을 이용한다면, 애플은 인증을 취소할 테고, 해당 애플리케이션도 작동을 중단할 것이다.
취소하겠다는 위협만으로도 합법적인 개발자들을 지키기에는 충분하다. 스팸이나 악성 소프트웨어를 날리거나, 명의도용을 하려면, 일단은 인증부터 받아야 하기 때문이다. 애플 스스로도 소프트웨어를 등록받는대로 조사하여, 빠르게 사용자 불만에 대응할 수 있다. 이런 시스템이 자리를 잡으면, 아이폰용 안티-바이러스 소프트웨어는 필요가 없을 것이다. 우쩜 우리 아이들은 Symantec이나 Norton이 뭔지, 존재했는지도 모를 것이다.
A Good Deal All Around.
그렇다고 아이폰 사용자 보안성을 위해, 선량한 개발자들만이 인증을 받는 것만으로는 부족하다. 악성 소프트웨어의 위협으로부터 보안성을 지키고, 합법 소프트웨어의 신뢰성을 확보하는 것 외에, 이런 인증 제도는 결코 전에 존재한 바 없는 휴대폰용 소프트웨어 시장을 만들어낼 수 있다.
지난 해, 필자는 여러 기사를 통해, 플랫폼 개방시 애플이 맞이하게 될 가능성과 문제점을 짚어 보았다.
애플이 풀게 될, 소프트웨어 시장의 가장 큰 문제 중 하나가 바로, 아이튠스를 통한 소프트웨어 공급 방법이다. 필자는 염가에 애플리케이션을 팔면서 이윤을 남길 수 있는, 개발자들을 위한 진짜 시장을 아이튠스가 조성할 수 있다고 주장하였다. 현재 휴대기기용 개발자들은 아예 포기하든가, 아니면 높은 가격을 받아야 한다. 실제로 돈주고 살 수 백명의 소수에게만 팔리지, 나머지 휴대폰 사용자들은 그저 크랙된 버전을 구하기 때문이다.
불법복제에 시달리는 것이야 소프트웨어 개발자나, 음악 아티스트나 매한가지이다. 음악은 물리 디스크 판매량이 거대하기는 하지만, 소프트웨어는 소매판매보다는 온라인에서 더 흔하다. 특히 휴대폰용이면 더욱 더 그러하다. 아이튠스에서 애플은 아이포드 게임을 통해, 휴대폰 전자 유통을 실험해보기 시작했다. 애플이 이 게임을 직접 사인했을뿐 아니라, FairPlay에 싸 놓았다. 물론 복제는 여전히 가능하지만, 사용자 대부분은 차라리 5달러 주고 원하는 게임을 구입하는 편을 더 편안하게 생각한다.
아이폰용 애플리케이션도 모두 FairPlay로 싸여 있다. 훔친 버전을 찾기보다, 합법적으로 사는 편이 더 쉬워진다는 의미다. 이렇게 되면 긍정적인 효과가 두 가지 발생한다. 첫 번째. 대량 판매를 위해 가격 인하 요인이 생긴다. 두 번째. 자동 업데이트 통보를 받으며, 구입 기록이 남기에, 소프트웨어 구입이 보다 간편해진다. 소비자 서비스도 더 낫다. 소프트웨어를 사용할 권리도 없으면서, 지원만 바라는 소비자들이 아니다. 당당히 돈 내는 소비자들을 위해 돈을 버는 개발자들이 해 주는 서비스이기 때문이다.
An iPhone SDK? Predictions for WWDC 2007!
써드파티 소프트웨어를 둘러싼 억측
Mobile Disruption: Apple’s iPhone and Third Party Software
iPhone 내부 공개는 없다
iPhone은 정말 폐쇄된 플랫폼인가?
iPhone, 어떻게 개방될까?
Something Old, Something New.
코드 사인을 애플이 처음 하는 것도 아니다. 이미 마이크로소프트 윈도의 Authenticode가 있고, 노키아의 Symbian Signed 프로그램이 2005년에 등장했다. RIM도 특정 API를 이용하여 블랙베리용 애플리케이션에 코드 사인을 사용한다. 주요 소비자용 플랫폼은 모두 이런 식의 코드 사인 프로그램을 운영한다.
일반적인 컴퓨팅을 말고, 코드 사인을 보면, 이 아이디어는 정말, 새로운 아이디어가 아니다. 현대의 모든 비디오게임 콘솔도 코드 사인을 이용하여, 개발자들이 해마다 라이센스 요금을 내야 한다. 원래 이런 방식을 만든 곳은 닌텐도였다. 닌텐도는 간단한 물리적인 칩, 10NES를 사용하여, 라이센스 계약서에 따라 게임 개발자들이 돈을 내도록 한다. "Nintendo Seal of Quality" 라이센스 비용을 내지 않고, 닌텐도의 엄격한 규율을 따르지 않는 써드파티는 카트리지에 넣을 10NES 칩을 받을 수 없다. 따라서 NES 콘솔용 게임을 출시할 수가 없게 된다.
다음 세대 게임 콘솔은 부트 ROM을 사용하여 카트리지나 광미디어에 있는 게임을 디지탈 인증하였다. 이 역시 라이센스 의무가 주어져 있다. 아이튠스를 통해 팔리는 아이포드용 게임 또한 디지탈 사인 시스템을 사용하여, 게임 복제나 수정, 스스로의 게임 제작을 어렵게 만들었다. 그러나 애플의 디지탈 아이포드 게임과 아이폰 애플리케이션 판매방식을 다른 콘솔 업체들과 비교해 보면 완전히 정 반대이다.
닌텐도와 마이크로소프트, 소니는 모두 하드웨어를 손해보면서 판매한다. 그리고 그 수입을 소프트웨어 라이센스로 벌어들인다. 그런데 애플은 아이포드와 아이폰 하드웨어에서 이윤을 올리는 반면, 소프트웨어 판매에 있어서는 손해보지 않는 선에서 팔겠다고 발표하였다. 따라서 게임 콘솔 자체의 값은 최대한 떨어져있지만, 게임 자체는 30$에서 70$ 선이다. 애플 하드웨어는 보다 고가이지만, 아이포드 게임은 5달러이며, 아이폰용 소프트웨어 대부분도 20달러 이하가 될 전망이다.
2007년, 마이크로소프트 Xbox 360의 죽음
How Much Does it Cost Developers?
소비자들이 일단 보게 되는 것은 소비자가이다. 그런데 개발자 입장에서, 그 비용은 소비자가와 차이가 크다. 최신 게임콘솔용 게임을 만드는 비용은 대단히 크다. 지난 가을, 소니의 플레이스테이션3 SDK 라이센스비용이 떨어졌는데... 내려갔다는 그 가격이 10,250$이다. SDK가 개발용으로 제작한 하드웨어를 제공하기때문에, 그 정도의 가격을 매기긴 해야 한다. 그래서 플레이스테이션3용 타이틀을 개발하는 곳은 제한적이다.
SonyHalves Price Of PlayStation 3 Development Kit — PS3 — InformationWeek
SDK 값이 이렇게 높지만, 사실 전체 개발 비용으로 보자면 SDK 값도 별로 크지 않다. 가령, 샌프란시스코의 Ubisoft는 Res Steel이란 게임을 개발하면서 1,275만 달러를 지출하였다. THQ의 사장, 퍼렐(Brian Farrell)은 Wii 개발비용이 플레이스테이션3나 엑스박스360의 1/4에서 절반 정도이리라 추측한다. Res Steel 정도의 게임이라면 2,400만~4,800만 달러 정도 들 것이라면서 말이다. SDK 값, 10,250달러가 그리 많아보이지 않을 정도다.
닌텐도 Wii 개발툴이 그나마 게임콘솔 SDK 중에서 제일 저렴하다. 그래도 개발사 규모에 따라 2천~1만 달러 선이다. 닌텐도는 이렇게 지적하고 있다. "정식 개발자(Authorized Developer)가 된다고 해서 개발한 게임 전부가 나오지는 않습니다. Wii 디스크-기반으로 게임을 개발중이라면, Wii 라이센스 규약문 엄수는 여러분의 책임입니다." 닌텐도 DS 개발비용도 비슷하다.
Software Development Support Group - Nintendo Wii
이에 반해 애플의 아이폰 2.0 SDK는 맥 개발과 동일한 툴, 하드웨어를 사용하며, 이들 툴은 이미 성숙해 있고, 친밀하다. 맥과 아이포드 터치, 아이폰 모두가 Cocoa라는 유사성을 갖고 있기에, 애플은 규모성을 발휘할 수 있다. 따라서 애플은 원하는 이들 모두에게 SDK를 무료로 배포할 수 있었다. 애플이 SDK를 선보인지 나흘만에, 이 SDK를 얻기 위해 등록한 이들 수만 10만 명이었다.
게임콘솔 업체들과는 달리, 애플의 새 SDK는 데스크톱 플랫폼의 익스텐션일 뿐이다. 요새 나오는 인텔 맥이라면 이 SDK를 모두 돌릴 수 있으며, 하드웨어 테스팅을 위한 하드웨어 값도 399달러에 불과하다.
게다가 맥용 개발을 할줄 알면, 아이폰 소프트웨어 개발도 바로 할 수 있다. 다만 실제로 소프트웨어를 선보이려면, 인증을 위해 99달러를 내야 한다. 아니면 등록한 다른 개발자를 찾아야 한다. 아이폰용 게임 개발도, 다른 콘솔게임 개발처럼 수 백만 달러를 요구하지 않는다.
Mobile Development In Comparison.
애플이 가진 친숙한 데스크톱-수준의 개발툴을, 다른 스마트폰 개발 프로그램과 비교해 보면 어떨까? 데스크톱 환경과 유사한 휴대폰용 개발 플랫폼을 제공하는 곳은 애플 외에 마이크로소프트 뿐이다. RIM이나 Palm, Symbian은 모두 특화된 개발경험을 매우 많이 요구하는 환경이다.
차이점은 그 외에도 많다. 썬의 자바 ME, 구글의 안드로이드, Palm, Symbian, RIM BlackBerry, 마이크로소프트의 윈도 모바일 모두, 여러 가지 기능을 가진 넓은 범위의 하드웨어에 해당되는 툴을 제공하려 시도하였다. 즉, 개발자들은 소수의 하이엔드급 기기, 아니면 제일 최소한의 기기를 목표로 개발하게 되었다. 현재 애플은 이미 설치된 기반이 거대한 하드웨어의 일부를 목표로, 규모의 이득을 보고 있다. 아이폰과 아이포드 터치는 같은 회사가 만드는, 대단히 유사한 기기이다.
애플이 아이폰 2.0 SDK라는 이름으로 SDK를 발표했을 때, 단일 인증비가 어떻게 99달러씩이나 하냐는 불만이 나타났다. 게다가 아이폰 App Store를 통한 판매 수입의 30%를 애플이 차지하는 것이 너무하다는 반응도 나왔다. 그럼 다른 곳은 어떻게 하는지 알아보도록 하자.
iPhone과 경쟁하기 - 소프트웨어
RIM BlackBerry Certificates.
RIM은 코드 사인 인증 출원에 100달러를 요구한다. 블랙베리용으로는 제한적인 API가 세 가지 있으며, 각각 개발자들이 받을 때, 인증이 되어 있어야 한다. 그리고 이 인증은 단일 머신에 제한되어 있기 때문에, 회사 안의 개발자 모두 각자 고유의 인증을 하거나, 시스템을 공유해야 한다. 코드 사인은 자동화될 수 없으며, 각 빌드에 있는 비밀 키를 일일이 쳐 주어야 한다. 또한 사인중에 인터넷에 계속 연결이 되어 있어야 하며, 그래야 RIM 서버가 반응과 인증을 해줄 수 있다.
BlackBerry Code Signing Tips | Eric Giguere’s BlackBerry Developers At Work!
Symbian Certificates.
노키아와 소니에릭슨, NTT DoCoMo 등 Symbian 파트너들이 파는 휴대폰을 합치면 전세계적으로 대다수를 차지한다. 그리고 이 모두가 Symbian OS 9.1 이후를 사용하는 경우, Symbian Signed 프로그램의 적용을 받는다. 프로그램에는 몇 가지 레벨이 있다.
Symbian은 Publisher ID로 인증 사인을 호출한다. 3년간(최근 6개월로 확장되었다) 200달러의 비용이다. Publisher ID를 얻지 못하면, 개발자들은 별도의 개인 키로 사인을 해야 하는데, 이 경우 애플리케이션은 자기 휴대폰에서만 사용 가능하지, 배포는 불가능하다. 이것이 바로 "Open Signed"라 불리우며, 테스팅이나 개인적인 사용 용도로만 쓰인다. 자기 애플리케이션을 배포하려면, Publisher ID를 입수하거나, 다른 Publisher ID를 공유해야 한다.
Symbian Signed Publisher Partners 프로그램은, 자기 애플리케이션에 사인을 받아 유통시키고 싶어 하는 프리웨어나 오픈소스 개발자들(보통 Publisher ID를 갖고 있지 않다)에게 사인 서비스를 제공한다.
Symbian 웹사이트를 보자. "보통, 독점 배포권을 갖고, 개발자를 대행하여 사인과 등록을 파트너가 할 수 있다. Publisher ID가 없는 셰어웨어 개발자들에게 유사 서비스가 존재하며, 일정 부분 수익을 공유할 수 있는 형태이다. 자신의 소프트웨어를 배포하기를 원하는 프리웨어나 오픈소스, 셰어웨어 개발자들에게는 Publisher ID가 필요하다."
그런데 Publisher ID에게, 새 애플리케이션을 사인할 때마다 매번 추가적으로 20달러씩을 더 내게 하는 "Express Signed" 프로그램이 있다. 이 시스템에 완전히 접근하기 위해서는, "Certified Signed" 프로그램이 따로 있다. 200~500유로(약 310~780달러)의 추가 비용을 내면 된다. 즉, Symbian 개발자들은 애플리케이션을 새로 내놓을 때마다 이 요금을 내야 한다.
Symbian Signed
Qualcomm BREW Certificates.
BREW 개발은 Verizon Wireless에서 나오는 다운로드, 혹은 대여용 게임과 주로 관련이 있으며, VeriSign으로부터 인증 패키지를 입수해야 가능하다. 최소 패키지는 애플리케이션 100개에 400달러이다. 500개 짜리 패키지는 895달러이고, 1,000개 짜리 패키지는 1,295달러다. VeriSign은 이렇게 지적한다. "동일한 컴퓨터와 동일한 버전의 마이크로소프트 인터넷 익스플로러에, VeriSign Authentic Document ID를 설치하고, 이용해야 한다."
Authentic Document IDs for BREW - Application Security from VeriSign, Inc.
Apple iPhone 2.0 SDK: the Kindest 30% Cut.
이러고 보니, 애플 프로그램이 제일 저렴하면서, 제일 단순한 보안 모바일 소프트웨어 플랫폼임을 알 수 있다. 고가의 강제적인 테스트 프로그램이 없으며, 디지탈 인증을 위해 고가의 선제 투자를 할 필요도 없고, 윈도 PC가 아니더라도 인증을 할 수 있다. 인증 외에도, 애플은 코드 사인을 요구하는 모바일 플랫폼 중에서도 여러 가지 독특한 것들을 제공한다.
첫 번째가 써드 파티 애플리케이션 배포를 위한 iTunes App Store 시스템이다. 99달러를 한 번 내면, 음반사가 음악을 아이튠스에 업로드하듯, 아이튠스에 애플리케이션을 사인시키고 업로드할 수 있다. 여기서 애플이 30%의 몫을 가져간다. 전문가들은 이 30%를 계속 이슈화시키려 하는데, 휴대폰 소프트웨어 스토어 대부분이 더 많이, 개발자들에게는 더 적게 지불한다는 점을 모르는 듯 하다.
애플 시스템과 제일 유사한 애플리케이션 스토어인 Danger를 보자. Danger의 수수료는 50%이다. 마이크로소프트는 Palm과 Symbian, 블랙베리 소프트웨어도 제공하는 Handango를 윈도 모바일 개발자들에게 권유하는데, 여기는 수수료가 40%이다. (이번 달 50%로 인상 예정이다.) 게다가 윈도모바일이나 Palm, 블랙베리, Symbian 휴대폰으로 직접 구입이나 접근을 할 수도 없다. 규모 있는 개발사들은 Handango에 무려 60~70%의 수수료를 판매할 때마다 낸다!
노키아의 Software Market/Content Discoverer와 Motricity의 Smartphone.net은 모두 40%를 받는다. 여기에 중간 수수료를 덧붙이기 때문에, 개발자는 50%만 수입으로 받을 수 있다. 또한 'non-real time fulfillment'의 명목으로 5%의 수수료를 더 받기도 한다. 또 있다. 애플은 달마다 개발자에게 수입을 주는데 반해, 노키아는 분기별로 준다.
Nokia Software Market
Motricity Software Agreement
다른 셰어웨어 목록 사이트는 타이틀을 더 저렴하게, 혹은 아예 무료로 뿌린다. 그러나 소비자들은 소프트웨어 타이틀을 어디에서 사야할 지 모른다. 유명 휴대폰용 소프트웨어 타이틀을 검색해 봐야, 목록은 안뜨고, 토렌트만 발견할 수 있다. 20달러 짜리 몇 개 팔아서 50%를 버는 것보다, 5달러 짜리로 수 만 카피를 팔되 70%를 버는 편이 훨씬 더 낫다.
마이크로소프트와 Symbian, RIM도 아이튠스에 비견할 만한 소프트웨어 스토어를 제공하려 하지만, 이들은 너무 늦었다. 이미 애플이 모든 주목의 대상이 되어버린 플랫폼을 구축하였으며, 애플이 제공하는 툴도 제일 친숙하고 현대적이고, 소비자들도 애플 스토어를 제일 신뢰한다. 개발자들에게 판매와 지속 가능한 이윤을 보장하니, 그 어느 스마트폰 어체도 아이폰을 둘러싼 세련된 애플리케이션에 맞설 수 없을 것이다.
그렇다면 혹시, 다른 휴대용 기기와 아이폰 간의 하드웨어를 비교하면 어떨까? 다음 기사에서 알아보겠다.
iPhone 2.0 SDK: How Signing Certificates Work
iPhone 2.0 SDK: How Signing Certificates Work
March 18th, 2008
Daniel Eran Dilger and Jason Smith
Last May, I asked Steve Jobs for a public comment to clarify Apple’s plans for third party software for the iPhone. He assured me that Apple did indeed recognize a market for software outside of the web platform outlined for the iPhone, but was “wrestling” with how to balance openness with security. Jobs repeated similar comments that summer at All Things D.
Answers from Steve Jobs at Apple’s Shareholder Meeting
Then, in a public message issued in October, Jobs went even further to outline Apple’s strategy for a native SDK and hinted that the company would be adopting measures similar to Nokia’s “Symbian Signed” digital signature program as a key part of its efforts to allow legitimate developers to contribute to the iPhone while keeping viruses, malware, and privacy attacks under control. The message now seems impossible to find on Apple’s servers, but stated the following:
Let me just say it: We want native third party applications on the iPhone, and we plan to have an SDK in developers’ hands in February. We are excited about creating a vibrant third party developer community around the iPhone and enabling hundreds of new applications for our users. With our revolutionary multi-touch interface, powerful hardware and advanced software architecture, we believe we have created the best mobile platform ever for developers.
It will take until February to release an SDK because we’re trying to do two diametrically opposed things at once—provide an advanced and open platform to developers while at the same time protect iPhone users from viruses, malware, privacy attacks, etc. This is no easy task. Some claim that viruses and malware are not a problem on mobile phones—this is simply not true. There have been serious viruses on other mobile phones already, including some that silently spread from phone to phone over the cell network. As our phones become more powerful, these malicious programs will become more dangerous. And since the iPhone is the most advanced phone ever, it will be a highly visible target.
Some companies are already taking action. Nokia, for example, is not allowing any applications to be loaded onto some of their newest phones unless they have a digital signature that can be traced back to a known developer. While this makes such a phone less than “totally open,” we believe it is a step in the right direction. We are working on an advanced system which will offer developers broad access to natively program the iPhone’s amazing software platform while at the same time protecting users from malicious programs.
We think a few months of patience now will be rewarded by many years of great third party applications running on safe and reliable iPhones.
Steve
P.S.: The SDK will also allow developers to create applications for iPod touch.
Steve Jobs Ends iPhone SDK Panic
What Do Signing Certificates Do?
How does signing an application have any impact upon security? In the computing world, code signing goes a bit beyond the equivalent of signing a document on the dotted line. Signed code is more like a parchment rolled up into a scroll and sealed with hot wax imprinted with a unique signet ring. Once so signed, the document can’t be altered, extended, revised, or corrected without breaking the seal. If the seal is broken, the recipient knows that something has happened to it along the way.
In addition to acting as evidence of tampering, digital code signing also unequivocally proves who signed the code. That means the two main attractions to signing code is to provide:
- Authentication - to prove the item does indeed come from the source that it says it comes from;
- Integrity - to prove the item has not changed since it was signed.
In practice, this means spammers and identity thieves can’t take existing utilities, attach an ugly hack, and then redistribute it as apparently legitimate software. It also means that companies with a history of making spyware and adware can simply be disqualified from offering any software for the iPhone. However, there’s also a third aspect of certificate security that will enable Apple to shutdown and clean up malware outbreaks immediately as they are discovered.
He Giveth and Taketh Away.
In the digital realm, the unique signing keys are issued by an authority–in this case Apple–to potentially hundreds of thousands of developers. Even more importantly, the recipient iPhones that will be examining the digital signatures of applications can verify not only the authenticity and integrity of the signing, but can also consult Apple to see if any of those signing keys have been revoked. Half the power of signing keys is in the ability to remotely revoke them, just as a drivers license can be revoked by the court without requiring a deputy to actually go out and demand the return of the physical license card.
Apple’s ability to both give out signing certificates to developers and to revoke those certificates afterward gives it the same kind of control over developers that the DMV holds over drivers. If drivers faced no threat of losing their license, there would be no way of holding them accountable to drive according to the law. That’s how the desktop PC world currently works: anyone can jump in a car and drive any way they like, and neither Microsoft nor Apple nor any other desktop operating system platform vendor can really do much to reign in bad or malicious software drivers apart from erecting protective barricades around sensitive buildings.
Desktop developers don’t obtain a license to code, but the bad driving of the very few causes big problems for the majority of good drivers out there. End users also suffer. While malware is not a significant problem on the Mac yet, Windows PC users have to run their boxes behind a firewall and typically need to run anti-virus and other cleanup tools that rob a significant amount of their system performance in overhead.
To prevent a similar sort of anarchy from developing in the mobile space, Apple decided that developers will need a license to code for the iPhone. While the SDK is free to download for anyone who signs up in Apple’s developer program, it is also limited to running code only in a test environment. In order to upload any code to an actual iPhone–for testing, distribution, or sale–developers will need to obtain a certificate from Apple to sign their apps with. If they don’t follow the rules, or if they allow others to use their assigned certificate to sign malicious code, Apple can revoke their certificate and their signed apps will all stop working.
The simple threat of revocation would likely be enough to prevent legitimate developers from allowing fly-by-night spammers and identity thieves to use their assigned certificates to sign and distribute malicious software. Apple can also vet software as it is submitted, and rapidly respond to user complaints by terminating the distribution and revoking the run rights of signed software. With such a system in place, there’s no need for iPhone anti-virus software. Our children will never know why Symantec and Norton ever existed.
A Good Deal All Around.
However, developers aren’t just being asked to contribute toward iPhone users’ security out of their own sense of goodwill. In addition to protecting users from malware threats and casting an aura of safety and trustworthiness over their own legitimate iPhone software, certificate-signed applications will also create a market for mobile software that has never really existed before.
Last year, I explored the possibilities and risks Apple faced in opening its platform in a series of articles. One of the greatest problems Apple could solve in delivering software through iTunes, I suggested, would be to give developers a real marketplace where they could sell their apps at low prices and still make money. Currently, mobile developers either have to give away their work, or offer it at a high price. That’s because they are only likely to sell a few hundred copies to the minority who will pay pretty much anything, while the rest of the mobile user population simply steals cracked versions.
Software developers suffer from piracy as much or more as recording artists. While there is a large business behind physical music sales, software is easier to find online than in retail stores, particularly mobile software. In iTunes, Apple began testing mobile electronic distribution with iPod Games. Not only are the games signed by Apple, but they’re also wrapped in a version of FairPlay that associates the game files with the user who bought them. While it’s still possible to steal them, it’s more convenient for most users to throw down the $5 to obtain the game they want.
All iPhone apps will similarly be wrapped by FairPlay, again making it easier for users to buy a legitimate copy than to find a stolen version. This will result in two positive effects: first, developers will be able to price their software lower to entice volume purchases. Second, users buying software will get a better overall experience, with automatic update notifications and records of their purchases. They can also expect better customer service, because they’ll be dealing with happy developers that know they’ve been paid rather than threadbare merchants who realize that most of the users demanding support haven’t contributed anything to use their software.
An iPhone SDK? Predictions for WWDC 2007!
More Absurd iPhone Myths: Third Party Software Panic
Mobile Disruption: Apple’s iPhone and Third Party Software
Six Reasons Why Apple May Never Open the iPhone
How Closed Is the iPhone?
How Open will the iPhone Get?
Something Old, Something New.
While Apple certainly isn’t the first company to begin working on code signing–Microsoft has been pushing Authenticode in Windows, Nokia began the Symbian Signed program for some mobiles in 2005, and RIM uses code signing for BlackBerry apps that make use of certain APIs–the iPhone marks the first time a highly visible, significant consumer computing platform has launched with a mandatory code signing program intact across the board.
Outside of general computing, the idea of code signing is far less novel. Every modern video game console unit uses code signing to force developers to pay licensing fees. The practice appears to have been invented by Nintendo, which began using a simple, physical equivalent to code signing–a lockout chip called the 10NES–to force games developers into the terms of its licensing contract. Without paying to license the “Nintendo Seal of Quality” and following Nintendo’s strict rules, third parties couldn’t obtain the 10NES chip to insert in their cartridges, and therefore couldn’t release games for the NES console.
Later generations of games consoles used a boot ROM routine to digitally verify that games on cartridge or optical media had paid their licensing dues. Apple’s iPod Games sold through iTunes also use a digital signing system to make it difficult to pirate the games, modify them, or create homebrew versions. However, Apple’s business model for digitally downloaded iPod games and iPhone apps is nearly opposite that of the console makers.
Nintendo, Microsoft, and Sony all sell hardware at or near a manufacturing loss and use software licensing to bring in their main revenues. Apple sells its iPod and iPhone hardware at a profit, and has announced the intention to operate software sales at just above breaking even. That’s why game console hardware costs as little as possible, yet games themselves cost $30 to $70 each. Apple’s hardware is more expensive, but iPod games cost $5, and most iPhone software titles are expected to be priced under $20.
Video Game Consoles 2007: Wii, PS3 and the Death of Microsoft’s Xbox 360
How Much Does it Cost Developers?
In addition to the retail prices that consumers face, there are big differences in costs to developers. The complex and unique nature of developing for the latest games consoles results in significant expenses for developers. Last fall, Sony slashed its fees for the PlayStation 3 SDK in half… to $10,250. Sony has to charge a lot because its SDK involves custom hardware and the package is only shared among the limited number of developers working on console titles.
Sony Halves Price Of PlayStation 3 Development Kit — PS3 — InformationWeek
Even so, the costs of the SDK are a trivial amount of overall development costs. San Francisco’s Ubisoft spent $12.75 million developing the game Red Steel, for example. THQ president Brian Farrell estimated that Wii development costs are around a quarter to half of that required for PlayStation 3 or Xbox 360 development, suggesting that a game like Red Steel would cost $24 to $48 million for those platforms. Suddenly $10,250 for an SDK doesn’t sound like much.
The Nintendo Wii development tools are among the cheapest of any game console, but still cost $2,000 to $10,000, depending on the size of the developer. Nintendo notes that “becoming an Authorized Developer does not mean any game you develop will be published. If your company is developing a Wii disc-based game, it is your responsibility to secure your own agreement with a Wii Licensee.” Developing for the Nintendo DS costs a similar amount.
Software Development Support Group - Nintendo Wii
In contrast, Apple’s iPhone 2.0 SDK uses the same tools and hardware as Mac development, and those tools are already mature and familiar to a wide audience. Apple’s economies of scale, combined with the similarities between Cocoa development on the Mac, iPod touch, and iPhone, makes it easy for Apple to offer the new SDK for free to anyone who wants to download it; in four days, 100,000 users signed up to obtain the beta.
Unlike the game console makers, Apple’s new SDK is really only an extension of its desktop platform. Any modern Intel Mac can run the development software, and the hardware itself only costs $399 to obtain for hardware testing. Anyone that can develop for the Mac can create iPhone software. In order to actually publish their work, developers will need to pay $99 to obtain a certificate, or alternatively, they’ll have to find another developer to sign their work for them. Developing games for the iPhone won’t incur the huge multimillion dollar risk for developers that console gaming does.
Mobile Development In Comparison.
How do Apple’s familiar, desktop-class development tools for the iPhone compare to other smartphone development programs? Only Microsoft offers a mobile development platform that similarly resembles its desktop environment. RIM, Palm, and Symbian are all highly unique development environments that require a lot of specialized development experience.
There are other differences as well. Mobile platforms, including Sun’s Java ME, Google’s Android, Palm, Symbian, RIM BlackBerry, and Microsoft’s Windows Mobile all attempt to deliver tools to accomodate a wide range of hardware with different features and capabilities. That leaves developers to either target a limited number of high end devices or a wide lowest common denominator profile. Apple currently has the advantage of targeting a limited scope of hardware that already has a significant installed base; both the iPhone and iPod Touch are very similar devices from the same maker.
When Apple announced its terms for developers under the iPhone 2.0 SDK, critics immediately shot off about how expensive it was for Apple to charge $99 for a signing certificate and take a 30% revenue share of apps delivered through the iPhone’s App Store. Here’s how those plans compare to what’s already in place:
Apple’s iPhone vs Smartphone Software Makers
RIM BlackBerry Certificates.
RIM charges $100 for each code signing certificate application. There are three sets of restricted APIs on the BlackBerry, and each requires a certificate bundled in a set the developer receives. Those certificates are bound to a single machine, so each developer in a company will need their own certificate or share a system. Signing code can not be automated, as it requires a user to type in a secret key at each build. The machine must also be connected live to the Internet during the signing process, and RIM’s servers must be up and responding in order for the process to work.
BlackBerry Code Signing Tips | Eric Giguere’s BlackBerry Developers At Work!
Symbian Certificates.
Nokia, Sony Ericsson, NTT DoCoMo, and other Symbian partners, which collectively make up the vast majority of phones sold worldwide, are bound together by the Symbian Signed program, which went into effect with phones using Symbian OS 9.1 or later. There are several levels to the program.
Symbian calls its signing certificate a Publisher ID; it costs $200 and now lasts for three years (recently extended from six months). Without obtaining a Publisher ID, developers can generate their own private key to sign apps, but those self-signed apps can only run on a single phone and so can’t be distributed. This is called “Open Signed,” and is intended only for testing or personal use.
In order to distribute their apps, developers have to obtain their own Publisher ID or arrange to share the use of another publisher’s. The Symbian Signed Publisher Partners program provides a signing service for freeware or open source developers who do not have a Publisher ID but want to distribute signed applications.
According to Symbian’s website: “Typically, the partner signs and publishes the application on behalf of the developer in return for privileged distribution rights; for example, exclusive distribution. Similar services are available for shareware developers without a Publisher ID, typically in return for a share of the sale proceeds. Freeware, open-source, or shareware developers who prefer to publish their own software will need a Publisher ID.”
The middle tier “Express Signed” program charges Publisher ID holders an additional $20 every time they sign a new app. In order to access the full features of the system, developers have to join the top tier “Certified Signed” program, which involves additional fees from 200-500 Euro ($310 - $780 US) charged by an independent test house for each app. Symbian developers have to pay these fees with each new release of their applications.
Symbian Signed
Qualcomm BREW Certificates.
Primarily associated with rented, downloadable games from Verizon Wireless, BREW development requires obtaining a certificate package from VeriSign. The minimum package to sign 100 applications is $400; a 500 package is $895, and a 1000 sign package is $1295. VeriSign notes that “you must apply for, pick up, and install your VeriSign Authentic Document ID on the same computer with the same version of Microsoft Internet Explorer.”
Authentic Document IDs for BREW - Application Security from VeriSign, Inc.
Apple iPhone 2.0 SDK: the Kindest 30% Cut.
That leaves Apple’s program the cheapest and the simplest secure mobile software platform. There is currently no expensive, compulsory testing program, no significant upfront investment in digital certificates, and the certificates work outside of a Windows PC. Outside of certificates, Apple also offers a number of other things that are unique among mobile platforms that have mandatory code signing programs.
The first is its iTunes App Store system for distributing third party applications. Once you’ve paid the $99 fee, you can sign and upload apps into iTunes just as labels upload their music into iTunes. Apple takes a 30% cut, which pundits again tried to dramatically gasp at, apparently unaware that most mobile software stores take as much or more while offering developers a lot less.
Take Danger, which offers an app store most similar to the system Apple outlined. It takes a 50% cut. Microsoft recommends Windows Mobile developers list with Handango, which also offers Palm, Symbian, and BlackBerry software. It takes a 40% cut from small developers (and plans to raise things to 50% this month) but doesn’t present any direct purchase or directory across Windows Mobile, Palm, BlackBerry, or Symbian phones. Larger developers are supposed to pay Handango 60 to 70% of their software revenues!
Nokia’s Software Market/Content Discoverer and Motricity’s Smartphone.net both take a 40% revenue cut, with some transactions giving the developer only 50% and/or charging them an additional 5% fee for ‘non-real time fulfillment.’ Nokia pays developers quarterly, rather than every month as Apple outlined.
Nokia Software Market
Motricity Software Agreement
Other shareware listing sites offer to present titles for less, even for free. However, users don’t know to shop around for software titles. Google for popular mobile titles, and you don’t find lots of free listing services, you find torrents for stealing the software. Earning 70% of tens of thousands of $5 sales is a much better deal than earning 50% of a few dozen $20 titles, or 100% of a handful of sales at $50.
While Microsoft, Symbian, RIM, and others scramble to offer their own software stores that can match iTunes, it will all be too little, too late. Apple has the cohesive platform grabbing the most attention, the most familiar and modern developer tools, and the most most trusted consumer software store. By offering developers guaranteed sales and sustainable profits at a low cost of entry, no smartphone vendor is going to be able to match the sophistication of apps that sprout up around the iPhone.
So how does the iPhone hardware compare with other handheld devices on the market? The next article takes a look.
More on the iPhone 2.0 SDK
iPhone 2.0 SDK: The No Multitasking Myth
iPhone 2.0 SDK: Java on the iPhone?
iPhone 2.0 SDK: How Signed Certificates Work
iPhone 2.0 SDK: Video Games to Rival Nintendo DS, Sony PSP
iPhone 2.0 SDK: Readers Write on Certificate Signing
I really like to hear from readers. Comment in the Forum or email me with your ideas.
Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks!
Technorati Tags: Apple, Development, iPhone, Mac, Microsoft, Software, the Media
Understanding how Apple’s FairPlay DRM works helps to answer a lot of questions: why it hasn’t been replaced with an open, interoperable DRM that anyone can use, why Apple isn’t broadly licensing FairPlay, and why the company hasn’t jumped to add DRM-free content from indie artists to iTunes.
The Quandary of Interoperable DRM
Why can't the music industry just adopt an open standard for DRM? The simple answer is that the basic concept of interoperable DRM makes no sense.
Since the point of DRM is to limit interoperability by using secrets, there is no open way to deliver a DRM system that does what it's supposed to do. If it were open, then it wouldn't be secret. When the secrets get out, it's now open, but it no longer works as DRM.
If that logic isn’t too difficult to fathom, here's another wrinkle to complicate things: the industry has already adopted interoperable frameworks for DRM. One is the MPEG-4 AAC standard, which is used by Apple in iTunes.
The earlier MP3 file format had no provision for DRM. However, the newer AAC format was designed with an open mechanism for companies to extend the format using their own DRM implementation. That's as open as DRM can possibly get: an agreed upon system for putting secrets in a specific place.
It's still a secret, but it's at least a known unknown. While anyone can access and play a standard AAC file, to use a DRM-protected AAC file they need to know the secret to decoding that particular file.
Advanced Audio Coding
Royalty payments are required for using the MP3 format for distributed content, but no licenses or fees are required to stream or distribute content in AAC, making it a more attractive format for streaming content, such as Internet radio. AAC also offers better compression, support for more channels of audio, and requires less processing power to decode than MP3.
An Enigma, Wrapped in a Riddle, Shrouded in Mystery
The AAC songs purchased from the iTunes music store are protected with Apple’s FairPlay DRM. Without knowing the FairPlay secrets, other parties can't play them.
In order to create a system that could manage access to billions of songs sold to millions of users, yet keep things simple and flexible, FairPlay uses sets of keys that work together to make sure that the system, even if it is cracked, still maintains Apple's commitment to music labels by limiting any damages.
A look at how FairPlay works helps to understand why Apple doesn't want to share the system with third party download stores and player manufacturers, and what would be involved in mixing DRM-free content into the iTunes Store.
iTunes Accounts and Authorizations
Prior to buying content from the iTunes Store, a user has to create an account with Apple's servers and then authorize a PC or Mac running iTunes.
During authorization, iTunes creates a globally unique ID number for the computer it is running on, then sends it to Apple's servers, where it is assigned to the user's iTunes account. Five different machines can be authorized.
When a user buys a song from the iTunes Store, a user key is created for the purchased file. The AAC song itself is scrambled using a separate master key, which is then included into the protected AAC song file. The master key is locked using the user key, which is both held by iTunes and also sent to Apple’s servers.
Protected, purchased content is locked within iTunes; songs are not scrambled on Apple's server. This speeds and simplifies the transaction by delegating that work to iTunes on the local computer.
The result is an authorization system that does not require iTunes to verify each song with Apple as it plays. Instead, iTunes maintains a collection of user keys for all the purchased tracks in its library.
To play a protected AAC song, iTunes uses the matching user key to unlock the master key stored within the song file, when is then used to unscramble the song data.
Every time a new track is purchased, a new user key may be created; those keys are all encrypted and stored on the authorized iTunes computer, as well as being copied to Apple's servers.
When a new computer is authorized, it also generates a globally unique ID number for itself and sends it to Apple, which stores it as one of the five authorizations in the user account.
Apple's server sends the newly authorized machine the entire set of user keys for all the tracks purchased under the account, so all authorized systems will be able to play all purchased songs.
An iTunes computer can be authorized by multiple iTunes user accounts; for each account, iTunes maintains a set of user keys.
Exploiting Authorizations in FairPlay
When a computer is deauthorized, it deletes its local set of user keys and requests Apple to remove the authorization from its records.
If the keys are backed up, users can deauthorize their systems, then restore the keys and authorize a new set of computers, resulting in more than five machines that can all play the existing purchased music.
However, any new music purchased on the newly authorized systems will create new keys, and the previously de-authorized machines will not be able to play the new purchases because they can't obtain the new keys.
iTunes Keys on the iPod
Any number of iPods can be used with an authorized computer running iTunes. Once an iPod is connected, it downloads all the user keys from iTunes so it can unlock and play any protected tracks. If that copy of iTunes is authorized to play songs from multiple accounts, all of the accounts' user keys are uploaded.
The iPod makes no decisions about which tracks it can play, it simply is given user keys for all the songs it contains by iTunes.
If iTunes has songs in its library, but lacks the keys to play them--from another account, or on a deauthorized computer that has dumped its keys--it will simply not copy the protected songs to the iPod.
That also explains why users can't dock a single iPod with different users’ iTunes and suck up all their music; the only option available is to replace the music on the iPod with the music from the new iTunes library.
Since iTunes manages all the music on an iPod, there is no way to sync an iPod with multiple iTunes libraries; the iPod simply wasn’t given the intelligence to mange multiple libraries.
With iTunes 7 however, Apple added the ability for an iPod registered with an iTunes account to sync purchased songs with any of the five machines authorized by that account. Each copy of iTunes can update the user keys on the iPod and add new purchased tracks, ensuring that the iPod can play all the music copied to it.
Cracking FairPlay in iTunes
Because protected AAC songs are scrambled with an encrypted master key, it is practically impossible to unscramble protected song files.
Instead, crackers typically attempt to steal the user keys so they can simply decrypt songs in the same matter as iTunes does. This is like breaking into a bank vault by stealing the combination rather than trying to smash through the vault walls.
-
•The first, distributed as QTFairUse, grabbed song data after it was unlocked and uncompressed by iTunes, and then dumped the raw stream into a large container file, requiring further processing afterward.
-
•The second, written by Johansen for the open source VLC media player--and reused in PlayFair, Hymn, JHymn and other derivatives--intercepts unlocked but not yet uncompressed song files, creating a small, ready to play, unencrypted AAC file.
-
•The third, originally used in PyMusique, a Linux client for the iTunes Store, pretends to be iTunes. It requested songs from Apple's servers and then downloaded the purchased songs without locking them, as iTunes would.
-
•The fourth, used in FairKeys, also pretends to be iTunes; it requests a user's keys from Apple's servers and then uses these keys to unlock existing purchased songs.
All of these exploits only work on song of a specific, known user account. They will not work against protected tracks obtained from an unknown user. FairPlay encryption has never been cracked to the point where anyone can open up any encrypted content, in the way that the CSS DRM on DVDs has.
Because iTunes happily converts protected AAC songs into standard, unprotected AAIF CD files when burning a CD, there isn't much point for a user trying to attack the system or steal its keys. The main reason for trying to defeat FairPlay is to exploit the system for the benefit of third parties.
RealNetworks and the Rhapsody Attack
The most obvious example is Real's attempt to sell its own DRM music that could play on the iPod. Since Real's own Helix DRM does not work on the iPod, Real created software that decrypts its own DRM music, then encodes it in a FairPlay-like package that could play on the iPod with DRM intact.
Apple responded by issuing a bizarre statement saying it was "stunned that RealNetworks has adopted the tactics and ethics of a hacker to break into the iPod," and then threatened to drop the DMCA bomb.
After that excessive posturing, Apple did what it should have done silently: it simply disabled Real tracks from playing. Since then, Apple and Real have squabbled back and forth, but since Apple controls the whole FairPlay system, it has had little problem in preventing Real's DRM from working on the iPod.
Jon Johansen, DRM Profiteer
After releasing a number of open source utilities to strip the DRM from FairPlay protected songs, Johansen decided that it would be more advantageous to get paid for his work.
Apple has worked tirelessly to stop attempts by Real, DoubleTwist, and Johansen's open source software to defeat its FairPlay system. Is the company worried about losing revenue to Real and other store competitors? Well, since Apple makes very little direct revenue from iTunes Store purchases, that's not likely.
Why Apple Cares About DRM
The real impetus behind blocking FairPlay cracks is that Apple has to answer to the labels it licenses its music from; if Apple allows crackers to break the system and recover songs, it has to pay damages to the RIAA.
The only reason Apple maintains FairPlay is to preserve access to licensed content from the music labels for the iPod and the Mac, QuickTime, and iTunes platforms.
Why Apple Doesn't Care About DRM
Foes of DRM have joined with foes of Apple to beat the company up over its efforts to keep FairPlay secure.
After years of negotiating with the RIAA, Jobs' probably knows that the labels are unlikely to give up their DRM demands. His comments really serve to point out that Apple benefits little from DRM, a rebuttal of the attacks from EU regulators that claim Apple’s FairPlay gives it a monopoly and restricts free trade.
As Jobs pointed out, the majority of music is being sold on CDs, and lacks any sort of DRM protection. As long as CDs are sold, it makes little sense for the labels to demand that iTunes sells music with unbreakable DRM, while EU regulators also chime in to demand that Apple share its DRM system with rivals. Two birds, one stone.
Jobs basically told the EU to bark up the record labels’ tree, which happens to be rooted in their own backyard.
If the labels allowed Apple to sell music without DRM, the iPod and iTunes Store could only become more popular. Even if download sales crashed because of rampant piracy, the only real loss would be the labels’, who take the vast majority of revenues from download sales. If sales went up, Apple would do even better.
There is really no way Apple would lose from abandoning DRM, unless doing so would cause the labels to pull out of the iTunes Store and try to resurrect Real's Helix or Microsoft's Janus as an alternative DRM system instead.
That’s the threat posed by allowing competitors to sell DRM that works on the iPod. As long as the playing field is level, Apple can compete. If Real were allowed to sell iPod-playable DRM, or if the iPod supported Microsoft’s Janus DRM, suddenly Apple would be competing against label-friendly DRM and lose any leverage.
At the same time, Apple obviously can't just turn off its DRM and sell the labels’ songs unencumbered without their blessing. Is there any middle ground?
Apple’s Problem With DRM
A number of analysts have frothed all over themselves to call Jobs a lying hypocrite, saying that if Jobs didn't secretly love DRM, he'd offer songs in iTunes without DRM right now. There are labels and independents willing to sell their music without DRM.
The reason Yahoo! is talking about MP3s is because its PlaysForSure business doesn’t get much attention. Apple doesn’t have the same problem, so it doesn’t need to make a meaningless show about offering a dozen MP3s.
The reason that Jobs isn't interested in DRM is not because of a desperate need for attention, nor a religious fervor for open sharing and caring, but rather because DRM only poses a risk and expense to Apple, with negligible benefit. Adding some DRM-free content to iTunes fails to solve the problem.
FairPlay’s Negligible Benefit to Apple
FairPlay may make PlaysForSure-based products from Creative and other Microsoft aligned rivals slightly less appealing because they "won't work with iTunes," but since those players work fine with CDs and have stores of their own, the real reason nobody's buying them is not because of the DRM in the iTunes Store.
PC enthusiasts like to complain that iTunes for Windows doesn’t even work very well, so when they complain that the majority of the market is hopelessly and inextricably tied to iTunes, well, it makes a for a good laugh.
Any slight competitive edge afforded to the iPod by Apple's FairPlay DRM is vastly overshadowed by the development expense and risk Apple incurs supporting a DRM system that only really benefits the RIAA.
So why isn't Apple jumping to adopt DRM-free indie content, to prove to its partner music labels that DRM is unnecessary to support sales?
As he points out, Apple already marks content in the iTunes Store as "clean" or "explicit," so why not sell music as "unencumbered" or "FairPlay," and let users decide?
Why iTunes Can't Mix DRM and non-DRM Content
The real answer seems to be simpler: the iTunes Store is designed to manage purchases along with their keys.
Offering DRM-free tracks next to protected songs in the iTunes Store would require significant changes to how iTunes works, and could inadvertently open up new exploits to the remaining DRM system, complicating the system further. The real rub is that it would do nothing to solve Apple’s real problem.
Apple wants things to be simpler and more efficient, not to offer DRM-free indie tracks next to DRM songs. Duh.
Apple isn't professing a lack of interest in DRM as a ruse to court the favor of DRM-haters, nor is it an ideological exercise in being free-content hippies. The company just doesn’t want to be burdened with maintaining a system that is complex, expensive to maintain and police, and which threatens to expose Apple to risk.
As long as the majority of music is being sold on wide-open, unprotected CDs, FairPlay DRM really serves little purpose beyond giving the RIAA members a false sense of security. If CDs were copy protected, DRM would make more sense as a tool in managing loss.
Making Things Worse
Mixing non-DRM music into iTunes does nothing to solve Apple's problem, it only complicates matters. Apple would have to update the iTunes software so it could download songs and skip encryption and key storage for non-DRM tracks.
Apple would also have to rework its servers to manage purchased tracks without dealing with keys. It would also have to update the iPod to manage purchased track syncing without trying to use keys. It would then need to spend time making sure all those changes didn’t introduce bugs or exploitable vulnerabilities in FairPlay.
That's a lot of engineering work to create a system that duplicates the effort of existing stores that already offer the minority of tracks available as MP3s. There simply isn't a large enough demand for the indie music available on MP3; that’s also why it is not popular enough to be carried by the big pop labels.
Whose Idea Was This?
If Apple were making huge profits from selling music, it might make sense. However, Apple sells music in the iTunes Store to make sure content is available for the iPod. Apple knows there’s no big profits in reselling music.
If online music stores were making money, the world’s number two store wouldn't be an outfit selling MP3s of artists that the big five labels won't even carry. Besides the iTunes Store, which is only earning a small profit, there are no significant, profitable online stores selling popular music.
That's simply a fact: selling other people's music is a low profit business for everyone apart from the big labels. Until they choose to sell their music without DRM, it makes no sense for Apple to outdo itself creating an even more complex system to sell unpopular music that is already available elsewhere.
The same logic also applies to the small number of pop bands ready to sell their music without DRM: compared to the volume of music sold through the big labels, they simply don’t matter.
What About Licensing FairPlay?
The record labels don't want to give up DRM. They also don't share Apple's problems with FairPlay--that it’s a big job to maintain and constantly under siege--because they are protected by their licensing contracts with Apple, which demand damages if FairPlay is ever cracked and not immediately repaired.
The labels’ only problem with DRM is that Apple's FairPlay is the only commercially successful version for downloads. For the labels, that's a liability, because it gives Apple a huge amount of leverage in its negotiations.
hello! i have a problem with this whole scheme of code signing… i’m just trying to put a developer profile on the iphone i’m using to develop… i’ve followed this tutorial on the 2.2 sdk… and it worked flawlessly… but now that i’m on 2.2.1… i can’t get the application installed on the iphone… i’ve found out that it wouldn’t sign the application correctly if i didn’t assign the code signing identity and any iphone os values to the developer certificate for my app, on the target app info… i remember i didn’t need to do that… and then i get the dreaded 0xE800003A, i’ve followed all of this step by step… and nothing… any clues?
Great article. I experienced many of the same problems. One note (and perhaps I just built mine wrong and my rejection email is forthcoming from Apple)… if I left the entitlements file in my “app store” release (using my app store provisioning file), I was still able to install the application on my device. Sound weird? Anyway, I’ve submitted it to Apple that way, I’ll let ya know if they reject it or not.
Great article. Wow, there’s more to this than I would have imagined. Are their any good step-by-step books on the market that anyone would recommend for getting started with iPhone development?
Awesome article. One question - i’m one of those “friends” that is getting an Ad-Hoc profile and app to test. The ad-hoc provisioning profile is on my iPhone now (i dragged it to iTunes dock), so that seemed positive. Looks like I have a .app file also, so dragged it to iTunes dock too and Sync’d…. but I get a message “the application could not be installed because it could not be verified.” Is there some other part of the process i’m missing?
@Joe: If the Ad-hoc provisioning profile has installed correctly on your iPhone and you’re getting this error message, in most cases the app has not been signed correctly. I’d recommend to touch base with the dev and make 100% sure that he used the correct certificate including your Device ID.
You might also find the tips available here helpful: http://www.codza.com/how-to-fix-iphone-code-signing-errors .
Hope this helps and let me know!