I used Delphi, Builder, and Visual Studio - and I found Borland's intellisense much less responsive than the one in the Microsoft IDE.
Although I use it with not-that-complex projects, in my case the difference between speed is evident: it takes forever for the list of relevant options to show up in Borland's IDEs, while in VS the speed at which it shows up and can be used is the same, even after the project grows in complexity.
If the invisible object does not reflect light, and absorbs it instead, what will the outsiders see when looking at it? A dark spot?
We expect the invisible object to be 100% transparent, such that by looking through it we'll see the things behind it. But since the approach being discussed is not about transparency, it employs the absorbtion or rays instead.....
In some of my prior work doing vision systems for Sony Aibos for RoboCup, we had to deal with similar problems (find an orange ball in an image that may be only 3x2 pixels, while ignoring the boundaries between red and yellow objects).
Could you tell me which approach was used in your project? I mean, I don't need an uber-detailed description, just some key facts; ex: "we used correlation", or maybe you applied some sort of scaling\rotation - invariant techniques, etc.
As a student, I experimented with image processing last year, and I was amazed by all the cool things that could be done with different algorithms, but I never managed to write a tool that could recognize an object on an image. It sort of worked, but I haven't had time to finalize it and release a version that would work for others too, not only for me, only when launched with a debugger, and only at step-by-step execution:-)
How reliable is object detection on a 3x2 sample? Looking for an orange ball on such a small image... Hmm, won't it be just an orange pixel on such a small image?
Another question - was that pattern recognition? i.e. your program was fed with images of orange balls and it attempted to find them on the target images, or did you somehow define an orange ball (ex: "a closed curve, the color of which must be within the specified RGB range") and the program had to figure the rest by itself?
When the all of the write-cycles are used, the drive cannot be written to anymore, but the data can still be read from it. So the lost one-million-dollar presentation scenario is not likely to happen.
I once read this somewhere, the idea was the same - the brain somehow writes the current events to an area that normally stores 'old' data; afterwards it is assumed that the information is old, just because it was read from that area.
How does the brain 'catch up'? Maybe the process goes like this: - the file is read from the memory, - in the initial phase the system checks the file's time-stamp (when it was created) - it is seen that the date is old hence the event is labelled as 'it has happened before' - but when the file is entirely loaded, the metadata are processed and the brain can see that the time tag is not synchronized with reality.
In other words, its like having two sets of metadata: - the one provided by the file system - the one that is defined by the format of the file itself
When the info is different, the system understands that something is incorrect.
Can somebody with experience in the field tell us which data structures are used by the brain?
I happen to speak Romanian as well; "Cluj" - as the others have noted, will remind people of 'kludge', which is certainly not a welcome thing in software.
For the other slashdotters - 'Cluj' is prononced as 'Klooj' (as the 'ouge' in the French 'rouge'), so it doesn't sound like a kludge to a native romanian.
What you wrote applies to trojans and spyware. Viruses, on the other hand, will corrupt your EXE files or modify them in one way or another.
I've never seen pages with instructions about manually editing binary files; plus that viruses will alter a hell of a lot of files, hence doing it by hand is: - time-consuming - not really going to work if you don't understand what you're doing
This is what an antivirus can do though.
I think the correct approach is the 'no access rights' approach; a virus will simply be unable to modify critical system files. As for the user's files, you either make regular backups and revert to one of them, or use something like Disk Firewall (search for this).
If you don't choose the cheapest ones on the market, then things are not THAT bad. Some scanners will take into account factors such as skin humidity, temperature, etc. Thus you can't just 'copy/paste' the fingerprint; nor you can chop off the person's finger.
Take a look at the unique identifier generated by the biometric scanner, some generate a 600b 'digest' of the finger, others need several KB (hence more valuable data are stored).
I don't know about other types of biometric scanners.. I wonder, how voice scanners handle such cases; i.e. what makes it impossible to record one's voice and play it back? Perhaps they acquire some special unique features of the voice and then require the person to read a randomly generated string of characters? (so there's no way to conduct a replay attack)
No, I didn't say that. The idea is that a non-Linux person will expect that command to work out of the box (like I did when I first encountered the problem). Since it won't work, the person will revert to the default "Linux is too complex for me" state, being unaware of the real cause of the problem.
HOWEVER, if hard drive crashes and you need to use data recovery software (R-Stuio, GetDataBack, etc.) there is no straight forward way of decrypting the files even if you know the password.
Data loss can be really painful, if the data were encrypted. Normally, the decryption key is embedded into the encrypted file itself, but the encryption key (let's denote it with k_E) itself is encrypted with something, a password for example, or the password's hash. So, even though k_E resides inside the encrypted file, it doesn't make the file less secure, but it does make it more fragile. If there's a one bit change in the part of the file which holds k_E, then the data are gone forever. When k_E is obtained by decrypting it using the password (or the password's hash), it will not be correct, because of that flipped bit. So the data recovery programs you mentioned may be able to physically recover the data, but that is useless, because at the logical level - the gathered data are encrypted, and the true encryption key was lost. If something like CBC mode is used, then an error in the first decrypted block will propagate to the next, and so on.... What you will recover is a bunch of crap.
The solution is to make a backup of the area of the file which contains k_E, provided that the encryption software allows you to do that. If it doesn't, then I am afraid to use such a program (unless somebody guarantees I will never have power outages, and my hardware will never fail, and my OS is going to last forever, etc). Of course, you can always backup the encrypted file itself, but then the backup is of a much greater size that it could have been if you backed up only k_E.
It uses some data from the user's profile as an encryption key. If you re-install the OS, or delete the user account - your data are really gone.
You cannot access EFS encrypted data if you mount the hard disk to a different machine; nor you can do that if you're dual booting.
So volume-based encryption tools such as Private Disk or TrueCrypt are a better idea. Not only that they give you more features, but they use more reliable encryption mechanisms. (EFS uses 3DES, and you get AES if you apply a service pack)
I wouldn't call that a bad design. The primary objective is to make sure that there is only one correct way to plug the thing into the port - and this is what we have today.
You say the design is bad because you need to do more than "just touch", in order to figure out how it should enter the port; regardless of that, the primary objective is still achieved.
It's not the BEST solution, but it IS one that satisfies the requirement. They could have done better (this applies to anything that exists on this planet, since there's always room for improvement).
So what do you want Microsoft to do in order to make you respect them? - buy the company - force their devices to be migrated to some flavor of Windows - handle the expenses needed to teach the personnel the new stuff - waste time on the previous items ?
RSS feeds are a one-way communication method. What if you want to contact THEM?
IM? hah, are you telling me you've never received spam via ICQ & co? This is a common phenomenon; the difference is that most IM clients allow you to "receive messages only from people in my list" and silently ignore all the other requests.
But what if the server which sends out the keys also checks the origin of the request (if it comes from a different address - the request is discarded, logged, and authorities are announced).
Of course, identity spoofing is possible, but if the initial design implies that all requests are made via SSH or some other secure channel, then it will be more complicated to try to request the decryption key.
And another detail - the server could be configured in such a way that if there's a timeout of X minutes (assuming that the machines keep the session alive, or notify the server when they go offline), the future requests will not be processed until an authorized person notifies the administration, or something of that sort. In other words - if somebody fails to contact the server admin in time, it is automatically assumed that a problem occurred.
Whole disk encryption forces you to encrypt absolutely everything - meaning that more processing power will always be needed. (Well, the data resode on the encrypted partition)
But the good news is that all the software you have on the computer is working with encrypted files, without even realizing it. So you don't have to change anything in your infrastructure, update programs, pay extra, lose some functionality, etc
So, what you get is 100% transparent encryption in change for a performance penalty (which varies from machine to machine).
Directory encryption gives you the flexibility to choose which data you want encrypted, and which not (so performance loss is minimal). But then, you have to manually decrypt the stuff before using it, and sometimes you might forget to encrypt it - which can be a serious problem.
A solution is vritual drive encryption. A program creates a virtual drive which is seen as another drive in the system, any application works with it in a usual fashion (since encryption is transparent and on-the-fly), while you are not forced to copy all your files to that drive, hence you don't waste CPU cycles on encrypting things such as your high-scores in Minesweeper:-)
Mda... your post [and the other guy's too] are pretty interesting. This "I can change myself" philosophy is rather inefficient.
I know that there are people who like me with "all settings set to default", yet I stick to the approach you guys have been criticizing. The interesting thing is that I have conducted a minor research on the topic ( http://area51.cimaea.nl/arhiva/2006/03/perfect.htm l, but something tells me you don't happen to accidentally speak Romanian, do you?); the objective was to determine which are the features women are looking for in men. One of the conclusions was that
the requirements are so generic, that basically any guy meets them (with minor adjustments*). Probably because most of the requests were at the logical level, and targeted personal skills (communication, ability to listen, back her up emotionally, etc), vs. being 'physical' ones (such as skin-color, height, strength, etc)
Perhaps the fact that their "request-lists" (and the essays that accompanied them) were so generic means that women are also often choosing the "I can change myself" approach?
The weird part is that I do understand that this is a bad|inefficient|not-optimal|.. strategy (not only judging by your comments, but also as a conclusion I made from the things I've been thru), but deep inside I believe that I am flexible enough to be with anyone...
Eh well, I just wanted to thank you for the informative posts, I'll have new material for analysis:-)
Such tricks may be efficient when applied against little kids in schools, but government agencies cannot assume the risk to let one go just because he seems to be a fool [i.e. this guy acts like a fool just to get the three-letter-agencies off his tail]. Come on, in the real world things are "triple-checked several times".
There probably are logs that say that somebody has indeed gained access to sensitive data, and that 'someone' is this guy, so they're after him.
"Doubt anything that can be doubted", I think this is a basic principle of any government agency. So even if they had no proof of the fact that he did something, they should still pay attention.
"... are self-selected because they tend to know more about technology than your average PC buyer..."
You've got to be kidding. Mac users are even MORE clueless than the average PC buyer, in my experience. They buy Macs specifically to *avoid* having to know anything about technology.
If your assumption is correct, then it is very likely that if there will be an increase in the Mac-virus activity, there won't be much resistance, so Mac viruses' growth curve will be very steep in the initial phase. Personally, I don't think things will be that way, but I'm really curious about that one.
Can somebody recommend a client for Linux that allows me to limit the range of IP addresses to which the client can establish connections [using the rules written in an ipfilter.dat, or something similar].
Non-Java please. I've been looking for such a client, but still failed to find one. Any tips will be appreciated.
You're correct; which is why biometry is never used as a single authentication factor, it's always accompanied by "something you know" and "something you have".
You can easily change your password, or generate new key-pairs and store them on your smart card or token.
And there is another important detail you should know, biometric scanners only return a TRUE/FALSE result, which isn't perfect (it compares the result to a threshold, and if it is above the threshold, it is considered that the person is the same person who enrolled the first time, otherwise - no).
See this discussion about how biometric data are actually used:
Q: what happens if i cut my finger! i work in a sheetmetal shop and cut myself just about everyday, does the fingerprint being read flag as a 1 or 0? or is the geometry information actualy used in the encryption itself? i could live with finding a way to make the reader think my finger is there, but if it is used in the encryption that seems like a problem waiting to happen.
Well-encrypted data should look absolutely random. In that case, there are no patterns, hence compression algorithms won't be able to compress anything. Try to compress an encrypted file, and you will get something greater in size [the overhead used by the compression tool].
That's why I'm still attached to my good old Sony DNE570 cd-mp3 player. It is powered by 2 AA batteries, I use 1800 mAh Ni-MH rechargables, and even though it's been about 2 years since I got these, I still recharge them not more often than once a month. When the rechargables were new, they could sometimes last 2 months(!) Nowadays 2500 mAh rechargables are a common thing, switching to these will extend the lifetime even more.
I use the player on a daily basis, 2x1h for trips to the uni and back, and whenever I'm going somewhere nad have no one to talk to - I play music. I think I can safely call this "intensive use".
My friends have players of all colors and flavors, hard-disk based, flash-memory based, others use PDAs or their mobiles... but frankly - they all suck when it comes to power consumption.
Another thing is that even though the cd-player contains moving parts - I have *NEVER* experienced skipped sound! They might have a hell of an efficient buffering mechanism - it works flawlessly.
One more detail, the Sonic Stage software that came with it sucks indeed, which is why I never use ATRAC for my CDs (although they say that using ATRAC will lower power consumption too).
CD-players might be bigger and have a smaller storage capacity, but I have never seen an alternative which can beat my DNE570 at the 'battery life' parameter.
Slashdot Mirror
I used Delphi, Builder, and Visual Studio - and I found Borland's intellisense much less responsive than the one in the Microsoft IDE.
Although I use it with not-that-complex projects, in my case the difference between speed is evident: it takes forever for the list of relevant options to show up in Borland's IDEs, while in VS the speed at which it shows up and can be used is the same, even after the project grows in complexity.
If the invisible object does not reflect light, and absorbs it instead, what will the outsiders see when looking at it? A dark spot?
We expect the invisible object to be 100% transparent, such that by looking through it we'll see the things behind it. But since the approach being discussed is not about transparency, it employs the absorbtion or rays instead.....
Who can explain?
Could you tell me which approach was used in your project? I mean, I don't need an uber-detailed description, just some key facts; ex: "we used correlation", or maybe you applied some sort of scaling\rotation - invariant techniques, etc.
As a student, I experimented with image processing last year, and I was amazed by all the cool things that could be done with different algorithms, but I never managed to write a tool that could recognize an object on an image. It sort of worked, but I haven't had time to finalize it and release a version that would work for others too, not only for me, only when launched with a debugger, and only at step-by-step execution :-)
How reliable is object detection on a 3x2 sample? Looking for an orange ball on such a small image... Hmm, won't it be just an orange pixel on such a small image?
Another question - was that pattern recognition? i.e. your program was fed with images of orange balls and it attempted to find them on the target images, or did you somehow define an orange ball (ex: "a closed curve, the color of which must be within the specified RGB range") and the program had to figure the rest by itself?
When the all of the write-cycles are used, the drive cannot be written to anymore, but the data can still be read from it. So the lost one-million-dollar presentation scenario is not likely to happen.
I once read this somewhere, the idea was the same - the brain somehow writes the current events to an area that normally stores 'old' data; afterwards it is assumed that the information is old, just because it was read from that area.
How does the brain 'catch up'? Maybe the process goes like this:
- the file is read from the memory,
- in the initial phase the system checks the file's time-stamp (when it was created)
- it is seen that the date is old hence the event is labelled as 'it has happened before'
- but when the file is entirely loaded, the metadata are processed and the brain can see that the time tag is not synchronized with reality.
In other words, its like having two sets of metadata:
- the one provided by the file system
- the one that is defined by the format of the file itself
When the info is different, the system understands that something is incorrect.
Can somebody with experience in the field tell us which data structures are used by the brain?
I happen to speak Romanian as well; "Cluj" - as the others have noted, will remind people of 'kludge', which is certainly not a welcome thing in software.
For the other slashdotters - 'Cluj' is prononced as 'Klooj' (as the 'ouge' in the French 'rouge'), so it doesn't sound like a kludge to a native romanian.
What you wrote applies to trojans and spyware. Viruses, on the other hand, will corrupt your EXE files or modify them in one way or another.
I've never seen pages with instructions about manually editing binary files; plus that viruses will alter a hell of a lot of files, hence doing it by hand is:
- time-consuming
- not really going to work if you don't understand what you're doing
This is what an antivirus can do though.
I think the correct approach is the 'no access rights' approach; a virus will simply be unable to modify critical system files. As for the user's files, you either make regular backups and revert to one of them, or use something like Disk Firewall (search for this).
If you don't choose the cheapest ones on the market, then things are not THAT bad. Some scanners will take into account factors such as skin humidity, temperature, etc. Thus you can't just 'copy/paste' the fingerprint; nor you can chop off the person's finger.
Take a look at the unique identifier generated by the biometric scanner, some generate a 600b 'digest' of the finger, others need several KB (hence more valuable data are stored).
I don't know about other types of biometric scanners.. I wonder, how voice scanners handle such cases; i.e. what makes it impossible to record one's voice and play it back? Perhaps they acquire some special unique features of the voice and then require the person to read a randomly generated string of characters? (so there's no way to conduct a replay attack)
No, I didn't say that. The idea is that a non-Linux person will expect that command to work out of the box (like I did when I first encountered the problem). Since it won't work, the person will revert to the default "Linux is too complex for me" state, being unaware of the real cause of the problem.
Data loss can be really painful, if the data were encrypted. Normally, the decryption key is embedded into the encrypted file itself, but the encryption key (let's denote it with k_E) itself is encrypted with something, a password for example, or the password's hash. So, even though k_E resides inside the encrypted file, it doesn't make the file less secure, but it does make it more fragile. If there's a one bit change in the part of the file which holds k_E, then the data are gone forever. When k_E is obtained by decrypting it using the password (or the password's hash), it will not be correct, because of that flipped bit. So the data recovery programs you mentioned may be able to physically recover the data, but that is useless, because at the logical level - the gathered data are encrypted, and the true encryption key was lost. If something like CBC mode is used, then an error in the first decrypted block will propagate to the next, and so on.... What you will recover is a bunch of crap.
The solution is to make a backup of the area of the file which contains k_E, provided that the encryption software allows you to do that. If it doesn't, then I am afraid to use such a program (unless somebody guarantees I will never have power outages, and my hardware will never fail, and my OS is going to last forever, etc). Of course, you can always backup the encrypted file itself, but then the backup is of a much greater size that it could have been if you backed up only k_E.
It uses some data from the user's profile as an encryption key. If you re-install the OS, or delete the user account - your data are really gone.
You cannot access EFS encrypted data if you mount the hard disk to a different machine; nor you can do that if you're dual booting.
So volume-based encryption tools such as Private Disk or TrueCrypt are a better idea. Not only that they give you more features, but they use more reliable encryption mechanisms. (EFS uses 3DES, and you get AES if you apply a service pack)
But this will only work if you've configured yum to use the livna repository.
I wouldn't call that a bad design. The primary objective is to make sure that there is only one correct way to plug the thing into the port - and this is what we have today.
You say the design is bad because you need to do more than "just touch", in order to figure out how it should enter the port; regardless of that, the primary objective is still achieved.
It's not the BEST solution, but it IS one that satisfies the requirement. They could have done better (this applies to anything that exists on this planet, since there's always room for improvement).
So what do you want Microsoft to do in order to make you respect them?
- buy the company
- force their devices to be migrated to some flavor of Windows
- handle the expenses needed to teach the personnel the new stuff
- waste time on the previous items
?
Yes, that's a damn efficient strategy!
RSS feeds are a one-way communication method. What if you want to contact THEM?
IM? hah, are you telling me you've never received spam via ICQ & co? This is a common phenomenon; the difference is that most IM clients allow you to "receive messages only from people in my list" and silently ignore all the other requests.
This would require fantabulous network speeds, otherwise we're bound to watching slide-shows (or 'please wait' screens) for the rest of our lives.
But what if the server which sends out the keys also checks the origin of the request (if it comes from a different address - the request is discarded, logged, and authorities are announced).
Of course, identity spoofing is possible, but if the initial design implies that all requests are made via SSH or some other secure channel, then it will be more complicated to try to request the decryption key.
And another detail - the server could be configured in such a way that if there's a timeout of X minutes (assuming that the machines keep the session alive, or notify the server when they go offline), the future requests will not be processed until an authorized person notifies the administration, or something of that sort. In other words - if somebody fails to contact the server admin in time, it is automatically assumed that a problem occurred.
So, what you get is 100% transparent encryption in change for a performance penalty (which varies from machine to machine).
Directory encryption gives you the flexibility to choose which data you want encrypted, and which not (so performance loss is minimal). But then, you have to manually decrypt the stuff before using it, and sometimes you might forget to encrypt it - which can be a serious problem.
A solution is vritual drive encryption . A program creates a virtual drive which is seen as another drive in the system, any application works with it in a usual fashion (since encryption is transparent and on-the-fly), while you are not forced to copy all your files to that drive, hence you don't waste CPU cycles on encrypting things such as your high-scores in Minesweeper
Look for a program called Private Disk.
I know that there are people who like me with "all settings set to default", yet I stick to the approach you guys have been criticizing. The interesting thing is that I have conducted a minor research on the topic ( http://area51.cimaea.nl/arhiva/2006/03/perfect.ht
The weird part is that I do understand that this is a bad|inefficient|not-optimal|.. strategy (not only judging by your comments, but also as a conclusion I made from the things I've been thru), but deep inside I believe that I am flexible enough to be with anyone...
Eh well, I just wanted to thank you for the informative posts, I'll have new material for analysis
* minor usually becomes major, according to
Such tricks may be efficient when applied against little kids in schools, but government agencies cannot assume the risk to let one go just because he seems to be a fool [i.e. this guy acts like a fool just to get the three-letter-agencies off his tail]. Come on, in the real world things are "triple-checked several times".
There probably are logs that say that somebody has indeed gained access to sensitive data, and that 'someone' is this guy, so they're after him.
"Doubt anything that can be doubted", I think this is a basic principle of any government agency. So even if they had no proof of the fact that he did something, they should still pay attention.
If your assumption is correct, then it is very likely that if there will be an increase in the Mac-virus activity, there won't be much resistance, so Mac viruses' growth curve will be very steep in the initial phase. Personally, I don't think things will be that way, but I'm really curious about that one.
Can somebody recommend a client for Linux that allows me to limit the range of IP addresses to which the client can establish connections [using the rules written in an ipfilter.dat, or something similar].
Non-Java please. I've been looking for such a client, but still failed to find one. Any tips will be appreciated.
You can easily change your password, or generate new key-pairs and store them on your smart card or token.
And there is another important detail you should know, biometric scanners only return a TRUE/FALSE result, which isn't perfect (it compares the result to a threshold, and if it is above the threshold, it is considered that the person is the same person who enrolled the first time, otherwise - no). See this discussion about how biometric data are actually used:
Well-encrypted data should look absolutely random. In that case, there are no patterns, hence compression algorithms won't be able to compress anything. Try to compress an encrypted file, and you will get something greater in size [the overhead used by the compression tool].
Note: applies to _well_-encrypted data
That's why I'm still attached to my good old Sony DNE570 cd-mp3 player. It is powered by 2 AA batteries, I use 1800 mAh Ni-MH rechargables, and even though it's been about 2 years since I got these, I still recharge them not more often than once a month. When the rechargables were new, they could sometimes last 2 months(!) Nowadays 2500 mAh rechargables are a common thing, switching to these will extend the lifetime even more.
I use the player on a daily basis, 2x1h for trips to the uni and back, and whenever I'm going somewhere nad have no one to talk to - I play music. I think I can safely call this "intensive use".
My friends have players of all colors and flavors, hard-disk based, flash-memory based, others use PDAs or their mobiles... but frankly - they all suck when it comes to power consumption.
Another thing is that even though the cd-player contains moving parts - I have *NEVER* experienced skipped sound! They might have a hell of an efficient buffering mechanism - it works flawlessly.
One more detail, the Sonic Stage software that came with it sucks indeed, which is why I never use ATRAC for my CDs (although they say that using ATRAC will lower power consumption too).
CD-players might be bigger and have a smaller storage capacity, but I have never seen an alternative which can beat my DNE570 at the 'battery life' parameter.