Help me make these happen. They're not the sort of things that one man can do alone.
First, in fashion. Argyle is the new plaid; houndstooth is the new pinstripe. This is my decision. Everybody go make it happen; now please. While you're at it, no more tucking jeans into boots unless you live in Texas. Even then, it might not be such a great idea.
In application interface design, I want to see woodgrain where I'm starting to get tired of seeing brushed metal. Brushed metal was cool for one season, but it got overused mostly because Apple refused to follow their own Human Interface Guidelines. The madness stops now, people. Woodgrain is the new brushed metal, for when the interface is meant to duplicate the feel of an existing device. I want a stylized look that *isn't* going to become so overused it loses its edge. People are so jaded with window decoration these days and they need to be snapped out of it. Elegant is the new complicated; beautiful is the new functional. Spread the word.
In web design, let's sit back and revolutionize the way people interact with web pages and the Web as a whole. It's time for a transformation in the nature of the medium. I'm not talking Web 2.0 here. I'm saying that Web 1.0 was really Print 2.0. Let's not chain ourselves to words on paper; we don't need that paradigm to constrain us any more. So let's band together and make an experience that is unique and completely separate from looking something up in a book or reading a newspaper, but that is so intuitive that people will feel like it's how they've always been doing it. I have my own ideas but it's too soon for them to come out. Let's race and see who gets there first.
And in my life, I want to get back to the production end of music. I love to listen, but I also love to play, and I haven't been playing at all recently. Getting my decks out of storage was the first big step. Getting my skills out of storage is going to take some doing. I can do this though, and I will do this. My mind constantly swims in music and I love it. I need to bring it back, but this time I'm going to use all of the new music that I have grown to either love or grown to realize has a place in hip hop, and I'm going to bring it back. A lifetime of listening to the widest possible variety of music night and day will definitely teach you that everything is connected and everything is influenced by everything. The best hip hop deejays are the ones that listen to rock (see also: DJ Shadow, but in particular Afrika Bambaataa and Prince Paul).
I know this is a tall order for myself, but within five years I want to be able to do whatever I want. You can take that to mean that I'll have enough money or enough influence or enough power or enough streetcred so that if I say I want to take three months and drive a motorcycle through all of South America, I can. If I want to travel to Siberia to take photographs of old soviet nuclear waste dumps, I want to be able to do that. We're entering decade three here; it's time I showed the world my power move.
That is all. Until later, space cadets.
-- m a x
21 December 2006
24 November 2006
Thanksgiving
I just returned from the odyssey that was Stahl Family Thanksgiving 2006. Oy. . . . It was really great to see my aunts and uncles and cousins and grandparents and everything; it was just really not so great having to drive six hours to get to Cleveland, drive six hours back, and suffer the awkward situation that is my relationship with my brother-in-law. Seeing Juliet again was awkward, too. I don't know what's wrong, but I worry about her a lot, even if she does constantly drive me away with her behaviour. Methinks that's an entry for another time though, or maybe another place.
Emily's parents were asking after me. I should write up a super-snooty bio and resume online somewhere for people to find. Maybe I'll even post it here! Hrmmmmm *schemes* stay tuned, space cadets.
Emily's parents were asking after me. I should write up a super-snooty bio and resume online somewhere for people to find. Maybe I'll even post it here! Hrmmmmm *schemes* stay tuned, space cadets.
21 November 2006
A Lesson for the Kids Out There
Before you decide to do some work at home, go ahead and look at your environment at home and make sure it's sufficiently similar to your environment at work for you to actually accomplish things. Things to look for include having similar software on your machine, having a similar server setup, and last but not least never trusting another human being to test your site from outside your home.
To all the people who tried in vain to help me out last night, thanks, but I really oughtn't've asked you in the first place 'cause it ended up being more embarrassing the more people who could view my incompetence. The site worked great on my machines, but didn't work at all on other people's outside my LAN. It looked straight outta ninety-three (oh by the way, Brian; you could've said that first; that'd've been handy to know). Bah. It's no one's fault. I was developing it in a vastly different environment then I planned on launching it. Even so; I was embarrassed and that was no good.
For those that still care after last night's fiasco, I was demonstrating the capabilities of my AJAX-enabled FAQ component, for Joomla. This component is capable of maintaining groups of frequently-asked questions in an intuitive and un-cluttered interface that people so far seem to love. As an added bonus, browsers that don't have Javascript enabled can still view the FAQs if they want (though they won't be treated to the awesome slide-out effect I wrote in). This site I'm including it in will not be publicly-accessible (it's on an company WAN), but the same FAQ component will be used on Vi.llaino.us and also on another upcoming project of mine. The beta version of it, if you will, is also on the First Data website.
Yeah . . . so . . . my dev environment is a little better at home now and I shouldn't be having any of these problems anymore. Good times, right? Until later, space cadets.
To all the people who tried in vain to help me out last night, thanks, but I really oughtn't've asked you in the first place 'cause it ended up being more embarrassing the more people who could view my incompetence. The site worked great on my machines, but didn't work at all on other people's outside my LAN. It looked straight outta ninety-three (oh by the way, Brian; you could've said that first; that'd've been handy to know). Bah. It's no one's fault. I was developing it in a vastly different environment then I planned on launching it. Even so; I was embarrassed and that was no good.
For those that still care after last night's fiasco, I was demonstrating the capabilities of my AJAX-enabled FAQ component, for Joomla. This component is capable of maintaining groups of frequently-asked questions in an intuitive and un-cluttered interface that people so far seem to love. As an added bonus, browsers that don't have Javascript enabled can still view the FAQs if they want (though they won't be treated to the awesome slide-out effect I wrote in). This site I'm including it in will not be publicly-accessible (it's on an company WAN), but the same FAQ component will be used on Vi.llaino.us and also on another upcoming project of mine. The beta version of it, if you will, is also on the First Data website.
Yeah . . . so . . . my dev environment is a little better at home now and I shouldn't be having any of these problems anymore. Good times, right? Until later, space cadets.
10 November 2006
End of an Error
Nick
1.26 bush isn't a lame duck president
1.26 he's cooked and being served
1.26 haha
max stahl
1.27 Oh he's gettin' served alright.
1.27 hahaha
Nick
1.27 haha
1.27 that was a certified zinger
max stahl
1.27 *swish!*
1.27 Count it.
1.26 bush isn't a lame duck president
1.26 he's cooked and being served
1.26 haha
max stahl
1.27 Oh he's gettin' served alright.
1.27 hahaha
Nick
1.27 haha
1.27 that was a certified zinger
max stahl
1.27 *swish!*
1.27 Count it.
18 October 2006
Digital Rights Management: Putting the Genie Back in the Bottle
Some of y'all might be familiar with DRM, some might not. Let me break it down thusly.
Digital Rights Management, or DRM, is the concept that the copyright owners of the contents of digital files should have control over how they are used on your computer. This is where things like iTunes' FairPlay® system come in. In FairPlay you're allowed to play your music files you've purchased on your computer and four other computers, and you're allowed to burn the files to CD a limited number of times. It sounds okay but kind of restrictive, right? This is the least restrictive of all the DRM formats that I've seen. The rabbit hole goes much deeper; let's take a look.
One of the earlier forms of DRM copy protection was CSS. That's not Cascading Stylesheets, but Content Scrambling System. CSS was the copy-protection scheme used for DVD players. This turned out to be ridiculously easy to break, requiring about 17 lines of code written shortly after DVDs became popular. The scheme consisted of a "region" encoding, that would restrict the playing of DVDs to players that had the same region. This way the cheaper DVDs produced in Japan could not be played on American DVD players, cheap American DVDs couldn't be played in England, etc. In addition, the contents of the DVD, the actual video, were scrambled according to a simple cryptographic scheme, protected pretty much only by its obscurity (stay tuned for more cryptographic articles later). This system provided the content providers with control over where their content could be sold (or at least viewed) and thus how much it would cost; it also protected the digital content of the DVDs from immediate ripping like was experienced with CDs. CD audio is just an integer stream representing the sound wave it aims to reproduce; ripping it to a computer just means transferring that information to the computer from the CD. Digital to digital; easy, right?
There is an incredible weakness in CSS, though, so easily exploitable that it becomes laughable. And as I will argue in a moment, this weakness is inherent in any DRM scheme imaginable, for a multitude of reasons. Look at this from a cryptographic perspective. Say Alice sends Bob a movie, but requires that the information remain secure in transit. However, she and Bob have nevere spoken before. So, they follow an established protocol for talking so that it's secure; they have a key with a limited keyspace (I totally can't remember what it is for CSS; maybe 512?) and when Bob receives the movie, he'll test all the keys really quickly and see which one decrypts the stream properly. In this little imaginary scenario, Alice is the DVD content provider and Bob is a DVD player. The weakest link that I was referring to above is that there has to be some way for Bob to guess the key intelligently, and we can guess it, too.
Therein lies the insurmountable hurdle for all content providers who wish to use any DRM of any kind: at some point, the purchaser has to be capable of hearing the music or viewing the file or watching the movie, and it's at this moment that it all breaks down. Let's back up, first, though.
For any secure channel (for the sake of argument, let's move away from the DVD analogy and move on to a TV episode you've purchased as a .mpv file), the recipient must at some point have both the cryptotext (the file, protected), and the key (presumably stored on their computer or sent via the internet and cached) at the same time. The actual data received in the end is the plaintext (in this case, our TV episode). If the user doesn't have the key, they're not authorized to view that content. Fine. But this entire scheme relies on the "trusted" nature of the program used to view the file. But what if we wrote a program that pretends to be the trusted program, opens the file, receives the key, and performs the decryption using the key, storing the plaintext on the hard drive rather than viewing it? It sounds, actually, a lot harder than it really is. iTunes 7 encryption was compromised in this way less than eight hours after the release of iTunes 7.
The only other real options for content providers are rootkits (see also: Sony's huge fuckup of this past year), which would attempt to enforce DRM on the operating system level, a hugely controversial move, or trusted hardware. Trusted hardware brings the same idea as trusted software down to the parts of a device you can kick. A DVD player is a simple example of one such device; the content providers have an agreement with the DVD player manufacturers that they will build their product with these certain features to limit users' ability to copy DVDs. But what if some enterprising hacker were to build an untrusted device that behaved like a trusted device? In Australia, for example, it's illegal to sell DVD players that aren't "regionless" (i.e., they must ignore the region encodings of DVDs); an Australian DVD player will act like a trusted device this way, but will not act in the way that content providers wish it to act.
There's a central fallacy here. At some point, the user must be able to view, listen to, or otherwise enjoy the content they've purchased. Whether at the speaker output, as it's being decoded for play, or elsewhere along the chain of DRM goodness, the plaintext data must reveal itself in order for this to happen. It is not possible for the user to be able to hear a song they've purchased without the data that makes up that song passing through some untrusted hardware or software along the way (like, for example, a pair of headphones). So at some point the file is bare and naked, and can be cached that way. Also, no DRM scheme can be overly complicated, because at some point a portable device may be expected to play files, and overly complicated DRM both slows down playback and also drains batteries. Because of the combination of these two things, no DRM scheme will ever be unbreakable; it is much more likely that every DRM scheme will fall into the "trivially breakable" category like FairPlay and CSS both are.
In conclusion, the music industry is now forced to undergo a radical shift in how they sell music. In the good old days, you'd buy your music on vinyl. Though you had in your hands an extremely high-quality analogue recording, lovingly reproduced with excellent fidelity, the owners of the copyright on that recording were guaranteed that you could only play it so many times before it would wear out. A 7-inch 45rpm single would wear out with a few hundred plays sometimes. So you'd buy a new record when that happened. Now, with digital formats, the music is encoded as binary and stored on a hard drive or backed up to CD, and the bits never die. The only way you could lose a recording is if you actually lost it via hard drive crash or otherwise. There is no longer any way for content owners to fully control what is done with their materials, and there is still a limitless market for content. When strained, consumers will find other ways to get what they want, and these consumers have rights, too. This DRM business is silly. All it does is limit honest consumers, and for those of us who want to exercise absolute control over our data, it has turned us into outlaws (see also: the Digital Millennium Copyright Act), and it doesn't even work.
Digital Rights Management, or DRM, is the concept that the copyright owners of the contents of digital files should have control over how they are used on your computer. This is where things like iTunes' FairPlay® system come in. In FairPlay you're allowed to play your music files you've purchased on your computer and four other computers, and you're allowed to burn the files to CD a limited number of times. It sounds okay but kind of restrictive, right? This is the least restrictive of all the DRM formats that I've seen. The rabbit hole goes much deeper; let's take a look.
One of the earlier forms of DRM copy protection was CSS. That's not Cascading Stylesheets, but Content Scrambling System. CSS was the copy-protection scheme used for DVD players. This turned out to be ridiculously easy to break, requiring about 17 lines of code written shortly after DVDs became popular. The scheme consisted of a "region" encoding, that would restrict the playing of DVDs to players that had the same region. This way the cheaper DVDs produced in Japan could not be played on American DVD players, cheap American DVDs couldn't be played in England, etc. In addition, the contents of the DVD, the actual video, were scrambled according to a simple cryptographic scheme, protected pretty much only by its obscurity (stay tuned for more cryptographic articles later). This system provided the content providers with control over where their content could be sold (or at least viewed) and thus how much it would cost; it also protected the digital content of the DVDs from immediate ripping like was experienced with CDs. CD audio is just an integer stream representing the sound wave it aims to reproduce; ripping it to a computer just means transferring that information to the computer from the CD. Digital to digital; easy, right?
There is an incredible weakness in CSS, though, so easily exploitable that it becomes laughable. And as I will argue in a moment, this weakness is inherent in any DRM scheme imaginable, for a multitude of reasons. Look at this from a cryptographic perspective. Say Alice sends Bob a movie, but requires that the information remain secure in transit. However, she and Bob have nevere spoken before. So, they follow an established protocol for talking so that it's secure; they have a key with a limited keyspace (I totally can't remember what it is for CSS; maybe 512?) and when Bob receives the movie, he'll test all the keys really quickly and see which one decrypts the stream properly. In this little imaginary scenario, Alice is the DVD content provider and Bob is a DVD player. The weakest link that I was referring to above is that there has to be some way for Bob to guess the key intelligently, and we can guess it, too.
Therein lies the insurmountable hurdle for all content providers who wish to use any DRM of any kind: at some point, the purchaser has to be capable of hearing the music or viewing the file or watching the movie, and it's at this moment that it all breaks down. Let's back up, first, though.
For any secure channel (for the sake of argument, let's move away from the DVD analogy and move on to a TV episode you've purchased as a .mpv file), the recipient must at some point have both the cryptotext (the file, protected), and the key (presumably stored on their computer or sent via the internet and cached) at the same time. The actual data received in the end is the plaintext (in this case, our TV episode). If the user doesn't have the key, they're not authorized to view that content. Fine. But this entire scheme relies on the "trusted" nature of the program used to view the file. But what if we wrote a program that pretends to be the trusted program, opens the file, receives the key, and performs the decryption using the key, storing the plaintext on the hard drive rather than viewing it? It sounds, actually, a lot harder than it really is. iTunes 7 encryption was compromised in this way less than eight hours after the release of iTunes 7.
The only other real options for content providers are rootkits (see also: Sony's huge fuckup of this past year), which would attempt to enforce DRM on the operating system level, a hugely controversial move, or trusted hardware. Trusted hardware brings the same idea as trusted software down to the parts of a device you can kick. A DVD player is a simple example of one such device; the content providers have an agreement with the DVD player manufacturers that they will build their product with these certain features to limit users' ability to copy DVDs. But what if some enterprising hacker were to build an untrusted device that behaved like a trusted device? In Australia, for example, it's illegal to sell DVD players that aren't "regionless" (i.e., they must ignore the region encodings of DVDs); an Australian DVD player will act like a trusted device this way, but will not act in the way that content providers wish it to act.
There's a central fallacy here. At some point, the user must be able to view, listen to, or otherwise enjoy the content they've purchased. Whether at the speaker output, as it's being decoded for play, or elsewhere along the chain of DRM goodness, the plaintext data must reveal itself in order for this to happen. It is not possible for the user to be able to hear a song they've purchased without the data that makes up that song passing through some untrusted hardware or software along the way (like, for example, a pair of headphones). So at some point the file is bare and naked, and can be cached that way. Also, no DRM scheme can be overly complicated, because at some point a portable device may be expected to play files, and overly complicated DRM both slows down playback and also drains batteries. Because of the combination of these two things, no DRM scheme will ever be unbreakable; it is much more likely that every DRM scheme will fall into the "trivially breakable" category like FairPlay and CSS both are.
In conclusion, the music industry is now forced to undergo a radical shift in how they sell music. In the good old days, you'd buy your music on vinyl. Though you had in your hands an extremely high-quality analogue recording, lovingly reproduced with excellent fidelity, the owners of the copyright on that recording were guaranteed that you could only play it so many times before it would wear out. A 7-inch 45rpm single would wear out with a few hundred plays sometimes. So you'd buy a new record when that happened. Now, with digital formats, the music is encoded as binary and stored on a hard drive or backed up to CD, and the bits never die. The only way you could lose a recording is if you actually lost it via hard drive crash or otherwise. There is no longer any way for content owners to fully control what is done with their materials, and there is still a limitless market for content. When strained, consumers will find other ways to get what they want, and these consumers have rights, too. This DRM business is silly. All it does is limit honest consumers, and for those of us who want to exercise absolute control over our data, it has turned us into outlaws (see also: the Digital Millennium Copyright Act), and it doesn't even work.
15 October 2006
New Blog
Since the shitty little move that Richard pulled a few weeks ago—namely the destruction of www.maxstahl.com—I haven't had a good place to put techy blog things.
So, you can expect things here kinda like were on my old site. Sort of theoretical and analytical articles on the Web, on programming (particularly for the web), on development in general, and also just on computer science and the sciences in general.
For more detailed commentary on web-specific topics, you'll want to stay tuned. We of the Great and Powerful Development Team at VSA are all going to have blogs soon and when I get that one I'll actually make a pretty good effort to keep it up. Until then, space cadets.
So, you can expect things here kinda like were on my old site. Sort of theoretical and analytical articles on the Web, on programming (particularly for the web), on development in general, and also just on computer science and the sciences in general.
For more detailed commentary on web-specific topics, you'll want to stay tuned. We of the Great and Powerful Development Team at VSA are all going to have blogs soon and when I get that one I'll actually make a pretty good effort to keep it up. Until then, space cadets.
Subscribe to:
Posts (Atom)
