The problem is that certificates change regularly. What you really want is public key pinning, where you are warned if the public key changes, without regard to what CA signed it—not just the key fingerprint, either—the entire key. After all, you have the server's public key. Why would you ever start trusting a different public key for the same server?
AFAICT, there are only two valid to reasons rekey a server: if the key gets compromised (which, being a serious security problem, should be publicly disclosed on your server in some way) or because you're upgrading to a larger key. In the latter case, you should ideally sign the new key with the old key so that it is verifiable, and the browser should ignore that the old key is not trusted for key signing when it is only being used as a secondary signature for verifying a key change.
But it really doesn't, at least in the bigger picture. If you, as a business owner, don't move into a new area, assuming that area has a reasonable chance of being profitable, somebody else will. And then you have two companies of 249 employees because your company didn't grow. At some point, the economies of scale resulting from combining into a smaller number of companies with more people far outweigh any disincentive that might appear to exist right at or near the limit, at which point you make the leap to being way above that 250 person limit, and those regulations can't create a disincentive.
The reality is that only a tiny percentage of companies are right at 250 employees. Most companies are either way smaller or way larger. A 1,000 employee company is not going to lay off 75% of its workforce just to avoid a law. At best, this creates a small disincentive for companies that are approaching that line to cross it, or a small incentive for companies that are only slightly above the line to reduce their headcount by a few people.
That said, in practice, most companies hire exactly as many people as they need in order to do a particular task (e.g. opening a new store), so unless the impact is serious enough to make a company decide to not expand into a new area, such incentives are unlikely to have any effect that doesn't get lost in the statistical noise, in much the same way that decreases to payroll taxes have little to no impact on hiring at companies that have over a few dozen employees, and for the same reason.
Boots on the ground? It always worked before we had high tech. I mean, before there were phones, they had to plant people inside an organization to learn its secrets unless they just happened to get lucky enough to catch a courier. The fact that communication channels are back to being moderately secure is uninteresting. It's really just a correction of a weakness that high tech introduced in the first place.
And now, with a self-driving car, you can have that bridge-turning experience you've always wanted but could never convince yourself to act on. Let the suicidal rejoice!
The summary is misleading. What the study actually says is that the total amount of content that the average person requests, if that person took the time to fully read or watch it would take 15.5 hours per day to fully consume. That's a very critical difference.
For example, let's say you read Slashdot. You read the headline, you read the summary (maybe), you read the article (hah!), and then you open up the comments, skim a few of them, and post a comment or two of your own. However, there are 500 comments farther down the page that you did not read. You spent three minutes on the page, but if you had read and digested every comment, it would have taken forty minutes. This study says that you consumed forty minutes of media.
It's not about how much time you spend consuming media, but rather how much media you are exposed to. This statistic is interesting for entirely different reasons than the amount of time you actually spent. It is a better indicator of how well informed you are (assuming the media is informative, or else it indicates how well you know your memes), and is a good indicator of how much bandwidth you use. By contrast, the amount of time you actually spent is a good metric for obesity and other health problems.:-)
This. By definition, if something is already obviously of benefit to everyone, some company is already doing research on it, and spending government money to subsidize that research provides no benefit whatsoever, because the research would get done anyway. Restrictions like what these senators are proposing fundamentally undermine the usefulness of the NSF, whose sole benefit to humanity is that they fund research that would not otherwise get done. They push the envelope. They explore new ideas whose benefits aren't yet clearly established.
If these people happen to be your senators, please write to them and tell them that this proposal will destroy our nation's ability to compete intellectually in the next century, and sets the stage for total economic collapse in the years to come.
The curious thing is that if you solicit sex from someone who a reasonable person would believe was not a minor, but actually is, I'm pretty sure that's still illegal, which is sort of a double standard. I guess the bottom line is to treat sex like cigarettes: if she's under 35, ask for three forms of ID.
BTW, it is not necessarily impossible to prove a belief, or at least to prove it with enough certainty that it qualifies as evidence. For example, it would be interesting to see how a jury would rule if the defendant in such a case provided diary entries that indicated that he or she was reasonably certain that the person on the other end was not actually a minor. Certainly that doesn't prove that the defendant really believed it, but it does at least present reasonable doubt.
Simple discovery should be all you actually need. After that, the rest is just mapping tables between the device's GUID and what it does. You don't typically add devices a hundred at a time. You add them one at a time. When you plug it in, it goes online. Your laptop or iPad or Raspberry Pi or whatever says, "Hey, I see a new electronic switch. What's attached?" And you say, "Bedside table lamp." And now you know what it does.
But even if you're adding hundreds of them at once (e.g. adding wall switches during new home construction), as long as the protocol is bidirectional, it should still be trivial to make the association. Simply put the computer in a mode where it listens for sensor changes. Turn on the wall switch, and your laptop or iPad says, "What did you just turn on?" And you say, "Bedroom ceiling fan." And now you know what it does once again.
I'm also a fan of multiplexing the communication over the existing power lines. It makes no sense to run extra control wires for something that just shouts, "It's 24 degrees" or "Somebody just turned me on" periodically. Just MHO.
As for cost, there's no reason for the controller to cost hundreds of dollars. Most people already have a TV. Use that as the interface, and use a Raspberry Pi Model A tied into the power-line network via USB. It ought to be possible to make a profit selling such devices at $50 apiece easily.
The bigger problem, which this article touches on, is when you want devices to talk to each other, rather than talking to the end user—things like electrically controlled baffles to manage temperature in multiple zones with a single blower—you need not only to know what protocol the devices speak, but also how those devices should integrate with one another, which isn't always obvious and can't always be preprogrammed. Instead, what you really need is an extremely simple, standardized programming language with rules based on measurements (input values) and actions (output values) to facilitate that interaction, and a master computer to handle running those programs—sort of an awk for home automation. For example, you might have a rule like this:
That rule would, of course, be expressed to the user in English as something like "If the thermostat is switched to heat and the bedroom temperature is at least three degrees warmer than the living room temperature, then turn off power to the bedroom baffle" (or even "... close the bedroom baffle").
Of course, that's all interesting in principle, but IMO it is putting the cart before the horse. We first need devices that can communicate with non-brain-damaged protocols. Minimally, this means:
A VID/PID pair that uniquely identifies the model of the device. The VID should be 128 bits long, with everyone agreeing to use the same GUID generation algorithm when generating the VID so you'll never get a collision. This avoids the need for anyone to be the "keeper of the VID list".
A GUID for every device.
Service discovery.
Bidirectional communication with retransmission.
A capabilities dictionary containing inputs and outputs, each with a possible range, type (e.g. float vs. int), scale, and unit.
A pairing protocol that proves you have physical access (e.g. the computer telling you to turn the switch on for five seconds, off for two, on for three, then off again) and ideally involves the exchange of a PK pair.
The ability to push a user-chosen device name back to the device after pairing, for easier identification later.
If this sounds like it is reimplementing a more open-hardware version of USB HID over power lines, that's because it is....
Such a design makes lots of things trivial—the stage lighting controller example posed by 486Hawk, for example.
In a modern architecture with proper power management, increasing the speed of the chip often does exactly that. If you graph power consumption over time, the total power consumption is the area under the line. Thus, if you make a chip that takes twice as much instantaneous power while it is active, but can do the work in a third as much time, then as long as you properly power down that extra hardware while it is idle, you're using two-thirds as much power when averaged out over time.
This assumes that the idle power of the faster chip doesn't increase so much that you make up the difference during long periods of inactivity, of course. Reducing idle power is almost invariably an important goal.:-)
I wonder if they found out what browser and OS are used at Apple and at Microsoft...
Exactly. When the answers to half of your questions are blindingly obvious without even asking them, you're really wasting your time. Start asking questions that are an actual threat to corporate secrets, though, and at most companies, the employees will clam up faster than a politician caught with a hooker behind a cheap Vegas strip club.
Take Apple for example. Let's see:
Do you have a cafeteria? Uh, yeah. It's listed on Yelp.
What operating system do you use? Three guesses and the first two don't count.
What service pack are you running? What the **** is a service pack?
What browser do you use? Three guesses and the first two don't count.
What mail client do you use? Three guesses and the first two don't count.
What antivirus system do you use? Um... dude, it's a Mac....
What's your ESSID? Hmm. I wonder if it could be AppleWiFi?
And so on. These sorts of questions are so innocuous and the information is so easy to obtain by literally anyone in the general public that even the most paranoid person wouldn't try to keep them secret. They don't represent a real-world way to get any further information in anything but the most bizarre scenarios. The interesting question is whether they can then use that information to get something of value. Short of that, this is like screaming that the sky is falling when really a bird just dropped something on your shoulder.
The fundamental failing here is that these folks naïvely assume everything has to be secret, and that obtaining information at a very low level of trust allows you to take advantage of a slippery slope to obtain information that requires a high level of trust. The reality is quite the opposite when it comes to almost everything on this list. Companies want potential job seekers to know that they have one of the best corporate cafeterias in the area. They want visitors to their campus to be able to use the Wi-Fi network to check their email. They want people to apply on their public jobs website for positions in the cafeteria. And so on. Those needs are fundamentally incompatible with keeping that information secret, period.
Further, for information that does have to be public knowledge, competent companies take steps to mitigate the damage that the information can do. For example, most companies require you to use a badge to access the corporate cafeteria, vet their new hires carefully, put the Wi-Fi on a public network with no access to internal systems, require you to use a VPN for access to any internal systems, require that confidential information be disposed of in locked metal bins, etc. The fact that those mitigations exist is not a secret (yet the existence of a VPN was one of the "flags"); if your security depends on keeping the mechanism of that security a secret, then it is broken by design.
In short, if the company is doing security right, then basically nothing on that list of flags is actually of value to an attacker, making this a really silly study.
Actually, no, California law explicitly allows you to hold a cell phone to place a call, but only in conjunction with a hands-free device, and only when dialing. The cell phone law merely says that it must be configured to support hands-free listening and talking, not dialing. Similarly, the highly problematic anti-texting law that has been used to prosecute people for such things as changing to the next song also has an explicit exception for using the phone to actually call someone, including the use of the phone's address book.
Thus, the law (at least in California) makes it very, very clear that it is acceptable to hold the device in your hand for the purposes of placing a phone call. Helpful tip: if you ever get pulled over and you have your phone in your hand, you should make certain that you are on the phone using your hands-free device when the officer walks up to your car. When the officer asks why you had the phone in your hand, the answer is always, "I was dialing someone on my phone." This has three effects:
1. The officer should say, "Have a nice day," and the traffic stop should end right then. At most, the officer should ask for your license and registration and ensure that they are valid and the vehicle isn't stolen.
2. If it goes to court, you have a legally admissible record of having placed a phone call at the time the officer pulled you over.
3. If the officer issues you a citation anyway, you can potentially sue the prosecutor and the officer for malicious prosecution (or even vexatious litigation if you can show a history of similar prosecutions).
I care about having a government that presumes guilt in situations where pesky things like "proof" would take too much work.
Unfortunately, in California, traffic infractions have been handled as though people were guilty until proven innocent for a very long time. The entire system is rigged to be purely a means of revenue generation, grossly violating both the letter and the spirit of California law, and nobody seems to care, mostly because the cost to fight a ticket is usually greater than the cost of the ticket. Traffic enforcement is a racket, parking enforcement doubly so.
Ah, sorry. I screwed up the example slightly. In a proper example, there's always a little more code to ensure that "a" is a strictly positive integer, because if it isn't, then a + 2 is guaranteed to not overflow, making the check superfluous.
Another, more common example of code optimizations causing security problems is this pattern:
int a = [some value obtained externally]; int b = a + 2; if (b < a) { // integer overflow occurred... }
The C spec says that signed integer overflow is undefined. If a compiler does no optimization, this works. However, it is technically legal for the compiler to rightfully conclude that two more than any number is always larger than that number, and optimize out the entire "if" statement and everything inside it.
For proper safety, you must write this as:
int a = [some value obtained externally]; if (INT_MAX - a < 2) { // integer overflow will occur... } int b = a + 2;
In my experience, it's a safe bet that any company that cuts as many corners as Adobe does in one area probably cuts corners in almost every other area. This leads to the obvious question of whether the crackers will find any serious security holes in Photoshop and exploit them. Given how much they seem to resist fixing even the most trivial bugs in Photoshop, I'd be willing to bet that the entire codebase is an unholy cesspool, which means it is probably rife with security holes, too.
Re: It was already a dangerous site to visit ...
on
PHP.net Compromised
·
· Score: 1
It's also easy to spot. As a rule, eval should be a security red flag in pretty much any programming language. The only even semi-valid reason to use it is for certain types of shell scripting, where it can be unavoidable. In fact, it ranks right up there with system() in the red flag handbook.
If you want an autonomous car where you can check mail and send texts on your way to work, you can have it right now. It's called a bus.
Only if either A. you have access to a park-and-ride facility that is closer to your house than your workplace is, or B. the bus stops very close to both your home and your workplace. I've usually found that unless your commute is at least half an hour by car, you'll spend more time walking to and from the bus than you would spend driving, and even if you don't count the walking time, it still takes 2–3 times as long to get there. As always, YMMV.
Public transit is great for moderately long commutes, particularly if parking sucks at your destination. If I'm going into San Francisco, I take public transit. If I'm going to work, though, there's actually enough parking, so it isn't worth the 20 minutes of walking and 30+ minutes on a bus just to save 15 minutes in my car. It would probably be slightly cheaper, but the inconvenience is pretty severe. And that's without having to change buses at all.
Re: It was already a dangerous site to visit ...
on
PHP.net Compromised
·
· Score: 1
It's horrible only because PHP doesn't build such functionality cleanly into the language. The ideal syntax looks more like this:
implode(glue => ",", pieces => $stuff);
Or even this:
implode(glue=",", pieces=$stuff);
And you're very wrong about reordering being the only benefit. Named calling parameters also provide much-needed information about what the parameters actually do when you're looking at the function call itself, without which you must mentally cross-reference the original function declaration to know how those parameters are being used. Being explicit as part of the call syntax reduces cognitive load, particularly when you're doing maintenance programming of a large code base, particularly when a function takes more than a couple of parameters. You know the old adage: If a function takes more than three parameters, you are likely to forget at least one of them.
Also, assuming the syntax is properly built into the language (with full compile-time type checking and errors if you try to specify a parameter name that isn't part of the declaration), you get no additional opportunity for nontrivial errors (in the worst case, you just get parse errors that cause a failure as soon as you try to load the file), while removing a lot of potential for other types of errors.
Re: It was already a dangerous site to visit ...
on
PHP.net Compromised
·
· Score: 3, Interesting
It makes sense. The implode function can readily detect the difference between a string and an array through simple type introspection, but the explode function cannot do the same with two strings. Indeed, I would argue that for any function, if the parameters must be of a specific type that can be readily distinguished from the type of other parameters, there's no reason for the parameter order to matter.
Then again, I would argue that the entire notion of programming languages in which the order of arguments is significant is arcane and archaic. IMO, an ideal programming language should require that each parameter be explicitly tagged so that the parameter order never matters, or at a minimum that the order is never implied merely by position. Perl can sort of do this with a hash, Python et al sort of do this with named parameters, etc.
Such a design pattern makes it relatively simple to add additional optional parameters, because the order ceases to matter. It means that you can insert those new parameters in an order that makes logical sense, rather than having to add them at the end of the parameter list with an explicit check to see if the parameter list is empty before shifting off the next item so that you don't break backwards compatibility with existing clients. And so on.
Unfortunately, most programming languages still force you to choose between strict compile-time type checking and mandatory tagging. If you take parameters in a varargs stype, you can force mandatory tagging, but you lose any compile-time checks. If you take parameters individually in the function, somebody can still pass parameters positionally, at which point you lose the readability advantages of being able to reorder the parameter names as you add new parameters.
I get the impression that Python 3 allows you to force explicit tagging by adding "*" as the first parameter. It would be great to see similar functionality in all other programming languages; it just makes a lot more sense than trying to extract meaning out of order.
Slashdot Mirror
The problem is that certificates change regularly. What you really want is public key pinning, where you are warned if the public key changes, without regard to what CA signed it—not just the key fingerprint, either—the entire key. After all, you have the server's public key. Why would you ever start trusting a different public key for the same server?
AFAICT, there are only two valid to reasons rekey a server: if the key gets compromised (which, being a serious security problem, should be publicly disclosed on your server in some way) or because you're upgrading to a larger key. In the latter case, you should ideally sign the new key with the old key so that it is verifiable, and the browser should ignore that the old key is not trusted for key signing when it is only being used as a secondary signature for verifying a key change.
But it really doesn't, at least in the bigger picture. If you, as a business owner, don't move into a new area, assuming that area has a reasonable chance of being profitable, somebody else will. And then you have two companies of 249 employees because your company didn't grow. At some point, the economies of scale resulting from combining into a smaller number of companies with more people far outweigh any disincentive that might appear to exist right at or near the limit, at which point you make the leap to being way above that 250 person limit, and those regulations can't create a disincentive.
In the end, it all balances out.
The reality is that only a tiny percentage of companies are right at 250 employees. Most companies are either way smaller or way larger. A 1,000 employee company is not going to lay off 75% of its workforce just to avoid a law. At best, this creates a small disincentive for companies that are approaching that line to cross it, or a small incentive for companies that are only slightly above the line to reduce their headcount by a few people.
That said, in practice, most companies hire exactly as many people as they need in order to do a particular task (e.g. opening a new store), so unless the impact is serious enough to make a company decide to not expand into a new area, such incentives are unlikely to have any effect that doesn't get lost in the statistical noise, in much the same way that decreases to payroll taxes have little to no impact on hiring at companies that have over a few dozen employees, and for the same reason.
Boots on the ground? It always worked before we had high tech. I mean, before there were phones, they had to plant people inside an organization to learn its secrets unless they just happened to get lucky enough to catch a courier. The fact that communication channels are back to being moderately secure is uninteresting. It's really just a correction of a weakness that high tech introduced in the first place.
And now, with a self-driving car, you can have that bridge-turning experience you've always wanted but could never convince yourself to act on. Let the suicidal rejoice!
[redacted joke about Ted Kennedy]
Exactly. The person who wrote the summary apparently didn't actually read the article, but he/she consumed it. :-D
The summary is misleading. What the study actually says is that the total amount of content that the average person requests, if that person took the time to fully read or watch it would take 15.5 hours per day to fully consume. That's a very critical difference.
For example, let's say you read Slashdot. You read the headline, you read the summary (maybe), you read the article (hah!), and then you open up the comments, skim a few of them, and post a comment or two of your own. However, there are 500 comments farther down the page that you did not read. You spent three minutes on the page, but if you had read and digested every comment, it would have taken forty minutes. This study says that you consumed forty minutes of media.
It's not about how much time you spend consuming media, but rather how much media you are exposed to. This statistic is interesting for entirely different reasons than the amount of time you actually spent. It is a better indicator of how well informed you are (assuming the media is informative, or else it indicates how well you know your memes), and is a good indicator of how much bandwidth you use. By contrast, the amount of time you actually spent is a good metric for obesity and other health problems. :-)
This. By definition, if something is already obviously of benefit to everyone, some company is already doing research on it, and spending government money to subsidize that research provides no benefit whatsoever, because the research would get done anyway. Restrictions like what these senators are proposing fundamentally undermine the usefulness of the NSF, whose sole benefit to humanity is that they fund research that would not otherwise get done. They push the envelope. They explore new ideas whose benefits aren't yet clearly established.
If these people happen to be your senators, please write to them and tell them that this proposal will destroy our nation's ability to compete intellectually in the next century, and sets the stage for total economic collapse in the years to come.
Gaaaah!
[sound of head literally exploding]
The curious thing is that if you solicit sex from someone who a reasonable person would believe was not a minor, but actually is, I'm pretty sure that's still illegal, which is sort of a double standard. I guess the bottom line is to treat sex like cigarettes: if she's under 35, ask for three forms of ID.
BTW, it is not necessarily impossible to prove a belief, or at least to prove it with enough certainty that it qualifies as evidence. For example, it would be interesting to see how a jury would rule if the defendant in such a case provided diary entries that indicated that he or she was reasonably certain that the person on the other end was not actually a minor. Certainly that doesn't prove that the defendant really believed it, but it does at least present reasonable doubt.
No, the oxygen is because fuel needs an oxidizer to burn, and if you aren't in the atmosphere, you don't have that.
Simple discovery should be all you actually need. After that, the rest is just mapping tables between the device's GUID and what it does. You don't typically add devices a hundred at a time. You add them one at a time. When you plug it in, it goes online. Your laptop or iPad or Raspberry Pi or whatever says, "Hey, I see a new electronic switch. What's attached?" And you say, "Bedside table lamp." And now you know what it does.
But even if you're adding hundreds of them at once (e.g. adding wall switches during new home construction), as long as the protocol is bidirectional, it should still be trivial to make the association. Simply put the computer in a mode where it listens for sensor changes. Turn on the wall switch, and your laptop or iPad says, "What did you just turn on?" And you say, "Bedroom ceiling fan." And now you know what it does once again.
I'm also a fan of multiplexing the communication over the existing power lines. It makes no sense to run extra control wires for something that just shouts, "It's 24 degrees" or "Somebody just turned me on" periodically. Just MHO.
As for cost, there's no reason for the controller to cost hundreds of dollars. Most people already have a TV. Use that as the interface, and use a Raspberry Pi Model A tied into the power-line network via USB. It ought to be possible to make a profit selling such devices at $50 apiece easily.
The bigger problem, which this article touches on, is when you want devices to talk to each other, rather than talking to the end user—things like electrically controlled baffles to manage temperature in multiple zones with a single blower—you need not only to know what protocol the devices speak, but also how those devices should integrate with one another, which isn't always obvious and can't always be preprogrammed. Instead, what you really need is an extremely simple, standardized programming language with rules based on measurements (input values) and actions (output values) to facilitate that interaction, and a master computer to handle running those programs—sort of an awk for home automation. For example, you might have a rule like this:
(device[0xdeadbeef01010101 == 1 && (device[0xdeadbeef00000001]->input[0] > device[0xdeadbeef00000002]->input[0] + 3)) { device->[0xdeadbeef00c03156]->output[3] = 0 }
That rule would, of course, be expressed to the user in English as something like "If the thermostat is switched to heat and the bedroom temperature is at least three degrees warmer than the living room temperature, then turn off power to the bedroom baffle" (or even "... close the bedroom baffle").
Of course, that's all interesting in principle, but IMO it is putting the cart before the horse. We first need devices that can communicate with non-brain-damaged protocols. Minimally, this means:
If this sounds like it is reimplementing a more open-hardware version of USB HID over power lines, that's because it is....
Such a design makes lots of things trivial—the stage lighting controller example posed by 486Hawk, for example.
In a modern architecture with proper power management, increasing the speed of the chip often does exactly that. If you graph power consumption over time, the total power consumption is the area under the line. Thus, if you make a chip that takes twice as much instantaneous power while it is active, but can do the work in a third as much time, then as long as you properly power down that extra hardware while it is idle, you're using two-thirds as much power when averaged out over time.
This assumes that the idle power of the faster chip doesn't increase so much that you make up the difference during long periods of inactivity, of course. Reducing idle power is almost invariably an important goal. :-)
Or why PS takes minutes just to launch.
Exactly. When the answers to half of your questions are blindingly obvious without even asking them, you're really wasting your time. Start asking questions that are an actual threat to corporate secrets, though, and at most companies, the employees will clam up faster than a politician caught with a hooker behind a cheap Vegas strip club.
Take Apple for example. Let's see:
And so on. These sorts of questions are so innocuous and the information is so easy to obtain by literally anyone in the general public that even the most paranoid person wouldn't try to keep them secret. They don't represent a real-world way to get any further information in anything but the most bizarre scenarios. The interesting question is whether they can then use that information to get something of value. Short of that, this is like screaming that the sky is falling when really a bird just dropped something on your shoulder.
The fundamental failing here is that these folks naïvely assume everything has to be secret, and that obtaining information at a very low level of trust allows you to take advantage of a slippery slope to obtain information that requires a high level of trust. The reality is quite the opposite when it comes to almost everything on this list. Companies want potential job seekers to know that they have one of the best corporate cafeterias in the area. They want visitors to their campus to be able to use the Wi-Fi network to check their email. They want people to apply on their public jobs website for positions in the cafeteria. And so on. Those needs are fundamentally incompatible with keeping that information secret, period.
Further, for information that does have to be public knowledge, competent companies take steps to mitigate the damage that the information can do. For example, most companies require you to use a badge to access the corporate cafeteria, vet their new hires carefully, put the Wi-Fi on a public network with no access to internal systems, require you to use a VPN for access to any internal systems, require that confidential information be disposed of in locked metal bins, etc. The fact that those mitigations exist is not a secret (yet the existence of a VPN was one of the "flags"); if your security depends on keeping the mechanism of that security a secret, then it is broken by design.
In short, if the company is doing security right, then basically nothing on that list of flags is actually of value to an attacker, making this a really silly study.
Actually, no, California law explicitly allows you to hold a cell phone to place a call, but only in conjunction with a hands-free device, and only when dialing. The cell phone law merely says that it must be configured to support hands-free listening and talking, not dialing. Similarly, the highly problematic anti-texting law that has been used to prosecute people for such things as changing to the next song also has an explicit exception for using the phone to actually call someone, including the use of the phone's address book.
Thus, the law (at least in California) makes it very, very clear that it is acceptable to hold the device in your hand for the purposes of placing a phone call. Helpful tip: if you ever get pulled over and you have your phone in your hand, you should make certain that you are on the phone using your hands-free device when the officer walks up to your car. When the officer asks why you had the phone in your hand, the answer is always, "I was dialing someone on my phone." This has three effects:
1. The officer should say, "Have a nice day," and the traffic stop should end right then. At most, the officer should ask for your license and registration and ensure that they are valid and the vehicle isn't stolen.
2. If it goes to court, you have a legally admissible record of having placed a phone call at the time the officer pulled you over.
3. If the officer issues you a citation anyway, you can potentially sue the prosecutor and the officer for malicious prosecution (or even vexatious litigation if you can show a history of similar prosecutions).
Unfortunately, in California, traffic infractions have been handled as though people were guilty until proven innocent for a very long time. The entire system is rigged to be purely a means of revenue generation, grossly violating both the letter and the spirit of California law, and nobody seems to care, mostly because the cost to fight a ticket is usually greater than the cost of the ticket. Traffic enforcement is a racket, parking enforcement doubly so.
Ah, sorry. I screwed up the example slightly. In a proper example, there's always a little more code to ensure that "a" is a strictly positive integer, because if it isn't, then a + 2 is guaranteed to not overflow, making the check superfluous.
Another, more common example of code optimizations causing security problems is this pattern:
int a = [some value obtained externally];
// integer overflow occurred ...
int b = a + 2;
if (b < a) {
}
The C spec says that signed integer overflow is undefined. If a compiler does no optimization, this works. However, it is technically legal for the compiler to rightfully conclude that two more than any number is always larger than that number, and optimize out the entire "if" statement and everything inside it.
For proper safety, you must write this as:
int a = [some value obtained externally];
// integer overflow will occur ...
if (INT_MAX - a < 2) {
}
int b = a + 2;
Oops. I think you just a word there.
In my experience, it's a safe bet that any company that cuts as many corners as Adobe does in one area probably cuts corners in almost every other area. This leads to the obvious question of whether the crackers will find any serious security holes in Photoshop and exploit them. Given how much they seem to resist fixing even the most trivial bugs in Photoshop, I'd be willing to bet that the entire codebase is an unholy cesspool, which means it is probably rife with security holes, too.
It's also easy to spot. As a rule, eval should be a security red flag in pretty much any programming language. The only even semi-valid reason to use it is for certain types of shell scripting, where it can be unavoidable. In fact, it ranks right up there with system() in the red flag handbook.
Only if either A. you have access to a park-and-ride facility that is closer to your house than your workplace is, or B. the bus stops very close to both your home and your workplace. I've usually found that unless your commute is at least half an hour by car, you'll spend more time walking to and from the bus than you would spend driving, and even if you don't count the walking time, it still takes 2–3 times as long to get there. As always, YMMV.
Public transit is great for moderately long commutes, particularly if parking sucks at your destination. If I'm going into San Francisco, I take public transit. If I'm going to work, though, there's actually enough parking, so it isn't worth the 20 minutes of walking and 30+ minutes on a bus just to save 15 minutes in my car. It would probably be slightly cheaper, but the inconvenience is pretty severe. And that's without having to change buses at all.
It's horrible only because PHP doesn't build such functionality cleanly into the language. The ideal syntax looks more like this:
implode(glue => ",", pieces => $stuff);
Or even this:
implode(glue=",", pieces=$stuff);
And you're very wrong about reordering being the only benefit. Named calling parameters also provide much-needed information about what the parameters actually do when you're looking at the function call itself, without which you must mentally cross-reference the original function declaration to know how those parameters are being used. Being explicit as part of the call syntax reduces cognitive load, particularly when you're doing maintenance programming of a large code base, particularly when a function takes more than a couple of parameters. You know the old adage: If a function takes more than three parameters, you are likely to forget at least one of them.
Also, assuming the syntax is properly built into the language (with full compile-time type checking and errors if you try to specify a parameter name that isn't part of the declaration), you get no additional opportunity for nontrivial errors (in the worst case, you just get parse errors that cause a failure as soon as you try to load the file), while removing a lot of potential for other types of errors.
It makes sense. The implode function can readily detect the difference between a string and an array through simple type introspection, but the explode function cannot do the same with two strings. Indeed, I would argue that for any function, if the parameters must be of a specific type that can be readily distinguished from the type of other parameters, there's no reason for the parameter order to matter.
Then again, I would argue that the entire notion of programming languages in which the order of arguments is significant is arcane and archaic. IMO, an ideal programming language should require that each parameter be explicitly tagged so that the parameter order never matters, or at a minimum that the order is never implied merely by position. Perl can sort of do this with a hash, Python et al sort of do this with named parameters, etc.
Such a design pattern makes it relatively simple to add additional optional parameters, because the order ceases to matter. It means that you can insert those new parameters in an order that makes logical sense, rather than having to add them at the end of the parameter list with an explicit check to see if the parameter list is empty before shifting off the next item so that you don't break backwards compatibility with existing clients. And so on.
Unfortunately, most programming languages still force you to choose between strict compile-time type checking and mandatory tagging. If you take parameters in a varargs stype, you can force mandatory tagging, but you lose any compile-time checks. If you take parameters individually in the function, somebody can still pass parameters positionally, at which point you lose the readability advantages of being able to reorder the parameter names as you add new parameters.
I get the impression that Python 3 allows you to force explicit tagging by adding "*" as the first parameter. It would be great to see similar functionality in all other programming languages; it just makes a lot more sense than trying to extract meaning out of order.