> flaw: you have to unpack the container to work on the files within, and that > leaves the unpackaged files open to interception. > > I've been using ScramDisk to store my critical data.
Bad news: your files may still be open to interception. When you open them with applications like Photoshop or MS Office or WinZIP, temporary copies are created outside of the container. Usually this is C:\WINDOWS\Temp\ or a temporary folder within your user home directory (for Win2K/XP).
If your computer crashes with the file still "open", the temporary copy is usually not deleted. If you closed them, they may still be recoverable by an UNDELETE utility (they are deleted when no longer needed).
Apart from this (annoying) behaviour of (usually large) applications, your files may also leak through the swapfile. When they are loaded to memory and stay there for long time, the OS might decide to swap them out to the swapfile (usually C:\win386.swap or C:\pagefile.sys). There they are not directly accessible, but tools like WinHEX (which read the harddrive sector-per-sector) can reveal the data.
Note also, that sophisticated attackers (let's say the FBI on their hunt for Osama) may even recover data that has been overwritten! The harddrives magnetic head doesn't follow the track by 100%. If you take apart the harddrive and "view" at the magnetic platters with a special instrument, you can visualize the big fat new data track and remainders of multiple previous versions of this track's data. Data recovery companies have those instruments. If you face attackers of this high degree, it is dangerous to write temporary data to the harddrive even when you MAKE SURE that they are "overwritten" afterwards.
The conclusion is that the only really safe way of handling this, is to NEVER EVER write ANYTHING to the harddrive without prior encryption. When no sector of the harddrive ever receives unprotected data, there is (by definition) absolutely no way to find unprotected data anywhere on it (no matter how sophisticated the recovery instruments).
DCPP is a product that does this, Safeboot is another. I even made one myself (for Win9x/DOS).
Most posts here indicate that it's easily defeated, because changing just one insignificant bit (eg for music files, an MP3-tag) results in a different hash value - thus defeating a blacklist of hashes. Of course they are right that this would work. But on the other hand, it would seriously harm the usefulness of P2P networks. If everybody would produce his "own" version of an MP3 song, that's different from all the other versions (by one MP3-tag frame), the software could not match them anymore.
As a result, a possible downloader would be presented thousands of DIFFERENT files with IDENTICAL naming. He would have to decide which one to download. He may then become victim of RIAA flooding and by chance download a "bad" file. Eg when 100x more bad versions are offered than good versions, he would have to download 100 times until he hits a good version. This doesn't have solution, because the solution would be to publish hash-lists of known-good-versions (like SHAREREACTOR) which could then be automatically merged into the blacklist of forbidden hashes by a RIAA robot script.
Another consequence is that the software couldn't do multi-source downloading anymore, because it can't know which files are identical (except for the MP3 tag). The downloader would have to rely on the SINGLE source to give him the FULL file. This might be feasable for MP3 (though already considerably degrade service quality), but is totally impossible for 700MB ISOs. This problem isn't solvable either, because the only solutions would be to either exclude the MP3 tags from the hash calculation (so that different files share the same hash), thus reverting to todays situation (where a hash blacklist would work). Or, one would have to split the file into various small chunks and modify only the first (so that all other chunks are common between all versions) and thus reduce the problem of single-source to just the first chunk. This however would keep all but the first chunk vulnerable to the blacklist approach and consequently is not a working solution either.
In short, P2P would not work anymore if the "defense" against blacklists would be any different from "ignore blacklist and download anyway".
Of course this is feasable! At least with todays steganography software.
What the software does, is to overwrite appearently insignificant portions of the "container" data (the audio/picture/text/whatever file that transports the smaller hidden file). The steganographers say (rightfully) that, by encrypting the hidden data with a strong-enough algorithm, it is indistinguishable from random data. Ie, no one (without the key used for encryption) would be able to tell if it's encrypted data, or perfectly random data.
However, the programmers of steganographic software now go one step further and say (wrongly!) that images and audio files carry random noise in their least significant bits (LSB). Certainly, the lowest of those 16 bits of CD quality audio does not carry much data. And granted, 16 bits give 96dB of dynamic range while analog master tapes (studio quality) only have about 80dB, and microphone technology hardly touches 96dB. The LSB of an audio wave file definately is noisy, no doubt about that.
But (big "BUT"), it is far from being perfectly random. In the LSB you might find 50Hz/60Hz hiss from the buildings electric cabeling. You might find characteristic noise that's typical for your brand of microphone, or even a kind of "noise fingerprint" that could be used to distinguish your microphone from others of the same brand (much like crime investigators can distinguish typewriters by analyzing the blackmail letter). Actually, an experiment showed that when cutting all but the LSB of a music wave file, the tune remains still recognizable!
What the stego programmers do is to replace that LSB (or even 4 least significant bits) with perfectly (pseudo) random data. That's a difference! I can just cut all but the LSB and check if it statistically matches perfect random data (whitenoise) or if "some of" the music tune is "somehow" in there (eg by correlation, a DSP technique).
The same applies for pictures. If the pictures were scanned, the lower bits will contain artefacts characteristic to the particular scanner used. Digital photos exhibit "signatures" of the CCD/CMOS chip used in the digicam. Etc.
The steganographers know this, while the programmers of stegano software deliberately ignores it. It's a solvable problem, but infinitely difficult. If you know what the stegano-detection software is looking for, you can easily avoid it. Just encrypt your hidden data to "perfect random" and then transform it (by adding data, thus loosing efficiency) to exhibit almost the same "fingerprint" signature as the data you are going to overwrite. In case of an audio wave file, impress a bit of the tune on your data.
But obviously, you can't reach perfection, because a 100% match means that you overwrite the original data with a 100% copy of it (-> you have stored 0 bytes of hidden data). Or you know how the detector works, what tresholds it uses to bin the file as "steganographic", and stay a little below the treshold. But that puts you on the risky side.. Will they change the tresholds? Will they check for other characteristics as well, something that you didn't address in your steganographic software?
That's why the steganographic programmers (not researchers!) ignore this problem. It has no practical solution. It's so much easier to just ignore it, and offer you the choice between 4 and 8 bits of hidden data per 16 bits of wave data (like eg "Scramdisk" does, a recommendable harddisk encryption software). This is better than nothing, but it is far from "not feasable" to detect!
> In 1992, I had a US Robotics Courier V.Everything modem that cost $500. I had to > purchase a 16650 UART chip for my serial port to get high speed transfers. It seemed > like a lot of software was still distributed on 3.5" disks. Fast forward 12 years > later to 2004. After all that time, modems run at exactly the same speed. V.92(?) > was fast when the 386 and 486 were kings but not any more.
Man, you should check your memory with a doctor.. In 1992 NMP5 was a new invention to speed up the transfers of those cool 2400 bps modems by a factor of up to 2. A little bit later the 2496 chipsets were released (2400 data, 9600 fax), and US-Robotics made the world go crazy with their hot 9600 HST (9600 forward 450 back) which later improved to 14400 HST (still 450 back channel). By that time, v32 and v32bis were standardized and gave 9600 / 14400 (full duplex!) to all.
Somewhere in 1994 there were 3 players, Telebit PEP Trailblazer with their amazing 18432bps technology, US-Robotis with their HST 14400 (which worked very well on noisy "satelite" connections, see Phrack/2600), and ZyXEL - the new player who improved over v32bis with their proprietary 16800 and later even 19200 bps modes.
V34 (28800 and later 33600) was standardized around 1995 if I recall correctly. X2/56K came a year later or so, but stayed proprietary solutions for a year (USR vs Rockwell), until v90 was defined. Only recently v92 was introduced as minor improvement - minor enough to not be employed in many places (eg in Europe most dialup access points are v90, not v92).
So, while in fact the US Robotics hardware remained the same over many years (the "dual standard" platform that came with HST 14400 (not 9600) and v32bis had enough horsepower to add the newer modes with firmware flash upgrades), the dialup modem technology has definately evolved in those 12 years. The only thing is that there is simply no way to stuff more data into a channel of such limited bandwidth. v34 is about the limit for "telephone line 3khz", and v92 is about the limit for "channel digitally sampled at 8khz 8bit". There's no more to do, everything is done already. You could make it cheaper or smaller or lighter if you really wanted to, but you can't make it faster.
Hey! If we combine this fact with yesterdays news we might just have solved that whole heatsink problem: just let the CPU produce light instead of heat, and then cut rectangular lightsink holes into the case to let the light dissipate..
Actually I prefer disc-based players, simply because I get tired of listening to the same music over and over again. With the same stuff on the drive for a long time (and even if it's lots of it), I'm unhappy. The advantage of a disc player is that you can swap the whole collection for a new one. Not a single one of those over-listened tunes remain. It's difficult to do that with a 20GB HD, even when you try hard.
That's why I favor disc players, although I'm rather a CD-R fan than MD. Actually I would love to see a DVD-R based player, but those are still to come.
> I own one of their players (The DP-450). I love it, simply love it.
I had the same player, and returned it. Hate to spoil, but
- it mutes the audio on AVIs with WMA audio encoding (DIVX AUDIO) - it freezes on most SVCD discs I tried, usually after fast-forwarding - it freezes on some older DIVX AVIs, usually within the first 20 seconds - it turns into a slideshow on DIVX3 with lots of stuff moving, like eg in
Matrix when the world turns into green hex numbers, or explosions with
particles flying around - it doesn't play MP3 discs headless (to replace CD player in stereo)
Other than that, it's a great product. I'd love to check their products again in a year or so.
Fingerprint-protected ATM cards won't work - ever
on
Fake ATM Fraud Expose
·
· Score: 2, Insightful
> It takes less than a dollar worth of materials and a matter of > seconds to capture a fingerprint off of... pretty much anything.
Yes! And I care to add for the sake of completeness, because this is just too often (deliberately?) ignored:
1. fingerprint-protected ATM card gets stolen 2. thief needs sample of owners' fingerprint to produce copy 3. ??????????....... bing! thief takes sample from ATM cards' surface. 4. profit! (well, or go to jail immediately)
Some guy from Poland "copied" the new Mercedes SLR, long before the real car hits the market. Mercedes tried to buy it from it to get it off the streets. Because that failed, they sue him.
> As long as you carefully transfer old files and their corresponding applications > to new storage media, you can hope that a emulator like this will give you access > to otherwise lost data.
Hm, not always true. Imagine you wrote your letters with some C64 editing software (maybe under GEOS). Now, even if you were still to own the files, and the software, and the emulator to run it and view your files - how would that enable you to actually USE them? You still can't incorporate them into the OfficeXP document that you're writing on the same (host) machine. And probably the only way to print them is to make a screen snapshot of the host machine, with the emulator window on top:-)
> I wonder if it can be used to keep my grades from being released to my parents, > I mean yes; they pay the tuition, but isnt the semi-unique sequence of D's and > F's my copyright?
Certainly you can sue the university for circumventing your resistance to reveal your copyrighted and well-covered skill profile. Printing and releasing it to third parties qualifies the university as professional class attacker, probably driven by monetary or political incentives. This should be enough to arrest them under DMCA for at least 6 months and then sending them to Russia.
> This means that often customers have to try several machines before finding > one that "works", but in most cases manage eventually to find a working machine
Great! Maybe I'll just eventually find another Cybercafe to check my mail on better working machines.
Remember that customers come and pay for service. They don't pay to be educated in OS advocacy.
> I forgot my ATM PIN, but weirdly, only when I used one particular ATM > - my brain worked fine at other ATMs.
Some ATMs have a keyboard like this:
7 8 9
4 5 6
1 2 3
0
Some ATMs have it like this:
1 2 3
4 5 6
7 8 9
0
When you run into one of the opposite category than you're used to, you won't ever get your PIN right. Either you don't look at the keypad and the ATM gets it wrong (1->7 etc). Or you look at the keypad and get confused yourself, forgetting how the PIN actually was.
Marc
Re:What about those of us
on
CNet on WinFS
·
· Score: 1
> In order to display the contents of C:\Foo\ the system has to search the entire > File Allocation Table to look for files that reside in C:\Foo\. This is why a > directory that has 1000 entries can sometimes take nearly forever to display in > Windows, and even longer if a networking situation is involved.
If it were true that searching the whole FAT is consuming so much time, it wouldn't matter if your open a directory with 1000 entries or _any_ other directory on the same partition (same FAT!).
As a matter of fact, "huge" directories don't open slowly because of their layout on the disk. The culprit is the windows file subsystem, which generates objects et al, for all the files that live in a directory. Even worse, if you don't just want access to the directory, but _also_ display the contents in a scrollbox (ie Explorer) - which generates yet another set of objects. You know, every file needs its icon read, with transpacency, the datestamp and filetype, the "default" app might be interrogated about the file, there's a tooltype help to be hooked, etc.
These problems are not cured by adding another layer of complexity. They will be brought even further to the surface.
Seems stupid, but happened to me. After using it on a daily basis for 2 years, it suddenly was "gone". Even writing a syllable based brute-force cracker didn't help, so after a week I gave up and reformatted.
> Does a USB mouse need to be able to transmit data in excess of 400mbit/sec?
Well, if the USB mouse sends slow packets, it blocks the bus for a long time. A lot of "fast" packets fit into one "slow" packet slot. Fast devices will suffer an unproportionally high bandwidth penalty, when you wiggle your el-cheapo USB2 mouse. After all, it's a shared resource.
> Apple gave him a file and promised their services to unlock it an > unlimited number of times to play it on his computers.
Following your analogy of the paint (good) and painter (service), it should be legal for the 2nd hand owner of the song file (good) to acquire a cracker to unlock it (service) for playing. It should be legal, too, to provide such service as company for all those 2nd hand owners, just like it is legal become a painter who works with color that was purchased elsewhere (eg from a competing painter).
So, something's wrong here. The analogy, or the current legal situation. Frankly, I don't know which of them is more flawed:-(
Very sad, the current bid is US $16,600.00. That is, it won't draw any attention to the DRM problem, but rather end as just-another-silly-ebay-auction (like "half-eaten burgers" or "the german language").
Your honor, my cat stepped on the keyboard just when I was about to read the Dell welcome screen. It was gone when I rebooted the computer to see it again. I think my cat cannot enter legal bindings with Dell.
+Funny, yes. But it might actually work when you embed the data into real pictures/movies. The technique of embedding is known as "steganography", and sometimes also as "digital watermark".
Scramdisk was an open source program to create encrypted containers (mount as driveletter in windows) in.WAV files. You could choose to use only the lower 4 bits (WAV 4x as large as hidden data) or the lower 8 bits (WAV 2x as large as data).
Be the first to post a FLAC (lossles audio compressor) of the next hot EMINEM album, with some 200 MB of your personal encrypted backup hidden in it, and your backup will live forever!
> RFID tags have the potential problem of a thief scanning my house to see what I have inside.
Yes! Certainly by the time that RFID tags are implanted into just about any product in your house, thieves also have developped bee-like robot drones to fly around your house and establish the necessary proximity for reading the tags!
We use RFID tags in our company for the security system, and soon also for door access. It's more convenient to just wave the tag, than to punch in security codes or unlock a door mechanically with a key. If the tag fails, or has been lost, or someone just doesn't want to use it, he can fallback to the "traditional" method. It's still there.
Slashdot Mirror
> flaw: you have to unpack the container to work on the files within, and that
> leaves the unpackaged files open to interception.
>
> I've been using ScramDisk to store my critical data.
Bad news: your files may still be open to interception. When you open them with applications like Photoshop or MS Office or WinZIP, temporary copies are created outside of the container. Usually this is C:\WINDOWS\Temp\ or a temporary folder within your user home directory (for Win2K/XP).
If your computer crashes with the file still "open", the temporary copy is usually not deleted. If you closed them, they may still be recoverable by an UNDELETE utility (they are deleted when no longer needed).
Apart from this (annoying) behaviour of (usually large) applications, your files may also leak through the swapfile. When they are loaded to memory and stay there for long time, the OS might decide to swap them out to the swapfile (usually C:\win386.swap or C:\pagefile.sys). There they are not directly accessible, but tools like WinHEX (which read the harddrive sector-per-sector) can reveal the data.
Note also, that sophisticated attackers (let's say the FBI on their hunt for Osama) may even recover data that has been overwritten! The harddrives magnetic head doesn't follow the track by 100%. If you take apart the harddrive and "view" at the magnetic platters with a special instrument, you can visualize the big fat new data track and remainders of multiple previous versions of this track's data. Data recovery companies have those instruments. If you face attackers of this high degree, it is dangerous to write temporary data to the harddrive even when you MAKE SURE that they are "overwritten" afterwards.
The conclusion is that the only really safe way of handling this, is to NEVER EVER write ANYTHING to the harddrive without prior encryption. When no sector of the harddrive ever receives unprotected data, there is (by definition) absolutely no way to find unprotected data anywhere on it (no matter how sophisticated the recovery instruments).
DCPP is a product that does this, Safeboot is another. I even made one myself (for Win9x/DOS).
Marc
Most posts here indicate that it's easily defeated, because changing just one insignificant bit (eg for music files, an MP3-tag) results in a different hash value - thus defeating a blacklist of hashes. Of course they are right that this would work. But on the other hand, it would seriously harm the usefulness of P2P networks. If everybody would produce his "own" version of an MP3 song, that's different from all the other versions (by one MP3-tag frame), the software could not match them anymore.
As a result, a possible downloader would be presented thousands of DIFFERENT files with IDENTICAL naming. He would have to decide which one to download. He may then become victim of RIAA flooding and by chance download a "bad" file. Eg when 100x more bad versions are offered than good versions, he would have to download 100 times until he hits a good version. This doesn't have solution, because the solution would be to publish hash-lists of known-good-versions (like SHAREREACTOR) which could then be automatically merged into the blacklist of forbidden hashes by a RIAA robot script.
Another consequence is that the software couldn't do multi-source downloading anymore, because it can't know which files are identical (except for the MP3 tag). The downloader would have to rely on the SINGLE source to give him the FULL file. This might be feasable for MP3 (though already considerably degrade service quality), but is totally impossible for 700MB ISOs. This problem isn't solvable either, because the only solutions would be to either exclude the MP3 tags from the hash calculation (so that different files share the same hash), thus reverting to todays situation (where a hash blacklist would work). Or, one would have to split the file into various small chunks and modify only the first (so that all other chunks are common between all versions) and thus reduce the problem of single-source to just the first chunk. This however would keep all but the first chunk vulnerable to the blacklist approach and consequently is not a working solution either.
In short, P2P would not work anymore if the "defense" against blacklists would be any different from "ignore blacklist and download anyway".
(at least in current P2P structures)
Marc
> I personally don't think that is feasible
Of course this is feasable! At least with todays steganography software.
What the software does, is to overwrite appearently insignificant portions of the "container" data (the audio/picture/text/whatever file that transports the smaller hidden file). The steganographers say (rightfully) that, by encrypting the hidden data with a strong-enough algorithm, it is indistinguishable from random data. Ie, no one (without the key used for encryption) would be able to tell if it's encrypted data, or perfectly random data.
However, the programmers of steganographic software now go one step further and say (wrongly!) that images and audio files carry random noise in their least significant bits (LSB). Certainly, the lowest of those 16 bits of CD quality audio does not carry much data. And granted, 16 bits give 96dB of dynamic range while analog master tapes (studio quality) only have about 80dB, and microphone technology hardly touches 96dB. The LSB of an audio wave file definately is noisy, no doubt about that.
But (big "BUT"), it is far from being perfectly random. In the LSB you might find 50Hz/60Hz hiss from the buildings electric cabeling. You might find characteristic noise that's typical for your brand of microphone, or even a kind of "noise fingerprint" that could be used to distinguish your microphone from others of the same brand (much like crime investigators can distinguish typewriters by analyzing the blackmail letter). Actually, an experiment showed that when cutting all but the LSB of a music wave file, the tune remains still recognizable!
What the stego programmers do is to replace that LSB (or even 4 least significant bits) with perfectly (pseudo) random data. That's a difference! I can just cut all but the LSB and check if it statistically matches perfect random data (whitenoise) or if "some of" the music tune is "somehow" in there (eg by correlation, a DSP technique).
The same applies for pictures. If the pictures were scanned, the lower bits will contain artefacts characteristic to the particular scanner used. Digital photos exhibit "signatures" of the CCD/CMOS chip used in the digicam. Etc.
The steganographers know this, while the programmers of stegano software deliberately ignores it. It's a solvable problem, but infinitely difficult. If you know what the stegano-detection software is looking for, you can easily avoid it. Just encrypt your hidden data to "perfect random" and then transform it (by adding data, thus loosing efficiency) to exhibit almost the same "fingerprint" signature as the data you are going to overwrite. In case of an audio wave file, impress a bit of the tune on your data.
But obviously, you can't reach perfection, because a 100% match means that you overwrite the original data with a 100% copy of it (-> you have stored 0 bytes of hidden data). Or you know how the detector works, what tresholds it uses to bin the file as "steganographic", and stay a little below the treshold. But that puts you on the risky side.. Will they change the tresholds? Will they check for other characteristics as well, something that you didn't address in your steganographic software?
That's why the steganographic programmers (not researchers!) ignore this problem. It has no practical solution. It's so much easier to just ignore it, and offer you the choice between 4 and 8 bits of hidden data per 16 bits of wave data (like eg "Scramdisk" does, a recommendable harddisk encryption software). This is better than nothing, but it is far from "not feasable" to detect!
Marc
> In 1992, I had a US Robotics Courier V.Everything modem that cost $500. I had to
> purchase a 16650 UART chip for my serial port to get high speed transfers. It seemed
> like a lot of software was still distributed on 3.5" disks. Fast forward 12 years
> later to 2004. After all that time, modems run at exactly the same speed. V.92(?)
> was fast when the 386 and 486 were kings but not any more.
Man, you should check your memory with a doctor.. In 1992 NMP5 was a new invention
to speed up the transfers of those cool 2400 bps modems by a factor of up to 2. A
little bit later the 2496 chipsets were released (2400 data, 9600 fax), and
US-Robotics made the world go crazy with their hot 9600 HST (9600 forward 450 back)
which later improved to 14400 HST (still 450 back channel). By that time, v32 and
v32bis were standardized and gave 9600 / 14400 (full duplex!) to all.
Somewhere in 1994 there were 3 players, Telebit PEP Trailblazer with their
amazing 18432bps technology, US-Robotis with their HST 14400 (which worked very
well on noisy "satelite" connections, see Phrack/2600), and ZyXEL - the new
player who improved over v32bis with their proprietary 16800 and later even 19200
bps modes.
V34 (28800 and later 33600) was standardized around 1995 if I recall correctly.
X2/56K came a year later or so, but stayed proprietary solutions for a year
(USR vs Rockwell), until v90 was defined. Only recently v92 was introduced as
minor improvement - minor enough to not be employed in many places (eg in
Europe most dialup access points are v90, not v92).
So, while in fact the US Robotics hardware remained the same over many years
(the "dual standard" platform that came with HST 14400 (not 9600) and v32bis
had enough horsepower to add the newer modes with firmware flash upgrades),
the dialup modem technology has definately evolved in those 12 years. The
only thing is that there is simply no way to stuff more data into a channel
of such limited bandwidth. v34 is about the limit for "telephone line 3khz",
and v92 is about the limit for "channel digitally sampled at 8khz 8bit".
There's no more to do, everything is done already. You could make it cheaper
or smaller or lighter if you really wanted to, but you can't make it faster.
Marc
> so tomorrow's cpu uses 150w. two light bulbs.
Hey! If we combine this fact with yesterdays news we might just have solved that whole heatsink problem: just let the CPU produce light instead of heat, and then cut rectangular lightsink holes into the case to let the light dissipate..
> I was tired of carrying media around with me
Actually I prefer disc-based players, simply because I get tired of listening to the same music over and over again. With the same stuff on the drive for a long time (and even if it's lots of it), I'm unhappy. The advantage of a disc player is that you can swap the whole collection for a new one. Not a single one of those over-listened tunes remain. It's difficult to do that with a 20GB HD, even when you try hard.
That's why I favor disc players, although I'm rather a CD-R fan than MD. Actually I would love to see a DVD-R based player, but those are still to come.
> If the 'villain' is using a mail program that displays HTML, his IP address is logged. ...or that of his ISPs' HTTP proxy.
> smooth playback came with 2.7.0
My experience is based on v2.7.4, Oct 2003.
> I own one of their players (The DP-450). I love it, simply love it.
I had the same player, and returned it. Hate to spoil, but
- it mutes the audio on AVIs with WMA audio encoding (DIVX AUDIO)
- it freezes on most SVCD discs I tried, usually after fast-forwarding
- it freezes on some older DIVX AVIs, usually within the first 20 seconds
- it turns into a slideshow on DIVX3 with lots of stuff moving, like eg in
Matrix when the world turns into green hex numbers, or explosions with
particles flying around
- it doesn't play MP3 discs headless (to replace CD player in stereo)
Other than that, it's a great product. I'd love to check their products again in a year or so.
> It takes less than a dollar worth of materials and a matter of
....... bing! thief takes sample from ATM cards' surface.
> seconds to capture a fingerprint off of... pretty much anything.
Yes! And I care to add for the sake of completeness, because this is
just too often (deliberately?) ignored:
1. fingerprint-protected ATM card gets stolen
2. thief needs sample of owners' fingerprint to produce copy
3. ??????????
4. profit! (well, or go to jail immediately)
It doesn't need molecular technology. They already try to come after you even today. See this nice (and real) example:
_ sl r-pl_us.htm
http://www.mb-portal.net/html/news/special/2003
Some guy from Poland "copied" the new Mercedes SLR, long before the real car hits the market. Mercedes tried to buy it from it to get it off the streets. Because that failed, they sue him.
Marc
> As long as you carefully transfer old files and their corresponding applications
:-)
> to new storage media, you can hope that a emulator like this will give you access
> to otherwise lost data.
Hm, not always true. Imagine you wrote your letters with some C64 editing software
(maybe under GEOS). Now, even if you were still to own the files, and the software,
and the emulator to run it and view your files - how would that enable you to actually
USE them? You still can't incorporate them into the OfficeXP document that you're
writing on the same (host) machine. And probably the only way to print them is to
make a screen snapshot of the host machine, with the emulator window on top
> I wonder if it can be used to keep my grades from being released to my parents,
> I mean yes; they pay the tuition, but isnt the semi-unique sequence of D's and
> F's my copyright?
Certainly you can sue the university for circumventing your resistance to reveal
your copyrighted and well-covered skill profile. Printing and releasing it to
third parties qualifies the university as professional class attacker, probably
driven by monetary or political incentives. This should be enough to arrest them
under DMCA for at least 6 months and then sending them to Russia.
> This means that often customers have to try several machines before finding
> one that "works", but in most cases manage eventually to find a working machine
Great! Maybe I'll just eventually find another Cybercafe to check
my mail on better working machines.
Remember that customers come and pay for service. They don't pay to
be educated in OS advocacy.
> I forgot my ATM PIN, but weirdly, only when I used one particular ATM
> - my brain worked fine at other ATMs.
Some ATMs have a keyboard like this:
7 8 9
4 5 6
1 2 3
0
Some ATMs have it like this:
1 2 3
4 5 6
7 8 9
0
When you run into one of the opposite category than you're used to, you won't ever
get your PIN right. Either you don't look at the keypad and the ATM gets it wrong
(1->7 etc). Or you look at the keypad and get confused yourself, forgetting how
the PIN actually was.
Marc
> In order to display the contents of C:\Foo\ the system has to search the entire
> File Allocation Table to look for files that reside in C:\Foo\. This is why a
> directory that has 1000 entries can sometimes take nearly forever to display in
> Windows, and even longer if a networking situation is involved.
If it were true that searching the whole FAT is consuming so much time, it
wouldn't matter if your open a directory with 1000 entries or _any_ other
directory on the same partition (same FAT!).
As a matter of fact, "huge" directories don't open slowly because of their
layout on the disk. The culprit is the windows file subsystem, which
generates objects et al, for all the files that live in a directory. Even
worse, if you don't just want access to the directory, but _also_ display
the contents in a scrollbox (ie Explorer) - which generates yet another set
of objects. You know, every file needs its icon read, with transpacency,
the datestamp and filetype, the "default" app might be interrogated about
the file, there's a tooltype help to be hooked, etc.
These problems are not cured by adding another layer of complexity. They
will be brought even further to the surface.
Marc
1. encrypt harddrive
2. fail to recall passphrase
Seems stupid, but happened to me. After using it on a daily basis for 2 years, it suddenly was "gone". Even writing a syllable based brute-force cracker didn't help, so after a week I gave up and reformatted.
> Does a USB mouse need to be able to transmit data in excess of 400mbit/sec?
Well, if the USB mouse sends slow packets, it blocks the bus for a long time. A lot of "fast" packets fit into one "slow" packet slot. Fast devices will suffer an unproportionally high bandwidth penalty, when you wiggle your el-cheapo USB2 mouse. After all, it's a shared resource.
Interesting.. Just yesterday the google groups database suffered failures. A lot of threads appeared in the search results, but couldn't be browsed.
> Apple gave him a file and promised their services to unlock it an
:-(
> unlimited number of times to play it on his computers.
Following your analogy of the paint (good) and painter (service), it should be legal for the 2nd hand owner of the song file (good) to acquire a cracker to unlock it (service) for playing. It should be legal, too, to provide such service as company for all those 2nd hand owners, just like it is legal become a painter who works with color that was purchased elsewhere (eg from a competing painter).
So, something's wrong here. The analogy, or the current legal situation. Frankly, I don't know which of them is more flawed
Very sad, the current bid is US $16,600.00. That is, it won't draw any attention to the DRM problem, but rather end as just-another-silly-ebay-auction (like "half-eaten burgers" or "the german language").
Your honor, my cat stepped on the keyboard just when I was about to read the Dell welcome screen. It was gone when I rebooted the computer to see it again. I think my cat cannot enter legal bindings with Dell.
+Funny, yes. But it might actually work when you embed the data into real pictures/movies. The technique of embedding is known as "steganography", and sometimes also as "digital watermark".
.WAV files. You could choose to use only the lower 4 bits (WAV 4x as large as hidden data) or the lower 8 bits (WAV 2x as large as data).
Scramdisk was an open source program to create encrypted containers (mount as driveletter in windows) in
Be the first to post a FLAC (lossles audio compressor) of the next hot EMINEM album, with some 200 MB of your personal encrypted backup hidden in it, and your backup will live forever!
Marc
> RFID tags have the potential problem of a thief scanning my house to see what I have inside.
Yes! Certainly by the time that RFID tags are implanted into just about any product in your house, thieves also have developped bee-like robot drones to fly around your house and establish the necessary proximity for reading the tags!
We use RFID tags in our company for the security system, and soon also for door access. It's more convenient to just wave the tag, than to punch in security codes or unlock a door mechanically with a key. If the tag fails, or has been lost, or someone just doesn't want to use it, he can fallback to the "traditional" method. It's still there.