Failing to apply the patch would be the failure of that one person to order the patch applied, plus the failure of his superior to notice that an action item hadn't been handled, plus a failure of the security team to notice that a ticket hadn't been completed, plus the failure of the head of the security team to notice his subordinates had uncompleted tickets sitting there. All this stuff should be tracked, and where I work it is and we have daily status meetings where stuff like this gets asked about, and development team managers and product managers have weekly status meetings where lack of progress on tickets and what needs done about it is a standard agenda item.
Plus a failure of their regular security auditing process to detect that a machine was running a version of software below the minimum allowed version. All this stuff should be detected programmatically in a company that size. This was not a failure of one person. This was a complete failure of the entire security organization at every level, which usually points to either a complete lack of leadership, inadequate budget to hire sufficient qualified staff, or (more likely) all of the above.
You could think of it as two-core CPU with a dedicated bus for maintaining cache coherency. If that bus stops working, you could still use the CPU, but you'd have to handle cache coherency externally by bus snooping or per-page reader-writer locks on main memory or some other scheme.:-)
It is pretty strange... for all their faults, the mainstream media is going to be about as good as you can expect on quickly vetting information, and there's no way that Facebook and Google would be able to verify things any faster without an equal amount of manpower. The thesis that they should is absurd.
I don't think anyone is suggesting that they should. I think what people are suggesting is that those sites should recognize whether something is a trending news story, recognize whether a given site has a history of publishing accurate information or spewing bulls**t, and rank the results/boost the posts accordingly.
On a related note, all the comments about censorship are way off the mark. Nobody is proposing making the 4chan trolls impossible to find. They're proposing ranking them lower than those likely-more-accurate mainstream news sources. You'd still be able to get to them by searching for appropriate terms or whatever, but an average person who wasn't looking for conspiracy theories wouldn't typically click through enough pages to stumble across them when searching for news about some world event.
And if the reports of their former security head being a music major are accurate, they were uniquely qualified to recognize when the contractors could not hum the right tune....
This sounds like standard MBA behavior. Being secure is expensive in the short term, which hurts short-term profits, which hurts the value of their options. Therefore, in their minds, it is better to factor in insecurity as a long-term risk and spend as little money as possible on it, knowing that when it crashes, they'll get new options priced at a lower price point anyway.
And this is why we have government regulations. Unbridled capitalism led by unscrupulous people would otherwise ruin us all.
The petition provided accurate information. The FCC turned down the request to add booster AM transmitters, because they considered the introduction of "experimental stations" a backdoor way of extending the broadcast license of the station.
Not quite. The repeaters in question had been in continuous operation for anywhere from 14 to 18 years. The FCC denied permission to continue operating these repeaters because they felt that there was no further benefit to experimenting with synchronous repeater technology, and that they were effectively just being used as commercial stations at this point, which requires a competitive bidding process.
The decision is, IMO, dubious, because they should have done this at least a decade sooner. De-licensing the repeaters after so many years of continuous repeater operation is tantamount to reducing the de-facto range of the main station, which represents the loss of a resource that the community had grown to depend on.
Really, this was a screw-up by the George W. Bush FCC, after which the Obama FCC said, "Screw it, we're not touching this mess", and subsequently, the Trump FCC said, "Let's poke a stick into this round, brown, paper-like object hanging under the eaves and see what happens."
The ugly layout of the iphone X is probably an example of this. They should have waited another five years for smaller facial sensors which could be put properly on the edge of the screen with only a minimal loss of screen space or they should have waited for a technology to do infra-red sensing through the existing screen. As it is, the design compromise is a) ugly and b) make using many apps more difficult. Probably that's an example of a design compromise which Apple would not have made in the past.
It's telling that I wasn't the only person in the room who used the word "ugly" the instant I saw it. In a room full of about thirty software engineers, all of whom use Apple products on a daily basis. This is by far the most un-Apple-like product I've seen since Spindler.
But it is by no means the first sign of their design decline. Here's a short list of only the most questionable design decisions they've made in the past five-ish years:
Apple TV (4th generation) comes with rechargeable remote, but no way to charge the remote.
iPhone 5 power button integrated on the motherboard (redesigned in 5s because of too many failures)
iPhone 6 and later come with power button across from the volume buttons, resulting in high error rate.
iPhone 8, and X glass back (I guess because plastic isn't snooty enough?)
Pro laptops missing the escape key (did all the vi users at Apple leave for Google and Tesla?)
Pro desktops that have almost no expandable storage, minimal GPU upgradability, and can't be rack-mounted
Mac Minis with no four-core models
MagSafe 2 (too thin to stay connected)
Removing MagSafe 2
Helvetica Neue and flat icons
To be fair, they made a bunch of questionable design decisions prior to that, like the glass back in the iPhone 4, the general unattractiveness of the cheese grater G5/Mac Pro design (though it was very functional, and I'd take it back in a second over what we have now), etc., but before approximately 2012, I saw one significant design screw-up every 2–3 years, and now I see two or three per year.
Things started going downhill before Forstall left, which pretty much points to SJ's "no" vote mattering a lot more than people realize.
First of all, do not leave your iPhone in direct sunlight. It'll kill it. Second, don't immerse it in water—not even to clean it. But the most important rule—the rule you can never forget—no matter how much it buzzes, no matter how red the charge indicator is, never charge it after midnight.
Yet you blame Intel because the wildly profitable Apple didn't find it profitable to make the machine you want.
I blame Intel because they used the same pinout for 4-core laptop CPUs as for 2-core in every generation of laptop chip prior to Haswell, and I think in every generation after it as well (except possibly the Broadwell die shrink). Somebody at Intel apparently said, "Oh, it doesn't really matter because laptop boards are all one-offs anyway and nobody upgrades laptop CPUs", and then found out the hard way why they were wrong.
I blame Intel because they could very easily have made their chips pin-compatible for almost no difference in R&D or manufacturing cost, and distributed that tiny cost across hundreds of millions of units, whereas the cost of building and certifying a new motherboard design is huge, and cannot be easily distributed across the much smaller profit from a single model of computer.
Look, I'm the first person to give Apple a hard time when they screw up (just look at some of my rants over the years, and you'll see what I mean). And I do agree that they screwed up by not biting the bullet and building a four-core model anyway. That said, it would have been trivial for Intel to do it right, and it would have been several orders of magnitude more expensive per unit for Apple to work around their design screw-up. So I don't blame them for telling Intel, "Screw it. We'll pick up your four-core chips again in Kaby." I'm just hoping they get around to picking back up the four-core chips in Kaby Lake (or, ideally, they could make it a point for the next Mini to *not* be an entire generation behind for once, and wait to ship a four-core Mini with Coffee Lake, but I'm not holding my breath).
The Mac Mini had relatively low sales volume, mostly concentrated at the low end. Sure, they could have designed two different versions of the motherboard, but the additional sales would likely not have covered the extra R&D expense, much less the impact of pulling engineers off of other products (with orders of magnitude higher sales volume) to work on it.
Additionally, I suspect they hoped that the low-end versions of the trashcan Mac Pro would reduce the call for high-end Mini hardware. That has not happened, for a number of reasons (size, cost, and lack of storage being the big ones), but I think that was the working theory at the time.
Problem is, I'm still using my 2010 Mac mini here and looking at the 2014 Mac mini, which is still the latest Mac mini model by the way, the future scares me.
No, the last actual Mac Mini was Macmini6,2 (2012). The 2-core 2014 "Mini" was Apple Hardware Engineering's idea of a great practical joke.
(Thanks, Intel, for using a different pinout for your four-core Haswell chips, making it financially infeasible for Apple to build both a low-end Mini and a decent Mini with the same logic board design. I blame you for my servers being half a decade old and counting.)
Agreed with your title, your post is near complete bulllshit. Stop believing programmers are special. We're not and that elitist attitude is one reason we have such a poor reputation. Nursing requires a ton of memorizing, ability to manage highly distressed people, dealing with body fluids and wastes, etc... Almost anyone can learn to be an ok enough scripter with someone giving them the requirements and design. For the many people who pass out at the sight or blood or a needle stick, that's way harder to get over than learning programming abstractions.
You missed my core point, which is that we don't need more "ok enough scripters". We need more competent engineers. Scripters are to LPNs as software engineers are to NPs.
Again, I'm not saying that nursing doesn't take a lot of skill, nor am I even saying that there aren't people who aren't cut out for it. I'm saying that the numbers don't lie. Most people don't fail at becoming nurses. Most people do fail at becoming software engineers. So anybody claiming that the only difference between a software engineer and a random person chosen off the streets is training has a very serious credibility problem.
Memory, language, and focus are not primarily genetically determined.
You'll also notice that I didn't say those three were. I said they have a genetic component, a fact that is trivially proven.
The Renaissance happened because people had more free time.
The Renaissance had many causes. One of those causes was the introduction of the Gutenberg printing press, which expanded access to the written word. But even if we assume your reason was more important, the reason people had more free time was that the death of so many people caused a worker shortage, which meant that people made higher income from their work and could spend less time working, allowing them more time to be creative. This doesn't really apply when your work *is* creative.
At first, I assumed that the reason it took so long was that in every previous attempt, somebody got the idea of calling it the Australian Space Service, and the unamused among them decided it was better to scuttle the whole thing.
Then, I realised that they spell it with an 'r' over there.
Algonquin College in Ottawa Ontario. They farmed out a simple system of keeping track of tests and students to an east indian firm called 'blackboard'. It was a disastrous shit show that never ended.
I've used Blackboard. You're being unfair to actual s**t shows.
The same thing happened to nursing. Originally, the salaries were high enough to qualify as middle-class wage earners. But the government claimed there was going to be a nursing shortage. Dozens new nursing colleges opened everywhere. Then suddenly, there was an oversupply of nurses; salaries fell through the floor, the hospitals soaked up the savings.
Of course, there are two big differences here:
A larger percentage of the public are capable of being successful at nursing.
Having more nurses doesn't inherently result in more nursing jobs.
If you look at retention rates and graduation rates as a percentage of incoming freshmen, three times as many CS majors drop out or change majors within the first year, and only about half as many CS majors actually graduate with a CS degree. This is not because CS is hard. After all, nursing is hard and requires intellect. CS requires... something entirely different and much more rare.
Programmers have to be highly creative, but also highly logical. Lots of people are highly creative, but have a hard time wrapping their heads around the logical aspects of programming. Those folks might be decent managers or product designers, but will probably never be good software engineers. Others are highly logical, but are not very creative. That second group might pass as "code monkeys", but also will never be good software engineers.
And programmers also have to simultaneously be able to think abstractly and concretely. They have to be able to see something abstract and turn it into a concrete representation. And to make the big bucks, they also have to be able to go the other way—to see what the final concrete representation is supposed to look like and work their way back to an abstract underlying architecture that can support it, and then turn that into concrete representations for each part.
Programmers also need a larger than average working set memory, a stronger language center, and stronger ability to pay attention—often to the point of hyperfocus (getting "in the zone"). Although to some degree those skills can be improved with practice, they all have a genetic component as well.
Another area with essentially the same properties is music. (This may be why musicians are so over-represented in tech.) Unsurprisingly, in a 2008 study, researchers concluded that musical ability is about 50% genetic. Some people really are naturally predisposed to being good at it, and that predisposition results in getting good at it much more quickly and ending up being better at it than people without that predisposition, regardless of how much effort the latter group puts in.
Any CS teacher will tell you that the same is true for computer programming. There is a sizable subset of people who, no matter how much they might want to learn how to program, will try and try and will never wrap their heads around it, or at best, will do so at a pace that makes it a very poor career choice for them.
It would be great if we exposed more people to computer programming at a young age so that a greater percentage of the people who are innately predisposed to being good programmers will choose careers in that field. I'm not convinced that this will drive the cost of labor down, though. After all, a glut of good programmers will also result in a glut of new ideas that turn into new companies that hire more programmers.
The same thing happened in music beginning in the 14th century. We called it the Renaissance. There wasn't a cheapening of creativity; if anything, the reverse was true. Creativity bred demand for creativity. Similarly, that's what will likely happen if we convince people that there is a shortage of computer programmers. In fact, that's what has been happening for the last couple of decades, just in case folks didn't notice.
This is why suing Equifax into oblivion is not enough because then the company and shareholders, not the executives responsible for the lack of security, suffer. What is needed are criminal charges against those in charge of this fiasco. It sounds like there is already an investigation into insider trading but what is really needed is charges related to data protection but I don't know if US law allows for that like it does in the EU and Canada.
First, the shareholders should suffer. Equifax, like all of the credit bureaus, is a fundamentally flawed business model built upon the crazy notion that an identifier is somehow a way of proving your identity, rather than merely a fact about that identity. At their very core, these companies are the antithesis of security, and this has been obvious for decades. Yet they have done surprisingly little to shore up the gaping flaws in that business model.
The shareholders, knowing that credit fraud is a rapidly growing problem, chose to invest in a company whose business is built on the vain hope that credit fraud will remain a minor nuisance. They invested in it knowing that eventually it could come crashing down in a giant ball of flame. They chose to ride the stock up, hoping to ride a wave of excess credit and get out before the inevitable collapse.
This isn't the sort of company failure that deserves a bailout. It wasn't some bizarre fluke that was impossible to predict. Their entire business model breaks completely as soon as the majority of working Americans' SSNs become suddenly public, and the gradual loss of that secrecy has been glaringly obvious for a very, very long time. The only real question was whether one of the credit bureaus would be responsible for their downfall or some other group (e.g. the Social Security Administration). It was never a question of if; it was always a question of when.
To quote the movie Airplane, "Shanna, they bought their tickets. They knew what they were getting into. I say, let 'em crash." If you bail the stockholders out for investing in a company built on a fundamentally shoddy foundation, then you're just encouraging people to take unnecessary risks and buy stocks that they should know better than to buy. They played Russian roulette, and they lost. End of story. The only question left is how to dispose of the company's corpse.
As for the execs, though, criminal charges are not enough. We need to bring back public shaming in the court square. Stick them in the stockades and use a multi-trillion dollar fine against Equifax to pay for an endless supply of tomatoes so that anyone affected by the breach can exact their revenge. And live stream it worldwide so that these people can serve as an example to others about what happens when you amass vast quantities of personally identifying information without taking appropriate precautions to ensure that it remains safe.
Apple had both a generic ban against running anything that wasn't Objective-C and anything that could be used to run non appstore applications (scripting engines included) several years ago.
That's not entirely accurate. You could always run JavaScript with JavaScriptCore. What you could not do was use downloaded, interpreted code to significantly change the functionality of the app. For an app like a web browser, the website's content is not part of the app's functionality, so you could use JavaScriptCore. One could reasonably argue that if you could find a way to transpile games into JavaScript and run them in WebKit, you could even have something like a game emulator, though AFAIK that theory has never been tested.
Either way, the main purpose was to ensure that an app could be properly reviewed before making it available on the store. If an app changes its functionality dramatically after the fact, that makes a proper review impossible. And reviewing arbitrary interpreters isn't particularly practical, either.
The security reasoning is at best an excuse thought up after the fact.
That's not really true. The reason they don't allow it is because JavaScript engines typically use JIT compiling to create native binary code and run it at a decent speed. Unless you want the third-party engines to be as slow as UIWebView's JavaScript interpreter (which doesn't use JIT compiling), Apple would need to allow select third-party apps to run unsigned code, which does, in fact, significantly increase the potential for all sorts of exploits (including jailbreaks).
iOS allows unsigned code to run only within a special, highly privileged execution context. Initially, only Safari ran in such a context. Many years later, their out-of-process execution/IPC became fast enough and transparent enough to make WKWebView practical, at which point they were able to relax that restriction somewhat and allow third-party apps to run JavaScript code. It is possible that Apple could eventually be convinced to allow third-party browsers to do JIT compiling and run unsigned code in such a context (within an entirely separate sandbox with no filesystem access), but it will be a long, uphill battle.
The question is not whether there's a security benefit from that limitation, but rather whether the security damage caused by a JavaScript interpreter monoculture exceeds the security benefit from not having random interpreters with the ability to run arbitrary code.
The funny thing is that I've implemented crypto algorithms. I'm intimately familiar with what they can and can't do. The largest botnet to date was a couple of million devices. Within five years, we'll likely have at least one that crests the ten-million-device mark. Depending on the speed of those devices (and whether they have hardware-assisted crypto support), that could easily mean on the order of a trillion cracking attempts per second or more.
Assuming a passphrase contains only the 95 printable ASCII characters, an eight-character passphrase would take about 1.8 hours even without any sort of dictionary words. A ten-character random passphrase would take only about 1.9 years. Worse, that's for actual random line noise passwords, which are pretty unlikely in practice. If you assume that they probably picked a combination of dictionary words and l33t-ed versions of those words, cracking it becomes almost a trivial problem with a sufficiently large botnet unless the passphrase is truly enormous.
So again, why do you think a strong passphrase is adequate to protect a crypto key? I'm not saying it doesn't slow down an attacker, but a compromised crypto key—even one protected by a strong, highly random passphrase—should still be immediately revoked. To do otherwise would be reckless and irresponsible. The cost of a mistake is large, and the cost of a revocation is small.
Is there a corporation that forces people to run Safari?
Apple. On iOS, all browsers (even Chrome) are actually running Safari's rendering engine, with the exception of browsers that run all the JavaScript server-side. The reason for this is that Apple won't let apps run non-Apple JavaScript engines out of concerns about security. (The irony here is not lost on me.)
If by "not risky", you mean "able to survive local brute-forcing by a massive botnet", then you have more faith in passphrases—even good passphrases—than I do.
There shouldn't even be UI for such a risky action. If you need the private key, you should have to hunt for the file on the hard drive, double-click it, and open it in a text editor. Doing the right thing should be easy, and doing the wrong thing should be hard.
Slashdot Mirror
Plus a failure of their regular security auditing process to detect that a machine was running a version of software below the minimum allowed version. All this stuff should be detected programmatically in a company that size. This was not a failure of one person. This was a complete failure of the entire security organization at every level, which usually points to either a complete lack of leadership, inadequate budget to hire sufficient qualified staff, or (more likely) all of the above.
You could think of it as two-core CPU with a dedicated bus for maintaining cache coherency. If that bus stops working, you could still use the CPU, but you'd have to handle cache coherency externally by bus snooping or per-page reader-writer locks on main memory or some other scheme. :-)
I don't think anyone is suggesting that they should. I think what people are suggesting is that those sites should recognize whether something is a trending news story, recognize whether a given site has a history of publishing accurate information or spewing bulls**t, and rank the results/boost the posts accordingly.
On a related note, all the comments about censorship are way off the mark. Nobody is proposing making the 4chan trolls impossible to find. They're proposing ranking them lower than those likely-more-accurate mainstream news sources. You'd still be able to get to them by searching for appropriate terms or whatever, but an average person who wasn't looking for conspiracy theories wouldn't typically click through enough pages to stumble across them when searching for news about some world event.
Sadly, our current political leaders are no Winston Churchill.
And if the reports of their former security head being a music major are accurate, they were uniquely qualified to recognize when the contractors could not hum the right tune....
This sounds like standard MBA behavior. Being secure is expensive in the short term, which hurts short-term profits, which hurts the value of their options. Therefore, in their minds, it is better to factor in insecurity as a long-term risk and spend as little money as possible on it, knowing that when it crashes, they'll get new options priced at a lower price point anyway.
And this is why we have government regulations. Unbridled capitalism led by unscrupulous people would otherwise ruin us all.
If the company finds that they breached their fiduciary duty in some way, they can try to go after their ill-gotten gains in civil court.
Not quite. The repeaters in question had been in continuous operation for anywhere from 14 to 18 years. The FCC denied permission to continue operating these repeaters because they felt that there was no further benefit to experimenting with synchronous repeater technology, and that they were effectively just being used as commercial stations at this point, which requires a competitive bidding process.
The decision is, IMO, dubious, because they should have done this at least a decade sooner. De-licensing the repeaters after so many years of continuous repeater operation is tantamount to reducing the de-facto range of the main station, which represents the loss of a resource that the community had grown to depend on.
Really, this was a screw-up by the George W. Bush FCC, after which the Obama FCC said, "Screw it, we're not touching this mess", and subsequently, the Trump FCC said, "Let's poke a stick into this round, brown, paper-like object hanging under the eaves and see what happens."
It's telling that I wasn't the only person in the room who used the word "ugly" the instant I saw it. In a room full of about thirty software engineers, all of whom use Apple products on a daily basis. This is by far the most un-Apple-like product I've seen since Spindler.
But it is by no means the first sign of their design decline. Here's a short list of only the most questionable design decisions they've made in the past five-ish years:
To be fair, they made a bunch of questionable design decisions prior to that, like the glass back in the iPhone 4, the general unattractiveness of the cheese grater G5/Mac Pro design (though it was very functional, and I'd take it back in a second over what we have now), etc., but before approximately 2012, I saw one significant design screw-up every 2–3 years, and now I see two or three per year.
Things started going downhill before Forstall left, which pretty much points to SJ's "no" vote mattering a lot more than people realize.
First of all, do not leave your iPhone in direct sunlight. It'll kill it. Second, don't immerse it in water—not even to clean it. But the most important rule—the rule you can never forget—no matter how much it buzzes, no matter how red the charge indicator is, never charge it after midnight.
I blame Intel because they used the same pinout for 4-core laptop CPUs as for 2-core in every generation of laptop chip prior to Haswell, and I think in every generation after it as well (except possibly the Broadwell die shrink). Somebody at Intel apparently said, "Oh, it doesn't really matter because laptop boards are all one-offs anyway and nobody upgrades laptop CPUs", and then found out the hard way why they were wrong.
I blame Intel because they could very easily have made their chips pin-compatible for almost no difference in R&D or manufacturing cost, and distributed that tiny cost across hundreds of millions of units, whereas the cost of building and certifying a new motherboard design is huge, and cannot be easily distributed across the much smaller profit from a single model of computer.
Look, I'm the first person to give Apple a hard time when they screw up (just look at some of my rants over the years, and you'll see what I mean). And I do agree that they screwed up by not biting the bullet and building a four-core model anyway. That said, it would have been trivial for Intel to do it right, and it would have been several orders of magnitude more expensive per unit for Apple to work around their design screw-up. So I don't blame them for telling Intel, "Screw it. We'll pick up your four-core chips again in Kaby." I'm just hoping they get around to picking back up the four-core chips in Kaby Lake (or, ideally, they could make it a point for the next Mini to *not* be an entire generation behind for once, and wait to ship a four-core Mini with Coffee Lake, but I'm not holding my breath).
The Mac Mini had relatively low sales volume, mostly concentrated at the low end. Sure, they could have designed two different versions of the motherboard, but the additional sales would likely not have covered the extra R&D expense, much less the impact of pulling engineers off of other products (with orders of magnitude higher sales volume) to work on it.
Additionally, I suspect they hoped that the low-end versions of the trashcan Mac Pro would reduce the call for high-end Mini hardware. That has not happened, for a number of reasons (size, cost, and lack of storage being the big ones), but I think that was the working theory at the time.
No, the last actual Mac Mini was Macmini6,2 (2012). The 2-core 2014 "Mini" was Apple Hardware Engineering's idea of a great practical joke.
(Thanks, Intel, for using a different pinout for your four-core Haswell chips, making it financially infeasible for Apple to build both a low-end Mini and a decent Mini with the same logic board design. I blame you for my servers being half a decade old and counting.)
The first car to have wheels that have no tires?
Oh. A hovercar.
You missed my core point, which is that we don't need more "ok enough scripters". We need more competent engineers. Scripters are to LPNs as software engineers are to NPs.
Again, I'm not saying that nursing doesn't take a lot of skill, nor am I even saying that there aren't people who aren't cut out for it. I'm saying that the numbers don't lie. Most people don't fail at becoming nurses. Most people do fail at becoming software engineers. So anybody claiming that the only difference between a software engineer and a random person chosen off the streets is training has a very serious credibility problem.
You'll also notice that I didn't say those three were. I said they have a genetic component, a fact that is trivially proven.
The Renaissance had many causes. One of those causes was the introduction of the Gutenberg printing press, which expanded access to the written word. But even if we assume your reason was more important, the reason people had more free time was that the death of so many people caused a worker shortage, which meant that people made higher income from their work and could spend less time working, allowing them more time to be creative. This doesn't really apply when your work *is* creative.
At first, I assumed that the reason it took so long was that in every previous attempt, somebody got the idea of calling it the Australian Space Service, and the unamused among them decided it was better to scuttle the whole thing.
Then, I realised that they spell it with an 'r' over there.
Algonquin College in Ottawa Ontario. They farmed out a simple system of keeping track of tests and students to an east indian firm called 'blackboard'. It was a disastrous shit show that never ended.
I've used Blackboard. You're being unfair to actual s**t shows.
Of course, there are two big differences here:
If you look at retention rates and graduation rates as a percentage of incoming freshmen, three times as many CS majors drop out or change majors within the first year, and only about half as many CS majors actually graduate with a CS degree. This is not because CS is hard. After all, nursing is hard and requires intellect. CS requires... something entirely different and much more rare.
Programmers have to be highly creative, but also highly logical. Lots of people are highly creative, but have a hard time wrapping their heads around the logical aspects of programming. Those folks might be decent managers or product designers, but will probably never be good software engineers. Others are highly logical, but are not very creative. That second group might pass as "code monkeys", but also will never be good software engineers.
And programmers also have to simultaneously be able to think abstractly and concretely. They have to be able to see something abstract and turn it into a concrete representation. And to make the big bucks, they also have to be able to go the other way—to see what the final concrete representation is supposed to look like and work their way back to an abstract underlying architecture that can support it, and then turn that into concrete representations for each part.
Programmers also need a larger than average working set memory, a stronger language center, and stronger ability to pay attention—often to the point of hyperfocus (getting "in the zone"). Although to some degree those skills can be improved with practice, they all have a genetic component as well.
Another area with essentially the same properties is music. (This may be why musicians are so over-represented in tech.) Unsurprisingly, in a 2008 study, researchers concluded that musical ability is about 50% genetic. Some people really are naturally predisposed to being good at it, and that predisposition results in getting good at it much more quickly and ending up being better at it than people without that predisposition, regardless of how much effort the latter group puts in.
Any CS teacher will tell you that the same is true for computer programming. There is a sizable subset of people who, no matter how much they might want to learn how to program, will try and try and will never wrap their heads around it, or at best, will do so at a pace that makes it a very poor career choice for them.
It would be great if we exposed more people to computer programming at a young age so that a greater percentage of the people who are innately predisposed to being good programmers will choose careers in that field. I'm not convinced that this will drive the cost of labor down, though. After all, a glut of good programmers will also result in a glut of new ideas that turn into new companies that hire more programmers.
The same thing happened in music beginning in the 14th century. We called it the Renaissance. There wasn't a cheapening of creativity; if anything, the reverse was true. Creativity bred demand for creativity. Similarly, that's what will likely happen if we convince people that there is a shortage of computer programmers. In fact, that's what has been happening for the last couple of decades, just in case folks didn't notice.
First, the shareholders should suffer. Equifax, like all of the credit bureaus, is a fundamentally flawed business model built upon the crazy notion that an identifier is somehow a way of proving your identity, rather than merely a fact about that identity. At their very core, these companies are the antithesis of security, and this has been obvious for decades. Yet they have done surprisingly little to shore up the gaping flaws in that business model.
The shareholders, knowing that credit fraud is a rapidly growing problem, chose to invest in a company whose business is built on the vain hope that credit fraud will remain a minor nuisance. They invested in it knowing that eventually it could come crashing down in a giant ball of flame. They chose to ride the stock up, hoping to ride a wave of excess credit and get out before the inevitable collapse.
This isn't the sort of company failure that deserves a bailout. It wasn't some bizarre fluke that was impossible to predict. Their entire business model breaks completely as soon as the majority of working Americans' SSNs become suddenly public, and the gradual loss of that secrecy has been glaringly obvious for a very, very long time. The only real question was whether one of the credit bureaus would be responsible for their downfall or some other group (e.g. the Social Security Administration). It was never a question of if; it was always a question of when.
To quote the movie Airplane, "Shanna, they bought their tickets. They knew what they were getting into. I say, let 'em crash." If you bail the stockholders out for investing in a company built on a fundamentally shoddy foundation, then you're just encouraging people to take unnecessary risks and buy stocks that they should know better than to buy. They played Russian roulette, and they lost. End of story. The only question left is how to dispose of the company's corpse.
As for the execs, though, criminal charges are not enough. We need to bring back public shaming in the court square. Stick them in the stockades and use a multi-trillion dollar fine against Equifax to pay for an endless supply of tomatoes so that anyone affected by the breach can exact their revenge. And live stream it worldwide so that these people can serve as an example to others about what happens when you amass vast quantities of personally identifying information without taking appropriate precautions to ensure that it remains safe.
All the oceans are connected together, so arguably if you're crossing the Atlantic, you're also crossing the Pacific. :-D
That's not entirely accurate. You could always run JavaScript with JavaScriptCore. What you could not do was use downloaded, interpreted code to significantly change the functionality of the app. For an app like a web browser, the website's content is not part of the app's functionality, so you could use JavaScriptCore. One could reasonably argue that if you could find a way to transpile games into JavaScript and run them in WebKit, you could even have something like a game emulator, though AFAIK that theory has never been tested.
Either way, the main purpose was to ensure that an app could be properly reviewed before making it available on the store. If an app changes its functionality dramatically after the fact, that makes a proper review impossible. And reviewing arbitrary interpreters isn't particularly practical, either.
That's not really true. The reason they don't allow it is because JavaScript engines typically use JIT compiling to create native binary code and run it at a decent speed. Unless you want the third-party engines to be as slow as UIWebView's JavaScript interpreter (which doesn't use JIT compiling), Apple would need to allow select third-party apps to run unsigned code, which does, in fact, significantly increase the potential for all sorts of exploits (including jailbreaks).
iOS allows unsigned code to run only within a special, highly privileged execution context. Initially, only Safari ran in such a context. Many years later, their out-of-process execution/IPC became fast enough and transparent enough to make WKWebView practical, at which point they were able to relax that restriction somewhat and allow third-party apps to run JavaScript code. It is possible that Apple could eventually be convinced to allow third-party browsers to do JIT compiling and run unsigned code in such a context (within an entirely separate sandbox with no filesystem access), but it will be a long, uphill battle.
The question is not whether there's a security benefit from that limitation, but rather whether the security damage caused by a JavaScript interpreter monoculture exceeds the security benefit from not having random interpreters with the ability to run arbitrary code.
The funny thing is that I've implemented crypto algorithms. I'm intimately familiar with what they can and can't do. The largest botnet to date was a couple of million devices. Within five years, we'll likely have at least one that crests the ten-million-device mark. Depending on the speed of those devices (and whether they have hardware-assisted crypto support), that could easily mean on the order of a trillion cracking attempts per second or more.
Assuming a passphrase contains only the 95 printable ASCII characters, an eight-character passphrase would take about 1.8 hours even without any sort of dictionary words. A ten-character random passphrase would take only about 1.9 years. Worse, that's for actual random line noise passwords, which are pretty unlikely in practice. If you assume that they probably picked a combination of dictionary words and l33t-ed versions of those words, cracking it becomes almost a trivial problem with a sufficiently large botnet unless the passphrase is truly enormous.
So again, why do you think a strong passphrase is adequate to protect a crypto key? I'm not saying it doesn't slow down an attacker, but a compromised crypto key—even one protected by a strong, highly random passphrase—should still be immediately revoked. To do otherwise would be reckless and irresponsible. The cost of a mistake is large, and the cost of a revocation is small.
Apple. On iOS, all browsers (even Chrome) are actually running Safari's rendering engine, with the exception of browsers that run all the JavaScript server-side. The reason for this is that Apple won't let apps run non-Apple JavaScript engines out of concerns about security. (The irony here is not lost on me.)
If by "not risky", you mean "able to survive local brute-forcing by a massive botnet", then you have more faith in passphrases—even good passphrases—than I do.
There shouldn't even be UI for such a risky action. If you need the private key, you should have to hunt for the file on the hard drive, double-click it, and open it in a text editor. Doing the right thing should be easy, and doing the wrong thing should be hard.
It's a tradeoff of durability versus readability. The screen that burns twice as bright burns half as long. (With apologies to Lao Tzu.)