In the first DVD case, in California in January 2000, the plaintiffs brought suit against Frank Stevenson, who wrote one of the programs, and some web sites that carried the program, and a large number of people (500 John Does) who linked to the program, either on their web sites or on Slashdot. The suit against the linkers was tossed out, though the suit against the authors succeeded, and I think the web sites were told to take it down. (The source code TShirts worn by many attendees weren't enjoined:-)
Emmanuel Goldstein is a special case, because he had originally been hosting the material, and replacing that with a link to material now posted elsewhere aftern you've been ordered not to post the material yourself tends (in the few cases that have addressed the issue) to be viewed differently than just having a link.
One of the arguments used in court to throw out the Communications Decency Act and its progeny was that censoring the net is a massive-overkill approach to protecting kids, when the same objective can be obtained by less restrictive means, such as filters. The least-restrictive-means test is a big hammer in freedom-of-speech law and court decisions about it. The courts did apparently gloss over the issue of whether filters should be used by parents who want them, or mandated by governments, particularly for libraries and schools, but perhaps also for ISPs.
Some Feds, pro-censorship groups, and of course censorware vendors have been using this to force public libraries to install filters, and one of the main arguments used in opposition (besides the obvious "censorship is UnAmerican and UnLibrarian") is that existing censorware products usually block too many things, either through clumsiness (like blocking "breast cancer") or not-very-hidden agendas, like blocking feminist sites.
But some Feds have recently been getting sneaky - they're going to the people who made these arguments, and asking them things like "So this censorware stuff you said was less restrictive isn't working, and isn't usable in public libraries? Would you be interested in testifying in court as an expert witness?". It looks like they may be trying to overthrow the least-restrictive-means argument, by contending that filters aren't that much less restrictive, and trying to Catch-22 us into letting them censor the net like they tried to before.
Peacefire is the group that was sued for revealing Cyberpatrol's blacklist, but also for publishing the password-cracker that lets you get around Cyberpatrol's restrictions.
The EFF archives on filtering are at
this link on eff.org, but they're a bit out of date (unless you believe the year is "19100":-).
The Censorware Project is more recent.
A reasonable fraction of the many blatant errors in Cyberpatrol's agenda need to be "explained by incompetence rather than attributed to malice"; classifying everything on the net is an impossibly large job, much of the gruntwork gets done by bots with only minimal accuracy, and there's certainly not enough time for real human attention to most of it. That doesn't excuse their lack of fixing problems they've been notified about, or the biases that do appear to be in that product and in many others. "Hackers" - oh, nooo! keep your kids away from them!
The referenced article has its mistakes as well - the Libertarian Party may occasionally be accused of being Republicans who smoke dope, and some of its members are, but that's pretty much a mischaracterization:-) It'd be much more accurate to classify most of the members as computer geeks who don't do real politics because that involves talking to non-geeky people in a way that's interesting to them and doing a lot of plain boring time-consuming hard work like precinct-walking.
A friend of mine was at the University of Colorado back in the late 70s. They had an infrared laser connecting two of their computer buildings - it went out the window of one to the rooftop of the other, and worked quite reliably. There was a bit of rain and snow fade, but it was reasonably tolerant, and it's on a relatively dry side of the mountains. Then one day the window broke. The laser system survived this... until the workman came and put a piece of plywood over the broken window:-)
The computer system, being the fine piece of 70s mainframe gear it was, crashed hard, and the computer center folks had trouble explaining to the guy that he couldn't put that plywood there because there was an invisible laser beam going right where he was standing....
OC12 line-o-sight is great. Unfortunately, the Center Of The Internet is the San Francisco Bay Area, aka Fog City, so one of the places it would be most useful you can't use it:-)
In practice, San Jose doesn't have anywhere near as much fog problem, and a 500-meter distance could connect the PacBell/ATT POP with the AboveNet/UUNet/MFS POP, though there are bundles of OC48 fiber under the street that do the job just fine.
The Justice Department and Microsoft have ratified a settlement proposal originally proposed April 1. Bill Gates is buying the Federal Government 2 million Macintoshes. The government agrees to stop using Microsoft operating systems and to leave Microsoft alone. Gates was quoted as saying "It's a Win-Win deal. The wholesale cost of the Macs is less than the drop the value of *MY* MS stock holdings since the previous announcement, and the Feds can go hassle\\\\\\negotiate with Steve Jobs for a while."
Spokespersons from the General Services Administration indicated that most Federally-owned Intel-based PCs will be donated to public schools, helping to bridge the Digital Divide, and users who need to retain the hardware for special applications can either install Linux or FreeBSD. "This historic arrangement will also allow us to deploy Posix-compliant software on the most common end-user platforms in Federal use, which we've been trying to mandate for 10 years."
A few details are not yet finalized, such as obtaining Sony Playstation 2 hardware for users needing supercomputer capability who don't want the non-exportable Mac G4 configurations.
Remember that having GSM voice doesn't necessarily mean that a country or region has GSM data, and you'll pay by the minute, but it does go pretty much everywhere outside the US.
AT&T Global Networks is the former IBM Global Network. (shameless plug for my employer). Directly provided IP dial service in most major locations, about 1500 POPs worldwide, about 1000 outside US. Fancy dialer if you're using Win9x, but you can also download the phone number list for Linux, etc.
iPass is an international partnership of ISPs - you dial into a local ISP, and your ISP will bill you some hourly surcharge. The surcharge may depend radically on the particular package your ISP obtains from iPass, and your ISP may also charge a monthly fee for access to it, so if you've got more than one ISP, check their offers.
GRIC is a different international partnership of ISPs, similar to iPass.
I've heard AOL offers some international dialup as well, but I don't know the extent.
Does Equant offer any dial service to the public, or only its members? It's tied in to an airport-industry partnership, and some part of the company provides network services worldwide, generally concentrated near airports (which may or may not be local calls to the major metropolitan areas.)
Sure, it's a brand you've never heard of, only 640x480, doesn't have a flash, and uses a serial interface to the computer. But it's good enough to put pictures on your web site, and the price is close enough to disposable that you can just get one if you don't have a digital camera without deciding whether it's the right camera for you to spend real money on. Some of them come packaged as cameras; some come packaged as image editing software that throws in a camera, and maybe costs a few bucks more.
I haven't tried it - I've got a $99 Toshiba I'll comment on separately.
Dividing Work Between Main CPUs and Peripherals
on
WinDSL Coming?
·
· Score: 3
Whenever you divide work between different boxes, you've got to think about what functions you need to perform, and what resources you'll consume performing them, and what resources you'll consume with the communciation, which is often the hard part unless you split the work at the right place.
Electrical functions obviously belong to the DSL board.
Raw CPU speed is cheap - put a DSP on the board and you can burn all the CPU cycles you need, as long as you don't need much interrupt handling or memory bandwidth. The low-level functions belong down on the DSL board.
The handoff between the DSL board and the PC should probably be Layer 2 frames (an AAL-5 frame looks about the same as an Ethernet packet or Frame Relay frame) (unless you really *want* to hand ATM cells to the PC for some reason.) If the DSL board is internal to the PC, this is clean and easy; if it's external, you either need some kind of Ethernet bridging (#insert risk-of-non-standardness) or maybe a USB interface. If the DSL board is internal, and you interface at some other functional level, you need to be careful to avoid interrupting the CPU to death, starving the DSL waiting for interrupts, and otherwise being a bad neighbor.
Routing, NAT, Firewalling, and IP in general take more memory and intelligence - you could implement them in the DSL box, which is convenient for users who don't like installing hardware or complex software, but moving them to the PC isn't a bad thing - it lets you do much more sophisticated router things, and really isn't that much more work for the PC - as long as the OS has a decent IP implementation, as opposed to some highly lame non-Unix-based products out there which will remain nameless due to professional courtesy.
But DSL doesn't support the end-user's needs - it also supports the DSL carrier (Layers 1 and 2) and the ISP (Layer 3) during installation , long-term operations, and service failures.
Diagnostics for the DSL functions really need to run even if there's no working PC. Obviously an internal board needs electricity, but it's nice if some basic handshake functions can answer from a board-based controller - but it doesn't take much intelligence to do this. (On the other hand, you could also implement this in a "reboot your PC in MSDOS mode" boot floppy.) If you are running diagnostics on the PC, you either need some custom interface, or else you need to make them use the same Layer 2 packets you use for data transfer.
Diags for the IP vendor have similar issues, though you need to use them when the system is up and running. Good DHCP client support is your friend. Broadcasts and Bootp are also your friends. As long as the board allows promiscuous receiving (which may be an issue for some external devices) you can build the rest of the handshakes you need.
Diags are most critical during installation, but running a high-quality service means you need run-time support as well - things like SNMP or at least PING need to work, and periodic uploads of information like electrical line qualities can be really helpful in preventing failures.
When I'm at a customer site, the main reason I lug a heavy laptop is to give Powerpoint presentations - a PDA with a VGA port and Pocket Powerpoint and a good MSBriefcase-like file synchronizer would let me leave the laptop behind and still do calendars and read email on the train. Even a VGA PCMCIA card would do, if the PDA knew how to use it. But without the ability to talk to a monitor or projector and enough ram for the typical 4MB bloated PPT, there's no point in hauling the bigger MS apps around, and I'd much prefer a lightweight friendly PDA OS like the Palm or Psion or at least the old HP MSDOS PDAs.
My Psion 3a was a wonderful machine; just at the upper limits of "pocket-sized", but I could type at full-speed (Graffiti - arrgxx\\gh) and the apps and OS were well-though-out, convenient, and synced well with PC apps. The 9.54MHz 8086-clone was more than enough horsepower for the apps it had, though crypto could be a bit slow. Hardware was extremely durable and solid, but unfortunately you can only drop it on the floor so many times and Psion's gotten a lot less responsive to US repair customers, and the cool new wares are mostly being written for Palms anyway.
One of my friends has a Cassiopeia with the new camera, MP3 player, etc. - good toys do somewhat make up for the OS:-)
Re:laptop without screen and battery - bright idea
on
Super Tiny Espresso PC
·
· Score: 2
I work in San Francisco - half the people walking down the street are talking to themselves anyway. And the other half are on cellphones.
I've never gotten a lot of phone spam - the bulk of it was from telephone companies and newspapers, and they're pretty good about obeying don't-call-list rules. (The rules, and their databases, aren't bright enough to prevent them from calling multiple phones at the same house, but my second line is usually either busy or answers with modem tone and usually has the phone ringer turned off.) Some of the new telespam machines are pretty insidious, but the "hello... 2 second pause" usually gets them.
So beia and technopop are slashdotted - the usual fate of small companies with cool products that get mentioned here. Guess I'll just have to sit around imagining a Beowulf cluster of the things until their site recovers:-)
How can we prevent this in the future? Now that Slashdot has been Borgified by the Andover folks, they've got enough funding and computer resources to cache the front couple of web pages and pictures for the articles they post, so that most of the load can be absorbed there and only the small percentage of people who read the deeper links will have to hit the real site.
Technical comment:Yes, I know this only helps people who have real html pages, and doesn't do as much for javascriptified dancing animated Shockwave voice-recognition GUIs making it hard to find the actual content. I don't feel bad about this:-) And even then it takes the initial load for the first page, even if it doesn't make it easy to get everything from the cache.
Shameless commercial plug: Caching is your friend. In addition to the server capacity at Slashdot and the caches at your ISP, there are caching service vendors such as AT&T (that was the plug) and of course Akamai. Caching also does a better job of speeding up pages that use real HTML (and also imagemaps), and again I don't feel at all bad about making well-behaved user interfaces get better treatment.
The article hits many of the basic topics, though I'd like to see Diffie-Hellman Key Exchange mentioned, and some coverage of the Web Of Trust and other key-cert approaches.
The big thing it needs is pointers to other resources - things like pgp.com, counterpane.com and Bruce Schneier's Applied Cryptography book, the Cypherpunks Archive, Ron Rivest's pages, and of course digicrime.com.
Palms are already wireless for short distances, and if you've got a PC or other device with a stronger IR than the Palm, you can get more than a couple of feet away. So if that red glass on top of your Nokia phone actually *did* anything (on the 6160, it apparently doesn't, but on some models it does), you could use that. Wouldn't be tough to build a gateway system, since all you need is PPP on an IRDA port on a PC.
I can't blame them for 6-8 week backorders at Circuit City - they were trying to sell a couch-potato-user-friendly-cuddly thing, and probably estimated that market tolerably well. They got slashdotted, and it takes longer to recover from that in the physical world than it does on your webserver. At least they were taking backorders rather than simply issuing rainchecks for future merchandise that might never arrive.
Changing the terms for people who ordered or especially who bought under the original deal is way rude.
Changing the machine design for people who didn't order the things the first couple of days is IMHO a bad idea, but they've got to salvage their business plan somehow; I wish they'd done it differently, and maybe they still can.
There are three and a half things I can see adding to the i-Opener
Disk drive if you want to run standalone
LAN interface if you want to run tethered
Wireless LAN for couch/backyard/bathtub use
More RAM/flash/etc. if you don't think there's enough
If you don't mind a cord, USB is fine for LANs. It's annoying for wireless use, since you have this frob hanging off the back -- there are also parallel port wireless 1-2Mbps LANs that have the same problem. I don't know if anybody's done a USB disk except CDROM or floppy; again, these are fine for deskwork and especially for initially firing up the system with your favorite OS (at least until you get it running wireless), but they're made for sitting at a desk. However, there are various PCMCIA-format disks ranging from triple-high clunky to cool and little, which give you standalone capabilities so you can use them unwired and unradioed.
The general comments on durability come down to this - it's not a laptop made for bashing by airport luggage handlers or being dropped 4 feet onto bare concrete by postal clerks. It's a friendly device for home use by adults and more responsible children, and sitting on the couch with the kids and cats but not with the large bouncy dog, or sticking in the kitchen as a television-substitute. And that's just fine - I'd like a device like that, and I'd prefer it unwired.
AT&T System V/MLS was the first B1-rated Unix system, developed by Bell Labs in the mid-late 80s. I wasn't one of the developers, but I worked with the system porting applications and convincing people to use the stuff and evaluating what a secure operating system would do in various environments. IIRC, it was certified on the AT&T 3B computers, but it also ran on Intel 386 PC platforms.
System V/MLS implemented Mandatory Access Controls, but didn't split root into least-privilege. The MAC stuff was wedged into the group permissions, with some bits stolen for security level (I think 0-7) and some for security groups, but a few bits left for Unix groups. This left most of the Unix data structures unscathed, but it was enough, and you could buid ACLs by creating groups that had the right people in them. There were a few modified tools for building groups with, and the rules that control what GID a file has when it's created were seriously hacked. (It looked sort of like the BSD feature that gives files the GID of the directory they're in.)
Mandatory Access Controls were designed for the military's SECRET/TOPSECRET/UNCLASSIFIED worldview, which doesn't match most non-military applications, but they turn out to be quite useful tools for making the system more secure for regular applications. You create a "System Low" classification group and put most of the standard software and critical configuration at that level, and nobody can write to it because MAC protects against higher-classification processes writing information that could be a security leak. And you create a "System High" group for logfiles and such, which nobody can read but loggers can append to.
Networking was very limited - this was in the days before anybody had a good solution for any of the Red Book requirements - trusting messages from other machines and trusting other machines to protect your messages require common administration (which didn't fit the Orange Book certification models well), or else require doing the right things with cryptography (which the NSA had a fairly heavy lock on, plus they didn't want to trust military secrets to civilian cryptography, so it wasn't politically usable even when the technology was good enough.) So we didn't have TCP/IP built into the kernel, but you could do things like UUCP over hardwired lines, as long as you ran different UUCP processes and directories for different security levels and dedicated RS232 ports to specific security levels.
Least privilege is one of the controversial areas, but it was possible to do B1 without it. It's a bit easier in a System V environment, where mail runs as Group Mail and uses setgid programs instead of needing to run as root, and of course if you don't have TCP/IP running you don't need as many privileged daemons (many of which run as root simply because low TCP/UDP port numbers are required to be root in BSD environments.)
Covert channel analysis was a B2 feature. It wasn't very possible back then - there are just too many ways to leak information, like high-classification processes grabbing and releasing disk space in Morse Code or whatever. PCs are 2-3 orders of magnitude faster - it's much harder to limit the speed of those channels today.
There were a few other magic things - a Secure Attention Key is a B3 requirement that gives you a secure, unforgeable communication with the login system; this basically used Ctrl-Alt-Delete on PCs, and I think Break on dumb terminals, which weren't able to be stolen by user processes. And there were some shadow directory things, so a low-classification user couldn't see higher-classification files or directories, but a higher-classification process could see high and low files.
I'm not currently a moderator, but that's a good article, worth moderating up as "Insightful". (I don't know if anybody will see this, given the huge amount of noise in the above threads:-)
Even an hour's outage costs a lot of money at a big commercial site, such as airline reservations.
Spoofing is pretty essential for the SYN-flood attack, which is really devastating when you haven't fixed your system to prevent it and you've got 1000 smurves pounding you with it.
But even non-forged machines can send web requests 100 times faster than regular users - not only is there no think time required, the client can request very big files, and drop them when they arrive rather than displaying them. 1000 smurfs on 56kbps dialups are 56Mbps, bigger than a T3. 1000 smurfs on cable modems can be much bigger - their upstream bandwidth is limited (but requests are small), and their downstream bandwidth is enormous, if they're not all on the same segment - figure 5-10Mbps per segment, though there'll be a good bit of clustering of smurfs (and if you can get away with spoofing anywhere, it's probably cable modems.) 1000 smurfs at 100 T3-connected universities can suck down 4.5Gbps, which is still large in today's Internet.
Transparent Caching at ISPs helps a lot. They're installing it anyway, just to manage their own bandwidths, but in the process it means that smurfs repeatedly requesting big static pages get turned into cache hits and stop bothering the target and the net. On the other hand, requests for big uncacheable dynamic pages are a problem - especially if the pages are real CPU-burners to calculate. So attacks on search engines can be moderately nasty, and slashdot-like conferencing system, and other things that try to be really dynamic.
Breaking your DNS caching is bad enough, and makes retrieving your pages slower and less reliable when you're not under attack, but changing your address also doesn't work well. Too many things cache DNS. Some DNS servers have minimum lifetimes on the values in their caches, so they won't respond to your attempt to escape the attack, and many browsers cache DNS results, so anybody who was using your site at the time of the attack also loses.
The next DDoS attacker needs to avoid the defenses against the previous attacks. An easy way around this problem is for the attacker to create a broadcast channel of some kind, which the smurves can use to communicate the latest attack information, including DNS. Suppose you own 1000 smurves. Instead of each one querying DNS for the target every second, each one queries every 1000 seconds, or 4000 seconds, with some protocol to spread out the queries, and broadcasts the result. Then each smurf receives up-to-date attack information, but no smurf queries often enough to be obvious, at least to an automatic attack detector. An easy improvement is not to broadcast the results of the query if they're the same as the previous result, or perhaps _any_ previous result.
Lots of broadcast techniques are possible. IRC is one choice. Writing to some free-web-server web page is another. Building a server that (ab)uses a free web page service or web-based email account is another. IP Multicast is fun if you can do it.
First of all, it doesn't solve the problem, because you have to protect ALL your protocols from use as a DDOS target, not just the web. But if you wanted to build something web-like, what could you do?
*casts don't map well to dynamic HTML, and don't map well to secure connections; you probably won't be able to fix those, so they're still a DDOS target.
Broadcasts go to everybody. You simply can't broadcast everything on the web to everybody - that would be reinventing Usenet, very badly, and wouldn't scale, would have broadcast storms, and would simply be blocked outright.
Multicasts go to people who ask to join a multicast group, which would need to be sparse-mode for the web to have a chance of scaling. (There are 2**28 (2**27?) valid Class D addresses, and more web pages than that, so you've also got a conservation problem...) This means that instead of sending a packet with a request to foo.bar.com for a web page, you send a send a request to foo.bar.com to find out what Class D address it broadcasts foo.bar.com/user42/bazz/page.html on, then send a request to some collection of routers to join you as a receiver of that Class D multicast group, and then send a request to foo.bar.com saying you're ready now and could they please multicast that page (and if you're lucky, related pages), and later, somehow decide you're done with that address and deregister yourself from the multicast group. If you did this, you'd need to re-invent the mechanisms for caching servers (which are what keep the web alive today), though that's certainly a doable thing, and you'd have to worry about how to prevent DDOS attacks in your new complex environment.
For instance, suppose you own a smurf at BigCableModem.net, and everybody who requests home.netscape.com/index.html (the Net's most popular web page) gets put in group D.D.D.D. So you join the group, and start requesting that page as fast as you can. Either BigCableModem.net, or CachingCompany.Net, or worst-case Netscape.com, starts blasting away as fast as it can, and everybody still in that multicast group starts receiving copies of that page as fast as the routers can deliver them, until they deregister themselves from the group. Of course, you can receive them much faster than they can, because you've actually told your LAN card not to listen to those mcast addresses even though you've told the ISP's router you want them (or you've at least told your card to/dev/null them.) OBTW, you're signing up for as many popular sites' multicasts as you can, to flood as big a set of mcast trees as possible, as well as flooding your neighborhood cable system or your DSL provider's upstream feeds from their DSLAM, or their dial POP's feeds. It may take the smurves down faster than in some DDOS attacks, but if you've got any chance of forging IP addresses on your requests, you can delay the eventual Death Of Smurf. Could be ugly...
One nice thing about voice-PDAs as opposed to laptops or palmtops is that they don't need to be accesible or even really small. The part that has to be conveniently accessible is your headset, and the rest can be in a pocket or belt pack or backpack, or on a PC on your desk, or off at the other end of a network somewhere. Some voice-dialing cellphones, for instance, keeps the voice recognition intelligence back at the central office or cell site, rather than wedging that much power into your handset.
One negative about Voice PDAs, like cellphones, is that you spend time in public talking to yourself while you walk down the street. (Here in my part of San Francisco, half the pedestrians do that because of cellphones, and half because of substance abuse...)
If you add visual displays, e.g. i-Glasses, you're adding extra volume and weight, and you get to walk down the street in Gargoyle mode:-)
Slashdot Mirror
Emmanuel Goldstein is a special case, because he had originally been hosting the material, and replacing that with a link to material now posted elsewhere aftern you've been ordered not to post the material yourself tends (in the few cases that have addressed the issue) to be viewed differently than just having a link.
But some Feds have recently been getting sneaky - they're going to the people who made these arguments, and asking them things like "So this censorware stuff you said was less restrictive isn't working, and isn't usable in public libraries? Would you be interested in testifying in court as an expert witness?". It looks like they may be trying to overthrow the least-restrictive-means argument, by contending that filters aren't that much less restrictive, and trying to Catch-22 us into letting them censor the net like they tried to before.
Peacefire is the group that was sued for revealing Cyberpatrol's blacklist, but also for publishing the password-cracker that lets you get around Cyberpatrol's restrictions. The EFF archives on filtering are at this link on eff.org, but they're a bit out of date (unless you believe the year is "19100" :-).
The Censorware Project is more recent.
A reasonable fraction of the many blatant errors in Cyberpatrol's agenda need to be "explained by incompetence rather than attributed to malice"; classifying everything on the net is an impossibly large job, much of the gruntwork gets done by bots with only minimal accuracy, and there's certainly not enough time for real human attention to most of it. That doesn't excuse their lack of fixing problems they've been notified about, or the biases that do appear to be in that product and in many others. "Hackers" - oh, nooo! keep your kids away from them!
The referenced article has its mistakes as well - the Libertarian Party may occasionally be accused of being Republicans who smoke dope, and some of its members are, but that's pretty much a mischaracterization :-) It'd be much more accurate to classify most of the members as computer geeks who don't do real politics because that involves talking to non-geeky people in a way that's interesting to them and doing a lot of plain boring time-consuming hard work like precinct-walking.
The computer system, being the fine piece of 70s mainframe gear it was, crashed hard, and the computer center folks had trouble explaining to the guy that he couldn't put that plywood there because there was an invisible laser beam going right where he was standing....
In practice, San Jose doesn't have anywhere near as much fog problem, and a 500-meter distance could connect the PacBell/ATT POP with the AboveNet/UUNet/MFS POP, though there are bundles of OC48 fiber under the street that do the job just fine.
Spokespersons from the General Services Administration indicated that most Federally-owned Intel-based PCs will be donated to public schools, helping to bridge the Digital Divide, and users who need to retain the hardware for special applications can either install Linux or FreeBSD. "This historic arrangement will also allow us to deploy Posix-compliant software on the most common end-user platforms in Federal use, which we've been trying to mandate for 10 years."
A few details are not yet finalized, such as obtaining Sony Playstation 2 hardware for users needing supercomputer capability who don't want the non-exportable Mac G4 configurations.
I haven't tried it - I've got a $99 Toshiba I'll comment on separately.
But DSL doesn't support the end-user's needs - it also supports the DSL carrier (Layers 1 and 2) and the ISP (Layer 3) during installation , long-term operations, and service failures.
and still do calendars and read email on the train. Even a VGA PCMCIA card would do, if the PDA knew how to use it. But without the ability to talk to a monitor or projector and enough ram for the typical 4MB bloated PPT, there's no point in hauling the bigger MS apps around, and I'd much prefer a lightweight friendly PDA OS like the Palm or Psion or at least the old HP MSDOS PDAs.
My Psion 3a was a wonderful machine; just at the upper limits of "pocket-sized", but I could type at full-speed (Graffiti - arrgxx\\gh) and the apps and OS were well-though-out, convenient, and synced well with PC apps. The 9.54MHz 8086-clone was more than enough horsepower for the apps it had, though crypto could be a bit slow. Hardware was extremely durable and solid, but unfortunately you can only drop it on the floor so many times and Psion's gotten a lot less responsive to US repair customers, and the cool new wares are mostly being written for Palms anyway.
One of my friends has a Cassiopeia with the new camera, MP3 player, etc. - good toys do somewhat make up for the OS
I work in San Francisco - half the people walking down the street are talking to themselves anyway. And the other half are on cellphones.
I've never gotten a lot of phone spam - the bulk of it was from telephone companies and newspapers, and they're pretty good about obeying don't-call-list rules. (The rules, and their databases, aren't bright enough to prevent them from calling multiple phones at the same house, but my second line is usually either busy or answers with modem tone and usually has the phone ringer turned off.) Some of the new telespam machines are pretty insidious, but the "hello ... 2 second pause" usually gets them.
How can we prevent this in the future? Now that Slashdot has been Borgified by the Andover folks, they've got enough funding and computer resources to cache the front couple of web pages and pictures for the articles they post, so that most of the load can be absorbed there and only the small percentage of people who read the deeper links will have to hit the real site.
Technical comment:Yes, I know this only helps people who have real html pages, and doesn't do as much for javascriptified dancing animated Shockwave voice-recognition GUIs making it hard to find the actual content. I don't feel bad about this
Shameless commercial plug: Caching is your friend. In addition to the server capacity at Slashdot and the caches at your ISP, there are caching service vendors such as AT&T (that was the plug) and of course Akamai. Caching also does a better job of speeding up pages that use real HTML (and also imagemaps), and again I don't feel at all bad about making well-behaved user interfaces get better treatment.
though I'd like to see Diffie-Hellman Key Exchange mentioned, and some coverage of the Web Of Trust and other key-cert approaches.
The big thing it needs is pointers to other resources - things like pgp.com, counterpane.com and Bruce Schneier's Applied Cryptography book, the Cypherpunks Archive, Ron Rivest's pages, and of course digicrime.com.
Palms are already wireless for short distances, and if you've got a PC or other device with a stronger IR than the Palm, you can get more than a couple of feet away. So if that red glass on top of your Nokia phone actually *did* anything (on the 6160, it apparently doesn't, but on some models it does), you could use that. Wouldn't be tough to build a gateway system, since all you need is PPP on an IRDA port on a PC.
Changing the terms for people who ordered or especially who bought under the original deal is way rude.
Changing the machine design for people who didn't order the things the first couple of days is IMHO a bad idea, but they've got to salvage their business plan somehow; I wish they'd done it differently, and maybe they still can.
- Disk drive if you want to run standalone
- LAN interface if you want to run tethered
- Wireless LAN for couch/backyard/bathtub use
- More RAM/flash/etc. if you don't think there's enough
If you don't mind a cord, USB is fine for LANs. It's annoying for wireless use, since you have this frob hanging off the back -- there are also parallel port wireless 1-2Mbps LANs that have the same problem. I don't know if anybody's done a USB disk except CDROM or floppy; again, these are fine for deskwork and especially for initially firing up the system with your favorite OS (at least until you get it running wireless), but they're made for sitting at a desk. However, there are various PCMCIA-format disks ranging from triple-high clunky to cool and little, which give you standalone capabilities so you can use them unwired and unradioed.The general comments on durability come down to this - it's not a laptop made for bashing by airport luggage handlers or being dropped 4 feet onto bare concrete by postal clerks. It's a friendly device for home use by adults and more responsible children, and sitting on the couch with the kids and cats but not with the large bouncy dog, or sticking in the kitchen as a television-substitute. And that's just fine - I'd like a device like that, and I'd prefer it unwired.
System V/MLS implemented Mandatory Access Controls, but didn't split root into least-privilege. The MAC stuff was wedged into the group permissions, with some bits stolen for security level (I think 0-7) and some for security groups, but a few bits left for Unix groups. This left most of the Unix data structures unscathed, but it was enough, and you could buid ACLs by creating groups that had the right people in them. There were a few modified tools for building groups with, and the rules that control what GID a file has when it's created were seriously hacked. (It looked sort of like the BSD feature that gives files the GID of the directory they're in.)
Mandatory Access Controls were designed for the military's SECRET/TOPSECRET/UNCLASSIFIED worldview, which doesn't match most non-military applications, but they turn out to be quite useful tools for making the system more secure for regular applications. You create a "System Low" classification group and put most of the standard software and critical configuration at that level, and nobody can write to it because MAC protects against higher-classification processes writing information that could be a security leak. And you create a "System High" group for logfiles and such, which nobody can read but loggers can append to.
Networking was very limited - this was in the days before anybody had a good solution for any of the Red Book requirements - trusting messages from other machines and trusting other machines to protect your messages require common administration (which didn't fit the Orange Book certification models well), or else require doing the right things with cryptography (which the NSA had a fairly heavy lock on, plus they didn't want to trust military secrets to civilian cryptography, so it wasn't politically usable even when the technology was good enough.) So we didn't have TCP/IP built into the kernel, but you could do things like UUCP over hardwired lines, as long as you ran different UUCP processes and directories for different security levels and dedicated RS232 ports to specific security levels.
Least privilege is one of the controversial areas, but it was possible to do B1 without it. It's a bit easier in a System V environment, where mail runs as Group Mail and uses setgid programs instead of needing to run as root, and of course if you don't have TCP/IP running you don't need as many privileged daemons (many of which run as root simply because low TCP/UDP port numbers are required to be root in BSD environments.)
Covert channel analysis was a B2 feature. It wasn't very possible back then - there are just too many ways to leak information, like high-classification processes grabbing and releasing disk space in Morse Code or whatever. PCs are 2-3 orders of magnitude faster - it's much harder to limit the speed of those channels today.
There were a few other magic things - a Secure Attention Key is a B3 requirement that gives you a secure, unforgeable communication with the login system; this basically used Ctrl-Alt-Delete on PCs, and I think Break on dumb terminals, which weren't able to be stolen by user processes. And there were some shadow directory things, so a low-classification user couldn't see higher-classification files or directories, but a higher-classification process could see high and low files.
Spoofing is pretty essential for the SYN-flood attack, which is really devastating when you haven't fixed your system to prevent it and you've got 1000 smurves pounding you with it.
But even non-forged machines can send web requests 100 times faster than regular users - not only is there no think time required, the client can request very big files, and drop them when they arrive rather than displaying them. 1000 smurfs on 56kbps dialups are 56Mbps, bigger than a T3. 1000 smurfs on cable modems can be much bigger - their upstream bandwidth is limited (but requests are small), and their downstream bandwidth is enormous, if they're not all on the same segment - figure 5-10Mbps per segment, though there'll be a good bit of clustering of smurfs (and if you can get away with spoofing anywhere, it's probably cable modems.) 1000 smurfs at 100 T3-connected universities can suck down 4.5Gbps, which is still large in today's Internet.
Transparent Caching at ISPs helps a lot. They're installing it anyway, just to manage their own bandwidths, but in the process it means that smurfs repeatedly requesting big static pages get turned into cache hits and stop bothering the target and the net. On the other hand, requests for big uncacheable dynamic pages are a problem - especially if the pages are real CPU-burners to calculate. So attacks on search engines can be moderately nasty, and slashdot-like conferencing system, and other things that try to be really dynamic.
Breaking your DNS caching is bad enough, and makes retrieving your pages slower and less reliable when you're not under attack, but changing your address also doesn't work well. Too many things cache DNS. Some DNS servers have minimum lifetimes on the values in their caches, so they won't respond to your attempt to escape the attack, and many browsers cache DNS results, so anybody who was using your site at the time of the attack also loses.
Lots of broadcast techniques are possible.
IRC is one choice. Writing to some free-web-server web page is another. Building a server that (ab)uses a free web page service or web-based email account is another. IP Multicast is fun if you can do it.
*casts don't map well to dynamic HTML, and don't map well to secure connections; you probably won't be able to fix those, so they're still a DDOS target.
Broadcasts go to everybody. You simply can't broadcast everything on the web to everybody - that would be reinventing Usenet, very badly, and wouldn't scale, would have broadcast storms, and would simply be blocked outright.
Multicasts go to people who ask to join a multicast group, which would need to be sparse-mode for the web to have a chance of scaling. (There are 2**28 (2**27?) valid Class D addresses, and more web pages than that, so you've also got a conservation problem...) This means that instead of sending a packet with a request to foo.bar.com for a web page, you send a send a request to foo.bar.com to find out what Class D address it broadcasts foo.bar.com/user42/bazz/page.html on, then send a
request to some collection of routers to join you as a receiver of that Class D multicast group, and then send a request to foo.bar.com saying you're ready now and could they please multicast that page (and if you're lucky, related pages), and later, somehow decide you're done with that address and deregister yourself from the multicast group. If you did this, you'd need to re-invent the mechanisms for caching servers (which are what keep the web alive today), though that's certainly a doable thing, and you'd have to worry about how to prevent DDOS attacks in your new complex environment.
For instance, suppose you own a smurf at BigCableModem.net, and everybody who requests home.netscape.com/index.html (the Net's most popular web page) gets put in group D.D.D.D. So you join the group, and start requesting that page as fast as you can. Either BigCableModem.net, or CachingCompany.Net, or worst-case Netscape.com, starts blasting away as fast as it can, and everybody still in that multicast group starts receiving copies of that page as fast as the routers can deliver them, until they deregister themselves from the group. Of course, you can receive them much faster than they can, because you've actually told your LAN card not to listen to those mcast addresses even though you've told the ISP's router you want them (or you've at least told your card to
http://www.funet.fi/ftp/pub/crypt/
ftp://ftp.ox.ac.uk/pub/crypto/misc/
MKLinux is available if you need it...
One negative about Voice PDAs, like cellphones, is that you spend time in public talking to yourself while you walk down the street. (Here in my part of San Francisco, half the pedestrians do that because of cellphones, and half because of substance abuse...)
If you add visual displays, e.g. i-Glasses, you're adding extra volume and weight, and you get to walk down the street in Gargoyle mode :-)