DOS had trouble growing because it was designed for real-mode operation where you added capability by wedging more stuff into a small space - it wasn't made to multitask, and they wanted to retain backward compatibility with everything.
Unix-like systems give you a lot of flexibility in letting things talk to each other, including keyboards and their substitutes, processes, etc., and they're not picky about what hardware really exists as long as it's not too weird. The critical issues for porting voice to Unix are things like making sure the scheduler has enough hard real-time support that the voice recognizer doesn't starve, working within a multi-process environment, and dealing with kernel-userspace boundaries. For instance, if your voice recognizer provides context-sensitive vocabularies, how do you keep track of which context(s) belong to which processes, and if they're in the kernel or other protected storage space, how do you pass vocabularies to them efficiently?
But most of that's pretty straightforward, and application level, and can't be worse than adding X Windows or NeWS was, and certainly not as difficult as adding TCP/IP had been.
More importantly, if you want to build voice applications, what kind of services do you think an OS will need to support them? Are they available in Linux? Do you need to add them? Is there anything big you have to get rid of to make them work? Sure, you could junk it all and use a capability-based system like the Extremely Reliable Operating System or some microkernel thing. But what do you need?
Even if the story is apocryphal, you *do* need to be careful to limit your voice commands to safe activities, because the stuff has never been 100% accurate, and at best Does What You Say, not Does What You Mean. "Oh, I Forgot C: was where the stuff lived" might also be heard as "Format C:"... So you pick a few dozen commands that you do often and that can't do major damage without at least some safewords around them.
Voicetyping things into text input boxes isn't as dangerous - so you put some wrong stuff in a paper you're writing, and it's got the usual interjections from editing and real-world interruptions and phone calls. You can edit that later.
Picking context-sensitive sets of things you actually want to talk to your computer about can be tougher...
Sigh. You'd expect that random podunkian journalists still don't know hackers from anarchists, but you'd think somebody from the Boston Glob talking to people at MIT who are explaining things to them in short little words could get the concept straight, at least for the duration of one newspaper article:-)
Unix systems do a really good job of keeping user-space processes from trashing each other, though they occasionally hog resources in ways at which the system designers didn't expect or the sysadmins didn't pay attention to soon enough. But it's still possible to crash Unix systems by messing around too much in the kernel. Linux has gotten much better than the old days, but making changes still means testing. A Virtual Machine environment, as long as it looks close enough to the real thing, can give you a convenient environment for testing kernel hacks, drivers for non-hardware-dependent pseudo-devices, and other things that may stomp around underneath the OS's hard crunchy shell.
The main reason to build a Beowulf cluster inside a system like this is just because you can. Since the internal networking is light-weight, it doesn't cost you too much.
JMS made some good points, but the basic advantages he suggests (better scheduler control, better memory allocation) really can be done by tweaking the process scheduler and memory allocation functions in the operating system, rather than massively cloning kernels. If there are limitations in the hardware (e.g. how many bits or frames of translation table space, etc.), this doesn't really get around it, but if you can already run more than 1 copy over VM, it may be easier than hacking everything that touches memory allocation. It can depend a lot on the sparseness of the virtual memory space you're trying to simulate.
While it may not do much for user space work, it would be a fun place to test kernels. You save the room-full of 1U rack-mounted boxes, and instead have lots of virtual machines you can blow away when your kernel hack fails, and it lets you test lots of different parameter combinations in parallel.
The "If one of those bottles should happen to fall" is from people who didn't like the line "take one down and pass it around" but couldn't hide the fact that they were beer bottles without killing the entire (relatively unkillable) song. So they watered it down.... 99 bottles of wimpy American beer on the wall, I suppose.
There have been other cases like this, particularly some of the UK newspaper "framing" cases, where the judges have clearly not gotten it. This was a big win, and web publishers that don't want people linking into their sites can easily enough deploy technology to prevent it, rather than going whining to judges.
You don't check to be sure that REFERER != them.com, you check that REFERER == us.com. This not only avoids the problem of them.com cheating, it means you don't have to update it when otherguys.com start siphoning your stuff too.
Alternatively, you can use cookies, or use URLs with magic numbers that are only good for a given session (or time out, or whatever).
(I forget which ticket mongers are which, so I'll refer to them as us.com and them.com, where us.com has the real information and them.com is siphoning it off.)
Or make sure your pages always include information identifying them as yours - put them in the text, or stripe the top of the images with your site info, or at least add your own advertising banners, so that the reader can figure out that it's your page they're seeing even if it's got somebody else's header frames around it.
> 3. ORBS only block proven Open Relay servers, and server which ORBS can't check.
So you're guilty _because_ you're innocent!:-)
Seriously, if the purpose of ORBS is to prevent machines from being used by SPAMMERS, and ORBS can't get in to abuse the relay as a test, then spammers can't get in to abuse it for spamming. If you've got a site that _deliberately_ blocks ORBS, either it's got some good reason to dislike the probes (e.g. the guys whose lameNT mailer crashes), or because it's running mailer protection software that interprets ORBS as a spammer's probe (good - so they're blocking real spammers too), or perhaps they provide spamming services (in which case the real problem is users with accounts there, not relays.)
Most email clients I've used try to send outgoing mail first before downloading incoming. So telling your users to check their mail first doesn't help if they're using popular POP clients like Eudora. The MSOutlook/Exchange products often do some authentication first, so they might be able to use this dodge.
At first glance, it looks like Mattel paid $1 and dropped charges in exchange for the rights to something they could have for free. But it's a bit deeper than that. Copyright protection, at least in the US, gives the owner of the copyright the power to restrict publication as well as to publish. Mattel is almost certain to NOT publish the stuff (:-), and certainly not to give the original authors the right to publish it.
The difficulty is whether they can restrict copying of copies that were downloaded before the agreement. I suspect not, though it puts them in a good position to threaten people.
I'm not a lawyer, though I have played a politician on TVp?
You probably bought the box with American Express, Visa, or Mastercard, and all of them have straightforward procedures for disputing credit card charges. If you ordered the box when the service was not mandatory, and didn't order the service, and they charged you anyway, RTFP (Read The Fine Print) on your credit card bill and follow the process. Be sure to indicate that the service was NOT mandatory at the time you ordered the box, though the company may have changed processes since then. Retail companies do NOT like having credit card companies bounce large numbers of charges on them - it costs them money, which is the opposite of what they're trying to accomplish by selling things - and credit card companies can be relatively grouchy to retailers who get lots of complaints against them.
N.B. Do wait for your hardware to arrive before complaining about the billing:-)
Gackk - Phil Collins's song from the Disney-muddled Tarzan getting the Oscar? It was ok, for the kind of characterless stuff Disney uses, but Blame Canada certainly should have beaten it.
It's a cute hack, but the legalities are the same whether you distribute the Secrets Of The DVD Masters by TV, T-Shirt, DVD, HTTP, or avian carriers. It doesn't affect the contractual status of the reverse engineering job, and it doesn't affect the legality of revealing trade secrets in countries like the US which treat it as trade-secret-because-of-contract (the cat's already out of the bag, but the person who allegedly illegally opened the bag is supposed to pay for fetching the cat and telling it to get back in the bag and stay there), and it doesn't affect the legality in countries where you can't have trade secret protection for things that aren't secret. Unlike cryptography, where part of the point was "anybody can independently invent this stuff or implement it from freely published literature, so don't claim this Offical Secrets Act crap", this is just reverse engineering of lame copy protection, allegedly violating a click-wrap contract the engineer voluntarily agreed to.
More seriously, if they accept taxes in free-form ASCII, and you've got a version of vi new enough to support umlauts (or you're willing to do EMACS), maybe it'll work. Much more likely that they'd want some kind of spreadsheet form (no macros, please!:-), or XML notation, or something that handles name/value pairs.
The other obvious format is bitmap, e.g. G3 Fax or GIF (if they've fixed the patent silliness), or PBM/PNM/etc.
Somebody beat me to the Al Gore joke:-) On the other hand, Al does stop by here in the Valley to do fundraisers, as well as to let Tipper play drums with the Grateful Dead. There are various efforts to get Silicon Valley types involved in Washington, i.e. give money to Democrats and Republicans, and there's gradually increasing momentum for Valley-based lobbying on issues such as Immigration for high-tech workers, software piracy, crypto exports, and export policy in general. There's a major conflict in lobbying between the entertainment side of the industry and the software-development side of the industry on copyrights and patents, and so far the Big Mouse has been winning over the mouse users. Some of the local Congresscritters have figured out that we're their major constituents, and work hard on valley issues; Zoe Lofgren and Anna Eschoo in particular.
A few Silicon Valley moneymakers have been using their money for more traditional politics, beyond industry-related issues. Unfortunately, the prime examples have been Ron Unz (:-) and of course Larry Ellison's work on Airplane Rights.
Jim Warren has done a lot of good work on the State of California government, particularly on electronic open access to state government data and state legislative activities, and he's one of the main reasons we have the access that we do. Jim gave a talk to the Cypherpunks group a few years ago - one of his big points was that state legislators respond quite well to written letters, and it only takes a few dozen letters per legislative district to let them know there's public opinion that they need to follow.
Libertarianism - one of the difficulties with Silicon Valley lobbying is that most of us are libertarians - either the partisan types, or entrepreneurs and technologists who don't think bureaucrats can improve things by telling us what to do (given the evidence from experience with their incompetence and motives) (though lots of us were college students who were happy to have research grants:-), or civil libertarians who don't like the overall injustice and war that governments have delivered over the years, or at least Draft-Dodging Republicans Who Smoke Pot. That means that the most common response we have to "what can the government do to help us" is the same as it was with the French government 200 years ago - "laissez faire" - go away and leave us alone - which is at odds with government's desire to grow and expand its bureaucratic activities.
Also, doing real politics is a lot of work, and most of us are pretty busy doing other things.
The EFF www.eff.org has been around for about 10 years now! It's primarily dealt with civil liberties issues - court cases on censorship and crypto export, court cases for accused "hackers", lobbying against really bad proposed laws such as the FBI's constant wiretapping proposals, Clipperphones, crypto export laws, keeping up to speed on Copyright and Patent law changes, etc. They'er starting to address privacy laws, a complex and rapidly-changing controversial topic.
Digital Millenium Copyright Act comments due by March 31! EFF has information here.
US crypto publishers have been able to do this since MIT talked the Feds into letting them do it. Of course, exporting crypto code on paper is so obviously covered by the 1st Amendment that the Feds didn't bother PGP exporting their source code in nice OCR-readable fonts with checksums on each page and letting a bunch of Europeans scan it:-)
Yeah, it's tacky. Blame Washington (either one, if you want)
For crypto, you've always been able to download the stuff from Finland or the Netherlands or wherever, since imports to the US aren't restricted, so you can avoid the Prove-you're-North-American routine.
The new crypto rules aren't perfect, and aren't very clearly defined, but they're clear enough that NAI is exporting PGP with the only restrictions being "Not on the US Enemies List".
The "only a few billion" comment is good, and some of the other poster's comments about it being much easier to find the sequence you're looking for by searching for the start token rather than having to sequence the whole mess are bang on as well.
The solution for securing steganography is straightforward - it's to say "it's not crypto, it 's just stego, but that can still be pretty effective" rather than saying "there's a trillion trillion possible sequences in this billion starting points, so nobody'd ever find it". So rather than hiding a plaintext message, which somebody might find, you encrypt your message with a real crypto algorithm, producing something that looks like random noise, and then if the underlying substrate you're hiding it in (whether its pictures, sounds, or DNA) looks enough like random bits, you're done; otherwise you make a model of the substrate and transform your cyphertext into that space. (Peter Wayner's paper on Mimic Functions has a really good discussion of this.) For an application like this, just getting the right ratio of nucleotides may be enough, or one or two levels of Markov chain beyond it. (Plus make sure the DNA isn't from a really popular mouse clone or whatever that somebody might have already sequenced:-) Then it does become much harder to find the cyphertext, which makes cracking it much much harder.
Dirtside said: Because the pair of primers provides a trillion trillion options, she concludes that the code is essentially unbreakable. Only in the same way that public-key encryption is unbreakable, in that you can't brute-force it in any reasonable amount of time. and randombit said something similar.
No, it's much different than that. Public-key encryption is exponentially hard, while this is just linear in the length of the chains. Computer-Crunching through a billion starting points looking for English-like sequences is a few minutes' work, though the chemical work in sequencing the whole mess is much slower. By contrast, it's easy to make a factoring job taking longer than the current age of the universe, just by making the keys a few hundred bits longer.
Shortly after Pointcast became popular at my company, the Firewall Gods had to kill it because it was swamping our links to the Internet. Now the same thing is happening to Napster. In both cases, it didn't have to, but the protocol design was designed to solve the author's scaling problems, not the users', so it was doomed. And in both cases, if they had worked with HTTP and its caching, they could have avoided most of the problem. Pointcast semi-fixed their problems by developing and selling a caching server, but it was a bandaid on a fundamentally broken protocol. We'll see if Napster and its OpenSource friends can do something similar or better, and other new services like imesh had better get the clue or they'll run into the same problems.
In the real world, most internet users are in one of two environments
Fast LAN or medium-speed WAN behind a firewall with slower outside connection
Slow dialup, concentrating large numbers of users to fast internal servers plus an Internet feed that's big but oversubscribed.
Businesses and universities are in the former model; most ISPs are the latter model, though the DSL and Cable Modem ISPs are somewhere in between. In both cases, http caching is available, and is a valuable tool for keeping most requests on the fast inner network instead of the slow connection to outside.
Napster was designed so that Napster.com's servers only handle the databases, not the bulk file transfer, which lets them handle a large number of users with manageable load (and avoid copyright blame, shifting it to the users:-) But what it ignores is the transfer of large numbers of users - which is a serious thing to ignore if you want to have zillions of users using your stuff.
University users look like business users - typically fast LANs on campus, slower connection to outside, so Napster would be no problem if most students got their MP3s from other students or a caching server at the same school, and only downloaded from outside when nobody at the school has the song they want. How would you design something like this? Here are a few possible approaches:
Give the Napster Database more information about where the client and file-sharers are, so it can show you the nearby sharers first, with something more relevant than just ping time. Even a crude measure like "same second-level domain name" helps a lot, because it keeps things in the same university or corporation.
Design a Napster Proxy/Cache Server you can install locally, and a way to find nearby servers, so you ask the cache if it's got your song instead of getting it from Napster themselves. This was easier for Pointcast to do, because their sales hook is "we're helping your employees get interesting business news, plus the occasional headline and sports score", as opposed to "we're helping your students pirate MP3s and Warez", but it's a start:-) But it can be minimal modification to the Napster protocols, with the complex work done by the proxy.
Design a "distributed proxy", which lets some random user's machine elect itself database cache in its domain or community; requires a mechanism to tell other users where to find it, but it may not be hard, and there could be interesting ways to generalize "community". It's a bti of work, and Napster needs to be sure their business model still works:-)
Use HTTP for file transfers, basically making each Napster sharer speak http, maybe on port 80 or 8080 instead of Napster's own protocols as the default. This lets web caches work automagically, though it really benefits if there's a way to get most clients at one university usually use the same few servers for each specific song they download (e.g. sharer-1 shares songs 1,2,3, sharer-2 shares 4,5,6, etc.) to maximize caching.
Other things the open source community will think up and code.
More flexible choice of port numbers, so Napster can hog ever-increasing amounts of bandwidth, choosing to be Anonymous Cowards rather than good netizens. (Hiding anonymously is fine, but the system still needs to clean up its bandwidth act as much as possible.)
I don't know how much of this is the reporting, either by the judges or the press, vs. how much is the winner's understanding of the technology involved (it sounds like it's her mistake, and the judges didn't understand it.) The idea of stashing messages in DNA is cool, and doing the actual work to build it is definitely cool stuff for a high-school student. But the crypto isn't correct.
Steganography is the art of hiding messages in things, where they aren't likely to be noticed, either because nobody'd think to look there, or because there's too much other junk for your message to stand out, or because you've done the work to make your message look similar to the background noise. The classic example is hiding a message in the low-order bits of a digitized photo image or a sound file, where they don't affect the output much, though they're usually visible if anybody looks.
Stashing a secret message in a bunch of a DNA has a good chance of "they wouldn't look there", but if they *did* decide to look in the bunch of DNA, a message like "JUNE6_INVASION: NORMANDY" probably has different enough statistics from the rest of the DNA around it that it might stand out. Sure, it's much more obvious to the intended recipient, who's looking for the specific start and end "primer" sequences, and it's also much more obvious to someone who knows the alphabet of nucleotides she's using to represent letters (as opposed to having to guess from entropy, where there'd be too many false positives.) But the conclusion "Because the pair of primers provides a trillion trillion options, she concludes that the code is essentially unbreakable" is insupportable - If you encode your message in a way that has similar statistics to the background signals/noise, you can hide it pretty well, but she's implying that straight plaintext is also unfindable there, and it's not, any more than hiding it in the low order bits of a picture is.
Nice work anyway, and it lets people make lots of entertaining comments about "Computer Viruses":-)
Hacking the Message Set; Related Devices
on
Date Pagers
·
· Score: 1
OK, so there's not much you can do with 2 bits - the mode settings are chat, fun, friend, and off/nonexistent. But if they're as cheap as Tamagothis, and a million have been sold in Japan, perhaps they'll catch on in various subcommunities here.
Dope-finder
The "Factoid" from Compaq' Western Research Labs has some similarities in the "what can you do with really cheap minimal messaging? space. It's been mentioned in Slashdot before. The main web page is http://research.compaq.com/wrl/projects/Factoid/
Slashdot Mirror
Unix-like systems give you a lot of flexibility in letting things talk to each other, including keyboards and their substitutes, processes, etc.,
and they're not picky about what hardware really exists as long as it's not too weird.
The critical issues for porting voice to Unix are things like making sure the scheduler has enough hard real-time support that the voice recognizer doesn't starve, working within a multi-process environment, and dealing with kernel-userspace boundaries. For instance, if your voice recognizer provides context-sensitive vocabularies, how do you keep track of which context(s) belong to which processes, and if they're in the kernel or other protected storage space, how do you pass vocabularies to them efficiently?
But most of that's pretty straightforward, and application level, and can't be worse than adding X Windows or NeWS was, and certainly not as difficult as adding TCP/IP had been.
More importantly, if you want to build voice applications, what kind of services do you think an OS will need to support them? Are they available in Linux? Do you need to add them? Is there anything big you have to get rid of to make them work? Sure, you could junk it all and use a capability-based system like the
Extremely Reliable Operating System
or some microkernel thing. But what do you need?
So you pick a few dozen commands that you do often and that can't do major damage without at least some safewords around them.
Voicetyping things into text input boxes isn't as dangerous - so you put some wrong stuff in a paper you're writing, and it's got the usual interjections from editing and real-world interruptions and phone calls. You can edit that later.
Picking context-sensitive sets of things you actually want to talk to your computer about can be tougher...
vandalizing computers, indeed
Unix systems do a really good job of keeping user-space processes from trashing each other, though they occasionally hog resources in ways at which the system designers didn't expect or the sysadmins didn't pay attention to soon enough. But it's still possible to crash Unix systems by messing around too much in the kernel. Linux has gotten much better than the old days, but making changes still means testing. A Virtual Machine environment, as long as it looks close enough to the real thing, can give you a convenient environment for testing kernel hacks, drivers for non-hardware-dependent pseudo-devices, and other things that may stomp around underneath the OS's hard crunchy shell.
JMS made some good points, but the basic advantages he suggests (better scheduler control, better memory allocation) really can be done by tweaking the process scheduler and memory allocation functions in the operating system, rather than massively cloning kernels. If there are limitations in the hardware (e.g. how many bits or frames of translation table space, etc.), this doesn't really get around it, but if you can already run more than 1 copy over VM, it may be easier than hacking everything that touches memory allocation. It can depend a lot on the sparseness of the virtual memory space you're trying to simulate.
While it may not do much for user space work, it would be a fun place to test kernels. You save the room-full of 1U rack-mounted boxes, and instead have lots of virtual machines you can blow away when your kernel hack fails, and it lets you test lots of different parameter combinations in parallel.
The "If one of those bottles should happen to fall" is from people who didn't like the line "take one down and pass it around" but couldn't hide the fact that they were beer bottles without killing the entire (relatively unkillable) song. So they watered it down
Shut one down,
Fork off another,
41000 bottles of penguin soup on the wall.
There have been other cases like this, particularly some of the UK newspaper "framing" cases, where the judges have clearly not gotten it. This was a big win, and web publishers that don't want people linking into their sites can easily enough deploy technology to prevent it, rather than going whining to judges.
This not only avoids the problem of them.com cheating, it means you don't have to update it when otherguys.com start siphoning your stuff too.
Alternatively, you can use cookies, or use URLs with magic numbers that are only good for a given session (or time out, or whatever).
(I forget which ticket mongers are which, so I'll refer to them as us.com and them.com, where us.com has the real information and them.com is siphoning it off.)
Or make sure your pages always include information identifying them as yours - put them in the text, or stripe the top of the images with your site info, or at least add your own advertising banners, so that the reader can figure out that it's your page they're seeing even if it's got somebody else's header frames around it.
So you're guilty _because_ you're innocent!
Seriously, if the purpose of ORBS is to prevent machines from being used by SPAMMERS, and ORBS can't get in to abuse the relay as a test, then spammers can't get in to abuse it for spamming.
If you've got a site that _deliberately_ blocks ORBS, either it's got some good reason to dislike the probes (e.g. the guys whose lameNT mailer crashes), or because it's running mailer protection software that interprets ORBS as a spammer's probe (good - so they're blocking real spammers too), or perhaps they provide spamming services (in which case the real problem is users with accounts there, not relays.)
Most email clients I've used try to send outgoing mail first before downloading incoming. So telling your users to check their mail first doesn't help if they're using popular POP clients like Eudora. The MSOutlook/Exchange products often do some authentication first, so they might be able to use this dodge.
The difficulty is whether they can restrict copying of copies that were downloaded before the agreement. I suspect not, though it puts them in a good position to threaten people.
I'm not a lawyer, though I have played a politician on TVp?
N.B. Do wait for your hardware to arrive before complaining about the billing
Gackk - Phil Collins's song from the Disney-muddled Tarzan getting the Oscar? It was ok, for the kind of characterless stuff Disney uses, but Blame Canada certainly should have beaten it.
It's a cute hack, but the legalities are the same whether you distribute the Secrets Of The DVD Masters by TV, T-Shirt, DVD, HTTP, or avian carriers. It doesn't affect the contractual status of the reverse engineering job, and it doesn't affect the legality of revealing trade secrets in countries like the US which treat it as trade-secret-because-of-contract (the cat's already out of the bag, but the person who allegedly illegally opened the bag is supposed to pay for fetching the cat and telling it to get back in the bag and stay there), and it doesn't affect the legality in countries where you can't have trade secret protection for things that aren't secret. Unlike cryptography, where part of the point was "anybody can independently invent this stuff or implement it from freely published literature, so don't claim this Offical Secrets Act crap", this is just reverse engineering of lame copy protection, allegedly violating a click-wrap contract the engineer voluntarily agreed to.
The other obvious format is bitmap, e.g. G3 Fax or GIF (if they've fixed the patent silliness), or PBM/PNM/etc.
On the other hand, Al does stop by here in the Valley to do fundraisers, as well as to let Tipper play drums with the Grateful Dead. There are various efforts to get Silicon Valley types involved in Washington, i.e. give money to Democrats and Republicans, and there's gradually increasing momentum for Valley-based lobbying on issues such as Immigration for high-tech workers, software piracy, crypto exports, and export policy in general. There's a major conflict in lobbying between the entertainment side of the industry and the software-development side of the industry on copyrights and patents, and so far the Big Mouse has been winning over the mouse users. Some of the local Congresscritters have figured out that we're their major constituents, and work hard on valley issues; Zoe Lofgren and Anna Eschoo in particular.
A few Silicon Valley moneymakers have been using their money for more traditional politics, beyond industry-related issues. Unfortunately, the prime examples have been Ron Unz (:-) and of course Larry Ellison's work on Airplane Rights.
Jim Warren has done a lot of good work on the State of California government, particularly on electronic open access to state government data and state legislative activities, and he's one of the main reasons we have the access that we do. Jim gave a talk to the Cypherpunks group a few years ago - one of his big points was that state legislators respond quite well to written letters, and it only takes a few dozen letters per legislative district to let them know there's public opinion that they need to follow.
Libertarianism - one of the difficulties with Silicon Valley lobbying is that most of us are libertarians - either the partisan types, or entrepreneurs and technologists who don't think bureaucrats can improve things by telling us what to do (given the evidence from experience with their incompetence and motives) (though lots of us were college students who were happy to have research grants :-), or civil libertarians who don't like the overall injustice and war that governments have delivered over the years, or at least Draft-Dodging Republicans Who Smoke Pot. That means that the most common response we have to "what can the government do to help us" is the same as it was with the French government 200 years ago - "laissez faire" - go away and leave us alone - which is at odds with government's desire to grow and expand its bureaucratic activities.
Also, doing real politics is a lot of work, and most of us are pretty busy doing other things.
Separate reply on EFF
Digital Millenium Copyright Act comments due by March 31! EFF has information here.
If the tape goes bad, you can even use it to wrap up the drive and mail it back for repair :-)
People who run mirros deserve a little extra credit on occasion
Yeah, it's tacky. Blame Washington (either one, if you want)
For crypto, you've always been able to download the stuff from Finland or the Netherlands or wherever, since imports to the US aren't restricted, so you can avoid the Prove-you're-North-American routine.
The new crypto rules aren't perfect, and aren't very clearly defined, but they're clear enough that NAI is exporting PGP with the only restrictions being "Not on the US Enemies List".
The solution for securing steganography is straightforward - it's to say "it's not crypto, it
's just stego, but that can still be pretty effective" rather than saying "there's a trillion trillion possible sequences in this billion starting points, so nobody'd ever find it". So rather than hiding a plaintext message, which somebody might find, you encrypt your message with a real crypto algorithm, producing something that looks like random noise, and then if the underlying substrate you're hiding it in (whether its pictures, sounds, or DNA) looks enough like random bits, you're done; otherwise you make a model of the substrate and transform your cyphertext into that space. (Peter Wayner's paper on Mimic Functions has a really good discussion of this.) For an application like this, just getting the right ratio of nucleotides may be enough, or one or two levels of Markov chain beyond it. (Plus make sure the DNA isn't from a really popular mouse clone or whatever that somebody might have already sequenced
Then it does become much harder to find the cyphertext, which makes cracking it much much harder.
Dirtside said:
Because the pair of primers provides a trillion trillion options, she concludes that the code is essentially unbreakable.
Only in the same way that public-key encryption is unbreakable, in that you can't brute-force it in any reasonable amount of time.
and randombit said something similar.
No, it's much different than that. Public-key encryption is exponentially hard, while this is just linear in the length of the chains. Computer-Crunching through a billion starting points looking for English-like sequences is a few minutes' work, though the chemical work in sequencing the whole mess is much slower. By contrast, it's easy to make a factoring job taking longer than the current age of the universe, just by making the keys a few hundred bits longer.
In the real world, most internet users are in one of two environments
- Fast LAN or medium-speed WAN behind a firewall with slower outside connection
- Slow dialup, concentrating large numbers of users to fast internal servers plus an Internet feed that's big but oversubscribed.
Businesses and universities are in the former model; most ISPs are the latter model, though the DSL and Cable Modem ISPs are somewhere in between. In both cases, http caching is available, and is a valuable tool for keeping most requests on the fast inner network instead of the slow connection to outside.Napster was designed so that Napster.com's servers only handle the databases, not the bulk file transfer, which lets them handle a large number of users with manageable load (and avoid copyright blame, shifting it to the users :-) But what it ignores is the transfer of large numbers of users - which is a serious thing to ignore if you want to have zillions of users using your stuff.
University users look like business users - typically fast LANs on campus, slower connection to outside, so Napster would be no problem if most students got their MP3s from other students or a caching server at the same school, and only downloaded from outside when nobody at the school has the song they want. How would you design something like this? Here are a few possible approaches:
- Give the Napster Database more information about where the client and file-sharers are, so it can show you the nearby sharers first, with something more relevant than just ping time. Even a crude measure like "same second-level domain name" helps a lot, because it keeps things in the same university or corporation.
- Design a Napster Proxy/Cache Server you can install locally, and a way to find nearby servers, so you ask the cache if it's got your song instead of getting it from Napster themselves. This was easier for Pointcast to do, because their sales hook is "we're helping your employees get interesting business news, plus the occasional headline and sports score", as opposed to "we're helping your students pirate MP3s and Warez", but it's a start
:-) But it can be minimal modification to the Napster protocols, with the complex work done by the proxy. - Design a "distributed proxy", which lets some random user's machine elect itself database cache in its domain or community; requires a mechanism to tell other users where to find it, but it may not be hard, and there could be interesting ways to generalize "community". It's a bti of work, and Napster needs to be sure their business model still works
:-) - Use HTTP for file transfers, basically making each Napster sharer speak http, maybe on port 80 or 8080 instead of Napster's own protocols as the default. This lets web caches work automagically, though it really benefits if there's a way to get most clients at one university usually use the same few servers for each specific song they download (e.g. sharer-1 shares songs 1,2,3, sharer-2 shares 4,5,6, etc.) to maximize caching.
- Other things the open source community will think up and code.
- More flexible choice of port numbers, so Napster can hog ever-increasing amounts of bandwidth, choosing to be Anonymous Cowards rather than good netizens. (Hiding anonymously is fine, but the system still needs to clean up its bandwidth act as much as possible.)
Remember, only YOU can prevent broadcast stormsSteganography is the art of hiding messages in things, where they aren't likely to be noticed, either because nobody'd think to look there, or because there's too much other junk for your message to stand out, or because you've done the work to make your message look similar to the background noise. The classic example is hiding a message in the low-order bits of a digitized photo image or a sound file, where they don't affect the output much, though they're usually visible if anybody looks.
Stashing a secret message in a bunch of a DNA has a good chance of "they wouldn't look there", but if they *did* decide to look in the bunch of DNA, a message like "JUNE6_INVASION: NORMANDY" probably has different enough statistics from the rest of the DNA around it that it might stand out. Sure, it's much more obvious to the intended recipient, who's looking for the specific start and end "primer" sequences, and it's also much more obvious to someone who knows the alphabet of nucleotides she's using to represent letters (as opposed to having to guess from entropy, where there'd be too many false positives.) But the conclusion "Because the pair of primers provides a trillion trillion options, she concludes that the code is essentially unbreakable" is insupportable - If you encode your message in a way that has similar statistics to the background signals/noise, you can hide it pretty well, but she's implying that straight plaintext is also unfindable there, and it's not, any more than hiding it in the low order bits of a picture is.
Nice work anyway, and it lets people make lots of entertaining comments about "Computer Viruses"
It's the Progressive Image Group, at
http://www.pig.com
Dope-finder
The "Factoid" from Compaq' Western Research Labs has some similarities in the "what can you do with really cheap minimal messaging? space.
It's been mentioned in Slashdot before.
The main web page is
http://research.compaq.com/wrl/projects/Factoid