Biometrics work fine when the identifying equipment is in the control of the entity that is granting access, and there is human oversight of the process. For example, going through customs. No one is going to be able to take your dangling eye and hold it in front of a retinal scanner while guards are looking on.
Being able to use one password is part of what makes SRP so nice - the server never sees your password, and can't use your verifier to impersonate you on another server, even if you used the same password on both. Even if someone were to hijack the server, the best they could do is brute force it, and the algorithm is expensive enough that it would take quite a while. External attempts to brute force can be easily detected by the server and countered (e.g. add a short delay after a wrong try, getting longer for each one, as well as log it and notify the (authentic) user the next time they authenticate).
One way of improving security on a simple password would be to use a 256-bit (or whatever) random bit string as an authenticator for SRP. Store it, encrypted with a memorized password, on a security server - access the security server using either the same or a different password (with SRP) to retrieve the encrypted string, then decrypt it in the browser and authenticate using SRP with the target server. The security server never sees the decrypted authenticator (and since it is a random bit string, there's no way to brute force it except by trying it against a target server). The only point of attack is in the browser.
For higher security requirements, use a second password to decrypt the same bit string, and use that with a more conventional hash-based authentication after the primary authentication using SRP - the alarms go off if someone gets in through the first level but can't authenticate at the second level.
Yes, what if? You wear glasses. Primary change as we age is that there is less ability to change focus. Visual acuity itself shouldn't change much unless there are other problems (cataracts, diabetes) until around age 65, at which point Age-Related Macular Degeneration can become a problem for some people.
Mac G5 (dual 1.8) with a couple Maxtor 250-300GB SATA drives - transferring files between them I get easily over 10MB/sec (which is rather startling when I consider that my first computer, a Lisa, had a total of 10MB of disk space).
You mean, the Control key? Control-left (or only)-click does the exact same thing as right-click in almost everything (the application can distinguish them and do different things, but the application could make you type with your fingers all off by one letter - if it is a reasonable program, it will make right-click and control-click be equivalent.
Hey, how'd I get logged out? Anyway, responding to my own post, Shift-scrollwheel DOES do horizontal scrolling! Wow, I should have played around more with it before posting!
What's really aggravating is that Apple had a system global value for dots-per-inch from the very first version of MacOS. Nothing ever used it, though, because nothing ever set it to anything but 72. Running Wish on MacOSX, it thinks there are 72 dpi, although it is easy enough to fix that:
Any such statement would have to include a distance from the.01" dots...my monitor is 100 DPI, and I can certainly see single dots, the difference between 2 dots next to each other and 2 dots separated by one pixel, or offset diagonally, from about 3 feet away.
The human eye has a resolution of about.3-.35 arc-minutes (2 dots have to be more than that apart to be distinguishable as separate points), according to this interesting page. Based on that, at 3 feet you'd be able to see between 272-318 dpi. That page doesn't say anything about it, but color vision has less resolution (blue being particularly bad).
On a 33" 16:9 screen (which is the same height as a 27" 4:3 screen), sitting 8 feet away, you'd need about 120 dpi, or about 3450x1940 pixels. A 100 degree wide angle of view is about 20000 pixels for full resolution (although you don't really get full resolution except in a fairly small portion of your field of view - but a monitor would need to have full resolution wherever you might look). Vertical field of view is somewhat less then horizontal, so you could get by with only 16000 pixels vertically, for a total of about 320 mega-pixels for the ultimate display. Well, OK, not ultimate, you'd really want a full 360 degree spherical view for that...which would take about 825 mega-pixels (though you could get by with much less with a head-mounted display and head-tracking).
Umm, I think you mean cos(arctan(900/1440)) * 17", which yields about 14.4" or a DPI of just about 100. An easier way to think of it is sqrt(1440^2 + 900^2)/17 for DPI. Then divide 1440 and 900 each by DPI to get the dimensions (14.4 x 9).
All the patent clause is saying is that if you sue them for violating a patent you hold with respect to reading or writing such files, they will remove your right to use the patent. That actually sounds reasonable. Let's say you come up with a great new method of writing the XML for one of these files in a much faster way, and you patent it. Microsoft is saying "in exchange for us allowing you to use our patents to read and write these files, you agree that we can use any of your patents when reading or writing these files" (well, not really, but it has the effect of that). Why should they let you use their patents when you won't let them use yours?
That's ridiculous. I can take BSD code, compile it, and sell it to you and prohibit you from making copies or derivatives of it. I can certainly include a notice in the code I'm distributing that has the Microsoft-required statement, and prohibit you from removing that notice. That's what the BSD license allows. About the only thing it requires is that copyright notices not be removed.
You include the Microsoft-required statement in your copyright notice. Boom, GPL compatible. The GPL allows requiring that copyright notices be left intact. GIve permission for people to remove the Microsoft statement - that way they can take portions of your code and use it in other things that don't (supposedly) infringe on Microsoft's patents.
Of course, if you already have a machine that can do output to a separate TV screen (e.g. Powerbook, Mac G5), you get that for free. Not a reason by itself to get a Powerbook or G5, but there are plenty of other reasons, so playing DVDs on a TV is just a bonus. If you don't have a large TV (27" at least), a 19" LCD monitor can show a widescreen DVD at full resolution for a lot less than a big High Definition TV. Not so good for watching with friends, but for just watching alone, it is arguably better than most TVs.
You can usually pick one up at Best Buy for around $30-40, sometimes that's with a rebate, sometimes it isn't. Cheapest I've found for a D-Link 802.11g router, with rebate, was $29 (and I had no problem with the rebate). Often it is cheaper to get a wireless router than an equivalent router without the wireless (particularly the 802.11b devices) - and since you can disable the wireless, who cares if it is included?
I wouldn't mind single devices that do lots of different things - the problem is that it is difficult enough to find single devices that do ONE thing well without compromising. The likelihood of finding a device that does multiple things well without compromising is a good example of "infinitesimal".
For example, a camera phone with a PDA in it - is the camera any good? Is the PDA one that I can write software for with open tools? Does the phone have adequate sound quality? Is the screen readable? And, in and out and all about, is the user interface any good?
As convergence continues, the real reason the RMS wanted open source comes to the front: I want the ability to make my devices work the way I want them to. It's hard enough to get good uncompromising hardware, but then I'm stuck with firmware that I can't modify and doesn't do things the way I want to do them.
I want the wearable computer, with a pair of glasses that project a true 3-D image directly into my eyes, give me good sound (ear buds or bone conduction), use that throat muscle voice pickup trick, have a microphone and video camera pickup, can project a laser keyboard on any surface, have a wireless connection (e.g. Bluetooth) to data gloves, printers, etc. Cell phone should then simply be an external radio transceiver (to keep the higher powered radio transmissions away from my head), and would simply be a connection to The Network. I interact with it using my choice of free or proprietary software, or write my own if I'm so inclined. The networking protocols are ubiquitous, both for the long-range and short range communications.
Until that's available, I'll stick with a separate camera, PDA, cell phone, MP3 player, GPS, watch, calculator. Or, rather, I'll stick with my watch and calculator, I don't have any of those other things. And I'm not so happy with the calculator (not since HP stopped making RPN calculators).
Nice Catch-22: if you don't like the fact that we've made changes that make your software become unusable, you can indicate that you don't accept these changes by not using the software. Continuing to use the software indicates acceptance that you can no longer use the software.
As an aside, this has nothing to do with any agreement made by Intuit with the end user. It SHOULD have to do with each individual bank deciding whether they want to continue to support old versions of the software. Instead, Intuit has gained a monopoly position here, and is able to dictate terms to all the banks saying "you can no longer support old versions of the software". Intuit enforces that by having the software check back with Intuit to verify that the bank in question has paid their licensing fees, probably a new fee for each new version of Quicken, even if the data format hasn't changed, and as someone else pointed out, for different platforms as well ("Your bank doesn't support Macintosh" == "Your bank didn't pay the extra fee for us to authorize your software to accept data from them on a Mac even though the data format is exactly the same"). It has nothing to do with Intuit needing to do this - the old software is working fine, it doesn't need "support". It has to do with Intuit interfering in the "free market" between banks and customers by telling each who they can do business with (customer: you can't do business with this bank, because they haven't paid their fee; bank: you can't do business with this customer because they haven't upgraded to the latest version).
BSD allows suid scripts, Linux doesn't. Some shells don't let you run suid (real and effective user id not the same), or require special options (e.g. csh requires a -b option).
Some of the security issues with suid shells are:
as mentioned, playing around with environment variables that a shell script may not verify. PERL does special handling to not trust environment variables when running suid, for example, so is relatively safe (and PERL does special handling to re-launch an suid version of PERL if the script is marked as suid, so it can do it even if the OS doesn't support suid scripts).
passing "interesting" file names as arguments to a suid script, specifically file names that appear to be switches passed to the script processor. This is why csh requires the-b option.
Changing the location a symbolic link points to between the time the script processor is launched and it tries to open the script file - create a symbolic link to the shell script, then delete the link and create a new one pointing to your own script. This could be dealt with by the script doing an fstat AFTER opening it to verify that an authorized script is executing (which causes potential problems when executing other non-suid scripts later).
As there are easy ways around it, and it makes you at least think about the problem and do it right, Linux not allowing it is probably for the best. It also avoids trying to figure out which suid operation to honor if both the script and processor are marked suid to different uids (although you could think of some convoluted scheme where the script is sgid, and the processor can only be executed by that group and is suid).
One way of making this more secure would be to have the kernel attach the script on a different file descriptor (e.g. fd 3) - this would allow the processor to see if anything funny is going on.
"Tiger's Eye" "Bird's Eye" diseased maple -- no match
"Tiger's Eye" "Bird's Eye" maple -- plenty of matches, here's a good image of Bird's Eye maple (with a reference to Tiger's Eye). Most of the Tiger's Eye examples seem to be in guitars or hi-fi consoles, but there's a reference to a cruise ship with a "tiger's eye maple" table (at playboy.com). There's a barrette for sale, but the Tiger's Eye in it is the stone, not the wood.
Lots of references to Tiger's Eye stone, but the only references to it and petrified wood are comparisons to the process, where portions of stone are replaced with other minerals. There's a nice example of Tiger's Eye quartz, and a slightly more detailed description, including some information about how it is formed (including the comparison to petrified wood).
Sorry, I know what hill climbing is, I was asking how evolution isn't hill climbing. It is a prototypical hill climbing process, which is why sometimes it gets stuck in a dead end top-of-the-hill local maximum.
In your examples, you only address one aspect of efficiency. Efficiency always has to be evaluated in the context of SURVIVAL (actually, reproduction, which is survival of offspring). Some aspects of the grasshopper might be more efficient in your example, but if it leads to the grasshopper being "SOL", then it wasn't efficient, by definition.
What do you mean, evolution isn't hill climbing? Yes, organisms tend to become more complex, but not at a cost in efficiency. If it isn't more efficient (at survival), it won't last. It may be more inefficient in some ways, but the efficiency with respect to survival will always tend to increase.
Yeah, I've been saying for years that the Web was basically a step backwards into batch processing, except that back then at least there was the concept of a real session. HTTP was designed as a stateless protocol for a reason, to avoid the overhead of keeping track of state. Tacking on kludges to keep track of state is ridiculous.
What I don't understand about this JSON is why everyone thinks that parsing Javascript is oh-so-much-faster than parsing XML. Not that I think XML is great either, mind you.
Tcl also uses script-passing for RPC, and has a plug-in for doing Tcl-script in browsers. I bet this would have been a bit cleaner using Tcl as the interchange instead of Javascript. Tcl has a well developed security model for keeping scripts like this safe. If the only reason for using something is "well, it's already built in to the browser", you're locking yourself in to an evolutionary dead-end. Well, the web browser did that to us Internet-ages (i.e. 5-10 years) ago already, but it isn't necessarily too late. Tacking on more stuff like this just digs us in deeper, though.
Network apps using Java make a whole lot more sense to me, at this point. Implement the Web browser part in Java if you must, but do scripting in "native" Java (which can be easily sandboxed). For "Web apps", use a (caching) network class loader and be done with it. If you don't need the Web browser part, it doesn't have to be there.
Slashdot Mirror
Biometrics work fine when the identifying equipment is in the control of the entity that is granting access, and there is human oversight of the process. For example, going through customs. No one is going to be able to take your dangling eye and hold it in front of a retinal scanner while guards are looking on.
Being able to use one password is part of what makes SRP so nice - the server never sees your password, and can't use your verifier to impersonate you on another server, even if you used the same password on both. Even if someone were to hijack the server, the best they could do is brute force it, and the algorithm is expensive enough that it would take quite a while. External attempts to brute force can be easily detected by the server and countered (e.g. add a short delay after a wrong try, getting longer for each one, as well as log it and notify the (authentic) user the next time they authenticate).
One way of improving security on a simple password would be to use a 256-bit (or whatever) random bit string as an authenticator for SRP. Store it, encrypted with a memorized password, on a security server - access the security server using either the same or a different password (with SRP) to retrieve the encrypted string, then decrypt it in the browser and authenticate using SRP with the target server. The security server never sees the decrypted authenticator (and since it is a random bit string, there's no way to brute force it except by trying it against a target server). The only point of attack is in the browser.
For higher security requirements, use a second password to decrypt the same bit string, and use that with a more conventional hash-based authentication after the primary authentication using SRP - the alarms go off if someone gets in through the first level but can't authenticate at the second level.
HP got a patent for this in July of 2003 (in patent #6,586,965), filed Oct 2001. What is news is that they've successfully demonstrated it working.
Yes, what if? You wear glasses. Primary change as we age is that there is less ability to change focus. Visual acuity itself shouldn't change much unless there are other problems (cataracts, diabetes) until around age 65, at which point Age-Related Macular Degeneration can become a problem for some people.
Mac G5 (dual 1.8) with a couple Maxtor 250-300GB SATA drives - transferring files between them I get easily over 10MB/sec (which is rather startling when I consider that my first computer, a Lisa, had a total of 10MB of disk space).
You mean, the Control key? Control-left (or only)-click does the exact same thing as right-click in almost everything (the application can distinguish them and do different things, but the application could make you type with your fingers all off by one letter - if it is a reasonable program, it will make right-click and control-click be equivalent.
Hey, how'd I get logged out? Anyway, responding to my own post, Shift-scrollwheel DOES do horizontal scrolling! Wow, I should have played around more with it before posting!
That's ok, in two or three years at that resolution, you'll be "stupid" too...
What's really aggravating is that Apple had a system global value for dots-per-inch from the very first version of MacOS. Nothing ever used it, though, because nothing ever set it to anything but 72. Running Wish on MacOSX, it thinks there are 72 dpi, although it is easy enough to fix that:
which then makes unit-based coordinates work correctly, e.g.will create a 1 inch rectangle.Any such statement would have to include a distance from the .01" dots...my monitor is 100 DPI, and I can certainly see single dots, the difference between 2 dots next to each other and 2 dots separated by one pixel, or offset diagonally, from about 3 feet away.
The human eye has a resolution of about .3-.35 arc-minutes (2 dots have to be more than that apart to be distinguishable as separate points), according to this interesting page. Based on that, at 3 feet you'd be able to see between 272-318 dpi. That page doesn't say anything about it, but color vision has less resolution (blue being particularly bad).
On a 33" 16:9 screen (which is the same height as a 27" 4:3 screen), sitting 8 feet away, you'd need about 120 dpi, or about 3450x1940 pixels. A 100 degree wide angle of view is about 20000 pixels for full resolution (although you don't really get full resolution except in a fairly small portion of your field of view - but a monitor would need to have full resolution wherever you might look). Vertical field of view is somewhat less then horizontal, so you could get by with only 16000 pixels vertically, for a total of about 320 mega-pixels for the ultimate display. Well, OK, not ultimate, you'd really want a full 360 degree spherical view for that...which would take about 825 mega-pixels (though you could get by with much less with a head-mounted display and head-tracking).
Umm, I think you mean cos(arctan(900/1440)) * 17", which yields about 14.4" or a DPI of just about 100. An easier way to think of it is sqrt(1440^2 + 900^2)/17 for DPI. Then divide 1440 and 900 each by DPI to get the dimensions (14.4 x 9).
State Farm offers this as a separate policy.
All the patent clause is saying is that if you sue them for violating a patent you hold with respect to reading or writing such files, they will remove your right to use the patent. That actually sounds reasonable. Let's say you come up with a great new method of writing the XML for one of these files in a much faster way, and you patent it. Microsoft is saying "in exchange for us allowing you to use our patents to read and write these files, you agree that we can use any of your patents when reading or writing these files" (well, not really, but it has the effect of that). Why should they let you use their patents when you won't let them use yours?
That's ridiculous. I can take BSD code, compile it, and sell it to you and prohibit you from making copies or derivatives of it. I can certainly include a notice in the code I'm distributing that has the Microsoft-required statement, and prohibit you from removing that notice. That's what the BSD license allows. About the only thing it requires is that copyright notices not be removed.
You include the Microsoft-required statement in your copyright notice. Boom, GPL compatible. The GPL allows requiring that copyright notices be left intact. GIve permission for people to remove the Microsoft statement - that way they can take portions of your code and use it in other things that don't (supposedly) infringe on Microsoft's patents.
Of course, if you already have a machine that can do output to a separate TV screen (e.g. Powerbook, Mac G5), you get that for free. Not a reason by itself to get a Powerbook or G5, but there are plenty of other reasons, so playing DVDs on a TV is just a bonus. If you don't have a large TV (27" at least), a 19" LCD monitor can show a widescreen DVD at full resolution for a lot less than a big High Definition TV. Not so good for watching with friends, but for just watching alone, it is arguably better than most TVs.
The kind with an amp so you can play the vast collection of downloaded music on the laptop, of course. Or a LAN party.
You can usually pick one up at Best Buy for around $30-40, sometimes that's with a rebate, sometimes it isn't. Cheapest I've found for a D-Link 802.11g router, with rebate, was $29 (and I had no problem with the rebate). Often it is cheaper to get a wireless router than an equivalent router without the wireless (particularly the 802.11b devices) - and since you can disable the wireless, who cares if it is included?
I wouldn't mind single devices that do lots of different things - the problem is that it is difficult enough to find single devices that do ONE thing well without compromising. The likelihood of finding a device that does multiple things well without compromising is a good example of "infinitesimal".
For example, a camera phone with a PDA in it - is the camera any good? Is the PDA one that I can write software for with open tools? Does the phone have adequate sound quality? Is the screen readable? And, in and out and all about, is the user interface any good?
As convergence continues, the real reason the RMS wanted open source comes to the front: I want the ability to make my devices work the way I want them to. It's hard enough to get good uncompromising hardware, but then I'm stuck with firmware that I can't modify and doesn't do things the way I want to do them.
I want the wearable computer, with a pair of glasses that project a true 3-D image directly into my eyes, give me good sound (ear buds or bone conduction), use that throat muscle voice pickup trick, have a microphone and video camera pickup, can project a laser keyboard on any surface, have a wireless connection (e.g. Bluetooth) to data gloves, printers, etc. Cell phone should then simply be an external radio transceiver (to keep the higher powered radio transmissions away from my head), and would simply be a connection to The Network. I interact with it using my choice of free or proprietary software, or write my own if I'm so inclined. The networking protocols are ubiquitous, both for the long-range and short range communications.
Until that's available, I'll stick with a separate camera, PDA, cell phone, MP3 player, GPS, watch, calculator. Or, rather, I'll stick with my watch and calculator, I don't have any of those other things. And I'm not so happy with the calculator (not since HP stopped making RPN calculators).
Nice Catch-22: if you don't like the fact that we've made changes that make your software become unusable, you can indicate that you don't accept these changes by not using the software. Continuing to use the software indicates acceptance that you can no longer use the software.
As an aside, this has nothing to do with any agreement made by Intuit with the end user. It SHOULD have to do with each individual bank deciding whether they want to continue to support old versions of the software. Instead, Intuit has gained a monopoly position here, and is able to dictate terms to all the banks saying "you can no longer support old versions of the software". Intuit enforces that by having the software check back with Intuit to verify that the bank in question has paid their licensing fees, probably a new fee for each new version of Quicken, even if the data format hasn't changed, and as someone else pointed out, for different platforms as well ("Your bank doesn't support Macintosh" == "Your bank didn't pay the extra fee for us to authorize your software to accept data from them on a Mac even though the data format is exactly the same"). It has nothing to do with Intuit needing to do this - the old software is working fine, it doesn't need "support". It has to do with Intuit interfering in the "free market" between banks and customers by telling each who they can do business with (customer: you can't do business with this bank, because they haven't paid their fee; bank: you can't do business with this customer because they haven't upgraded to the latest version).
BSD allows suid scripts, Linux doesn't. Some shells don't let you run suid (real and effective user id not the same), or require special options (e.g. csh requires a -b option).
Some of the security issues with suid shells are:
As there are easy ways around it, and it makes you at least think about the problem and do it right, Linux not allowing it is probably for the best. It also avoids trying to figure out which suid operation to honor if both the script and processor are marked suid to different uids (although you could think of some convoluted scheme where the script is sgid, and the processor can only be executed by that group and is suid).
One way of making this more secure would be to have the kernel attach the script on a different file descriptor (e.g. fd 3) - this would allow the processor to see if anything funny is going on.
"Tiger's Eye" "Bird's Eye" diseased maple -- no match
"Tiger's Eye" "Bird's Eye" maple -- plenty of matches, here's a good image of Bird's Eye maple (with a reference to Tiger's Eye). Most of the Tiger's Eye examples seem to be in guitars or hi-fi consoles, but there's a reference to a cruise ship with a "tiger's eye maple" table (at playboy.com). There's a barrette for sale, but the Tiger's Eye in it is the stone, not the wood.
Lots of references to Tiger's Eye stone, but the only references to it and petrified wood are comparisons to the process, where portions of stone are replaced with other minerals. There's a nice example of Tiger's Eye quartz, and a slightly more detailed description, including some information about how it is formed (including the comparison to petrified wood).
Sorry, I know what hill climbing is, I was asking how evolution isn't hill climbing. It is a prototypical hill climbing process, which is why sometimes it gets stuck in a dead end top-of-the-hill local maximum.
In your examples, you only address one aspect of efficiency. Efficiency always has to be evaluated in the context of SURVIVAL (actually, reproduction, which is survival of offspring). Some aspects of the grasshopper might be more efficient in your example, but if it leads to the grasshopper being "SOL", then it wasn't efficient, by definition.
What do you mean, evolution isn't hill climbing? Yes, organisms tend to become more complex, but not at a cost in efficiency. If it isn't more efficient (at survival), it won't last. It may be more inefficient in some ways, but the efficiency with respect to survival will always tend to increase.
Yeah, I've been saying for years that the Web was basically a step backwards into batch processing, except that back then at least there was the concept of a real session. HTTP was designed as a stateless protocol for a reason, to avoid the overhead of keeping track of state. Tacking on kludges to keep track of state is ridiculous.
What I don't understand about this JSON is why everyone thinks that parsing Javascript is oh-so-much-faster than parsing XML. Not that I think XML is great either, mind you.
Tcl also uses script-passing for RPC, and has a plug-in for doing Tcl-script in browsers. I bet this would have been a bit cleaner using Tcl as the interchange instead of Javascript. Tcl has a well developed security model for keeping scripts like this safe. If the only reason for using something is "well, it's already built in to the browser", you're locking yourself in to an evolutionary dead-end. Well, the web browser did that to us Internet-ages (i.e. 5-10 years) ago already, but it isn't necessarily too late. Tacking on more stuff like this just digs us in deeper, though.
Network apps using Java make a whole lot more sense to me, at this point. Implement the Web browser part in Java if you must, but do scripting in "native" Java (which can be easily sandboxed). For "Web apps", use a (caching) network class loader and be done with it. If you don't need the Web browser part, it doesn't have to be there.