No, all you need to do to compromise any package you liked is to change the MD5 on the portage servers AND change the actual package on some totally different server. Having to crack two totally different unrelated machines to do it is far harder than cracking just the server that the package comes from.
The problem with having a shared secret between you and the 'download provider' is that every piece of software comes from a different place! You'd have to share a secret with hundreds or even thousands of different servers; which seems pretty impractical.
Gentoo is not Debian, where all packages come from a single set of mirrors; although Gentoo do mirror the majority of the files required on their own servers, many files are not mirrored for various reasons (too frequently changing e.g. cvs snapshots, licencing restrictions e.g. Transgaming's WineX..) and are downloaded from the original source (and the original source is used as a fallback for files that fail to download or md5sum correctly from the Gentoo distfiles mirror).
Also, if you share a secret with the download provider and someone roots their server, they're going to have access to your shared secret.
That kind of thing is a simple coding error that can happen in any language, and is a problem in any language. It's not hard to track down where things are referred from if you have a decent debugger. Soft, weak and phantom references don't use any significant memory, and you can make them automatically remove themselves from collections..etc that they may be in using reference queues. The standard library WeakHashMap class has most of it implemented for you.
Your example with the About box is cute, but it's no better with explicit allocation; if you are intending to only add the event handler once, then you will likewise only free it once, and you will leak exactly the same amount of memory.
I can't, in fact, think of any examples at all where a mistake that causes a 'leak' in Java is not also a leak in an equivalent program with explicit allocation.
Actually, MP2 is MPEG 1 Layer 2, and although it works ok at low bitrates, it's terrible at higher rates, and doesn't support sufficiently high rates for good reproduction of mastered audio.
If you have a circular loop of 15 objects and a reference to a single object, then you have references to *all 15 objects*. Any memory management strategy which frees the other objects is *unsafe*. Why is this a problem? If you didn't want the other 14 objects, it's trivial to clear the reference in the one you have, leaving the other 14 as an isolated chain which will then be freed.
The Sun GC used in HotSpot since at least Java 1.2 is 'perfect', which means it always correctly determines whether something is garbage or not; it never misses something which can legally be freed.
Java can, in some conditions, be *faster* than compiled native code because of optimisations that can only be performed at runtime (insufficient information available at compile-time). Nothing I use that's written in Java runs slower than equivalent native-code software (and I'm talking about total CPU cycles used, not perceived user speeds). The fantastic optimisation abililities of HotSpot do come at a significant cost in memory and a small cost in startup time, but I only start my IDE once a day and have six gigabytes of ram, so it doesn't bother me. =)
Java runs fine on my cellphone with 4MB of memory too, and is still speedy enough not to seem any slower than native Symbian apps.
The standard Sun JVM has a 'perfect' garbage collector; in this context, perfect means 'always collects exactly what is garbage'. It doesn't miss anything. If you are finding something not being collected, then you have a reference to it. Probably a conveniently invisible one.;)
The GC doesn't care whether you're looping or not; in fact, there is an asynchronous GC (one which runs simultaneously to your program) now available for experimentation...
Nope, what I make is used by the product development team to build system images for particular machines. They're the ones who get to make things work =)
I was never having a discussion about implementing practical systems today, just about the theory of journalling. Maybe someone higher up in the thread was, I dunno.;)
ext3 has the massive advantage (on Linux) of being based on ext2, and ext2 has been beaten on for so long by so many people in so many configs that it's pretty damn stable at this point. It's actually diverged a bit by this stage, though - its on-disk format is still 'ext2 with a journal' but the algorithms for allocation..etc have changed a little and work better in theory.
I'm an OS developer, so dwelling on implementation too much is bad for me. Gotta keep the idealistic goals in my sights, otherwise you just keep maintaining what's there instead of doign anything better =)
Ah; I did not realise that synchronous mode was the default, as I've always configured it to use softupdates before. If you have been talking about FFS synchronously mounted, then you are comparing apples to oranges; ANY fs mounted synchronously is safe, there's nothing special about FFS there.
I am rarely interested in reality of this kind of thing; implementation details are dull. Yes, it's entirely possible, probably even likely, that the FFS implementation is more stable and safe than many other filesystems - reiser in particular is notorious for having had many data-loss-inducing bugs in the past (though hopefully less at present). I have never lost data through an FS bug in any filesystem; my main systems variously use reiser, ext3 and FFS with softupdates. All the servers I run that require guarentees from the filesystem run on a filesystem which provides them: either reiser mounted synchronously, or ext3 with full data journalling.
So, from my personal experience, the implementations all work fine. I was never making a claim that any particular FS was better, merely correcting your original incorrect statement about the flaws in journalled filesystems. FFS has a fine history of reliability, but so does ext2 under normal use (i.e. when you always unmount cleanly). =)
I know all about log-structured filesystems too; but there are very few modern implementations that are stable and complete. They work well for certain access patterns, and not for others. Data-journalling FSes do indeed temporarily write to the journal, then commit to the final locations. The temporary writes are all fast appends, and the final writes can be saved until the disk is less busy to be written in a nice order through the elevator algorithm. The result is a modest performance hit on writes in exchange for getting all the safety benefits of a log-structured FS, and with no problems with read performance later.
I've read plenty about ffs, including the source, and have used it for a long time. It does allow the situation I describe - while metadata is preserved correctly in all but the most tricky of cases, data is not committed to disk until fsync() unless you mount your filesystem in synchronous mode (which means you have to take the performance penalty for doing so, and you can mount *any* fs in sync mode to get that guarantee if you don't mind it being slow). If you believe otherwise, please, show me the documentation/code that explains its commit behaviour differently, and I'll apologise for claiming you are wrong.
A data journalled FS never needs to be fsync()ed, and appending to the journal is much faster than syncing. For 'enterprise' systems (what an arbitrary definition that is; as I pointed out, all mail servers everywhere are required to make all possible efforts to avoid losing mail they have committed to delivering) applications typically fsync() at the appropriate times without any consideration for the filesystem they are running on, which usually means that a data-journalled system will perform worse, not better, than something like FFS, because everything gets committed to disk twice immediately (instead of the non-journal commit being postponed until a better time). Data-journalling is not *needed* in any situation, except where an application does not fsync() and still trusts writes to be synchronous (to 'fix' these apps on FFS requires mounting synchronously again..), but it is a better solution than manually syncing.
Preventing incomplete writes is not the same as preventing data loss. If the OS tells the app that data is written to disk, and it is not, then data has been lost. This never happens with a fully data-journalled filesystem, because the OS will not claim that the write is complete until it's at least been recorded in the journal. The write might not be complete if power dies right then, but *nobody has been told that it was*.
This is vital for any kind of database, mail server, or other system in which the server process has to be able to tell the client that their data is 'safe'. For example, the mail RFCs forbid a server to reply to the DATA part of an SMTP transaction with a confirmation until the mail has been written to permanent storage; replying 200 means that you have taken responsibility for ensuring the mail's delivery. Without full-data journalling, this means you have to fsync() after writing but before confirming the write; this can be slow. With full-data journalling, you are assured that the write has been journalled and will be replayed.
Mail servers and databases running on FFS or any other non-data-journalled filesystem have to fsync() frequently to preserve data integrity. This is not neccecary on a data-journalled FS.
>Besides, you seem to be a bit clueless once more.. journaling filesystems do not prevent data loss, they prevent situations where your data and meta data is out of sync, and they provide for a rollback to resync those in case they do end up being out of sync still.
Actually, ext3 does prevent data loss in full data journalled mode. Also, a journalled FS will only ever have to roll back at most one transaction to recover; under all normal circumstances, not even that is neccecary as transactions can be replayed instead of undone.
-Os is not just -O2 without size-increasing optimisations. It also includes size-decreasing optimisations which can decrease speed further still. The speed difference between -Os and -O2 is actually quite dramatic.
Most binaries don't usually have working sets sufficiently large to make much difference, given that modern CPUs have huge caches. =)
You can make your own Windows CD that will install SP4; just take a copy of SP4, and any CD (SP3/2/1, gold, doesn't matter) and slipstream it. http://old.bink.nu/bootcd/ has instructions on how to do this while preserving the bootability of your CD. This can be done with 2000, XP or 2K3 and works with any service pack.
The film sometimes comes on several reels and is spliced by the cinema; this way, it's easier to transport (a single-reel film is *huge* and weighs one hell of a lot), and it can be shown at cinemas which still have dual-projector setups (not many these days, but they exist). Sometimes when a print of a film makes its way around the place for second runs..etc, it gets spliced into one reel, then cut back up, then spliced again..etc. =)
Solid support does not mean fixing the bugs; it means continuing to answer the phone, explain that the problem is known, and telling the customer how to work around it. While you're completely correct that most of Windows doesn't get fixed, and that many of the issues are design flaws, not implementation bugs, this *doesn't matter* to most users of Windows, home or corporate. As long as someone can tell them how to get around the problems, that's good enough. Sad but true.
Well of course you do, and it is only running like this to hide your emails to grandma right? Some amazing contraption that foils all attempts to analyze it. Experts from around the world have tried and failed against this mighty, forensic expert, crushing machine. It is people that think like you that makes this job so much fun.8-> My first guess would be you have a root kit installed, so sneaky. No way around that, grab the sledgehammer Joe!
I'm glad you're entertained. It runs like that because it was the logical conclusion of improving the security configuration of my currently deployed server; it's an interesting experiment and currently hosts no data. Perhaps it will at some point in the future.
Root kit? I think not.
* User's data is encrypted using keys generated from their logon exchange. The keys cannot be read from kernel memory while the user is logged in as root cannot read kernel memory or attach debuggers. The files cannot be read by a different user, even root, while the user is logged in as mandatory access control forbids it. You cannot su to that user because once you are logged in, no process you create can setuid().
* Swap space is encrypted.
* All processes run under least-privilege ACLs through mandatory access control.
* No user can run any program that is not owned and writable solely by root. Any root process not created during startup may not write to any file outside root's home directory. This means no installing or compiling anything.
* The machine's ssh host key is stored in RAM and not backed up anywhere; turning it off (to tamper with the drive contents) will lose you the key and thus no user will log into the machine once it has been tampered with. No process may access the host key other than sshd; no process may inspect sshd's memory or attach a debugger to it.
That's a pretty brief summary of the important points. Obviously, no system is perfect; I was interested in seeing how far down this road it's possible to go without requiring security hardware. Comments would be welcome.
It's all very well having clever forensic techniques existing; I'm not denying that they do. But there are not enough computer forensic experts that they can always take one along when they want to search someone's house. It's much easier to just take hardware. Especially if there is such a 'backlog' that it takes many months before an expert can take a look.
I'd be interested to know how you propose taking an image of a running disk on a machine controlled by your 'opponent', btw, as I have a server whose configuration is specifically designed to foil legal investigation, and it'd be nice to discover any more holes. Same goes for a RAM dump - surely you aren't expecting the machine to cooperate with you? =)
If I muddied the issue, I'm sorry; my original statement remains, though, that it is far more common and likely for hardware to be taken (whether it's from a company or an individual) than not. As for my 'sensationalised' statement, I have no first-hand experience, as my friend was not charged. However, it's been reported widely by many news sources whom I trust, and I have read more than one court transcript of the subsequent civil lawsuit.
Yes, this did happen in the USA. I am from the UK; I was visiting my friend in the US when his house was searched.
Whether he had in fact done anything wrong is pretty irrelevant to the story, if you read it correctly; my point was that the kind of evidence which would definately require examination of computers (such as logs from online services..etc) *did not exist* - he was explicitly told that they took the computers just because it's common to find evidence against someone for all manner of things on their computer. Your post suggested the opposite.
Re:League Women Voters Opposes Paper Trails
on
Evoting in the News
·
· Score: 1
Damn, I wish I still had mod points. Mod parent up, this is a *fantastic* explanation.
This resembles how the Plan 9 filesystem works. It keeps *every* version of every file, forever (unless you use the admin tools to erase the archives). It was originally intended to use WORM jukeboxes to offload old copies, but now it's pretty cheap to run it using just huge amounts of online storage.
How can you get a good copy of the data without taking it apart? How do you know that the machine isn't rigged to erase stuff if you boot it up the wrong way? You have to take the disk out and duplicate it using your own equipment in controlled conditions. What is admissible in evidence is not the issue; what is actually done is. I'm sure that yes, sometimes they will do it 'the easy way', but more often than not, they don't. I should point out that yes, my friend's experience is also first hand knowledge to me, because I was *there* when the police arrived with their warrant.
You're assuming way too much about fairness; 'They have your IP, login used, ISP logs etc..', and 'When they show up at your house it's to gather the final bit of evidence'. This is wrong. Yes, this should be the way it works, but it isn't. The friend I mentioned had his house searched and all his computing equipment seized based on *hearsay* which had been reported to the police by a social worker; there was no computer-related evidence against him because he hadn't *done* anything and the police admitted this; they explicitly said that they were taking the computers 'just to be sure', rather than because they had any reason to think they were involved in a crime. At the time of the search they had absolutely no evidence to base a case on; the purpose of the search was to establish *anything at all*. He lived in a shared flat, and the police took the computers belonging to his housemates as well (who were not in any way implicated in the case), simply because they were connected by a network to share their cable modem connection.
They held the equipment for eleven months without arresting him, charging him or even interviewing him informally; they told him this was because there was a 'backlog' and that it had taken over nine months for the equipment to be first looked at. When they finally did contact him, it was to say that they hadn't found anything, and asking him to come and collect his equipment; no apology, and no further explanation. Evidently, they were intending to base their case on the contents of his computer, without having any evidence to suggest that there was anything incriminating there to find.
The net result of this was that he and three other people unlucky enough to be living in the same house were deprived of their posessions for nearly a year because the police thought that he might perhaps have been involved in a crime, despite having no evidence other than word of mouth that this was the case.
Perhaps you live in some kind of nice happy world where these things don't happen, but they do in this one. I will admit that this case is probably an extreme and it may well be rare, but it happened.
I never said anything about seizing company computers; when I said 'whole networks' I referred to home networks, like the one my friend had.
Slashdot Mirror
No, all you need to do to compromise any package you liked is to change the MD5 on the portage servers AND change the actual package on some totally different server. Having to crack two totally different unrelated machines to do it is far harder than cracking just the server that the package comes from.
The problem with having a shared secret between you and the 'download provider' is that every piece of software comes from a different place! You'd have to share a secret with hundreds or even thousands of different servers; which seems pretty impractical.
Gentoo is not Debian, where all packages come from a single set of mirrors; although Gentoo do mirror the majority of the files required on their own servers, many files are not mirrored for various reasons (too frequently changing e.g. cvs snapshots, licencing restrictions e.g. Transgaming's WineX..) and are downloaded from the original source (and the original source is used as a fallback for files that fail to download or md5sum correctly from the Gentoo distfiles mirror).
Also, if you share a secret with the download provider and someone roots their server, they're going to have access to your shared secret.
Here we are in violent agreement. =)
That kind of thing is a simple coding error that can happen in any language, and is a problem in any language. It's not hard to track down where things are referred from if you have a decent debugger. Soft, weak and phantom references don't use any significant memory, and you can make them automatically remove themselves from collections..etc that they may be in using reference queues. The standard library WeakHashMap class has most of it implemented for you.
Your example with the About box is cute, but it's no better with explicit allocation; if you are intending to only add the event handler once, then you will likewise only free it once, and you will leak exactly the same amount of memory.
I can't, in fact, think of any examples at all where a mistake that causes a 'leak' in Java is not also a leak in an equivalent program with explicit allocation.
Actually, MP2 is MPEG 1 Layer 2, and although it works ok at low bitrates, it's terrible at higher rates, and doesn't support sufficiently high rates for good reproduction of mastered audio.
If you have a circular loop of 15 objects and a reference to a single object, then you have references to *all 15 objects*. Any memory management strategy which frees the other objects is *unsafe*. Why is this a problem? If you didn't want the other 14 objects, it's trivial to clear the reference in the one you have, leaving the other 14 as an isolated chain which will then be freed.
The Sun GC used in HotSpot since at least Java 1.2 is 'perfect', which means it always correctly determines whether something is garbage or not; it never misses something which can legally be freed.
Java can, in some conditions, be *faster* than compiled native code because of optimisations that can only be performed at runtime (insufficient information available at compile-time). Nothing I use that's written in Java runs slower than equivalent native-code software (and I'm talking about total CPU cycles used, not perceived user speeds). The fantastic optimisation abililities of HotSpot do come at a significant cost in memory and a small cost in startup time, but I only start my IDE once a day and have six gigabytes of ram, so it doesn't bother me. =)
Java runs fine on my cellphone with 4MB of memory too, and is still speedy enough not to seem any slower than native Symbian apps.
The standard Sun JVM has a 'perfect' garbage collector; in this context, perfect means 'always collects exactly what is garbage'. It doesn't miss anything. If you are finding something not being collected, then you have a reference to it. Probably a conveniently invisible one. ;)
The GC doesn't care whether you're looping or not; in fact, there is an asynchronous GC (one which runs simultaneously to your program) now available for experimentation...
Nope, what I make is used by the product development team to build system images for particular machines. They're the ones who get to make things work =)
I was never having a discussion about implementing practical systems today, just about the theory of journalling. Maybe someone higher up in the thread was, I dunno. ;)
ext3 has the massive advantage (on Linux) of being based on ext2, and ext2 has been beaten on for so long by so many people in so many configs that it's pretty damn stable at this point. It's actually diverged a bit by this stage, though - its on-disk format is still 'ext2 with a journal' but the algorithms for allocation..etc have changed a little and work better in theory.
I'm an OS developer, so dwelling on implementation too much is bad for me. Gotta keep the idealistic goals in my sights, otherwise you just keep maintaining what's there instead of doign anything better =)
Ah; I did not realise that synchronous mode was the default, as I've always configured it to use softupdates before. If you have been talking about FFS synchronously mounted, then you are comparing apples to oranges; ANY fs mounted synchronously is safe, there's nothing special about FFS there.
I am rarely interested in reality of this kind of thing; implementation details are dull. Yes, it's entirely possible, probably even likely, that the FFS implementation is more stable and safe than many other filesystems - reiser in particular is notorious for having had many data-loss-inducing bugs in the past (though hopefully less at present). I have never lost data through an FS bug in any filesystem; my main systems variously use reiser, ext3 and FFS with softupdates. All the servers I run that require guarentees from the filesystem run on a filesystem which provides them: either reiser mounted synchronously, or ext3 with full data journalling.
So, from my personal experience, the implementations all work fine. I was never making a claim that any particular FS was better, merely correcting your original incorrect statement about the flaws in journalled filesystems. FFS has a fine history of reliability, but so does ext2 under normal use (i.e. when you always unmount cleanly). =)
Cool; I've been waiting for a stable LFS for a while. I'll hafta install NetBSD and have a fiddle.
I know all about log-structured filesystems too; but there are very few modern implementations that are stable and complete. They work well for certain access patterns, and not for others. Data-journalling FSes do indeed temporarily write to the journal, then commit to the final locations. The temporary writes are all fast appends, and the final writes can be saved until the disk is less busy to be written in a nice order through the elevator algorithm. The result is a modest performance hit on writes in exchange for getting all the safety benefits of a log-structured FS, and with no problems with read performance later.
I've read plenty about ffs, including the source, and have used it for a long time. It does allow the situation I describe - while metadata is preserved correctly in all but the most tricky of cases, data is not committed to disk until fsync() unless you mount your filesystem in synchronous mode (which means you have to take the performance penalty for doing so, and you can mount *any* fs in sync mode to get that guarantee if you don't mind it being slow). If you believe otherwise, please, show me the documentation/code that explains its commit behaviour differently, and I'll apologise for claiming you are wrong.
A data journalled FS never needs to be fsync()ed, and appending to the journal is much faster than syncing. For 'enterprise' systems (what an arbitrary definition that is; as I pointed out, all mail servers everywhere are required to make all possible efforts to avoid losing mail they have committed to delivering) applications typically fsync() at the appropriate times without any consideration for the filesystem they are running on, which usually means that a data-journalled system will perform worse, not better, than something like FFS, because everything gets committed to disk twice immediately (instead of the non-journal commit being postponed until a better time). Data-journalling is not *needed* in any situation, except where an application does not fsync() and still trusts writes to be synchronous (to 'fix' these apps on FFS requires mounting synchronously again..), but it is a better solution than manually syncing.
Preventing incomplete writes is not the same as preventing data loss. If the OS tells the app that data is written to disk, and it is not, then data has been lost. This never happens with a fully data-journalled filesystem, because the OS will not claim that the write is complete until it's at least been recorded in the journal. The write might not be complete if power dies right then, but *nobody has been told that it was*.
This is vital for any kind of database, mail server, or other system in which the server process has to be able to tell the client that their data is 'safe'. For example, the mail RFCs forbid a server to reply to the DATA part of an SMTP transaction with a confirmation until the mail has been written to permanent storage; replying 200 means that you have taken responsibility for ensuring the mail's delivery. Without full-data journalling, this means you have to fsync() after writing but before confirming the write; this can be slow. With full-data journalling, you are assured that the write has been journalled and will be replayed.
Mail servers and databases running on FFS or any other non-data-journalled filesystem have to fsync() frequently to preserve data integrity. This is not neccecary on a data-journalled FS.
That's the difference.
>Besides, you seem to be a bit clueless once more.. journaling filesystems do not prevent data loss, they prevent situations where your data and meta data is out of sync, and they provide for a rollback to resync those in case they do end up being out of sync still.
Actually, ext3 does prevent data loss in full data journalled mode. Also, a journalled FS will only ever have to roll back at most one transaction to recover; under all normal circumstances, not even that is neccecary as transactions can be replayed instead of undone.
-Os is not just -O2 without size-increasing optimisations. It also includes size-decreasing optimisations which can decrease speed further still. The speed difference between -Os and -O2 is actually quite dramatic.
Most binaries don't usually have working sets sufficiently large to make much difference, given that modern CPUs have huge caches. =)
You can make your own Windows CD that will install SP4; just take a copy of SP4, and any CD (SP3/2/1, gold, doesn't matter) and slipstream it. http://old.bink.nu/bootcd/ has instructions on how to do this while preserving the bootability of your CD. This can be done with 2000, XP or 2K3 and works with any service pack.
The film sometimes comes on several reels and is spliced by the cinema; this way, it's easier to transport (a single-reel film is *huge* and weighs one hell of a lot), and it can be shown at cinemas which still have dual-projector setups (not many these days, but they exist). Sometimes when a print of a film makes its way around the place for second runs..etc, it gets spliced into one reel, then cut back up, then spliced again..etc. =)
Solid support does not mean fixing the bugs; it means continuing to answer the phone, explain that the problem is known, and telling the customer how to work around it. While you're completely correct that most of Windows doesn't get fixed, and that many of the issues are design flaws, not implementation bugs, this *doesn't matter* to most users of Windows, home or corporate. As long as someone can tell them how to get around the problems, that's good enough. Sad but true.
Unfortunately, noexec is trivial to bypass, just run: /lib/ld-linux.so.2 /home/me/my-evil-binary
Sorry =)
Well of course you do, and it is only running like this to hide your emails to grandma right? Some amazing contraption that foils all attempts to analyze it. Experts from around the world have tried and failed against this mighty, forensic expert, crushing machine. It is people that think like you that makes this job so much fun.8-> My first guess would be you have a root kit installed, so sneaky. No way around that, grab the sledgehammer Joe!
I'm glad you're entertained. It runs like that because it was the logical conclusion of improving the security configuration of my currently deployed server; it's an interesting experiment and currently hosts no data. Perhaps it will at some point in the future.
Root kit? I think not.
* User's data is encrypted using keys generated from their logon exchange. The keys cannot be read from kernel memory while the user is logged in as root cannot read kernel memory or attach debuggers. The files cannot be read by a different user, even root, while the user is logged in as mandatory access control forbids it. You cannot su to that user because once you are logged in, no process you create can setuid().
* Swap space is encrypted.
* All processes run under least-privilege ACLs through mandatory access control.
* No user can run any program that is not owned and writable solely by root. Any root process not created during startup may not write to any file outside root's home directory. This means no installing or compiling anything.
* The machine's ssh host key is stored in RAM and not backed up anywhere; turning it off (to tamper with the drive contents) will lose you the key and thus no user will log into the machine once it has been tampered with. No process may access the host key other than sshd; no process may inspect sshd's memory or attach a debugger to it.
That's a pretty brief summary of the important points. Obviously, no system is perfect; I was interested in seeing how far down this road it's possible to go without requiring security hardware. Comments would be welcome.
It's all very well having clever forensic techniques existing; I'm not denying that they do. But there are not enough computer forensic experts that they can always take one along when they want to search someone's house. It's much easier to just take hardware. Especially if there is such a 'backlog' that it takes many months before an expert can take a look.
I'd be interested to know how you propose taking an image of a running disk on a machine controlled by your 'opponent', btw, as I have a server whose configuration is specifically designed to foil legal investigation, and it'd be nice to discover any more holes. Same goes for a RAM dump - surely you aren't expecting the machine to cooperate with you? =)
If I muddied the issue, I'm sorry; my original statement remains, though, that it is far more common and likely for hardware to be taken (whether it's from a company or an individual) than not. As for my 'sensationalised' statement, I have no first-hand experience, as my friend was not charged. However, it's been reported widely by many news sources whom I trust, and I have read more than one court transcript of the subsequent civil lawsuit.
Yes, this did happen in the USA. I am from the UK; I was visiting my friend in the US when his house was searched.
Whether he had in fact done anything wrong is pretty irrelevant to the story, if you read it correctly; my point was that the kind of evidence which would definately require examination of computers (such as logs from online services..etc) *did not exist* - he was explicitly told that they took the computers just because it's common to find evidence against someone for all manner of things on their computer. Your post suggested the opposite.
Damn, I wish I still had mod points. Mod parent up, this is a *fantastic* explanation.
This resembles how the Plan 9 filesystem works. It keeps *every* version of every file, forever (unless you use the admin tools to erase the archives). It was originally intended to use WORM jukeboxes to offload old copies, but now it's pretty cheap to run it using just huge amounts of online storage.
How can you get a good copy of the data without taking it apart? How do you know that the machine isn't rigged to erase stuff if you boot it up the wrong way? You have to take the disk out and duplicate it using your own equipment in controlled conditions. What is admissible in evidence is not the issue; what is actually done is. I'm sure that yes, sometimes they will do it 'the easy way', but more often than not, they don't. I should point out that yes, my friend's experience is also first hand knowledge to me, because I was *there* when the police arrived with their warrant.
You're assuming way too much about fairness; 'They have your IP, login used, ISP logs etc..', and 'When they show up at your house it's to gather the final bit of evidence'. This is wrong. Yes, this should be the way it works, but it isn't. The friend I mentioned had his house searched and all his computing equipment seized based on *hearsay* which had been reported to the police by a social worker; there was no computer-related evidence against him because he hadn't *done* anything and the police admitted this; they explicitly said that they were taking the computers 'just to be sure', rather than because they had any reason to think they were involved in a crime. At the time of the search they had absolutely no evidence to base a case on; the purpose of the search was to establish *anything at all*. He lived in a shared flat, and the police took the computers belonging to his housemates as well (who were not in any way implicated in the case), simply because they were connected by a network to share their cable modem connection.
They held the equipment for eleven months without arresting him, charging him or even interviewing him informally; they told him this was because there was a 'backlog' and that it had taken over nine months for the equipment to be first looked at. When they finally did contact him, it was to say that they hadn't found anything, and asking him to come and collect his equipment; no apology, and no further explanation. Evidently, they were intending to base their case on the contents of his computer, without having any evidence to suggest that there was anything incriminating there to find.
The net result of this was that he and three other people unlucky enough to be living in the same house were deprived of their posessions for nearly a year because the police thought that he might perhaps have been involved in a crime, despite having no evidence other than word of mouth that this was the case.
Perhaps you live in some kind of nice happy world where these things don't happen, but they do in this one. I will admit that this case is probably an extreme and it may well be rare, but it happened.
I never said anything about seizing company computers; when I said 'whole networks' I referred to home networks, like the one my friend had.