All the Perl that's Practical to Extract and Report

iTunes and "Sharing"

pudge on 2003-04-30T11:36:13

Someone told me he thought that the fact that iTunes cannot copy Playlist Sharing files, but could only stream them, was a restriction by the server. This seemed unlikely, so I did some investigation.

Copying the MP3 in reality is painfully easy:

[pudge@bourque pudge]$ curl http://10.0.1.132:03689/databases/32/items/1104.mp3?session-id=20570 > file.mp3 % Total % Received % Xferd Average Speed Time Curr. Dload Upload Total Current Left Speed 100 11.0M 100 11.0M 0 0 3071k 0 0:00:03 0:00:03 0:00:00 2818k

Now I have the MP3 as a file, streamed from iTunes via Playlist Sharing. Nothing on the server side prohibits this. I open it in iTunes and it is a regular ol' MP3. It has the exact same bytecount as the original file.

Note: I got the URL by peeking at the TCP/IP traffic with Interarchy:

010.000.001.104:49825->010.000.001.132:03689 (224 bytes) TH_PUSH TH_ACK GET /databases/32/items/1104.mp3?session-id=20570 HTTP/1.1

So I call the exact same thing with curl, except that I save to a file instead of opening the URL in iTunes. I can't tell a way to get the URL without doing that; this is not meant to describe a way to fetch arbitrary files from iTunes Playlist Sharing, just proving that copying files the same way you stream them is technically trivial.

And more fun: if I open that URL in iTunes instead of downloading it via curl, it shows up as a regular stream in my Library. And it DOES work with get current track AppleScript, although if I play the exact same stream via Playlist Sharing, it doesn't. Again, I maintain this behavior is either a bug or intentional breakage, not a neglected feature. And because I have proven that copying the file is so technically trivial, I believe DRM concepts are most likely involved.

Jobs says that users are not being treated like criminals, but iTunes 4 assumes that if I want to share my tracks with more than three computers, if I want to copy streamed track, if I want to burn more than 10 CDs with a "protected" track, that I am doing so illegitimately. I know they need to strike a balance with their partners, but that doesn't mean I am going to just ignore these facts.

I am, frankly, more offended by the clearly false assertion by Jobs that we are not being treated like criminals than I am by the fact that I cannot share the music or burn playlists without limit (except in the case of copying files from shared playlists).

BTW, this morning my Apple ID finally was able to work with iTunes Music Store. It wasn't site traffic, nor my credit card, since I could connect with a different Apple ID at the same time, using the same credit card. I am just happy Apple fixed whatever was wrong with my Apple ID.

The Big Five vs. the rest of us

ziggy on 2003-04-30T15:07:29

I am, frankly, more offended by the clearly false assertion by Jobs that we are not being treated like criminals than I am by the fact that I cannot share the music or burn playlists without limit (except in the case of copying files from shared playlists).
First of all, the "good karma" limitations being placed on copying media are like the lock on your front door -- it's there to keep honest people honest, not prevent illegal activity. Anyone who wants to illegally copy digital music badly enough will find a way to do so, just like anyone who wants to break into your house badly enough will pick the lock.

These rules are obviously transitional. Apple struck a decent bargain with the excessively conservative Big Five music companies.

Re:The Big Five vs. the rest of us

pudge on 2003-04-30T15:14:08

It is more like Apple putting a lock on my front door and letting me have a key to it, that I can use 10 times a day, in order to make sure I am not letting anyone else use my computer.

Re:The Big Five vs. the rest of us

joek on 2003-05-05T03:52:22

There is NOT a 10x limit on burning a particular song (protected or not). You can burn any song an infinite amount of times.

There is a playlist restriction... not a song restriction.

Re:The Big Five vs. the rest of us

pberry on 2003-05-07T15:14:51

Locks on houses seem really only to keep the owner out when they forget their keys. Honest people don't go into other people's houses and as you point out, criminals will not be detered by a lock.

That being said... ;-)

The real entity treating you like a "criminal" is the copyright owner. When, not if, the AAC protection is cracked it will be the RIAA and not Apple that slaps you with a DMCA violation. When you work around the 10 playlist burning limitation it will be the RIAA who comes after you, not Apple.

I know I may sound like an Apple apologist here, but as long as we are trying to figure out who the "bad guy" is we might as well make all the relevant facts made clear.

Thinking that the music industry (read: The Big 5) were going to let plain jane mp3 files be downloaded with no restrictions is naive. They have been bitten by their lack of vision repeatedly and frankly I'm amazed that Apple was able to negotiate even these restrictive terms.

Plus, keep in mind you are not buying the song. The song is still owned by the copyright owner. You are simply licensing some rights temporarily. Check the EULA...

Re:The Big Five vs. the rest of us

pudge on 2003-05-07T15:31:57

The real entity treating you like a "criminal" is the copyright owner. When, not if, the AAC protection is cracked it will be the RIAA and not Apple that slaps you with a DMCA violation. When you work around the 10 playlist burning limitation it will be the RIAA who comes after you, not Apple.

Apple is the one preventing me from doing things with songs I might, as far as they know, have the legal right to do. I am not saying the RIAA gets a pass. The only reason Apple is doing what it does is to appease the RIAA and its music label partners. But Apple is saying one thing ("it is your music"), and doing another ("we will prevent you from playing it on more than three computers"). There's no way around this. Explaining the purpose of the restriction doesn't justify the inconsistent statements.

I am not saying iTMS sucks, or that Apple sucks. I am bemoaning that Apple is, in this case, saying one thing and doing another.

The 10 burn restriction...

