You don't need access to their PC if you have a copy of its credentials (otherwise, yes, it's a lot of effort to dig stuff out of a phone that probably could have come from the PC itself.) But who knows what kind of access you have to their PC? Perhaps you can send a corrosive DLNA packet to iTunes and get the credentials that way. Or maybe a snatch-and-grab phishing attack has only the capacity to send a few hundred bytes before it gets shut down, instead of letting you download all the juicy gigabytes of backup files.
Attacks don't always have to be directly on the repository of the info; sometimes it's very useful to be able to make them from a distance.
It's not really a MITM attack, it's spoofing credentials. It's copying the credential token from machine X, installing it on machine Y, then telling machine Y to connect to iCloud pretending to be machine X, and then downloading all the ancient backups in hopes they contained undeleted and unprotected juicy information.
In the past people have used "sort-of" MITM attacks* for jailbreaking, specifically to keep your iPhone from "upgrading" itself to the new version of iOS. The jailbreakers had figured out that they could restore from an old version of iOS and jailbreak it, so Apple wanted to stop that. They introduced SHSH blobs that contained your phone's signed version info, and when you wanted to install an old version of iOS from a backup, they would check to make sure you hadn't upgraded to a newer version. So the jailbreakers came up with a program called TinyUmbrella that you would load up with your iPhone's old SHSH blobs, and it would pretend to be the official Apple blob server. You'd modify your hosts file to redirect the Apple server at your local host, run TinyUmbrella, then launch iTunes. When iTunes wanted to restore the user-specified version of iOS, it would request the latest blobs, but TinyUmbrella would deliver them, tricking the phone into staying at its older version of iOS. In more recent versions of iOS Apple required the server to securely exchange the messages so iTunes could no longer be fooled, but this worked through about iOS version 6 or so.
Of course, this is not a MITM attack against iCloud, but rather against their update process. Still, it was a pretty clever hack.
* I say "sort-of" because TinyUmbrella did not intercept the blob exchange itself; it only stood in as a phony Apple server for a SHSH blob you had to extract on your own, using another tool.
I was a member of my high school's student parliament but wouldn't think to report that during a background check and wouldn't consider it any more relevant than what this woman did thirty years ago.
Was your high school's student parliament dedicated to the violent overthrow of the US government? Don't you think that's maybe the kind of student activity you might find rather difficult to forget? Then it's probably not the same thing.
Private research dollars are expected to produce profitable innovations. Bell Labs wasn't run for the good of all humanity, it was run to innovate in the communications space, and it did. They made tremendous amounts of money on the research their lab produced. And the rest of us have continued to benefit from the existence of the transistor. But even though they were wildly successful, where are they now?
Government funded research isn't expected to produce profit, but instead to the betterment of all. Look at any the Big Science projects, such as anything NASA does, or the Human Genome Sequencing project. These projects aren't intended to produce money, they are intended to further our collective understanding.
If private labs are profitable, they are built and run. Google Labs, Microsoft Research, etc., they do a lot of useful stuff and donate much of it. Even the research universities are not contributing as much to the common good as they once did, and are now becoming profit centers for their schools. A tiny example is to look at how much money the University of Minnesota's ag laboratories have made patenting apple hybrids. This is something that once upon a time would have been shared with everyone.
I've always said that when I retire I'm going to go back to school and finish that physics degree.
If it's something you're passionate about, don't wait. I went back as soon as my son left the house, and I found I had more free time. Very satisfying.
The entire premise of the article is bull. Are companies ever going to get off this fixation on specific programming languages?
No. Companies (at least the executives running them) look at their code base differently than technologists. They see the cost of maintenance as X$, and if it's written in ten languages, the cost of hiring ten people to do maintenance is 10X. If you say "one person can know ten languages" they assume such people are expensive and very hard to find.
They want a simple way to manage the cost of maintenance. Cutting the number of languages in use accomplishes that goal, in their minds. Therefore, this practice will continue at companies that don't have unlimited IT budgets.
This. Something like 5-15% of people are immune to logic, and you just have to ignore them if you want to make progress. What it means is that you have to convince more of the people in the "unknown" category. The problem is that of those logic-proof people, some have a strong financial incentive to sway opinions to their side, so it becomes a tough battle.
Not the whole audience. Some of us actually do care that they're not spouting the technobabble you hear in the typical Sci Fi shows, or that when the characters do make mention of it, it's to mock it, just as we do.
Normal cell conversation encryption isn't end-to-end. GSM encryption only protects the conversation from your phone to the tower you're talking to. You're right in that both parties each need one of the high security phones to support true end to end encryption. I've heard it said that at Facetime and iMessage used to be secure, but the tinfoil hat crowd has claimed Apple has since had to provide "lawful intercept capability".
Because the baseband systems are generally invisible to the phone OS, and because the phone OS is usually the place people are interested in hacking, they have not received much attention. Still, there are quite a few researchers who have begun hacking the baseband stack, and in general they've found them to be very poorly coded, and riddled with security vulnerabilities. They have discovered serious flaws that allow malformed packets from the wireless network to hack the phones. While it may be "unlikely", it could certainly be possible.
The US is finally going to Chip and PIN next year. It just takes a long time to get a million businesses to spend the money needed to convert their readers.
Sure, chip and PIN messages can be intercepted, but the data that can be intercepted cannot be reused dor a second fraudulent transaction, and cannot be tampered with.
Chip and PIN moves the trust out of the merchants' terminals and out of the network. Only the chip and the bank's systems have the secret knowledge needed to participate in the conversation. You no longer have to wonder if Home Depot's readers are safe, because it won't matter.
With a billion credentials, they certainly haven't had the chance to exploit them all yet. It's too late for 0.01% of the victims, but not too late for the rest of us.
In cryptography, it means a number that is only used once -- n-once. However, it is actually the wrong word to use here, as a cryptographic seed's most important attribute is unpredictability.
Don't underestimate the importance of the right education. Our company almost collapsed under the stupid organizational structure put in place by our last CIO, who was not an engineer, and had no idea how engineers work. I never before realized how much damage an org chart could do.
I also make it a point to go through supermarket lines with a real cashier rather than a do-it-yourself scanner. Not because I am a technophobe (quite the opposite) but because I like dealing with a real human.
I generally avoid the self checkout, but I might use it if there are no other customers in front of me and there's a line at the cashier. Have you ever waited for a self checkout behind a typical person? I want to claw my brain out as I watch them stupidly wave a package over the scanner again and again, all the while covering the barcode with their hand. Or they bounce everything off the glass, as if they're buying basketballs. Or they have to sift through their entire basket, to find that one bottle of Axlotl juice that they want to put in the bag next.
Maybe the requirement to upload bulk updates was a lower priority for that development team than getting other features implemented, and it's still on their stack. Or maybe they ran out of budget before getting to implement that feature. Maybe the stakeholder who was assigned to work with that development team failed to understand his or her own user base - the stakeholder's job is to provide the business perspective, and maybe he thought a pretty color scheme was more important than bulk uploads.
People can still make poor decisions in any framework, which does not necessarily invalidate that framework. The good thing about an Agile approach is that as long as the team is there, the software can still be easily changed.
And if she hasn't already, your wife has the responsibility to file a bug report or at least report her concerns to the stakeholder - the team may not even know of this need for bulk updating, or the financial impact of the one-at-a-time process. It sounds like it's fairly easy to quantify the cost of the inefficiency, which should help prioritize it accordingly.
Software is malleable in that whatever is on the inside can be safely changed through refactoring to meet your new design goals. And yes, you have to adhere to strong design principles: the open/close principle helps ensure that you can safely migrate to a new API while still supporting your old clients; the interface segregation principle helps ensure that your clients are always getting the right service without confusion; and you have to commit to serious code coverage metrics for your automated tests. That means you don't even write an exception handler unless you have a unit test that proves it properly catches the exception.
And developers absolutely cannot work in a vacuum, or be incompetent - there's no room for them. So when they're writing the negative tests, they are expected to be smart enough understand the permutations and the boundaries in the requirements they're implementing. But high complexity means lots of paths through the code, which means lots of tests, and this need for testability that is practically and realistically achievable provides incentive for the developer to keep code complexity down. That is a feat he or she continually accomplishes through the refactoring step of TDD. That way, instead of writing fifty tests, perhaps they can split it into five modules and write ten tests. Not coincidentally, this activity continues to improve modularity, reusability, and maintainability of the module. So it improves the code's design after it's written (an activity that still was not needed up front.) As a bonus, you get to execute the automated tests again and again, so future maintainers benefit by knowing they haven't broken your module. TDD is actually a design methodology, not a test strategy.
And I know that you're using CAPTCHAs as a clever example (how can you prove that you wrote a transformation so complex that you can't Turing test it?), but the real answer there is it depends on what code you're testing. Are you testing the code that processes the outcome for a true or false response? Are you testing the user interface, that allows them to type letters into a text box? Those tests aren't especially hard to automate. But when you're talking about the specifics of "is this CAPTCHA producing a human-interpretable output?" then you're talking about usability testing, which is expensive, manual, and slow. It's a task you'd perform after changing the CAPTCHA generation routines, but you wouldn't be able to automate. So I'd have to manually test it only after changing the generation routines, and I wouldn't alter the generation routines without scheduling more user testing.
(If I ever had to write a CAPTCHA for real, I'd probably try to parameterize it and allow the admins to tweak the image generation without my having to further change and test the code. So if the admin figures out how to tweak it to a black-on-black test, and preventing low-contrast color schemes wasn't identified in the original effort, the admin could still untweak it. And yes, that should generate a bug report, even though it would be recoverable.)
But in terms of difficult to test code, teams that do this kind of development work well will often have different suites of tests for different situations. Etsy does this really well, by splitting tests into various categories: slow, flaky, network, trunk, sleep, database, etc. They always run all trunk tests on every build, but only if the developer is working on something that tests the actual network communication would he execute the network tests. See http://codeascraft.com/2011/04... for their really inspiring blog.
There's a ton (or a megabyte) wrong with the hardware/software construction analogy, but organizations like the IEEE keep pushing on it because that's the way people look at "engineering".
The problem is the analogy makes everyone who doesn't understand software think there has to be some "big design up front" before you write software. Of course, when the end product is as infinitely malleable as software, that's simply not true. The human interface needs a design in order to mesh with the humans in an elegant and consistent fashion, but the code? No. The only purpose of code design is to make the code readable and maintainable, and those are attributes you achieve through test driven development and continual refactoring.
I'm not saying that ideas like object orientation, design patterns, design principles, etc., are unimportant, nor am I saying that an overall application structure like Model-View-Controller, or Extract-Transform-Load, is wrong. But the continued efforts wasted trying to make Big Design Up Front work leads to unimaginably expensive wasteful processes that only work for a very limited, very rigid set of products, and of those most fail anyway. Worse is when non-developers fail to realize that the code itself is the language of design. Back to the construction analogy, people think that an engineer produces a blueprint, then 100 people grab hammers and shovels and build the building. Hire 200 people. They don't all have to be skilled laborers, either, some are just guys with shovels and hammers. Want it to go up faster? But in software development, anything automatable has already been automated. When a software developer needs to do "construction", he or she types "make". Want it to go faster? Buy a bigger build server.
The engineering the IEEE is trying to achieve is accomplished by test-first development, continual automated testing, and peer code reviews. It is not achieved by producing thousands of documents, months of procedures, and boards of review.
My father-in-law believed he could "witch" wires, pipes, or whatever, using two pieces of copper wire. Funny thing is, he could never repeat a witching while blindfolded. We figured that decades in the construction industry meant that he could subconsciously spot the clues where a typical pipeline would be run.
If I were planning where to run tile in a field, I'd look for the low spot, and the easiest, straightest run from there to a drainage ditch. Doesn't take beechwood sticks or copper wires to figure that out.
V2V doesn't have to be limited to reporting just your own vehicle's data. Each packet could include data known about other nearby vehicles. Why does this matter? Because my car has radar, cameras, and ultrasonic sensors that detect all sorts of nearby vehicles today, so its packets could include reports on all the nearby vehicles it detects, including your old car.
Additional data on other vehicles helps identify failing systems (or cheats), and can theoretically provide some corroborating information about the nearby traffic. Let's say that one of the paranoid people who have posted above tries to dodge tickets by rigging their V2V to always report they're traveling the speed limit, even when they're exceeding it by 30 km/h (even though it's obvious that reporting your coordinates every 100 milliseconds will reveal your true speed.) But if a couple different cars with radar report "vehicle at X,Y, bearing B, change in bearing -3.000 d/s, velocity 38.00 m/s, acceleration +0.1 m/s/s", then even if the offending car self-reports that it is going at 29.00 m/s the rest of the cars in the area can still respond as if it were traveling at 38.00 m/s.
(It's also interesting to consider that evolution will tend to remove incorrectly reporting cars from the road, as they will be involved in more accidents.)
Note that this doesn't even violate anyone's privacy in order to achieve safety. The packet doesn't have to identify the vehicle, as its location is (or at least should be) unique. That way if my right side ultrasonic blind spot sensor picks up a car that is 2 m away, it can simply report the existence of a vehicle at the computed X,Y.
Finally, how does this benefit you, in your old vehicle that doesn't have a V2V system? Once other cars on the road have V2V, those other cars will control themselves to avoid colliding with you. Every car that automatically steers itself away from harming you is one less chance at an accident you might get in. It won't make much of a difference initially, but as time goes on and more vehicles become equipped, you'll gradually have your risks reduced.
But your quote specifically says, "principally through performance on a common statewide placement examination." It does not say the CSU system uses SAT or ACT for admissions standards. Perhaps if they based admissions on the SAT or ACT results, they'd need less remediation. Of course, that means rejecting a bunch of the little revenue-generating tykes instead of sending them over to the bursar's office to extract the maximum amount of Financial Aid money from them.
It would be interesting to compare the graduation rates to the remedial course attendance. Do the remedial students fail to graduate at a higher rate than the qualified students? Are we doing those younger, under-qualified students a disservice by allowing them to matriculate?
Slashdot Mirror
You don't need access to their PC if you have a copy of its credentials (otherwise, yes, it's a lot of effort to dig stuff out of a phone that probably could have come from the PC itself.) But who knows what kind of access you have to their PC? Perhaps you can send a corrosive DLNA packet to iTunes and get the credentials that way. Or maybe a snatch-and-grab phishing attack has only the capacity to send a few hundred bytes before it gets shut down, instead of letting you download all the juicy gigabytes of backup files.
Attacks don't always have to be directly on the repository of the info; sometimes it's very useful to be able to make them from a distance.
Oh, the fools! If only they'd built it. with 6001 hulls! When will they learn?
It's not really a MITM attack, it's spoofing credentials. It's copying the credential token from machine X, installing it on machine Y, then telling machine Y to connect to iCloud pretending to be machine X, and then downloading all the ancient backups in hopes they contained undeleted and unprotected juicy information.
In the past people have used "sort-of" MITM attacks* for jailbreaking, specifically to keep your iPhone from "upgrading" itself to the new version of iOS. The jailbreakers had figured out that they could restore from an old version of iOS and jailbreak it, so Apple wanted to stop that. They introduced SHSH blobs that contained your phone's signed version info, and when you wanted to install an old version of iOS from a backup, they would check to make sure you hadn't upgraded to a newer version. So the jailbreakers came up with a program called TinyUmbrella that you would load up with your iPhone's old SHSH blobs, and it would pretend to be the official Apple blob server. You'd modify your hosts file to redirect the Apple server at your local host, run TinyUmbrella, then launch iTunes. When iTunes wanted to restore the user-specified version of iOS, it would request the latest blobs, but TinyUmbrella would deliver them, tricking the phone into staying at its older version of iOS. In more recent versions of iOS Apple required the server to securely exchange the messages so iTunes could no longer be fooled, but this worked through about iOS version 6 or so.
Of course, this is not a MITM attack against iCloud, but rather against their update process. Still, it was a pretty clever hack.
* I say "sort-of" because TinyUmbrella did not intercept the blob exchange itself; it only stood in as a phony Apple server for a SHSH blob you had to extract on your own, using another tool.
I was a member of my high school's student parliament but wouldn't think to report that during a background check and wouldn't consider it any more relevant than what this woman did thirty years ago.
Was your high school's student parliament dedicated to the violent overthrow of the US government? Don't you think that's maybe the kind of student activity you might find rather difficult to forget? Then it's probably not the same thing.
Private research dollars are expected to produce profitable innovations. Bell Labs wasn't run for the good of all humanity, it was run to innovate in the communications space, and it did. They made tremendous amounts of money on the research their lab produced. And the rest of us have continued to benefit from the existence of the transistor. But even though they were wildly successful, where are they now?
Government funded research isn't expected to produce profit, but instead to the betterment of all. Look at any the Big Science projects, such as anything NASA does, or the Human Genome Sequencing project. These projects aren't intended to produce money, they are intended to further our collective understanding.
If private labs are profitable, they are built and run. Google Labs, Microsoft Research, etc., they do a lot of useful stuff and donate much of it. Even the research universities are not contributing as much to the common good as they once did, and are now becoming profit centers for their schools. A tiny example is to look at how much money the University of Minnesota's ag laboratories have made patenting apple hybrids. This is something that once upon a time would have been shared with everyone.
Private money isn't the only answer.
I've always said that when I retire I'm going to go back to school and finish that physics degree.
If it's something you're passionate about, don't wait. I went back as soon as my son left the house, and I found I had more free time. Very satisfying.
The entire premise of the article is bull. Are companies ever going to get off this fixation on specific programming languages?
No. Companies (at least the executives running them) look at their code base differently than technologists. They see the cost of maintenance as X$, and if it's written in ten languages, the cost of hiring ten people to do maintenance is 10X. If you say "one person can know ten languages" they assume such people are expensive and very hard to find.
They want a simple way to manage the cost of maintenance. Cutting the number of languages in use accomplishes that goal, in their minds. Therefore, this practice will continue at companies that don't have unlimited IT budgets.
This. Something like 5-15% of people are immune to logic, and you just have to ignore them if you want to make progress. What it means is that you have to convince more of the people in the "unknown" category. The problem is that of those logic-proof people, some have a strong financial incentive to sway opinions to their side, so it becomes a tough battle.
Not the whole audience. Some of us actually do care that they're not spouting the technobabble you hear in the typical Sci Fi shows, or that when the characters do make mention of it, it's to mock it, just as we do.
Normal cell conversation encryption isn't end-to-end. GSM encryption only protects the conversation from your phone to the tower you're talking to. You're right in that both parties each need one of the high security phones to support true end to end encryption. I've heard it said that at Facetime and iMessage used to be secure, but the tinfoil hat crowd has claimed Apple has since had to provide "lawful intercept capability".
Because the baseband systems are generally invisible to the phone OS, and because the phone OS is usually the place people are interested in hacking, they have not received much attention. Still, there are quite a few researchers who have begun hacking the baseband stack, and in general they've found them to be very poorly coded, and riddled with security vulnerabilities. They have discovered serious flaws that allow malformed packets from the wireless network to hack the phones. While it may be "unlikely", it could certainly be possible.
Also, take a look at CANDYGRAM.
The US is finally going to Chip and PIN next year. It just takes a long time to get a million businesses to spend the money needed to convert their readers.
Sure, chip and PIN messages can be intercepted, but the data that can be intercepted cannot be reused dor a second fraudulent transaction, and cannot be tampered with.
Chip and PIN moves the trust out of the merchants' terminals and out of the network. Only the chip and the bank's systems have the secret knowledge needed to participate in the conversation. You no longer have to wonder if Home Depot's readers are safe, because it won't matter.
With a billion credentials, they certainly haven't had the chance to exploit them all yet. It's too late for 0.01% of the victims, but not too late for the rest of us.
In cryptography, it means a number that is only used once -- n-once. However, it is actually the wrong word to use here, as a cryptographic seed's most important attribute is unpredictability.
Don't underestimate the importance of the right education. Our company almost collapsed under the stupid organizational structure put in place by our last CIO, who was not an engineer, and had no idea how engineers work. I never before realized how much damage an org chart could do.
... the use of the new "picture" tag which is a container for multiple image sizes/formats ...
... and it will only require 50,000 words in which to send it.
I also make it a point to go through supermarket lines with a real cashier rather than a do-it-yourself scanner. Not because I am a technophobe (quite the opposite) but because I like dealing with a real human.
I generally avoid the self checkout, but I might use it if there are no other customers in front of me and there's a line at the cashier. Have you ever waited for a self checkout behind a typical person? I want to claw my brain out as I watch them stupidly wave a package over the scanner again and again, all the while covering the barcode with their hand. Or they bounce everything off the glass, as if they're buying basketballs. Or they have to sift through their entire basket, to find that one bottle of Axlotl juice that they want to put in the bag next.
All you have to do is sign up and they'll migrate your email account to their IMAP servers. https://xcsignup.comcast.net/o...
IIRC they hurriedly provided this back about the time Windows 8 came out, because Windows 8 has no POP3 client.
Maybe the requirement to upload bulk updates was a lower priority for that development team than getting other features implemented, and it's still on their stack. Or maybe they ran out of budget before getting to implement that feature. Maybe the stakeholder who was assigned to work with that development team failed to understand his or her own user base - the stakeholder's job is to provide the business perspective, and maybe he thought a pretty color scheme was more important than bulk uploads.
People can still make poor decisions in any framework, which does not necessarily invalidate that framework. The good thing about an Agile approach is that as long as the team is there, the software can still be easily changed.
And if she hasn't already, your wife has the responsibility to file a bug report or at least report her concerns to the stakeholder - the team may not even know of this need for bulk updating, or the financial impact of the one-at-a-time process. It sounds like it's fairly easy to quantify the cost of the inefficiency, which should help prioritize it accordingly.
Software is malleable in that whatever is on the inside can be safely changed through refactoring to meet your new design goals. And yes, you have to adhere to strong design principles: the open/close principle helps ensure that you can safely migrate to a new API while still supporting your old clients; the interface segregation principle helps ensure that your clients are always getting the right service without confusion; and you have to commit to serious code coverage metrics for your automated tests. That means you don't even write an exception handler unless you have a unit test that proves it properly catches the exception.
And developers absolutely cannot work in a vacuum, or be incompetent - there's no room for them. So when they're writing the negative tests, they are expected to be smart enough understand the permutations and the boundaries in the requirements they're implementing. But high complexity means lots of paths through the code, which means lots of tests, and this need for testability that is practically and realistically achievable provides incentive for the developer to keep code complexity down. That is a feat he or she continually accomplishes through the refactoring step of TDD. That way, instead of writing fifty tests, perhaps they can split it into five modules and write ten tests. Not coincidentally, this activity continues to improve modularity, reusability, and maintainability of the module. So it improves the code's design after it's written (an activity that still was not needed up front.) As a bonus, you get to execute the automated tests again and again, so future maintainers benefit by knowing they haven't broken your module. TDD is actually a design methodology, not a test strategy.
And I know that you're using CAPTCHAs as a clever example (how can you prove that you wrote a transformation so complex that you can't Turing test it?), but the real answer there is it depends on what code you're testing. Are you testing the code that processes the outcome for a true or false response? Are you testing the user interface, that allows them to type letters into a text box? Those tests aren't especially hard to automate. But when you're talking about the specifics of "is this CAPTCHA producing a human-interpretable output?" then you're talking about usability testing, which is expensive, manual, and slow. It's a task you'd perform after changing the CAPTCHA generation routines, but you wouldn't be able to automate. So I'd have to manually test it only after changing the generation routines, and I wouldn't alter the generation routines without scheduling more user testing.
(If I ever had to write a CAPTCHA for real, I'd probably try to parameterize it and allow the admins to tweak the image generation without my having to further change and test the code. So if the admin figures out how to tweak it to a black-on-black test, and preventing low-contrast color schemes wasn't identified in the original effort, the admin could still untweak it. And yes, that should generate a bug report, even though it would be recoverable.)
But in terms of difficult to test code, teams that do this kind of development work well will often have different suites of tests for different situations. Etsy does this really well, by splitting tests into various categories: slow, flaky, network, trunk, sleep, database, etc. They always run all trunk tests on every build, but only if the developer is working on something that tests the actual network communication would he execute the network tests. See http://codeascraft.com/2011/04... for their really inspiring blog.
There's a ton (or a megabyte) wrong with the hardware/software construction analogy, but organizations like the IEEE keep pushing on it because that's the way people look at "engineering".
The problem is the analogy makes everyone who doesn't understand software think there has to be some "big design up front" before you write software. Of course, when the end product is as infinitely malleable as software, that's simply not true. The human interface needs a design in order to mesh with the humans in an elegant and consistent fashion, but the code? No. The only purpose of code design is to make the code readable and maintainable, and those are attributes you achieve through test driven development and continual refactoring.
I'm not saying that ideas like object orientation, design patterns, design principles, etc., are unimportant, nor am I saying that an overall application structure like Model-View-Controller, or Extract-Transform-Load, is wrong. But the continued efforts wasted trying to make Big Design Up Front work leads to unimaginably expensive wasteful processes that only work for a very limited, very rigid set of products, and of those most fail anyway. Worse is when non-developers fail to realize that the code itself is the language of design. Back to the construction analogy, people think that an engineer produces a blueprint, then 100 people grab hammers and shovels and build the building. Hire 200 people. They don't all have to be skilled laborers, either, some are just guys with shovels and hammers. Want it to go up faster? But in software development, anything automatable has already been automated. When a software developer needs to do "construction", he or she types "make". Want it to go faster? Buy a bigger build server.
The engineering the IEEE is trying to achieve is accomplished by test-first development, continual automated testing, and peer code reviews. It is not achieved by producing thousands of documents, months of procedures, and boards of review.
My father-in-law believed he could "witch" wires, pipes, or whatever, using two pieces of copper wire. Funny thing is, he could never repeat a witching while blindfolded. We figured that decades in the construction industry meant that he could subconsciously spot the clues where a typical pipeline would be run.
If I were planning where to run tile in a field, I'd look for the low spot, and the easiest, straightest run from there to a drainage ditch. Doesn't take beechwood sticks or copper wires to figure that out.
V2V doesn't have to be limited to reporting just your own vehicle's data. Each packet could include data known about other nearby vehicles. Why does this matter? Because my car has radar, cameras, and ultrasonic sensors that detect all sorts of nearby vehicles today, so its packets could include reports on all the nearby vehicles it detects, including your old car.
Additional data on other vehicles helps identify failing systems (or cheats), and can theoretically provide some corroborating information about the nearby traffic. Let's say that one of the paranoid people who have posted above tries to dodge tickets by rigging their V2V to always report they're traveling the speed limit, even when they're exceeding it by 30 km/h (even though it's obvious that reporting your coordinates every 100 milliseconds will reveal your true speed.) But if a couple different cars with radar report "vehicle at X,Y, bearing B, change in bearing -3.000 d/s, velocity 38.00 m/s, acceleration +0.1 m/s/s", then even if the offending car self-reports that it is going at 29.00 m/s the rest of the cars in the area can still respond as if it were traveling at 38.00 m/s.
(It's also interesting to consider that evolution will tend to remove incorrectly reporting cars from the road, as they will be involved in more accidents.)
Note that this doesn't even violate anyone's privacy in order to achieve safety. The packet doesn't have to identify the vehicle, as its location is (or at least should be) unique. That way if my right side ultrasonic blind spot sensor picks up a car that is 2 m away, it can simply report the existence of a vehicle at the computed X,Y.
Finally, how does this benefit you, in your old vehicle that doesn't have a V2V system? Once other cars on the road have V2V, those other cars will control themselves to avoid colliding with you. Every car that automatically steers itself away from harming you is one less chance at an accident you might get in. It won't make much of a difference initially, but as time goes on and more vehicles become equipped, you'll gradually have your risks reduced.
But your quote specifically says, "principally through performance on a common statewide placement examination." It does not say the CSU system uses SAT or ACT for admissions standards. Perhaps if they based admissions on the SAT or ACT results, they'd need less remediation. Of course, that means rejecting a bunch of the little revenue-generating tykes instead of sending them over to the bursar's office to extract the maximum amount of Financial Aid money from them.
It would be interesting to compare the graduation rates to the remedial course attendance. Do the remedial students fail to graduate at a higher rate than the qualified students? Are we doing those younger, under-qualified students a disservice by allowing them to matriculate?