What you say is true of the decoder, but the issues with insane software demands do affect even large CPUs significantly. The percentage of the CPU dedicated to instruction decoding can go down as you increase the amount of execution units etc., but x86 CPUs still have to dedicate a lot of chip routing and logic to the (many) "special cases" that software might demand yet are incompatible with modern CPU optimizations. Things like snooping writes in case the CPU needs to invalidate a TLB, etc. As you add complexity, you have to keep adding these special cases and workarounds for things that were once implicit in older, more trivial CPUs. These things don't scale down when you add complexity; instead, they come along with complexity that you add. I wouldn't be surprised if up to 25% of the silicon area of a modern x86 chip could be shaved off if only the ISA requirements on the software were more like those of PowerPC or ARM (not the ISA itself, just the requirements and limitations on what the software can and can't do).
Thumb is implemented as a layer on top of ARM (at least last I checked), so usually the ARM decoder will still be active while in Thumb mode. However, Thumb and Thumb-2 are essentially compressed versions of ARM, so the vast majority of the decoder can be shared. The combined decoder for a modern ARM CPU is still much simpler and better performing than the decoder for an x86 CPU.
Another large advantage is that ARM programs by definition do not use things like self-modifying code without informing the CPU (i.e. issuing a dcache store and an icache invalidate). This means that ARM CPUs can be essentially Harvard architecture machines and they practically don't need any snooping logic for the caches. x86 CPUs always have to watch for insane things like an instruction modifying the instruction immediately after it in the pipeline, while that doesn't even work at all on ARM (you need the aforementioned flush/invalidate plus a write barrier and whatnot). Having CPUs impose these kinds of (reasonable) demands on the software is a very good thing for performance.
The x86 CISC instruction set is so convoluted and ancient that x86 CPUs spend a lot of die area (and power) dealing with it and the weird ways that extensions have been tacked over time. The fact that it's old also means the CPU requires tons of logic because the instruction set was designed for simpler, less well performing CPUs. Newer techniques to speed things up usually work best with software support, while x86 CPUs have to implement these older techniques and then add a compatibility layer to make them work seamlessly with the old instruction set and old OSes that know nothing about them.
One large difference between ARM and x86 that people rarely realize is that ARM only (usually) guarantees compatibility at the application (usermode) level, while x86 has to maintain compatibility down to the OS (kernelmode) level. ARM is free to update their architecture, add features required for modern performance, and require that the OS deal with them. This is hardly an issue because OSes adapt fast these days and the ARM market has no dependency on ancient OSes. x86 still has to deal with the fact that some nutjob might want to run Windows 3.11. Even when x86 does implement newer stuff, like the SYSCALL and SYSRET instructions that aim to replace the ancient and slow software interrupt system call mechanism, OSes are slow to adapt and the CPU still has to carry around the logic for the old crap. Forever.
Here we have a platform where there is no reason whatsoever to have an ass-backwards-compatible architecture in order to run legacy Windows apps. There is zero reason to use x86 here other than marketing and Intel. Please go away, we're perfectly happy with a modern RISC architecture (ARM), thank you very much.
Here's to hoping that ARM will permeate its way up into the netbook market and beyond, instead of the other way around. We've been tortured by x86 long enough already.
One thing you can (very barely) do with mine is determine the location of the sound. By which I mean the audio is delayed by about one sample between channels if the audio comes from a point directly to one side of the laptop (and which channel lags depends on which side). This is how I convinced myself that it really was a stereo sum/difference signal and there were two mics. See the math here: one 48kHz sample is about 7mm. The only way to actually tell of course is to make a sharp click by banging together some metal objects or something; only then can you clearly see that one channel is ahead of the other.
Of course, if the mics actually were on opposite sides of the laptop you could try some reasonably interesting tricks, but at 1cm separation it's all but useless.
Fine, Mr. Pedantic, it's probably a MEMS Single-Chip Microphone and Sigma-Delta Encoder with Pulse Density Modulation output.
Trivia: in my laptop, they actually put two of them side by side (about 1cm separation) for an absolutely worthless version of stereo. Worse, the ALC889 chip on the laptop insists on sending it to software as a sum/difference signal. I managed to find a secret vendor register bit that will throw away the difference part and pipe the sum (average) signal to both L and R though, so if you have an Acer Aspire 8930G and you run Linux your front microphone will work normally as a regular mono mic.
Acer uses digital microphones (at least on my Aspire, anyway, so I assume they do on these recalled laptops too). Typical electret analog mics require power, but it's delivered via a resistor on top of the audio path, so it's safe if short circuited. Digital mics have a separate power connection. They probably hooked this up to a system power bus (5V/3.3V/whatever) with no current protection. The current available on these buses will easily feed a short circuited thin wire, which will cause significant heating.
Sounds like someone at Acer needs to learn to put safety fuses between power domains, especially when you're feeding power from a fat power bus into a tiny wire.
For what it's worth, we've been messing around with Vodafone UK's femtocell (they call it the Access Gateway) and successfully made it work in Germany by piping its connection through an OpenVPN to a server in the UK. This one doesn't have GPS, though it does have a GSM modem that can theoretically pinpoint the country and nearby cells, though they don't appear to use it (properly) yet.
I may be wrong, but I was under the impression that the PIN is used to pair, and pairing establishes link keys that are then used to secure the communications. My assumption is that there's a randomized element to these keys, such that someone eavesdropping the pairing process would probably be able to get them, but not someone who eavesdrops a session after the devices have been paired.
DECT phones (which are pretty popular in Europe, not so sure about the USA) do have encryption. I believe it's been broken, but at least they tried. Same with Bluetooth.
There's no "trick" to work with locked phones. GSM has no network-side authentication, so all you have to do is impersonate your carrier's network (this is trivial). But I can't imagine this being in line with regulations. Another issue is that encryption does not work unless you're a carrier and share a secret with the phone's SIM, which means that invariably your calls will be broadcast in the clear when you're using this device.
I'm not entirely sure this is a good idea. Femtocells are great, but impersonating carriers gets you into all sorts of sticky issues.
I assure you a WEP network with long key and running a low transmission (for example instant messenger + RSS + WWW surfing, vs video streaming, torrents or online games) can take good many hours to break.
.
Good job living under a rock. ARP replay attacks have been able to break into just about any WEP network with any traffic for quite a while now. All you need is a single ARP packet and you win.
Obviously you haven't yet heard about the ridiculously shitty 4.2 system updater nintendo pushed that tends to brick even PRISTINE consoles...
You mean the one I have repeatedly described as broken, and which I knew would brick consoles even before it came out because I've run their boot2 update function under an emulator and realized how broken it was? I'm definitely not excusing Nintendo for that one by any stretch. They fucked it up bigtime.
The fact that Nintendo screwed up the boot2 update code and then decided to force a boot2 update onto users is orthogonal to this discussion, unless you're trying to compare it to the brickage risk of using the completely moronic tools involved in playing copied games, in which case I can guaran-damn-tee that the risk of being bricked by 4.2 is ridiculously lower than that of being bricked by those tools. Just think about the statistics of the matter for a second: Nintendo screwed up a bootloader update, which under some rare (but definitely relevant when you're selling millions) circumstances bricks consoles. We're seeing some people report bricks, and probably a sizable number worldwide, but still a small fraction (<1%) of the total Wii owners performing the update. Keep in mind that 1% is ~600000 consoles. That's a lot of consoles, but still 1%.
Contrast that to many of the tools I'm talking about, which under many (common) circumstances will brick consoles 100% of the time, simply due to the complete lack of error checking and general developer cluelessness. Some of the best ones are the tools that patch your System Menu IOS (meant to play copied games from DVD directly from the System Menu). A whole bunch of those started bricking all Wiis after the 4.2 update, because Nintendo updated to a different IOS number and stubbed out the old IOS. The tool would blindly grab the latest version (note that there's a way to specify an older version!), then attempt to patch it (and fail, because there's nothing to patch, but ignore the failure and go on!), then install it (overwriting the good copy that the system requires to boot!) while keeping the old System Menu that requires it, resulting in an instantaneous brick. Would it really have been that hard to 1) use a known good version or punt, 2) check that you really got the version you want, 3) actually abort when things to wrong instead of happily playing along and bricking a console? I think most people writing these tools just haven't learned about function return values.
There's also that firmware downgrader out there that managed to provoke bricks when Nintendo's updater was run afterwards; I still have no clue how they managed to pull that off, but it's probably related to using insane version numbers. Not that it matters, anyway; downgrading sounds great if you're coming from a PSP background, but it's an absolutely ridiculously bad idea on a Wii. They're two completely different system architectures.
Then there are the so-called "user failures". An extremely typical one is installing a cIOS as System Menu IOS manually, then uninstalling it. Installing it replaces your current system firmware, and uninstalling it deletes your system firmware. User error? Perhaps, but did the author of the installer tool not even think of adding a warning before, oh, I don't know, deleting your firmware? Not to mention that it's the natural thing to attempt if you don't know any better ("I installed a patch, so I'll uninstall it"), and precious few bits of documentation mention this "feature".
The bottom line is that just about every single one of these tools is written in a pinch, using copy and pasted code, and with zero attempt to analyze what's really going on and what the consequences may be in the future (and don't even bother mentioning user-friendliness or idiot-proofness). People just patch and tweak and mess with things until they work, and completely ignore what might happen in the future. This is how you get ridicuous things like cIOSCO
My personal experience is that the vast majority of people using these tools are teenagers and young adults who want free games. I've had several heated debates on the subject and I could count on my fingers the number of people with whom I've been able to have a coherent conversation and who succesfully defended a point of using these tools for legitimate backup or convenience purposes. Oh, sure, many people will shout around the term "backup", but all you have to do is spend a few days around "backup" forums to realize that it's all a thin veil. I find especially hilarious the use of the term for Virtual Console and WiiWare copies, when Nintendo already provides a perfectly good way of backing up your titles (copy them to an SD card) and scratched discs and drive issues don't apply. These are the same people loading disc "backups".
The downside to using USB loaders (and the like) is that they're written, supported, and/or documented by said idiotic teenagers, and they have little to no clue how the Wii actually works. I have a personal statistic of over 70 people actively e-mailing me (for no particular reason - I haven't put out a call or anything) because their Wiis were bricked due to bugs and failures of tools for and related to loading copies. For comparison, I've yet to hear of a single person being bricked by regular functional (non-system modifying) homebrew plus the Homebrew Channel, BootMii, DVDX, and the exploits needed to install them (this includes software that lets you load out-of-region software, but not copies). Making the jump from using homebrew to using homebrew to play copies gets you a very significant increase in the chances of bricking your Wii.
I said tricks to bypass copy protection, not tricks to bypass region encoding. Region encoding is usually a separate affair (not so much on the PS2, but on the Wii it is), and bypassing regions is actively condoned and encouraged by the (non-warez-supporting) homebrew community. In fact, bypassing regions can be done using simple tools on the Wii (heck, even I wrote a simple region-free game loader a month ago or so), while playing copies requires deeper firmware hacks (and these are usually written by clueless idiots, which puts your Wii at a significant bricking risk).
Even more importantly, Wii modchips are (as of 4.2) completely useless to bypass region encoding (because they started using the region bits in the RSA-signed area), which means that as of the latest firmware modchips are used to play copies 100% of the time and region bypassing is no longer possible or a valid excuse (whether those copies are legitimate backups or not is a separate issue).
You mean it still can't run warez and it can't run unlimited homebrew with access to all the hardware. Other OS mode offers a quite reasonable subset that keeps a sizable proportion of the homebrew community happy. Except on the newer PS3 Slim, and my bet is Sony's move to ditch Other OS will get their full OS hacked sooner now.
Au contraire, experience with game consoles suggests the opposite: hardware hackers wanting to run their own firmware will still do so (and with complex systems like these there will be holes), and then people who want to work around the DRM will piggyback on their efforts. The most notable difference will be that the latter will be those wanting to freely use their media (since people who just want to get free movies will just download them from the internet as they do today, sans DRM), while >90% of people using homebrew hacks to bypass console copy protection are in it for the warez games, which they can't run at all otherwise (non-DRMed media will play anywhere, but warez games will only play on a hacked console, emulators notwithstanding). Or in other words, this will make the resulting hacks somewhat more legit than game console hacks.
Re:Is the newest version deployed everywhere?
on
GSM Decryption Published
·
· Score: 2, Insightful
Security experts get to roll their own cryptography, publish it, have it reviewed for years by many other security experts, and eventually it might be deemed secure.
Rolling your own and using it yourself is a guaranteed failure.
MPlayer SVN-r29463-4.3.2 on Linux worked fine for me. The files are pretty raw, that's true; the cuts are rough and a chunk of the beginning is missing, but most of the juicy bits are there.
It's not just for SEO purposes. Stuffing the article title into the URL is also informative for those who read the URL. Of course, that belongs inside the tag linking to it, but few formats (besides plain HTML) support anchor text that differs from the link (especially all the text-based mediums that have had hyperlinking shoehorned in by using automatic linkification).
Slashdot Mirror
What you say is true of the decoder, but the issues with insane software demands do affect even large CPUs significantly. The percentage of the CPU dedicated to instruction decoding can go down as you increase the amount of execution units etc., but x86 CPUs still have to dedicate a lot of chip routing and logic to the (many) "special cases" that software might demand yet are incompatible with modern CPU optimizations. Things like snooping writes in case the CPU needs to invalidate a TLB, etc. As you add complexity, you have to keep adding these special cases and workarounds for things that were once implicit in older, more trivial CPUs. These things don't scale down when you add complexity; instead, they come along with complexity that you add. I wouldn't be surprised if up to 25% of the silicon area of a modern x86 chip could be shaved off if only the ISA requirements on the software were more like those of PowerPC or ARM (not the ISA itself, just the requirements and limitations on what the software can and can't do).
Thumb is implemented as a layer on top of ARM (at least last I checked), so usually the ARM decoder will still be active while in Thumb mode. However, Thumb and Thumb-2 are essentially compressed versions of ARM, so the vast majority of the decoder can be shared. The combined decoder for a modern ARM CPU is still much simpler and better performing than the decoder for an x86 CPU.
Another large advantage is that ARM programs by definition do not use things like self-modifying code without informing the CPU (i.e. issuing a dcache store and an icache invalidate). This means that ARM CPUs can be essentially Harvard architecture machines and they practically don't need any snooping logic for the caches. x86 CPUs always have to watch for insane things like an instruction modifying the instruction immediately after it in the pipeline, while that doesn't even work at all on ARM (you need the aforementioned flush/invalidate plus a write barrier and whatnot). Having CPUs impose these kinds of (reasonable) demands on the software is a very good thing for performance.
The x86 CISC instruction set is so convoluted and ancient that x86 CPUs spend a lot of die area (and power) dealing with it and the weird ways that extensions have been tacked over time. The fact that it's old also means the CPU requires tons of logic because the instruction set was designed for simpler, less well performing CPUs. Newer techniques to speed things up usually work best with software support, while x86 CPUs have to implement these older techniques and then add a compatibility layer to make them work seamlessly with the old instruction set and old OSes that know nothing about them.
One large difference between ARM and x86 that people rarely realize is that ARM only (usually) guarantees compatibility at the application (usermode) level, while x86 has to maintain compatibility down to the OS (kernelmode) level. ARM is free to update their architecture, add features required for modern performance, and require that the OS deal with them. This is hardly an issue because OSes adapt fast these days and the ARM market has no dependency on ancient OSes. x86 still has to deal with the fact that some nutjob might want to run Windows 3.11. Even when x86 does implement newer stuff, like the SYSCALL and SYSRET instructions that aim to replace the ancient and slow software interrupt system call mechanism, OSes are slow to adapt and the CPU still has to carry around the logic for the old crap. Forever.
Here we have a platform where there is no reason whatsoever to have an ass-backwards-compatible architecture in order to run legacy Windows apps. There is zero reason to use x86 here other than marketing and Intel. Please go away, we're perfectly happy with a modern RISC architecture (ARM), thank you very much.
Here's to hoping that ARM will permeate its way up into the netbook market and beyond, instead of the other way around. We've been tortured by x86 long enough already.
One thing you can (very barely) do with mine is determine the location of the sound. By which I mean the audio is delayed by about one sample between channels if the audio comes from a point directly to one side of the laptop (and which channel lags depends on which side). This is how I convinced myself that it really was a stereo sum/difference signal and there were two mics. See the math here: one 48kHz sample is about 7mm. The only way to actually tell of course is to make a sharp click by banging together some metal objects or something; only then can you clearly see that one channel is ahead of the other.
Of course, if the mics actually were on opposite sides of the laptop you could try some reasonably interesting tricks, but at 1cm separation it's all but useless.
Fine, Mr. Pedantic, it's probably a MEMS Single-Chip Microphone and Sigma-Delta Encoder with Pulse Density Modulation output.
Trivia: in my laptop, they actually put two of them side by side (about 1cm separation) for an absolutely worthless version of stereo. Worse, the ALC889 chip on the laptop insists on sending it to software as a sum/difference signal. I managed to find a secret vendor register bit that will throw away the difference part and pipe the sum (average) signal to both L and R though, so if you have an Acer Aspire 8930G and you run Linux your front microphone will work normally as a regular mono mic.
Really thin PCB traces almost qualify ;)
(Hey, it's better than nothing at all!)
Acer uses digital microphones (at least on my Aspire, anyway, so I assume they do on these recalled laptops too). Typical electret analog mics require power, but it's delivered via a resistor on top of the audio path, so it's safe if short circuited. Digital mics have a separate power connection. They probably hooked this up to a system power bus (5V/3.3V/whatever) with no current protection. The current available on these buses will easily feed a short circuited thin wire, which will cause significant heating.
Sounds like someone at Acer needs to learn to put safety fuses between power domains, especially when you're feeding power from a fat power bus into a tiny wire.
For what it's worth, we've been messing around with Vodafone UK's femtocell (they call it the Access Gateway) and successfully made it work in Germany by piping its connection through an OpenVPN to a server in the UK. This one doesn't have GPS, though it does have a GSM modem that can theoretically pinpoint the country and nearby cells, though they don't appear to use it (properly) yet.
The OpenBSC (!=OpenBTS) guys did it at HAR and this year's 26C3 too.
I may be wrong, but I was under the impression that the PIN is used to pair, and pairing establishes link keys that are then used to secure the communications. My assumption is that there's a randomized element to these keys, such that someone eavesdropping the pairing process would probably be able to get them, but not someone who eavesdrops a session after the devices have been paired.
DECT phones (which are pretty popular in Europe, not so sure about the USA) do have encryption. I believe it's been broken, but at least they tried. Same with Bluetooth.
No, but don't count on UMTS being free of issues either.
There's no "trick" to work with locked phones. GSM has no network-side authentication, so all you have to do is impersonate your carrier's network (this is trivial). But I can't imagine this being in line with regulations. Another issue is that encryption does not work unless you're a carrier and share a secret with the phone's SIM, which means that invariably your calls will be broadcast in the clear when you're using this device.
I'm not entirely sure this is a good idea. Femtocells are great, but impersonating carriers gets you into all sorts of sticky issues.
.
Good job living under a rock. ARP replay attacks have been able to break into just about any WEP network with any traffic for quite a while now. All you need is a single ARP packet and you win.
You mean the one I have repeatedly described as broken, and which I knew would brick consoles even before it came out because I've run their boot2 update function under an emulator and realized how broken it was? I'm definitely not excusing Nintendo for that one by any stretch. They fucked it up bigtime.
The fact that Nintendo screwed up the boot2 update code and then decided to force a boot2 update onto users is orthogonal to this discussion, unless you're trying to compare it to the brickage risk of using the completely moronic tools involved in playing copied games, in which case I can guaran-damn-tee that the risk of being bricked by 4.2 is ridiculously lower than that of being bricked by those tools. Just think about the statistics of the matter for a second: Nintendo screwed up a bootloader update, which under some rare (but definitely relevant when you're selling millions) circumstances bricks consoles. We're seeing some people report bricks, and probably a sizable number worldwide, but still a small fraction (<1%) of the total Wii owners performing the update. Keep in mind that 1% is ~600000 consoles. That's a lot of consoles, but still 1%.
Contrast that to many of the tools I'm talking about, which under many (common) circumstances will brick consoles 100% of the time, simply due to the complete lack of error checking and general developer cluelessness. Some of the best ones are the tools that patch your System Menu IOS (meant to play copied games from DVD directly from the System Menu). A whole bunch of those started bricking all Wiis after the 4.2 update, because Nintendo updated to a different IOS number and stubbed out the old IOS. The tool would blindly grab the latest version (note that there's a way to specify an older version!), then attempt to patch it (and fail, because there's nothing to patch, but ignore the failure and go on!), then install it (overwriting the good copy that the system requires to boot!) while keeping the old System Menu that requires it, resulting in an instantaneous brick. Would it really have been that hard to 1) use a known good version or punt, 2) check that you really got the version you want, 3) actually abort when things to wrong instead of happily playing along and bricking a console? I think most people writing these tools just haven't learned about function return values.
There's also that firmware downgrader out there that managed to provoke bricks when Nintendo's updater was run afterwards; I still have no clue how they managed to pull that off, but it's probably related to using insane version numbers. Not that it matters, anyway; downgrading sounds great if you're coming from a PSP background, but it's an absolutely ridiculously bad idea on a Wii. They're two completely different system architectures.
Then there are the so-called "user failures". An extremely typical one is installing a cIOS as System Menu IOS manually, then uninstalling it. Installing it replaces your current system firmware, and uninstalling it deletes your system firmware. User error? Perhaps, but did the author of the installer tool not even think of adding a warning before, oh, I don't know, deleting your firmware? Not to mention that it's the natural thing to attempt if you don't know any better ("I installed a patch, so I'll uninstall it"), and precious few bits of documentation mention this "feature".
The bottom line is that just about every single one of these tools is written in a pinch, using copy and pasted code, and with zero attempt to analyze what's really going on and what the consequences may be in the future (and don't even bother mentioning user-friendliness or idiot-proofness). People just patch and tweak and mess with things until they work, and completely ignore what might happen in the future. This is how you get ridicuous things like cIOSCO
My personal experience is that the vast majority of people using these tools are teenagers and young adults who want free games. I've had several heated debates on the subject and I could count on my fingers the number of people with whom I've been able to have a coherent conversation and who succesfully defended a point of using these tools for legitimate backup or convenience purposes. Oh, sure, many people will shout around the term "backup", but all you have to do is spend a few days around "backup" forums to realize that it's all a thin veil. I find especially hilarious the use of the term for Virtual Console and WiiWare copies, when Nintendo already provides a perfectly good way of backing up your titles (copy them to an SD card) and scratched discs and drive issues don't apply. These are the same people loading disc "backups".
The downside to using USB loaders (and the like) is that they're written, supported, and/or documented by said idiotic teenagers, and they have little to no clue how the Wii actually works. I have a personal statistic of over 70 people actively e-mailing me (for no particular reason - I haven't put out a call or anything) because their Wiis were bricked due to bugs and failures of tools for and related to loading copies. For comparison, I've yet to hear of a single person being bricked by regular functional (non-system modifying) homebrew plus the Homebrew Channel, BootMii, DVDX, and the exploits needed to install them (this includes software that lets you load out-of-region software, but not copies). Making the jump from using homebrew to using homebrew to play copies gets you a very significant increase in the chances of bricking your Wii.
I said tricks to bypass copy protection, not tricks to bypass region encoding. Region encoding is usually a separate affair (not so much on the PS2, but on the Wii it is), and bypassing regions is actively condoned and encouraged by the (non-warez-supporting) homebrew community. In fact, bypassing regions can be done using simple tools on the Wii (heck, even I wrote a simple region-free game loader a month ago or so), while playing copies requires deeper firmware hacks (and these are usually written by clueless idiots, which puts your Wii at a significant bricking risk).
Even more importantly, Wii modchips are (as of 4.2) completely useless to bypass region encoding (because they started using the region bits in the RSA-signed area), which means that as of the latest firmware modchips are used to play copies 100% of the time and region bypassing is no longer possible or a valid excuse (whether those copies are legitimate backups or not is a separate issue).
You mean it still can't run warez and it can't run unlimited homebrew with access to all the hardware. Other OS mode offers a quite reasonable subset that keeps a sizable proportion of the homebrew community happy. Except on the newer PS3 Slim, and my bet is Sony's move to ditch Other OS will get their full OS hacked sooner now.
Au contraire, experience with game consoles suggests the opposite: hardware hackers wanting to run their own firmware will still do so (and with complex systems like these there will be holes), and then people who want to work around the DRM will piggyback on their efforts. The most notable difference will be that the latter will be those wanting to freely use their media (since people who just want to get free movies will just download them from the internet as they do today, sans DRM), while >90% of people using homebrew hacks to bypass console copy protection are in it for the warez games, which they can't run at all otherwise (non-DRMed media will play anywhere, but warez games will only play on a hacked console, emulators notwithstanding). Or in other words, this will make the resulting hacks somewhat more legit than game console hacks.
Security experts get to roll their own cryptography, publish it, have it reviewed for years by many other security experts, and eventually it might be deemed secure.
Rolling your own and using it yourself is a guaranteed failure.
MPlayer SVN-r29463-4.3.2 on Linux worked fine for me. The files are pretty raw, that's true; the cuts are rough and a chunk of the beginning is missing, but most of the juicy bits are there.
The NY Times article is missing quite a lot detail. Slashdot users might appreciate the raw video from the talk (torrent): part 1, 2, 3.
Unary. The base that you use to tell the joke need not match the base mentioned in the joke. Though it does kind of break the joke.
It's not just for SEO purposes. Stuffing the article title into the URL is also informative for those who read the URL. Of course, that belongs inside the tag linking to it, but few formats (besides plain HTML) support anchor text that differs from the link (especially all the text-based mediums that have had hyperlinking shoehorned in by using automatic linkification).