frumiousbar on 2003-05-02T21:39:42

FYI, the 10 burn restriction is not per-track, it's per playlist. In other words, say that you have a playlist with 10 tracks in it. You can only burn this playlist 10 times. However, you can burn the individual files as many times as you want as long as you keep using different playlists. The goal is to prevent people from mass producing a CD.

rtsp-streams then?

db on 2003-05-06T12:03:13

This was simple, however, any suggestions on how to record non-recordable Real Audio-streams? Is it possible to somehow dump all traffic on a certain connection (specified by being udp, coming from a certain address to a certain port)?

Re:rtsp-streams then?

pudge on 2003-05-06T13:39:38

I would think it is possible, yes. I couldn't tell you how, though tcpdump might be of use ...

Re:rtsp-streams then?

gnat on 2003-05-07T15:06:35

Use Audio Hijack.

--Nat

Re:rtsp-streams then?

db on 2003-05-08T08:16:09

The problem with Audio HiJack is that it, obviously, only support audio. I want to capture video as well.

Re:rtsp-streams then?

gnat on 2003-05-08T17:51:55

Snapz Pro captures Mac audio and video.

--Nat

iTunes sharing

AnonymousChicken on 2003-05-11T15:07:32

I've been looking into this a little more. File order appears to be keyed on Date-Added. If you add the Date added field to itunes, and then stream the files, you can see they continue almost sequencially.


  192.168.1.101:49186 -> 140.247.81.130:3689 [AP]
    GET /databases/35/items/289.mp3?session-id=11720 HTTP/1.1..Host: metadata:1..User-Agent: iTunes/4.0 (Macintosh; N; PPC)..connection: close.. ..


T 192.168.1.101:49187 -> 140.247.81.130:3689 [AP]
    GET /databases/35/items/290.mp3?session-id=11720 HTTP/1.1..Host: 140.247.81 .130..Cache-Control: no-cache..Accept: */*..x-audiocast-udpport:49177..icy-
    metadata:1..User-Agent: iTunes/4.0 (Macintosh; N; PPC)..connection: close.. ..


T 192.168.1.101:49188 -> 140.247.81.130:3689 [AP]
    GET /databases/35/items/291.mp3?session-id=11720 HTTP/1.1..Host: 140.247.81 .130..Cache-Control: no-cache..Accept: */*..x-audiocast-udpport:49178..icy-
    metadata:1..User-Agent: iTunes/4.0 (Macintosh; N; PPC)..connection: close.. ..


T 192.168.1.101:49189 -> 140.247.81.130:3689 [AP]
    GET /databases/35/items/292.mp3?session-id=11720 HTTP/1.1..Host: 140.247.81 .130..Cache-Control: no-cache..Accept: */*..x-audiocast-udpport:49179..icy-
    metadata:1..User-Agent: iTunes/4.0 (Macintosh; N; PPC)..connection: close.. ..



The ID of the music is continuing (blah-blah.mp3) is continuing, nearly sequencially.
One thing to note is that in some cases, this order might be screwed up slightly. This is because if a song is deleted from the user's libraby, it appears to keep it's number reserved.

The other thing that can screw the order up is songs that were batch-imported in the same minute. It seems that iTunes only tracks down to the minute, so the order within that minute is arbitrary, as far as I can tell.

If, after determining the URL via ngrep, and taking the IP, you retrieve it using curl (or wget), you add it to iTunes, it retains the id3 information.

It would be an interesting test to see if iTunes is adding information to the file before streaming it. (for identification, as Pudge suggested)
This would be possible by doing a binary diff on the two files. I don't have two macs with iTunes 4 installed (yet!, but I intend to install iTunes on the others soon), so I can't test this theory. Any volunteers?

(Side note- It would be trivial to write a perl script that parsed the ngrep output, and fed it into wget automatically, to download any songs you double-click. You wouldn't even need to listen to the entire song. Just start it playing, and iTunes will finish for you. I won't post mine, for reasons below.)

Side note redux-
      Apple may have inadvertantly created a file-sharing utility rivaling Napster/Kazaa. This creates an interesting legal issue. This creates an interesting legal issue. Keep in mind that a student was recently sued for creating a software device that searched Network shares for mp3 files.

Given the RIAA's stance towards piracy, and that they want to work with apple, I suspect they would sue whomever wrote the 4 line perl script, rather than Apple. They are also likely to ask "index" sites like spymac to shut down, and send a cease-and-desist, or a lawsuit..

-Crutz

Re:iTunes sharing

pudge on 2003-05-11T15:21:06

It would be an interesting test to see if iTunes is adding information to the file before streaming it. (for identification, as Pudge suggested)
This would be possible by doing a binary diff on the two files. I don't have two macs with iTunes 4 installed (yet!, but I intend to install iTunes on the others soon), so I can't test this theory. Any volunteers?

I already did this when I posted the journal entry, saying "I open it in iTunes and it is a regular ol' MP3. It has the exact same bytecount as the original file." I believe I also checked the MD5 of it, though I can't recall specifically, but I am pretty sure it is the exact same file.

As to Apple ... they can sue whomever they like, but the recent Kazaa (I think it was Kazaa, I forget exactly) suit shows that the court isn't willing to blame the people who write the code ... for now, anyway. Napster got shut down because they had some ability to block the illegal MP3s and made no effort to, because the MP3s were going through their servers, etc. The distributed P2P systems are not, for now, liable. If you shut down Gnutella, for example, it wouldn't stop anyone from using Gnutella. Moreso for a four-line perl script. I can't see any reason to worry about it.