3G has a wavelength of a little over six inches, by my math. If you want to talk about effects on brain tissue, that's about the width of your skull, and a half-wave antenna would be about the width of one hemisphere. You're right that it is ridiculously unlikely, but if it were possible for low-power EM to have a noticeable effect on human physiology, it would probably occur up in the GHz range, not in the FM range, where a full wave antenna is over ten feet long.
Amazon Review: The product listing claimed to be for Helium-5, but when I opened the box a microsecond later, I found that it was really just Helium-4 and a bunch of stray electrons. Would not buy again.
No doubt fusion could be pretty tremendous, but in a world where you might have to foot the cost of the power lines and poles delivering archaic grid power to your house, solar and wind can have a big cost advantage.
Especially when you factor in the cost of power lines all the way to the moon.:-D
Perl's taint mode, unfortunately, excludes arguments to "print" when checking for taintedness. That might be good enough for command-line tools, but when you're looking for security bugs in server code, those are precisely the places where you most want to check. And it bafflingly untaints content pulled from a regexp match, which is also very bad, and equally bafflingly, does not do so if your locale is something other than POSIX.
So yes, Perl's taint mode does what is described above. However, preventing you from passing user-generated data as a command-line argument, while useful, is woefully insufficient as a security tool for CGI purposes.
SQL injections are not a programming language issue. It is a problem with the coders.
That would be true if they had designed the API perfectly security-wise from day one. The reality, however, is that the initial MySQL APIs were pretty bad. In addition to the mysql_escape_string problem (fundamentally broken for some multibyte character encodings), PHP didn't support parameterized queries (as far as I know) until PDO and MySQLi were added in PHP 5 (2004). So basically, for any code written before 2004, SQL injections are, in fact, a programming language issue.
Unfortunately, most code doesn't get rewritten unless it is known to be broken, which means there's an awful lot of code out there that predates PHP 5 that is still in active use, security holes and all. So SQL injections, on the whole, are a combination of a programming language issue and a maintenance issue. PHP 7 is finally forcing people to clean up that crap by dropping the old API. However, it should have been deprecated in 2004, and it should have required someone to modify php.ini if they wanted to keep using that old API after about 2005 or 2006, to force people to update their code.
So a call to your particular framework's equivalent of htmlspecialcharacters just doesn't cut it, unfortunately. The only way I can see to handle all this securely and automatically is to actually parse your templates and keep track of each context that is entered/exited and apply appropriate, nested escaping rules. This is awful and slow.
Still not good enough if you have code that emits HTML using print statements. It would have to parse the output on its way to the browser. That's just another reason why the idea of automatically "fixing" the content borders on insanity. Much better to spew errors if you pass the data to the client without running any of those quoting methods or explicitly mark it as safe in some other way. That way, the programmer is forced to decide how it should be handled on a case-by-case basis, and code that already does the right thing requires minimal changes (calling one function to mark tainted strings as clean in spots where you really do mean to output the content without quoting).
Not if you properly check the referrer. But that's another discussion.
This can be an issue with POST requests, but it is far more likely with GET requests, where somebody on a random third-party server can create an ordinary link that then causes things to happen for the user while logged in to your website.
A good language should be designed in such a way that the simple way is the safe way, and make you be more explicit if you want something else. For example the php expression blocks should do html escaping, and when you don't want escaping you would use a more verbose command that would make it clear that you are outputting a trusted value.
Oh, [expletive deleted], no. That ranks right up there with PHP's magic quotes feature, which caused far more security holes than it fixed, because the behavior wasn't under the programmer's direct control, short of disabling it outright. PHP has no way to know whether you are outputting HTML intentionally, so it cannot know whether it should quote it or not. It also cannot determine whether content came from a user, because it could have been stored in a database in the meantime. Thus, any such automated modification of content is likely to break things as often as it fixes them, if not more often.
What PHP should have is tainted content tracking, and a warning or error if you try to emit unsanitized content without either escaping it or flagging it as known-safe, whether that content came from the user or from a database. And the same thing should happen when using variables that came from the user or from disk as part of a SQL query string. And so on.
The advantages to that design are that A. the developer must explicitly decide how to correctly sanitize the content based on context, which means that the developer is forced to learn about the security implications and seriously consider them, B. it works for more than just HTML output, and is potentially extensible to arbitrary output formats through arbitrary protocols, and C. the code either works or it doesn't; there's no opportunity for the code to work for 99 users and fail for the 100th user solely because that user happens to have an ampersand in his or her username or whatever.
Security cannot be automatic. Any attempts to do so invariably fail spectacularly. It must be designed as you're writing code. Things like static analyzers and tainting are good tools for helping you catch potential problems, but cannot reasonably be expected to fix those problems without programmer input on a case-by-case basis.
It's pretty obvious the most common language is going to have the most apparent bugs and the most security woes because it is the one that is most used to solve the majority of problems.
That argument doesn't work when the measurement is in bugs per megabyte.
Actually, it does, and the reason is somewhat subtle: There are only so many good programmers out there. As a language becomes more popular, the demand for programmers who know that language increases faster than the supply of good programmers who know that language. The more popular the language, the higher the percentage of programmers writing code in that language who don't know what they are doing.
No, nothing is wrong. On the average, security of code written in a language can be approximated by the formula S = P * L * (100 - D), where P is the quality of the programmers, L is the quality of the language, and D is the percentage of code that works with SQL databases. For example:
C++ is a potentially problematic language because of C, but most people don't use lots of C string/buffer manipulation, so it isn't affected nearly as much as you might think. And the people who program in C++ tend to be pretty decent programmers. And nobody uses C++ for working with SQL databases, within a small margin of error. So you have a large number times a small number times a large number, hence medium security.
PHP is a language that isn't too different from C and C++ except that it lacks the pointer bits. This should make it safer. However, PHP was a "popular language" for many years, and during that time, a lot of people who weren't very good programmers wrote a lot of code. So the sheer volume of low-quality programmers made it a bigger security target. And nearly all PHP code interacts with SQL databases, within a small margin of error. So you have a small number times a small number times by a small number, hence low security.
Most of PHP's quirks are because it does not abstract you very far from C. And I know the author claimed that this wasn't a valid point, but it really is. PHP is an interpreted C with mandatory sigils (dollar signs) and basic support for classes. Every release seems to move it even closer to C, because that's the language that a lot of people know and are comfortable working with.
What makes PHP crucially different from C is that it is an interpreted language, which means you don't have to recompile and relink every time you make a change. When you're doing web development, that design saves a lot of time. So the author's "Just write C" comment is just silly. Besides, mod_php is faster than CGI (or even FastCGI), so depending on the interpreter penalty, the PHP code may be faster than C. And with the performance improvements in PHP 7, that's an even more likely scenario.
Also, PHP's template capabilities (mixing HTML and snippets of PHP) make it better for some types of web programming than C.
Separation of Church and State. There's fear that allowing same-sex marriage could result in people suing churches for refusing to perform them. Obviously, it would be a serious Constitutional violation if the courts did so, which should make those fears irrational, but the courts have been known to ignore the Constitution now and then, so maybe it isn't.
The correct (morally, legally, ethically) solution is to ban all government recognition of marriage. Require a complete separation between religious ceremonies and civil ceremonies, and completely revoke churches' rights to perform the latter. This properly ensures that A. churches cannot be sued for refusing to perform a now-strictly-religious ceremony, and B. churches that wish to perform gay marriage ceremonies would be allowed to do so. It also ensures the same legal rights (tax-wise, for example) for all couples, regardless of whether they are same-sex, because those would be based on the civil union rather than the religious marriage.
Like most political issues, there's no middle ground because both sides are arguing over one aspect of the issue when the real flaw is an entirely different aspect. Any solution that satisfies both sides must completely throw away all the existing assumptions and start from scratch. Otherwise, you end up with a solution that everyone is equally dissatisfied with, which is entirely the wrong way to govern a country.
Not sure why you say that. We're reasonably certain that these so-called Wi-fi "allergies" are completely bogus. However, if they were real, the most likely cause would be a feedback loop of neurons amplifying a signal, in which the length of some portion of that loop was of the right length to tune a particular frequency. So if a Wi-Fi allergy could actually exist, then it almost certainly would be frequency-sensitive. But again, Wi-Fi allergy claims consistently fail to stand up to testing, making the discussion moot.
US: Christian pro-life fanatics who want to outlaw abortion, including in cases of rape & incest, and are campaigning in the primary elections so that one of their favored candidates wins the party nomination
And occasionally shooting up or bombing abortion clinics.
I thought 100% CPU loops in a background application were exactly what the App Store review process was designed to prevent.
Unfortunately, first-party code doesn't go through that same process. I was thinking in particular about a recent experience with spotlight indexing when I made that snarky comment.
This. "I would buy an iPhone if it were only thinner," said no one ever.
What would make me upgrade my iPhone 6S to the iPhone 7 rather than skipping two generations and buying the iPhone 8? Give me the ability to carry my phone for a two week trip, using it the way I do now, without having to charge it.
By contrast, there's something bordering on pure insanity about the notion of taking away the headphone jack that many of us use very heavily in our cars while charging the device just so that Apple's engineers can brag about how much thinner they made a device that's already too thin to hold up to your ear without being constantly in fear of dropping it unless you put it in a case. Doubly so when you realize that it will likely mean relying more and more on software tricks to keep the battery life numbers up, while the worst-case battery life (with one of those hundred minor background daemons sitting in a tight loop using 100% of one CPU) continues to decline.
In the U.S., portable devices like cell phones can be used in airplane mode during takeoff and landing. Wireless headsets, however, are not allowed. So this would mean that if you plan to fly, you'll have to carry your wired headphones and an adapter. Just another reason that removing the headphone jack is an idiotic idea.
Samsung has sold hundreds of millions of phones with OLED screens in.
Samsung manufactures OLED screens. They don't have to worry about a supplier not being able to meet demand, because they are the supplier. If they have to throw more money at it to bump up production, they will. If the yield is too low, they can make up for it by cranking up the price of OLEDs disproportionately for everyone else that they supply panels to, or by cutting off those other companies entirely.
A company buying panels from somebody else doesn't have that flexibility.
Eventually, those bearings fail, and you have to replace the motor, but not for a very long time.
I certainly hope not. You can typically press new bearings in for just about all other motors, after all.
You can put new bands in a transmission, too. Still, probably 99% of the time, you get a rebuilt transmission installed, and the installer ships back the old part to be remanufactured. I would expect that to be true for electric motor repairs as well.
You missed suspension, steering, body work/subframe rot, electical issues, HVAC issues, LED lights (yeah, they do go bad, apparently rather often from what I've seen on the road), tires, snow tires and wheels, parking brake adjustment, brake fluid, bearing replacement, differential work (though that could be eliminated), axle issues, interior problems (broken seats, for example), interior lights, batteries, and probably other stuff I've forgotten.
Brakes and steering on most electric vehicles are electrical, not hydraulic, which should result in very low maintenance, at least within the currently typical lifespan of a car.
Besides, most of the things on that list are repairs (after failures), not routine maintenance (to prevent future failures). There's nothing you can do maintenance-wise to prevent a blown interior bulb or a broken seat (except perhaps losing weight if you're on the heavy side).
The only thing on your list that I would consider true maintenance is tires, which was one of the things I mentioned.
And yes owners, there is oil needed for your volt.
Um, no. Electric cars use permanently lubricated bearings. There's no mechanism by which the dealer can add oil to anything. Eventually, those bearings fail, and you have to replace the motor, but not for a very long time.
Electric cars do need tire rotation, brake pad replacement, and replacement of brake lights and other exterior lights (if they aren't LEDs). Beyond that, they should be largely maintenance-free.
Slashdot Mirror
3G has a wavelength of a little over six inches, by my math. If you want to talk about effects on brain tissue, that's about the width of your skull, and a half-wave antenna would be about the width of one hemisphere. You're right that it is ridiculously unlikely, but if it were possible for low-power EM to have a noticeable effect on human physiology, it would probably occur up in the GHz range, not in the FM range, where a full wave antenna is over ten feet long.
Amazon Review: The product listing claimed to be for Helium-5, but when I opened the box a microsecond later, I found that it was really just Helium-4 and a bunch of stray electrons. Would not buy again.
Especially when you factor in the cost of power lines all the way to the moon. :-D
Perl's taint mode, unfortunately, excludes arguments to "print" when checking for taintedness. That might be good enough for command-line tools, but when you're looking for security bugs in server code, those are precisely the places where you most want to check. And it bafflingly untaints content pulled from a regexp match, which is also very bad, and equally bafflingly, does not do so if your locale is something other than POSIX.
So yes, Perl's taint mode does what is described above. However, preventing you from passing user-generated data as a command-line argument, while useful, is woefully insufficient as a security tool for CGI purposes.
Not sure about Ruby's taint mode.
That would be true if they had designed the API perfectly security-wise from day one. The reality, however, is that the initial MySQL APIs were pretty bad. In addition to the mysql_escape_string problem (fundamentally broken for some multibyte character encodings), PHP didn't support parameterized queries (as far as I know) until PDO and MySQLi were added in PHP 5 (2004). So basically, for any code written before 2004, SQL injections are, in fact, a programming language issue.
Unfortunately, most code doesn't get rewritten unless it is known to be broken, which means there's an awful lot of code out there that predates PHP 5 that is still in active use, security holes and all. So SQL injections, on the whole, are a combination of a programming language issue and a maintenance issue. PHP 7 is finally forcing people to clean up that crap by dropping the old API. However, it should have been deprecated in 2004, and it should have required someone to modify php.ini if they wanted to keep using that old API after about 2005 or 2006, to force people to update their code.
Make those warnings become errors in production mode unless you explicitly set a flag to allow dangerous APIs in your php.ini file.
Still not good enough if you have code that emits HTML using print statements. It would have to parse the output on its way to the browser. That's just another reason why the idea of automatically "fixing" the content borders on insanity. Much better to spew errors if you pass the data to the client without running any of those quoting methods or explicitly mark it as safe in some other way. That way, the programmer is forced to decide how it should be handled on a case-by-case basis, and code that already does the right thing requires minimal changes (calling one function to mark tainted strings as clean in spots where you really do mean to output the content without quoting).
Not if you properly check the referrer. But that's another discussion.
This can be an issue with POST requests, but it is far more likely with GET requests, where somebody on a random third-party server can create an ordinary link that then causes things to happen for the user while logged in to your website.
Oh, [expletive deleted], no. That ranks right up there with PHP's magic quotes feature, which caused far more security holes than it fixed, because the behavior wasn't under the programmer's direct control, short of disabling it outright. PHP has no way to know whether you are outputting HTML intentionally, so it cannot know whether it should quote it or not. It also cannot determine whether content came from a user, because it could have been stored in a database in the meantime. Thus, any such automated modification of content is likely to break things as often as it fixes them, if not more often.
What PHP should have is tainted content tracking, and a warning or error if you try to emit unsanitized content without either escaping it or flagging it as known-safe, whether that content came from the user or from a database. And the same thing should happen when using variables that came from the user or from disk as part of a SQL query string. And so on.
The advantages to that design are that A. the developer must explicitly decide how to correctly sanitize the content based on context, which means that the developer is forced to learn about the security implications and seriously consider them, B. it works for more than just HTML output, and is potentially extensible to arbitrary output formats through arbitrary protocols, and C. the code either works or it doesn't; there's no opportunity for the code to work for 99 users and fail for the 100th user solely because that user happens to have an ampersand in his or her username or whatever.
Security cannot be automatic. Any attempts to do so invariably fail spectacularly. It must be designed as you're writing code. Things like static analyzers and tainting are good tools for helping you catch potential problems, but cannot reasonably be expected to fix those problems without programmer input on a case-by-case basis.
Actually, it does, and the reason is somewhat subtle: There are only so many good programmers out there. As a language becomes more popular, the demand for programmers who know that language increases faster than the supply of good programmers who know that language. The more popular the language, the higher the percentage of programmers writing code in that language who don't know what they are doing.
No, nothing is wrong. On the average, security of code written in a language can be approximated by the formula S = P * L * (100 - D), where P is the quality of the programmers, L is the quality of the language, and D is the percentage of code that works with SQL databases. For example:
Most of PHP's quirks are because it does not abstract you very far from C. And I know the author claimed that this wasn't a valid point, but it really is. PHP is an interpreted C with mandatory sigils (dollar signs) and basic support for classes. Every release seems to move it even closer to C, because that's the language that a lot of people know and are comfortable working with.
What makes PHP crucially different from C is that it is an interpreted language, which means you don't have to recompile and relink every time you make a change. When you're doing web development, that design saves a lot of time. So the author's "Just write C" comment is just silly. Besides, mod_php is faster than CGI (or even FastCGI), so depending on the interpreter penalty, the PHP code may be faster than C. And with the performance improvements in PHP 7, that's an even more likely scenario.
Also, PHP's template capabilities (mixing HTML and snippets of PHP) make it better for some types of web programming than C.
Separation of Church and State. There's fear that allowing same-sex marriage could result in people suing churches for refusing to perform them. Obviously, it would be a serious Constitutional violation if the courts did so, which should make those fears irrational, but the courts have been known to ignore the Constitution now and then, so maybe it isn't.
The correct (morally, legally, ethically) solution is to ban all government recognition of marriage. Require a complete separation between religious ceremonies and civil ceremonies, and completely revoke churches' rights to perform the latter. This properly ensures that A. churches cannot be sued for refusing to perform a now-strictly-religious ceremony, and B. churches that wish to perform gay marriage ceremonies would be allowed to do so. It also ensures the same legal rights (tax-wise, for example) for all couples, regardless of whether they are same-sex, because those would be based on the civil union rather than the religious marriage.
Like most political issues, there's no middle ground because both sides are arguing over one aspect of the issue when the real flaw is an entirely different aspect. Any solution that satisfies both sides must completely throw away all the existing assumptions and start from scratch. Otherwise, you end up with a solution that everyone is equally dissatisfied with, which is entirely the wrong way to govern a country.
Not sure why you say that. We're reasonably certain that these so-called Wi-fi "allergies" are completely bogus. However, if they were real, the most likely cause would be a feedback loop of neurons amplifying a signal, in which the length of some portion of that loop was of the right length to tune a particular frequency. So if a Wi-Fi allergy could actually exist, then it almost certainly would be frequency-sensitive. But again, Wi-Fi allergy claims consistently fail to stand up to testing, making the discussion moot.
Not apps. System daemons.
And occasionally shooting up or bombing abortion clinics.
Unfortunately, first-party code doesn't go through that same process. I was thinking in particular about a recent experience with spotlight indexing when I made that snarky comment.
This. "I would buy an iPhone if it were only thinner," said no one ever.
What would make me upgrade my iPhone 6S to the iPhone 7 rather than skipping two generations and buying the iPhone 8? Give me the ability to carry my phone for a two week trip, using it the way I do now, without having to charge it.
By contrast, there's something bordering on pure insanity about the notion of taking away the headphone jack that many of us use very heavily in our cars while charging the device just so that Apple's engineers can brag about how much thinner they made a device that's already too thin to hold up to your ear without being constantly in fear of dropping it unless you put it in a case. Doubly so when you realize that it will likely mean relying more and more on software tricks to keep the battery life numbers up, while the worst-case battery life (with one of those hundred minor background daemons sitting in a tight loop using 100% of one CPU) continues to decline.
In the U.S., portable devices like cell phones can be used in airplane mode during takeoff and landing. Wireless headsets, however, are not allowed. So this would mean that if you plan to fly, you'll have to carry your wired headphones and an adapter. Just another reason that removing the headphone jack is an idiotic idea.
Clinging to your beliefs by proving that the paper doesn't contradict them will cost you money. :-D
Samsung manufactures OLED screens. They don't have to worry about a supplier not being able to meet demand, because they are the supplier. If they have to throw more money at it to bump up production, they will. If the yield is too low, they can make up for it by cranking up the price of OLEDs disproportionately for everyone else that they supply panels to, or by cutting off those other companies entirely.
A company buying panels from somebody else doesn't have that flexibility.
Back in the day when Gopher was still useful, and 2400 baud was enough for anybody.
You can put new bands in a transmission, too. Still, probably 99% of the time, you get a rebuilt transmission installed, and the installer ships back the old part to be remanufactured. I would expect that to be true for electric motor repairs as well.
Brakes and steering on most electric vehicles are electrical, not hydraulic, which should result in very low maintenance, at least within the currently typical lifespan of a car.
Besides, most of the things on that list are repairs (after failures), not routine maintenance (to prevent future failures). There's nothing you can do maintenance-wise to prevent a blown interior bulb or a broken seat (except perhaps losing weight if you're on the heavy side).
The only thing on your list that I would consider true maintenance is tires, which was one of the things I mentioned.
Ah. My bad. I assumed that because this was about electric cars, the vehicle actually was... you know, an electric car, not a hybrid....
Um, no. Electric cars use permanently lubricated bearings. There's no mechanism by which the dealer can add oil to anything. Eventually, those bearings fail, and you have to replace the motor, but not for a very long time.
Electric cars do need tire rotation, brake pad replacement, and replacement of brake lights and other exterior lights (if they aren't LEDs). Beyond that, they should be largely maintenance-free.