And we have Constitutional limits on power to prevent tyranny of the majority. Unfortunately, that doesn't seem to be working so well as of late, mostly because we have a Supreme Court that largely sees the Constitution as a piece of paper rather than as a crucial set of limits on government.
I'd be willing to bet a large set of people who do not fly are ignorant of what people who are dissatisfied with the TSA are upset about.
You don't even have to recognize the security theater for what it is in order to dislike having to choose between being photographed naked or groped in order to fly. You can think that the TSA is doing a good job of protecting public safety at a macro level and still hate what they're doing at an individual level. It takes a bit of mental gymnastics for most folks, but it certainly isn't all that unlikely.
Either way, as far as I'm concerned, anyone who has not flown recently should have absolutely no voice in the matter. In fact, unaffected parties should never have any say in anything, whether it is straight people denying gays the right to marry, white men denying blacks and women the right to vote, or non-fliers deciding on what security measures fliers should have to endure. There's no difference except in degree.
You are comparing single-core processors to a quad-core processor. Of course the i5 is going to be faster. It would be better to divide the performance of the i5 by 4, to represent the performance of a single core of the processor.
Based on those numbers, the quad-core i5 processor is approximately equal in performance to 335 Raspberry Pi cores (at this type of computation). Thus, even a single-core of the i5 would still be equivalent to almost 84 Raspberry Pi cores, and costs only about $600 even if you buy it pre-built as a laptop. By contrast, 335 Raspberry Pi machines would cost almost $12,000 (or more like $16k by the time you add power supplies, power cords, and flash cards). Even dividing by four, 84 of them (with power and flash) would cost about as much as a new Mac Pro with 12 cores. That, in turn, is equivalent to somewhere on the order of a Porsche Boxster worth of Raspberry Pi units as far as computing power goes.:-)
And they're also not remotely efficient in power-per-watt. That Mac Pro takes about as much power as only a hundred Raspberry Pi boards, assuming a mythical 100% efficient power supply for the Pi, but would outperform a couple of thousand of them. So current Intel offerings are somewhere around 20x as efficient as a chip based on an eight-year-old ARM cell design. No surprise there.
But that's really not the point. In performance-per-dollar or performance-per-watt, clusters of several-year-old CPUs will almost never be cost-effective. What makes them interesting is that they can be a cheap platform for letting folks test cluster-computing (distributed multiprocessing) apps experimentally without investing a huge amount of money. When testing how well an algorithm scales, assuming your tests don't tie up the hardware for such a long period of time that other folks in the class can't use it, it really doesn't matter how fast the total performance of the hardware is. What matters is the number of nodes. Thus, for supercomputer research, these sorts of devices are seriously cool.
Well, upon rereading the summary, it turns out it's a purely nominative use of a mark to describe an uncovered product. Still, it's a factual, nominative use, without which it would be impossible to describe the product in question, so it should be pretty solidly on the "this guy has no case" side of the line.
Now whether he has a case against the publisher or not is another question.
If the only difference is the size of a single view, the technique you describe might make sense. Usually, that isn't the case, though, so as a rule, manipulating view sizes in code is a bad way to design an iPad app.
When adding iPad support to an app, you typically provide a separate NIB file (a file that describes the size, location, and resizing behavior of windows and views) for the larger screen size so that you don't do any view resizing in code at all. In that iPad-sized NIB file, you either make your views a different size or add additional views to take up the extra space (or, more commonly, both), depending on your needs.
I have no idea which technique will be adopted by folks developing software for iPhone 5.
3. If such a trademark were ever actually granted, and they did NOT file suit against someone else using it, that would amount to failure to protect the trademark, thus rendering it invalid. So they HAVE to sue (or at least issue cease and desist).
No, a mark holder does not have to file suit or even send off nasty letters when other people use the same thing. That's not required at all. So long as the relevant group of customers are not confused about the commonality of sources of goods and services labeled with the mark, there is no confusion, and no danger to the viability of the mark, and thus no need to take action to defend it lest it be lost.
Worse than that, they can be countersued for doing so, as purely nominative use of a mark to name the covered product is prima facie protected use of a trademark. It would be particularly extraordinary if such a suit ever succeeded. As such, this lawsuit, if it ever hit the courts, would almost certainly be deemed frivolous, possibly rising to the level of barratry, and at a minimum, this clown would owe the reviewers attorneys' fees and probably additional damages.
Or keep personally identifiable information separate from everything else. Ensure that you cannot get to one data set from the other and vice versa. Use login information as a hash into the identity database and the behaviors database. If you must store any time stamps on database records, make sure you do so in a way that prevents using them to easily correlate the two data sets (e.g. update the time stamp on the personal info record only when the user changes his/her password, address, or whatever, rather than at every login).
To the extent possible, store the information locally on the client side, or if you must store it on the server (for synchronizing between multiple computers), encrypt it client-side and send the encrypted blob to the server. Sure, that wouldn't prevent you from getting the information (because you control the site's code), but it does make it unlikely that somebody who compromises your database server can get the information.
And there's a hosting provider that has never made a billing error?
The only people who could get seriously screwed by such a mistake are people who paid for a service costing hundreds or thousands of dollars on a debit card. Those folks have reason to be angry if they got hit with overdraft fees, but most banks will refund those fees (since the charge that caused them was in error) assuming the person calls the bank and explains the situation.
Most of their customers probably didn't even notice it unless they hit a monthly billing cycle within about a two or three day period....
Out of curiosity, what problems have you had with Dreamhost? They've been rock solid for me.
Now GoDaddy... *that* was terrible. Their UNIX boxes had process limits measured in seconds, which meant that just trying to upload a single RAW image file tended to fail about eight times out of ten. And in spite of those limits, their web servers would frequently stall for the better part of a minute before replying to an HTTP request. They were horribly managed hacks. It is no surprise that anonymous could DDOS their systems. I doubt it took more than one machine on a moderately fast connection and five lines of shell script.
Oh, and when I asked them to move me to a different server, they said no. I cancelled my account less than a week after I first set it up.
I've been using DH ever since, and have had no problems. To be fair, I'm mostly serving static content right now (except for a custom PHPBB instance with a custom authentication system that I'm just starting to set up). YMMV if you are trying to run Wordpress or something similarly bloated and heavyweight.
Because the bandwidth of the fiber is shared among all the people at your node. If everyone simultaneously cranked up iTunes or BitTorrent and started downloading movies at the same time, I doubt you would maintain that 20+ Mbps service speed.
Also because your speeds and cost are so atypical that it isn't even funny. Most Internet service in rural areas seems to average about $50 a month and provides less bandwidth.
Finally, because we're rapidly approaching the point where Internet bandwidth is hopelessly insufficient to meet users' needs. With users wanting to watch downloaded or streaming movies, perform network-based backups, use virtual computers (e.g. using VLC) that are maintained and backed up by someone else, etc., the performance and throughput of the outgoing pipe is getting more and more critical for a good user experience, and it just hasn't kept up with internal infrastructure speeds.
It's hard to even find a switch these days that isn't gigabit, yet as soon as you leave the premises, you're at a clunky single-to-low-double-digit megabit speed—about two orders of magnitude slower. That's just not acceptable. We're at the point where there's little reason to further upgrade the speeds of internal networks, mainly because of the lack of performance upstream. That's really rather bad news for all the industries that depend on the sale of upgraded equipment, and it potentially holds back lots of useful innovations—concepts that we haven't even dared to dream about because they are so completely infeasible over double-digit megabit networks.... Distributed social networking. Mass-market acceptance of video-and-voice-over-IP. True virtual/cloud computing (doing video editing using a hard drive in another state, for example). And so on.
Gigabit (uplink and downlink) to the premises would solve SO many problems.
Except that users cannot choose a less vulnerable OS. All OSes have significant numbers of vulnerabilities in that database.
most would consider it ridiculous to not install Flash on the modern web browser... or Adobe Reader....
Actually, that's exactly what I'm arguing. You should not install Flash. Or Adobe Reader (at least the plug-in version of it). Or Java.
Also, users will be secure if they don't install anything at all.
In theory, yes. In practice, web browsers are much more critical as far as vulnerabilities go because they are constantly being exposed to untrusted content. Most applications are not. Software that runs in that environment has to be extremely well written. Browsers are fairly well written, with remarkably few serious security holes. Flash is the exact opposite. Adobe Reader and Java are somewhere in-between.
... or not install MS Office [with all the macro viruses]...
That one is a little different. It isn't hard to avoid that risk. Just don't use MS Office to open content that other people send you. You can't do that with a web browser, and because Java, Flash, and Adobe Reader run *in* a browser, you can't readily avoid using them to open content that other people send you, either. Your only option for improving the security of those tools, short of fixing all the security holes, is to not install them, or at minimum, to use something like ClickToFlash to disable them except on specific, user-chosen websites. The danger of that approach, however, is that websites will interpret the presence of those sorts of extensions as an indication that you have the plug-in in question, and will fail to fall back to alternative technologies even when available. Also, their stats will show that those plug-ins are still available almost everywhere, thus slowing the demise of those (almost always unnecessary) browser plug-ins.
Yes, in the short term, refusing to install those plug-ins may cause some temporary pain (though not much—I can only think of a handful of sites that I've visited in the past five years that required Flash, and exactly one that required Java; PDF is on its way out as an end-user delivery medium, too, as HTML/CSS improves), but as more people do this, fewer companies will grow to rely on those technologies, and the need for using them will continue to diminish. The advent of iOS went a long way towards killing these technologies, and the web is a safer place for their absence. The next step is up to the desktop user community and the developer community.
To the extent that Flash or Java are necessary to work around lack of features in a browser, file bugs and propose solutions. To the extent that websites require Flash or Java, complain to the site admins, and then don't go to those sites. When web browser developers have to go to insane lengths like running each tab in a separate process so that when Flash crashes (frequently), it doesn't take down the whole browser, it should be obvious that there's a problem. More precisely, when it represents the vast majority of browser crashes, there's a BIG problem. And although Java doesn't cause nearly as many browser crashes (possibly in part because there are many, many fewer sites that actually use Java), it has still had an abysmal security record lately, having been the sole successful vector for compromising OS X in recent memory. Any platform that is being actively used as a vector for compromising users' computers is a serious security risk and should be avoided unless there is no other alternative.
One more point to note... if you're going to get in a single-car accident at 65 MPH and hit a pylon or something, you're dead. If you do it at 85 or 90 MPH, you're just REALLY dead. Same difference.
No, even that mostly comes down to a question of whether the road was designed for that speed or not. A properly designed road would not let you hit it head-on at 65, much less 85 or 90. This is done by putting a guard rail in front of the post and making it long enough that if you are traveling at an angle where you would hit the post head-on, you will crumple a hundred feet of guard rail first and slow down to almost nothing, and if you are not traveling at an angle where you'd hit it head-on, you will deal the guard rail and/or the post at best a glancing blow, then keep going in a slightly different direction.
Heck, an ideal design for a 100 MPH road would probably have concrete walls down both sides (possibly with continuous guard rails inside them) and no posts to run into in the first place. The worst you can do there is get into a situation where you hit a wall out control and go spinning off and hit the other wall eventually.
Of course, those designs break down when the road is wide enough to turn and hit a wall head-on (e.g. an eight-lane or ten-lane road), but again, that's a fault of the road design.
Anyone that rejects AGW... is, quite simply, ignorant.
Careful, there. There's a broad spectrum of rejection. Anyone who says that humans haven't affected the climate at all is ignorant. However, this still leaves many questions for which the answers are less than adequate:
How much of the change in temperature is caused by humans, and how much is caused by natural cyclical variation?
How much is caused by our CO2 emissions versus our considerable water vapor emissions?
Is it really wise to "fix" the problem with solutions that often replace CO2 with more water vapor?
And so on. But the biggest reason so many people doubt AGW entirely (which is probably going too far) is because there are so many vocal AGW proponents who cross the line into loony wing-nut territory by suggesting utterly implausible theories like a "runaway greenhouse effect" (despite the greenhouse gasses being lower than at many points in our planet's history), using AGW as an excuse to push the progress of technology backwards through forced electrical conservation and light bulb bans rather than forwards by funding improvements in clean power generation or pushing for coal bans, trying to convince everyone to use horribly time-inefficient short-range public transportation instead of pressuring automakers to improve fuel efficiency or pressuring them to move to all-electric designs or pressuring governments to make traffic lights more efficient or pushing for pro-telecommuting legislation and policies, etc.
In short, the AGW proponents did this to themselves with their Greenpeace-esque agenda of causing the biggest negative impact on the most people to artificially raise awareness instead of pushing for changes that maximally improve the problem with minimal negative (or even positive) impact. I have no real sympathy for them now when they whine that nobody is listening.
Maybe when we get some believable AGW proponents (scientists) in the foreground and stop letting the extremists abuse AGW to promote their own twisted political agendas, things will start to improve.
That's not a fair comparison. Users don't realistically have a choice about whether to run an OS. They do have a choice whether to add additional vulnerabilities by tacking on an unnecessary abstraction layer like Flash or Java.
In other words, the current design tries too hard to cram too much into too little space. I tend to agree, though for non-case-mounted uses, I could see the compact size being useful. It's definitely a tradeoff.
Not necessarily. It *might* be possible to store the data used during the verification process in such a way that it would not be sufficient to reconstruct the key data in the absence of the actual print. For example, if you need ten data points, you might choose fifty data points and store a copy of forty of them, which you would then use to distort the scanned image so that the remaining ten would be correct with a high degree of probability. That *might* get you your ten robust data points without actually telling you anything about them.
Alternatively, you could use a cryptographic system designed so that each piece of data provides a portion of a key, and any k of the n pieces of data are sufficient to reconstruct the key. This might be done in any number of ways, mostly involving sophiticated checksums and error correction, and you might even have to have the equivalent of a.par file for your crypto key, but it should be possible, at least in theory.
Or it might require combining techniques like these with who-knows-how-many other techniques.
I have no idea if anybody actually has developed such technology, though. Biometrics are insecure for so many other reasons (triviality of duplication and the inability to change them being the most obvious) that they really aren't that interesting to me.:-)
It's not the fact that it is plain text that concerns me. What concerns me is that it uses a password at all. I'm not personally familiar with how Windows does things, but if you were implementing this on OS X, you'd implement a custom authorization plug-in that would be queried for permission instead of using a password. I assume that this is just a case of the implementors of this particular fingerprint reader tool not knowing what they're doing.
One of two things is true: either the device can reproducibly generate a long enough crypto key (based on the fingerprint itself) to provide adequate protection on its own or it doesn't. If it does, you don't need to store the password. That crypto key can be used for things like full disk encryption, etc. If it doesn't, then no matter how you store the pasword, it will never be secure, because the key must be stored somewhere, too, and as long as the crypto key is stored somewhere, it doesn't matter if the password is in plain text, ROT-13, XORed with a known sequence, or encrypted with AES-128 or AES-256; if Eve = Alice, Eve gets your password. Encryption is basically useless here for the same reason that DRM is basically useless. In other words, no matter how the password is stored, it is fundamentally and unavoidably insecure by design.
The only way to do something like this with even the slightest bit of security is with an authorization plug-in. Further, unless the hardware/software can reproducibly generate a long crypto key from a fingerprint, the only way to support full disk encryption would involve storing the key in some form, in which case it would be fundamentally insecure because you'd have the Alice = Eve problem again.
It's not just the lack of mounting holes. Give me a quarter inch of empty board space all the way around with no components and I don't need holes. Just build a case where the board slides in. The problem with this board design is that it has neither mounting holes nor even one single solitary contact point where you can put physical pressure on both sides of the board in the same spot without knocking components off. Opposite the CE logo are the major power regulating components for the whole board. Opposite the RPi logo are dozens of tiny surface-mount components. The closest you can get to a friction mounting involves removing the GPIO header and/or putting pressure on top of the USB stack (moderately safe) or video jack (moderately safe).
Or if I knew I wasn't ever going to use the GPIO header on a particular board, I guess I could remove it, cut the traces, and drill a screw hole in the corner where they belong, and another one almost opposite it, between the USB and Ethernet jacks, assuming there aren't any hidden traces in an inner layer of the board that I'm not able to see, but if the last board layer artwork posted (http://www.raspberrypi.org/wp-content/uploads/2011/11/gerbers2.png) is correct, then it's safe to drill there. That said, since I already see GPIO pins that I know are connected, but show no traces, I don't have much faith in that image.
Because of the lack of mounting holes, it is very hard to design a snug-fitting case for the the first-gen Raspberry Pi. I'm pretty sure the component placement precludes using a rail-mounted design (slide-in) because there are too many components right at the edge of the board. And there are components at every corner of the board. About the only thing I can come up with are flat rubber bumpers where the CE logo is, under the Ethernet jack, and under the video jack, with different-thickness rubber bumpers on top of the USB jacks and the Pi logo, coupled with insanely tight tolerances around the edges of the board to eliminate sliding back and forth.
I ordered five of these a week ago and learned about the inability to mount them rigidly after I ordered them. They shipped yesterday. I'm not happy. I definitely would not have ordered them had I known that in just a few weeks, I'd be able to get one without this rather serious design flaw.
Obligatory Hitchhiker's Guide to the Galaxy quote:
"But Mr. Dent, the plans have been available in the local planning office for the last nine months."
"Oh yes, well, as soon as I heard I went straight round to see them, yesterday afternoon. You hadn't exactly gone out of your way to call attention to them, had you? I mean, like actually telling anybody or anything."
"But the plans were on display..."
"On display? I eventually had to go down to the cellar to find them."
"That's the display department."
"With a flashlight."
"Ah, well, the lights had probably gone."
"So had the stairs."
"But look, you found the notice, didn't you?"
"Yes," said Arthur, "yes I did. It was on display on the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.’"
Actually, I've been wondering if the whole "no drinks through security" rule was made at the request of the airport merchants who charge three dollars for a $0.30 bottle of water....
Slashdot Mirror
And we have Constitutional limits on power to prevent tyranny of the majority. Unfortunately, that doesn't seem to be working so well as of late, mostly because we have a Supreme Court that largely sees the Constitution as a piece of paper rather than as a crucial set of limits on government.
You don't even have to recognize the security theater for what it is in order to dislike having to choose between being photographed naked or groped in order to fly. You can think that the TSA is doing a good job of protecting public safety at a macro level and still hate what they're doing at an individual level. It takes a bit of mental gymnastics for most folks, but it certainly isn't all that unlikely.
Either way, as far as I'm concerned, anyone who has not flown recently should have absolutely no voice in the matter. In fact, unaffected parties should never have any say in anything, whether it is straight people denying gays the right to marry, white men denying blacks and women the right to vote, or non-fliers deciding on what security measures fliers should have to endure. There's no difference except in degree.
Based on those numbers, the quad-core i5 processor is approximately equal in performance to 335 Raspberry Pi cores (at this type of computation). Thus, even a single-core of the i5 would still be equivalent to almost 84 Raspberry Pi cores, and costs only about $600 even if you buy it pre-built as a laptop. By contrast, 335 Raspberry Pi machines would cost almost $12,000 (or more like $16k by the time you add power supplies, power cords, and flash cards). Even dividing by four, 84 of them (with power and flash) would cost about as much as a new Mac Pro with 12 cores. That, in turn, is equivalent to somewhere on the order of a Porsche Boxster worth of Raspberry Pi units as far as computing power goes. :-)
And they're also not remotely efficient in power-per-watt. That Mac Pro takes about as much power as only a hundred Raspberry Pi boards, assuming a mythical 100% efficient power supply for the Pi, but would outperform a couple of thousand of them. So current Intel offerings are somewhere around 20x as efficient as a chip based on an eight-year-old ARM cell design. No surprise there.
But that's really not the point. In performance-per-dollar or performance-per-watt, clusters of several-year-old CPUs will almost never be cost-effective. What makes them interesting is that they can be a cheap platform for letting folks test cluster-computing (distributed multiprocessing) apps experimentally without investing a huge amount of money. When testing how well an algorithm scales, assuming your tests don't tie up the hardware for such a long period of time that other folks in the class can't use it, it really doesn't matter how fast the total performance of the hardware is. What matters is the number of nodes. Thus, for supercomputer research, these sorts of devices are seriously cool.
Well, upon rereading the summary, it turns out it's a purely nominative use of a mark to describe an uncovered product. Still, it's a factual, nominative use, without which it would be impossible to describe the product in question, so it should be pretty solidly on the "this guy has no case" side of the line.
Now whether he has a case against the publisher or not is another question.
Was it the one where the AT&T guy read something like a hundred marketing statements in a row off of note cards?
If the only difference is the size of a single view, the technique you describe might make sense. Usually, that isn't the case, though, so as a rule, manipulating view sizes in code is a bad way to design an iPad app.
When adding iPad support to an app, you typically provide a separate NIB file (a file that describes the size, location, and resizing behavior of windows and views) for the larger screen size so that you don't do any view resizing in code at all. In that iPad-sized NIB file, you either make your views a different size or add additional views to take up the extra space (or, more commonly, both), depending on your needs.
I have no idea which technique will be adopted by folks developing software for iPhone 5.
Worse than that, they can be countersued for doing so, as purely nominative use of a mark to name the covered product is prima facie protected use of a trademark. It would be particularly extraordinary if such a suit ever succeeded. As such, this lawsuit, if it ever hit the courts, would almost certainly be deemed frivolous, possibly rising to the level of barratry, and at a minimum, this clown would owe the reviewers attorneys' fees and probably additional damages.
Never attribute to malice what can be attributed to GoDaddy's incompetence just as easily.
You pervs better not be hacking my boxers.
Or keep personally identifiable information separate from everything else. Ensure that you cannot get to one data set from the other and vice versa. Use login information as a hash into the identity database and the behaviors database. If you must store any time stamps on database records, make sure you do so in a way that prevents using them to easily correlate the two data sets (e.g. update the time stamp on the personal info record only when the user changes his/her password, address, or whatever, rather than at every login).
To the extent possible, store the information locally on the client side, or if you must store it on the server (for synchronizing between multiple computers), encrypt it client-side and send the encrypted blob to the server. Sure, that wouldn't prevent you from getting the information (because you control the site's code), but it does make it unlikely that somebody who compromises your database server can get the information.
And there's a hosting provider that has never made a billing error?
The only people who could get seriously screwed by such a mistake are people who paid for a service costing hundreds or thousands of dollars on a debit card. Those folks have reason to be angry if they got hit with overdraft fees, but most banks will refund those fees (since the charge that caused them was in error) assuming the person calls the bank and explains the situation.
Most of their customers probably didn't even notice it unless they hit a monthly billing cycle within about a two or three day period....
NearlyFreeSpeech is okay as long as you don't need lots of disk space. Otherwise it's very expensive.
Out of curiosity, what problems have you had with Dreamhost? They've been rock solid for me.
Now GoDaddy... *that* was terrible. Their UNIX boxes had process limits measured in seconds, which meant that just trying to upload a single RAW image file tended to fail about eight times out of ten. And in spite of those limits, their web servers would frequently stall for the better part of a minute before replying to an HTTP request. They were horribly managed hacks. It is no surprise that anonymous could DDOS their systems. I doubt it took more than one machine on a moderately fast connection and five lines of shell script.
Oh, and when I asked them to move me to a different server, they said no. I cancelled my account less than a week after I first set it up.
I've been using DH ever since, and have had no problems. To be fair, I'm mostly serving static content right now (except for a custom PHPBB instance with a custom authentication system that I'm just starting to set up). YMMV if you are trying to run Wordpress or something similarly bloated and heavyweight.
Because the bandwidth of the fiber is shared among all the people at your node. If everyone simultaneously cranked up iTunes or BitTorrent and started downloading movies at the same time, I doubt you would maintain that 20+ Mbps service speed.
Also because your speeds and cost are so atypical that it isn't even funny. Most Internet service in rural areas seems to average about $50 a month and provides less bandwidth.
Finally, because we're rapidly approaching the point where Internet bandwidth is hopelessly insufficient to meet users' needs. With users wanting to watch downloaded or streaming movies, perform network-based backups, use virtual computers (e.g. using VLC) that are maintained and backed up by someone else, etc., the performance and throughput of the outgoing pipe is getting more and more critical for a good user experience, and it just hasn't kept up with internal infrastructure speeds.
It's hard to even find a switch these days that isn't gigabit, yet as soon as you leave the premises, you're at a clunky single-to-low-double-digit megabit speed—about two orders of magnitude slower. That's just not acceptable. We're at the point where there's little reason to further upgrade the speeds of internal networks, mainly because of the lack of performance upstream. That's really rather bad news for all the industries that depend on the sale of upgraded equipment, and it potentially holds back lots of useful innovations—concepts that we haven't even dared to dream about because they are so completely infeasible over double-digit megabit networks.... Distributed social networking. Mass-market acceptance of video-and-voice-over-IP. True virtual/cloud computing (doing video editing using a hard drive in another state, for example). And so on.
Gigabit (uplink and downlink) to the premises would solve SO many problems.
Except that users cannot choose a less vulnerable OS. All OSes have significant numbers of vulnerabilities in that database.
Actually, that's exactly what I'm arguing. You should not install Flash. Or Adobe Reader (at least the plug-in version of it). Or Java.
In theory, yes. In practice, web browsers are much more critical as far as vulnerabilities go because they are constantly being exposed to untrusted content. Most applications are not. Software that runs in that environment has to be extremely well written. Browsers are fairly well written, with remarkably few serious security holes. Flash is the exact opposite. Adobe Reader and Java are somewhere in-between.
That one is a little different. It isn't hard to avoid that risk. Just don't use MS Office to open content that other people send you. You can't do that with a web browser, and because Java, Flash, and Adobe Reader run *in* a browser, you can't readily avoid using them to open content that other people send you, either. Your only option for improving the security of those tools, short of fixing all the security holes, is to not install them, or at minimum, to use something like ClickToFlash to disable them except on specific, user-chosen websites. The danger of that approach, however, is that websites will interpret the presence of those sorts of extensions as an indication that you have the plug-in in question, and will fail to fall back to alternative technologies even when available. Also, their stats will show that those plug-ins are still available almost everywhere, thus slowing the demise of those (almost always unnecessary) browser plug-ins.
Yes, in the short term, refusing to install those plug-ins may cause some temporary pain (though not much—I can only think of a handful of sites that I've visited in the past five years that required Flash, and exactly one that required Java; PDF is on its way out as an end-user delivery medium, too, as HTML/CSS improves), but as more people do this, fewer companies will grow to rely on those technologies, and the need for using them will continue to diminish. The advent of iOS went a long way towards killing these technologies, and the web is a safer place for their absence. The next step is up to the desktop user community and the developer community.
To the extent that Flash or Java are necessary to work around lack of features in a browser, file bugs and propose solutions. To the extent that websites require Flash or Java, complain to the site admins, and then don't go to those sites. When web browser developers have to go to insane lengths like running each tab in a separate process so that when Flash crashes (frequently), it doesn't take down the whole browser, it should be obvious that there's a problem. More precisely, when it represents the vast majority of browser crashes, there's a BIG problem. And although Java doesn't cause nearly as many browser crashes (possibly in part because there are many, many fewer sites that actually use Java), it has still had an abysmal security record lately, having been the sole successful vector for compromising OS X in recent memory. Any platform that is being actively used as a vector for compromising users' computers is a serious security risk and should be avoided unless there is no other alternative.
No, even that mostly comes down to a question of whether the road was designed for that speed or not. A properly designed road would not let you hit it head-on at 65, much less 85 or 90. This is done by putting a guard rail in front of the post and making it long enough that if you are traveling at an angle where you would hit the post head-on, you will crumple a hundred feet of guard rail first and slow down to almost nothing, and if you are not traveling at an angle where you'd hit it head-on, you will deal the guard rail and/or the post at best a glancing blow, then keep going in a slightly different direction.
Heck, an ideal design for a 100 MPH road would probably have concrete walls down both sides (possibly with continuous guard rails inside them) and no posts to run into in the first place. The worst you can do there is get into a situation where you hit a wall out control and go spinning off and hit the other wall eventually.
Of course, those designs break down when the road is wide enough to turn and hit a wall head-on (e.g. an eight-lane or ten-lane road), but again, that's a fault of the road design.
Careful, there. There's a broad spectrum of rejection. Anyone who says that humans haven't affected the climate at all is ignorant. However, this still leaves many questions for which the answers are less than adequate:
And so on. But the biggest reason so many people doubt AGW entirely (which is probably going too far) is because there are so many vocal AGW proponents who cross the line into loony wing-nut territory by suggesting utterly implausible theories like a "runaway greenhouse effect" (despite the greenhouse gasses being lower than at many points in our planet's history), using AGW as an excuse to push the progress of technology backwards through forced electrical conservation and light bulb bans rather than forwards by funding improvements in clean power generation or pushing for coal bans, trying to convince everyone to use horribly time-inefficient short-range public transportation instead of pressuring automakers to improve fuel efficiency or pressuring them to move to all-electric designs or pressuring governments to make traffic lights more efficient or pushing for pro-telecommuting legislation and policies, etc.
In short, the AGW proponents did this to themselves with their Greenpeace-esque agenda of causing the biggest negative impact on the most people to artificially raise awareness instead of pushing for changes that maximally improve the problem with minimal negative (or even positive) impact. I have no real sympathy for them now when they whine that nobody is listening.
Maybe when we get some believable AGW proponents (scientists) in the foreground and stop letting the extremists abuse AGW to promote their own twisted political agendas, things will start to improve.
That's not a fair comparison. Users don't realistically have a choice about whether to run an OS. They do have a choice whether to add additional vulnerabilities by tacking on an unnecessary abstraction layer like Flash or Java.
In other words, the current design tries too hard to cram too much into too little space. I tend to agree, though for non-case-mounted uses, I could see the compact size being useful. It's definitely a tradeoff.
Not necessarily. It *might* be possible to store the data used during the verification process in such a way that it would not be sufficient to reconstruct the key data in the absence of the actual print. For example, if you need ten data points, you might choose fifty data points and store a copy of forty of them, which you would then use to distort the scanned image so that the remaining ten would be correct with a high degree of probability. That *might* get you your ten robust data points without actually telling you anything about them.
Alternatively, you could use a cryptographic system designed so that each piece of data provides a portion of a key, and any k of the n pieces of data are sufficient to reconstruct the key. This might be done in any number of ways, mostly involving sophiticated checksums and error correction, and you might even have to have the equivalent of a .par file for your crypto key, but it should be possible, at least in theory.
Or it might require combining techniques like these with who-knows-how-many other techniques.
I have no idea if anybody actually has developed such technology, though. Biometrics are insecure for so many other reasons (triviality of duplication and the inability to change them being the most obvious) that they really aren't that interesting to me. :-)
It's not the fact that it is plain text that concerns me. What concerns me is that it uses a password at all. I'm not personally familiar with how Windows does things, but if you were implementing this on OS X, you'd implement a custom authorization plug-in that would be queried for permission instead of using a password. I assume that this is just a case of the implementors of this particular fingerprint reader tool not knowing what they're doing.
One of two things is true: either the device can reproducibly generate a long enough crypto key (based on the fingerprint itself) to provide adequate protection on its own or it doesn't. If it does, you don't need to store the password. That crypto key can be used for things like full disk encryption, etc. If it doesn't, then no matter how you store the pasword, it will never be secure, because the key must be stored somewhere, too, and as long as the crypto key is stored somewhere, it doesn't matter if the password is in plain text, ROT-13, XORed with a known sequence, or encrypted with AES-128 or AES-256; if Eve = Alice, Eve gets your password. Encryption is basically useless here for the same reason that DRM is basically useless. In other words, no matter how the password is stored, it is fundamentally and unavoidably insecure by design.
The only way to do something like this with even the slightest bit of security is with an authorization plug-in. Further, unless the hardware/software can reproducibly generate a long crypto key from a fingerprint, the only way to support full disk encryption would involve storing the key in some form, in which case it would be fundamentally insecure because you'd have the Alice = Eve problem again.
It's not just the lack of mounting holes. Give me a quarter inch of empty board space all the way around with no components and I don't need holes. Just build a case where the board slides in. The problem with this board design is that it has neither mounting holes nor even one single solitary contact point where you can put physical pressure on both sides of the board in the same spot without knocking components off. Opposite the CE logo are the major power regulating components for the whole board. Opposite the RPi logo are dozens of tiny surface-mount components. The closest you can get to a friction mounting involves removing the GPIO header and/or putting pressure on top of the USB stack (moderately safe) or video jack (moderately safe).
Or if I knew I wasn't ever going to use the GPIO header on a particular board, I guess I could remove it, cut the traces, and drill a screw hole in the corner where they belong, and another one almost opposite it, between the USB and Ethernet jacks, assuming there aren't any hidden traces in an inner layer of the board that I'm not able to see, but if the last board layer artwork posted (http://www.raspberrypi.org/wp-content/uploads/2011/11/gerbers2.png) is correct, then it's safe to drill there. That said, since I already see GPIO pins that I know are connected, but show no traces, I don't have much faith in that image.
Because of the lack of mounting holes, it is very hard to design a snug-fitting case for the the first-gen Raspberry Pi. I'm pretty sure the component placement precludes using a rail-mounted design (slide-in) because there are too many components right at the edge of the board. And there are components at every corner of the board. About the only thing I can come up with are flat rubber bumpers where the CE logo is, under the Ethernet jack, and under the video jack, with different-thickness rubber bumpers on top of the USB jacks and the Pi logo, coupled with insanely tight tolerances around the edges of the board to eliminate sliding back and forth.
I ordered five of these a week ago and learned about the inability to mount them rigidly after I ordered them. They shipped yesterday. I'm not happy. I definitely would not have ordered them had I known that in just a few weeks, I'd be able to get one without this rather serious design flaw.
Obligatory Hitchhiker's Guide to the Galaxy quote:
—Douglas Adams
Actually, I've been wondering if the whole "no drinks through security" rule was made at the request of the airport merchants who charge three dollars for a $0.30 bottle of water....