Slashdot Mirror
New Two-Headed Hard Drive Intended To Secure Web Sites
dlur writes: "This article states that Scarabs (In Japanese), a Japanese company, is developing a hard drive with two heads, one read-only and another that is read/write. With this comes two cables, the read-only side going to the external web server, and the r/w cable going to an internal protected server. While this should make it quite a bit tougher for script kiddies to place their mark on a page, I doubt it will stop any real hackers from getting to a site's DB as that would still need to be r/w."
First a 60-foot squid, now a mutant two-headed hard drive. What next, the announcement of the Bearded Lady Linux distro?
Karma: Good (despite my invention of the Karma: sig)
Two hard drives heads, one OS, one root/administrator account. If your box is r00ted, it doesn't matter how many hard drives or hard drive heads you have you have still been 0wn3d.
Zaphod's been using this kind of drive for years to store his porn collection.
"Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
This sounds like a nice drive to use in TiVo-type units as well, so that the read head can return data as the r/w head updates the media, rather than flopping the only head back and forth.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
It seems a malicious user could still attempt to serve defaced pages off of a ram disk on the compromised machine. Yes, a reboot will fix the problem, but that's only slightly more convenient than restoring a compromised system from backups. Furthermore, I suspect that the read-only harddrive would encourage admins to become lazier with regard to applying server patches, since the system would be perceived as "secure".
Having a read and a read-write cable doesn't really solve anything. You really have to take the web-site down while you are updating, otherwise you need a very interesting combo of web site and file system.
See my journal, I write things there
Comment removed based on user account deletion
Too easy... Must resist!
Nah, forget it.
"I mean, two heads are better than one."
As Timothy points out, this only prevents script kiddies from being able to modify existing content using a backdoor or whatnot. However, it won't do anything about denial of service attacks, since the server software and its modules/plugins are all in RAM, and will still be receiving inputs. Buffer overflows and whatnot are still possible. However, defacements will at least go away, and those are the second-most high-profile types of attacks, as they're visible to the general public. Database attacks would be the worst, though, since, as Timothy again points out, they must be writeable.
"Mod, mod, mod...and another troll bites the dust."
You don't need to write to the disk to make a compromised server serve up bogus content.
Furthermore, we can already do this same thing by mounting a network file system (say) in read-only mode. Other than being funky, what's the point?
As the article poster touched on, this won't do anything if you're concerned with RDBMS integrity (and have a site which requires write access to your RDBMS).
For static content, it sounds like a cool idea, even if they get root all they can do is view things and not touch. Of course, if that compromised boxen is attached to an internal network to your RDBMS, then they can go to hax0ring the heck out of your DB, they just have to use whatever tools you have installed on the web server.
Thanks,
--
Matt
Every e-commerce Web site I can think of requires writing data to the server based on user-entered data using the Web site itself. If I want the site to store my credit card number, or even an account profile with my shipping address, the Web server needs to be able to write to a hard drive somewhere.
Now, the sites that are the greatest/most significant targets for hackers are the ones that store personal data on the site's users, credit card data being the most valuable. So this hard drive would be useless for the servers that need it most.
Besides, even if the above weren't the case -- for instance, a banking site that (for some reason) only allowed you to read your account data, not make any transactions online -- does read-only really prevent hacking? All it means is that the hackers can't make changes to the server data; it doesn't mean that they can't steal passwords to access that data. So this might be good for the companies that use it, but it also gives a false sense of security by providing no additional protection to me, the user.
I don't know the technical particulars to the drive, but I'd guess that they'd have to make a way for all static data to be stored on the read-only head and have only dynamic data on the read-write head. Of course, they'd have to make both accessible to the web server in order to receive info from users, but it would help reduce the amount of damage that skript kiddies could do by ensuring that the entire site can't be taken out. Of course, regular backups and a decent admin provide the same level of security for a site. So this only really looks good for reducing the size of backups and for static websites that are only updated by the server admins.
But then, of course, I'm no expert with these drives and there may be other factors which I am overlooking.
Well an external web server could be set up to mount everything NFS read only. Seems like that would be a bit simpler.... ...but since 99% of sites are dynamic it seems to be an impossibility anyway...
Remember you can do the SAME thing with the hard drive you currently own and a CD drive. Here are some simple instructions...
/mnt/cdrom
A create your website
B burn it to CD
C modify httpd.conf, document root, set to
Voila! and I didn't need to hire a team of japanese researchers to figure it out either.
I've often wondered why slower RPM drives don't do dual read-write heads for faster access times and transfer speeds. I'd rather buy a dual-headed 7200 RPM drive with a single Serial-ATA rather than some 15000 RPM drive. The slower dual-headed drive should be able to keep up with the faster RPM drive, yet be quieter (the platter motor -- two head positioning motors would be a bit louder, but not much so), utilize a higher on-disk bit density, and with a good control system, give me better overall speed with a random access usage pattern.
Seeing as most large web sites don't serve their database off of their web server, I don't think this would be a problem. The code for the web page is served off of the server with that funky two-headed drive. Its read only to the internet, but the dynamic content, for instance user posts here on slashdot, are retreived and stored on a separate, secure db server. Your PHP, ASP, whatever, will call SQL queries to that server and not 'localhost' like (un)usual. Read the original posting. It pretty much states this already with the script kiddes vs. real hackers statement.
The admins most likely have a network connection on their machine, and if so, that could be hacked.
Why not a hack that resides in RAM?
It doesn't seem that this would stop a determined attacker; they'd just do an end run around the tech. It does seem that this would be an excellent way to speed up harddrives in general..audio and video... ohhhh.
I can already do this setup for my web server:
NFS server exports directories with web pages to web server read-only and does not allow logins from the web server (and firewall does its best to block even attempts of such). So even if the web server is fully compromized, the web page cannot be changed.
Of course, if the web server has writeable disks of its own the cracker could make it serve a page from there instead of the real page; but the two-headed disks will have the same problem, you can only solve it by not giving the web server any writeable disks, boot it from CDROM or from the network.
Of course none of the R/W computers will be in any way attached to the internet.... in the best possible setup a machine that has access to both networks can be compromised, etc. If it's not, updating will be a major pain, so much so they might as well flip the read-only jumper on the drives between updates rather than use this system.
Aside from the obvious, there are much better uses for more than one head in a drive. Multiple simultaneous seeks, faster seeks, and twice the raw read rate. The market for this should be huge. Hard drive transfer rate is the bottleneck for most tasks, including boot time. All the while with less heat, power, and noise of the 7200+rpm drives.
"I don't know that atheists should be considered citizens, nor should they be considered patriots." George HW Bush
This would completely screw up any modern OS (or Windows).
The OS assumes that it, and it alone, modifies the disk, and that the disk won't change state without the OS making that change. This is one of the reasons you don't want to allow raw disk access from a VMWare or DOSemu session to a mounted file system - the emulated OS will access the disk, and the host OS's file system won't know about it. Boom! Instant corrupted file system.
In the case of this double-ended drive, the web server will assume that, since it has read the disk once, it needn't read that sector again. Then the write side computer modifies the disk, and the web server won't pick it up.
I'd rather see a disk with dual heads, and the logic to allow the system to read different sectors at the same time, all kept coherent by the drives controller as a way to increase throughput.
But to use this as a protection on a web server is just plain dumb.
www.eFax.com are spammers
I've had a similar idea when it comes to making a log server. If it is only physically possible to write to the log server, then there would be no way someone could erase their tracks.
Hacker Media
Sure, this new drive can protect existing data from destruction, but we need protection from the wrong people reading the information that's already in a website.
Height: 38U, Weight: 0 Newtons, Eyes: #0000FF, OS: Gray Matter 1.0 (Alpha)
This has been done before on a slightly different scale.
When you have a storage array that supports multi initiator SCSI you can connect one connection of the array to the external facing machine in read-only mode and the other connection to the internal facing machine in read-write mode.
Unless you want to go to the trouble of making an OS that is 100% read-only, you'll need to have something writeable on that web server. It'd be cheaper to serve your website off CD-ROM (for the sake of this argument) but who's to keep a script kiddie from mounting your website on a ramdisk or another writable area?
Besides, you can always make hot-swap hard drive read-only with a jumper block.
It's the same deal with a SAN (Storage Area Network). I could easily zone two physical servers into the same LUN on the SAN and make one mount r/o and the other r/w, but unless the OS has some sort of understanding that this kind of thing is going to happen (like a clustering system), I would expect some problems on the r/o mounted system.
p.s. I'm no expert, I'm just wondering logistically how this is all going to work. It doesn't make sense to me...
p.p.s. I know there is no real security in mounting a disk r/o because someone could just remount r/w, unlike the physical solution this product provides. But in either case, I would think the issues with two boxes mounting the same file system without clustering would be a problem. If it isn't, I'd love to do something similar with my SAN just for performance and load balancing purposes...
How about 2 r/w heads, to increase performance?
So sayeth the article:
Hackers will be unable to attack Web sites protected by a new security system unless they can change the laws of physics, according to Naoto Takano
I'm working on it all ready. So far I've managed to get the relativity theory down to E/2 = MC^(1.9)
And standard Earth Gravity now has a value of 8.8m/s/s.
Up.
And don't try to fill up a garbage bag anytime soon. I've been playing with volume. They're now "Garbage Bags of Holding."
This is SO a gimmick. It is no replacement for a properly configured server that's 99.98% locked down. You're going to need a second machine to feed files onto the box anyway, so why not just grant the webserving box read-only access on the file server ? Ideally this server would be totally isolated from the internet, and wouldn't accept write requests coming from the web box. So the only way to update anything is to be sitting on a workstation on the inside, and then to have a valid login on the fileserver.
This is so frickin' simple, the only reason this Scarabs company is even in business is because there are too many idiots running semi-important servers out there. Having your network admin'd by a clueless fuck is not something that will be solved by a piece of buzzy hardware.
-Billco, Fnarg.com
On a different disk, in other words yes. OS, pagefiles, and files that the web server would be writing to are still on a R/W drive. Information you only view would be on the read only drive.
I built a system like this with 2 and later 3 heads, years ago. actually wrote an article on it for a magazine:)
:)
.
Uses 20 Meg MFM single platter 5 1/2 drives (the tolernaces were the most forgiving, I probably had the only 486 with MFM hard drives in it
It was WAY cool though, (I had it under glass to watch it)
We took pictures, and the rejected aticle, sealed em in an envelope with a signed notarized affidavit. and had the post office postmark the flap
I was going to patent it (this is circa 1992) but I was told by many contemperaries it was the dumbest idea they had heard.
Now if I can find it watch out
Sig went tro...aahemmm.....fishing........
This product seems to me to be useless for any site that provides access to database information through dynamic pages.
Seeing how most web sites who would be in the market for a product like this have "advanced" sites, I would argue this product has a very small potential customer base.
-Pete
Soccer Goal Plans
Uhhh, once you have control of the web server, can't you write outside of DocumentRoot if you choose?
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Yes indeed, this is a complicated, sure-to-cause-more-problems-than-it-solves solution to a non-problem. Export filesystems read-only to your static Web servers and read-write to your back-end thinkers (DB servers, content management systems, etc).
If you're really smart, you're doing all of this on a netapp filer so that the access speed is as good as or better than local-attached storage (and, yes that's true even though it sounds wacked... it's because of thier NVRAM-based journaling filesystem for which their NFS server code is hand-tuned).
Great.
/. ever taken a security class? /. ever worked in on security projects and/or audits?
Now, we have to explain one more thing to VCs and MBAs. All they know is there is this thing called a website that exists on a thing called a webserver.
Hasn't anyone on
Has anyone on
Let me break it down for the rest of you:
This ads exactly zero extra security for a well-run website. Most well-run sites already have seperately firewall'd http-webservers and database machines. Some well-run sites have the application server on yet a third firewall'd network (or vlan etc).
Any place worth 5cents will not have valued data sitting on an httpd server!
This is really Ooooga-Boooga in a nutshell for VCs and MBAs trying to make a buck on security-scared VCs and MBAs running other companies.
I don't buy it.
Secure your site properly - as one other poster mentioned, for the less-funded (read: cheap/poor/startup/blah) company/service you can simply mount a CD-R with your site's static content on it. Even JSPs can live on a CDr (as long as they're precompiled into servlets, or there's a scratch disk for the JSP-container to compile them).
Haven't you all seen urls of obscene length at some point? Dynamic pages are generated by _static requests_ -- in a sense, you could generate ALL possible dynamic pages and store them, giving them all their unique url. This of course, is a "Bad Thing". However, some (older) cgi scripts let you see the url to the page you are reading. Take, for instance, a google search. A google search for "hax0red" yields....http://www.google.com/search?hl=en&ie=IS O-8859-1&q=hax0red&btnG=Google+Search
Not for nothin, but I didn't need write access to google to get a dynamic page. As long as the user doesn't have to _ENTER_ any data that needs to be stored locally, this system works just fine.
This is _NOT_ a solution for ebanking, etrading, managing personal accounts and the like (where data needs to be WRITTEN back). For the majority of dynamic web pages, this works just fine.
(ok ok ok yes there is still the buffer overrun issue -- and yes your url's get messy...but at least they dont have actual _write_ access to the hard drive...as someone else already said...a quick reboot and any _possible_ -- not even probable -- damage is gone.)
When in doubt, parenthesize. At the very least it will let some poor schmuck bounce on the % key in vi. (Larry Wall)
Not sure if they do anymore, but IIRC hard drives already have or have had write protect tabs available. Write protect works just fine for floppy disks.
Multiple heads seems like it would be a massive extra expense compared to changing the firmware that doesn't really provide a whole lot of extra security.
Of course, most of the older drives also had prominent lights and pushbuttons on the front that let you write-protect the drive, in some cases on a per-port basis.
What has often been missing is OS support for dual-ported drives; the lack of support is most conspicuous today. As a result most modern OS's trying to use a dual ported drive will have to "take its turn" having the disk mounted if there's any possiblity the other machine is going to do a write. If the OS doesn't even support the simple concepts of mount and dismount, then you probably cannot use it at all!
According to this "The God Janus, husband of Jana, is known as the custodian of the universe, the God who watches over doors and gateways, and the two-headed God of ... "
Please send any patent inquires to
Cesear, Emporer of Rome
123 Pantheon Drive
There are 01 kinds of cars in the world. The General Lee, and everything else.
From the article:
"The original idea of a hard disk having two heads emerged around 1985..."
Funny that the technology hasn't been implemented after all this time... Or has it?
From the StorageReview.com reference section:
"Such hard disks have been built. Conner Peripherals, which was an innovator in the hard disk field in the late 1980s and early 1990s (they later went bankrupt and their product line and technology were purchased by Seagate) had a drive model called the Chinook that had two complete head-actuator assemblies: two sets of heads, sliders and arms and two actuators. They also duplicated the control circuitry to allow them to run independently. For its time, this drive was a great performer. But the drive never gained wide acceptance, and the design was dropped. Nobody to my knowledge has tried to repeat the experiment in the last several years.
There are several reasons why it is not practical to make a drive with more than one actuator. Some are technical; for starters, it is very difficult to engineer. Having multiple arms moving around on a platter makes the design complex, especially in small form factors. There are more issues related to thermal expansion and contraction. The heat generated inside the hard drive is increased. The logic required to coordinate and optimize the seeks going on with the two sets of heads requires a great deal of work. And with hard disk designs and materials changing so quickly, this work would have to be re-done fairly often.
However, the biggest reasons why multiple actuators designs aren't practical are related to marketing. The added expense in writing specialty electronics and duplicating most of the internal control components in the drive would make it very expensive, and most people just don't care enough about performance to pay the difference. Hard disks are complex technology that can only be manufactured economically if they are mass-produced, and the market for those who would appreciate the extra actuators isn't large enough to amortize the development costs inherent in these fancy designs. It makes more sense instead to standardize on mass-produced drives with a single actuator stack, and build RAID arrays from these for those who need the added performance. Compare a single 36 GB drive to an array of four 9 GB drives: in effect, the array is a 36 GB drive with four sets of everything. It would in most cases yield performance and reliability superior to a single 36 GB drive with four actuators, and can be made from standard components without special engineering."
So, from the looks of things, it would be easier and cheaper to use single-head drives in easy-to-put-together configurations than put two heads in the same drive. Admittedly, the StorgeReview.com reference's author didn't mention setting up a read-only/read-write scheme, but the logic still works. I'd guess that it would still be easier to make a RAID container that provides read-only access on one channel and read-write on another.
Again, from the article:
"Scarabs is also working on a different version of the technology--instead of putting two heads on a hard disk, the company is connecting two SCSI interface circuits to a conventional hard disk with one head, one set to send read-only electronic signals and the other to send read/write signals."
This company already knows that their gimmick drive won't sell. No one will buy an over-priced drive with higher probability of failure over a (comparatively) cheap SCSI trick that requires no extra moving parts.
"Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
somebody give this man a cookie! he pretty much nailed it. of course this isn't the case for most small sites, but once you start looking at the "enterprise" level, you see than your webservers are in new york while your databases are in chicago. this type of thing is great for webservers that are "dynamic" by way of a database
And then how does the database get updated via user input?
Again, works great for static web sites, but doesn't help much for dynamic.
Casual Games/Downloads
You can do the same with dumb sun boxes, that boot off the net, mount a read only parition with apache/content, and connect to a database. Good thing, if you update the content directly, your stack of boxes all have updated content. Make sure you have a nice storage array that can push data to the boxes.
Simple, Secure, and very easy to maintain.
Complicates the cache issue? How? Basically, they are making two complete hard drive assemblies on a common assembly, but one can only is designed from the ground up to be read-only, from the head to the interface, providing the most possible levels of protection to get through. If the drive head is physically incapable of modifying data, then no bug in any software or firmware can be explotied to allow writes.
I personally think this is useless for other reasons, completely redundant with networked strategies to do the same thing, at least with competent administrators. However, I guess this thing would be good for places with less-than-stellar administration. Then, they could have the web server's only connection to the data through that safe harddrive cable. If an organization is just serving up static data, then they probably aren't sophisticated enough of an organization to afford stellar admin people, so I guess this thing has a place.... No where near me though.
XML is like violence. If it doesn't solve the problem, use more.
Other than expense, why not just use some sort of shared storage appliance. The admin can be allowed to mount the appliance rw, while the webserver can be given read only access? I think EMC has products that do this.
When I want your opinion I will beat it out of you.
A headline to draw in the geek girls?
Tsk tsk... Timothy!
Blearf. Blearf, I say.
Not if writes to the disk as physically prevented which they are in this case. The general idea is not to prevent the trashing of the web server, but rather it is to protect the data it is serving from being wiped out. Which of course as others have said is pretty pointless, people generally don't break in just to erase things.
A head crash would still kill the whole drive, but I'm guessing that if the read head were to just wear out, or if a wire were to come loose, then only one set of heads would stop working.
Xaotik Designs
I remember someone telling me from back in the magnetic drum days, that the fastest drums had one head per track, so you only ever had rotational latency delays (average half the the rotation time) - no physical seek (move the head) delays. I often wondered if multiple heads on a modern disk drive would improve performance...
... again, let the disk controller decide to move the closer head ... I know that I can pick items out a heap much quicker with two hands than one due to economy of movement....
I know on a modern disk the tracks are too tightly packed to do a head-per-track, but was wondering if you had (say) 2 heads on a single arm seperated by a third the width of the disk, then any track could be read with a much smaller movement (compared to full disk seeks) by seeking with the closest head, and when queuing up reads for an "elevator algorithm" of seeks you could also get performance gains by grabbing out of order data with the "trailing" head.
I realise the price goes up with complexity, and the heavier head might take longer to settle, but was wondering if this wouldn't give better performance for scattered reads for those who need it (eg servers) and don't mind paying....
Now I'm a software geek, not a hardware bod, so does anyone know why this isn't done ? (I can guess lots of reasons myself, thanks). Is it effectively just RAID striping on a single disk ?
And how about more heads (5 across, 10 across...), or 2 sets of heads on opposite sides of the disk to cut rotational latency in half (if kept in step) or
--
T
I spent a lot of money on booze, birds and fast cars. The rest I just squandered. - George Best
Why not use two hard drives, and a bit of cleverness in the software to write the incoming data stream to one while the user is viewing a stream on the other? This seems cheaper than custom hard drives, and preserves the ability to keep upgrading the capabilities by going to new commodity hard drives as biggers ones continue to get cheaper.
I've seen a couple of projects on freshmeat that do this. Basically, a daemon sits around and watches files and if they change, they do something about it. This could be anything from logging to sounding an alarm to replacing the content.
I could have a repository sitting offline storing all of my content (or even everything... OS, databases, scripts, tools, etc etc) and have it "log in" to the servers from the inside and check everything for changes periodically. In a lot of cases, tests could be done from the outside as well (web content specifically). That machine, though physically connected, would simply shut off its interfaces and block everything unless it was doing its work.
I think a recent website hack occurred at USA Today... such a scheme could have caught the hack within minutes and even have replaced the forged content with whatever was supposed to be there.
Well I'm pretty sure that all the data is stored on the same drive and both heads can read from that drive. The difference here is that one head can read only, and that is connected to the outside world, while one head is read/write, and that is connected to the server. No matter what security you put in, if you have user data that can somehow come in and be written, you still have potential for hacking, and so having two heads really doesn't get you anywhere.
~ now you know
Anyone else reminded of the silly scene where Arnie has to instruct his friends how to flip his neural net from R/O to R/W mode?
[
I've been hearing a lot of people say "clip pin 23 to your IDE cable" to prevent writing.
Would it be difficult for a company to come up with a "plug between" adapter between the harddrive and the IDE cable? maybe it would have a jumper on it that you could remove, or better yet, plug in an extension cable with a switch onto the jumper location so you wouldn't have to open the case every time a change is made. If there was enough of a demand, these could be manufactured cheaper than IDE cables.
I think it could be a much cheaper solution to the folks that don't need top of the line. Then again, Mounting the filesystem "read only" would be even easier.
I read the article and it described a system where if you have a website that serves only static content you can use this snake oil technology to prevent people from defacing your website. Why is the technology snake oil:
Get two of them. One to serve "content", the other to record transactions. Content server has the read only head on, the transaction server has the write only head on. Hot swap them for updates and transfer of information.
Not as convient as it is currently done, but for a little ma/pa shop, it might be perfect.
Burn Hollywood Burn
I had an idea along these lines, only it worked a little differently:
... and so on. If there is a change, the server could alert the admin and let them know what the attempted change was to.
:)
Create a webserver that has a RAM disk big enough to hold the site. Then, at boot, dump all the contents from the CD-ROM over to the RAM Disk. Then, periodically check a few things in RAM:
- # of files served vs. # of files on the CD
- Dates modified
- Significant changes in file size
- Maybe a file comparison on a random file here and there
- Refresh the RAMdisk with what's on the CD-ROM at regular intervals like every hour.
That idea's not as well developed as I'd like, but it's food for thought.
Wouldn't this make the web server unable to read cache, the information could change.
Can't you have the same effect by having the web server with read only permission to be the only externally accessible program?
Or just mount a ro network drive, over dedicated gigabit ether it shouldn't be that big of an issue.
I think it's set up so both heads access the same data, just whatever is using the read-only head can't modify anything.
Not sure if it would be best to have two separate computers access opposite sides, or have one use the drive as two parts. Probably the first.
--
You are the weakest link! BLEARGH!
That what was all this school was for... to teach us how to solve our own problems. -- janeowit
BTW, anyone owning an old Mac or any Apple][ series outfitted with a 3.5" drive has a similar setup. 5 zones, but definitely directly-opposing heads and not this nonstandard setup. I think the 5zone drives finally got the axe when Jobs decided to not include a floppy with iMac.
The 400k (single sided) and 800k (double sided)formats were always zoned, though the early drives did actually change speeds, and loudly at that. Once Apple introduced HD drives, (the first "SuperDrive") the variable spindle speeds went away. That said, they could read and write the old formats just fine, by changing bitrates instead of spindle speed. The SuperDrive could also read and write MFM DD floppies (720k) in addition to HD. (1440k)
We varied bitrate instead of spindle speed from the beginning on duplication equipment, but the dupe equipment never had the cost pressure that a consumer-ish PC did.
Thank god we never had to build a Twiggy duplicator....and my Lisa had a proper 3.5" drive
You have violated Robot's Rules of Order and will be asked to leave the future immediately.
Why not just keep your content on an NFS server and export it read-only via GigE?
Couldn't this potentially cause problems with log files being written? Unless you'd prefer not to have log files, but we are on the subject of security, right?
to turn off the buffer cache.
So, yes, the cookie is stored client side. The data it represents, however does not (and shouldn't for a number of reasons, including security) reside on the client computer.
Good web programmers should also delete the cookies from the browser for login data when the user 'logs out' from the site.
The Virtual Bookcase: book reviews
Surely two heads is going to have a considerable effect on the MTBF, in the order of 40% maybe, since most of the the drive failures I've had have resulted from head failure. With enough drives in your storage array that increase is going to become very visible, very quickly.
UNIX? They're not even circumcised! Savages!
Of course, now this Guardian is itself a great target for hackers... Plus I think this technique is already patented :-)
I do not deploy Linux. Ever.
Many old school coders still feel that the only way to debug source code is with a blue bic pen on greenbar.
I do not deploy Linux. Ever.