Exactly. Today, you can't "really" do a cross country trip unless you are extremely careful about where you go, where you stop, and do your research on charging stations, hours of operation, hotels nearby, etc. They need to continue building up to the point where the average person can just say, "roadtrip" and go. That will take time, and probably means easily swappable batteries at locations (similar to how in the US they have swappable propane tanks at stores and you just switch yours out with a full one for a fee. Those locations would need some serious grid power so they can charge the empties. Until they have that, this whole "charging" thing is going to continue to be a problem. Having stunts like this try to convince people that it is viable isn't really all that productive when anyone can see it isn't viable for most people - yet.
Why do you "need" swappable batteries to do what the Tesla did without swappable batteries? 20 minute charge time sounds reasonable for the rare long distance trip, (especially if charge stations are available at restaurants and hotels so you can charge while you sleep or eat) but their goal is to drop the charge time to 5-10 minutes, which should eliminate the need to swap out batteries -- which sounds like a logistical nightmare if battery swap stations have to stock a dozen or more expensive batteries to cover all of the cars on the road, and the station might be out of your battery type when you go in for a swap.
A gasoline tanker could drive itself across the country easily if the fuel hose attached to its own tank. Lifting yourself out of the Earth's gravity well has always been 95% of the battle. Every pound in extra weight requires multiple pounds of fuel.
What makes this a gimmick just because other conventionally fueled vehicles may be able to make the trip without refueling? Those vehicles are not electric.
And what does earth's gravity well have anything to do with it? The Tesla drove coast-to-coast, it didn't launch itself into orbit.
You needn't use a gasoline tanker if you just want a vehicle that can do the trip without refueling -- a 48mpg Prius could do it with an extra fuel tank -- it would take around 60 gallons (375 lbs) of extra fuel (in addition to the the 12 gallon fuel tank).
Surely people should also understand how to repair the cars they drive every day. It's not that hard, they just need to learn how to use basic hand tools and diagnostic tools, and then everything is is a simple step by step process. Sure there are tip and techniques that mechanics develop over time as they have more experience, but hey, anyone fresh out of a 12 week "Become an auto mechanic" boot camp can rebuild an engine.
And for that matter, everyone should become a plumber, electrician, HVAC engineer, etc. If you don't know how to build and repair the technology you use every day, how can you hope to survive?
I know, there once was a time when some basic mechanical knowledge was needed, but nowadays one can expect to go years (or decades) without ever opening the hood of their car -- my wife hasn't looked under the hood to her car, ever, after 10+ years of car ownership -- she used to take it in for oil changes every 5000 miles, but her new car tells her when it needs an oil change (every 10,000 miles) -- so just like computers, people can treat them as a "black box" without knowing anything about how to build or repair them.
No one's going to have paper maps in their cars, and navigation systems may just say "Sorry, I can't find your location" if they try to pull up a map.
Remember: GPS is not functional when driving through parking garages or tunnels. How are you going to navigate Le tunnel sous la Manche; if your driverless car cannot tolerate GPS unavailability?
I believe the driverless cars are going to have to put through heavy scrutiny for safety, before they become available to consumers. INCLUDING options for safe operation -- and backup options for the human to navigate their vehicle, in case GPS is unavailable.
Short distance navigation is easy through simple inertial sensors, or distance sensing, but navigating 15 miles from work to the office may not be possible if the designers decided that there's no reason to read road signs or other pattern mapping to match the real world with maps. GPS is reliable and ubiquitous, so why spend money developing a backup for something that will never fail.
Inertial navigation for cars, on road network? Overengineer much? Theres this invention called a map out there. Turn left you are now on this street, turn right you are now here. Not exactly rocket science. For driving cars, GPS is a convenience, life will not stopp if you dont have it.
For people driving cars GPS is just a convenience, but what about self-driving cars?
And how often do GPS outages happen? There is also GLONASS and a few others out there. If they are all out it means you are in a war zone, being jammed, and your maps not working is probably least of your problems.
That's my point -- GPS is so reliable that there's no need to spend money on a backup system, aside from something to take you a block or two in the city when you lose sight of the satellites. So if the GPS network does go down, then cars won't be able to navigate, and the people in those cars won't have been paying attention to where their cars take them for years, so they won't be able to navigate either. No one's going to have paper maps in their cars, and navigation systems may just say "Sorry, I can't find your location" if they try to pull up a map.
When driverless cars are commonplace, a GPS outage will leave millions of drivers stranded away from home because they will no longer know how to get home on their own
Wait.... GPS outage? If humans can find their way around without GPS; I see no reason a driverless car shouldn't be able to.
That's the problem - people are becoming reliant on GPS and can't find their way around without GPS. One of my coworkers has lived here for almost a year and can't find his way to a restaurant 3 miles away (that he's been to a dozen times) without GPS.
Hell... they can have a huge map database in the car.
All the car needs to do is use its last known position plus data from sensors and dead-reckoning based navigation to identify its current position.
Most Inertial sensors are only good for a short time before they become too inaccurate to use. Manufacturers could have the car use pattern mapping to match its surroundings with onboard maps, but when GPS available "all the time", why bother implementing something that will rarely be used.
Certainly, the driverless car would be unsafe, if it relied on continuous perfect GPS reception to work.
There are many places --- such as inside parking garages, or on roads in deep forested areas: where a usable GPS signal cannot be received. Plenty of times in urban areas; it's ordinary for GPS signals to be interfered with so much so that GPS devices give up and say satellite connection lost.
I've never driven on a road where my standalone GPS couldn't get a signal -- even within cities and driving in forested areas. I've had it take a while to get a lock in cities, but once the GPS gets a lock, it's always been able to maintain it.
Sure there is... how else would you propose we signal, when the car just in front of us is driving at 10 miles per hour on a 30 mph road, when a pedestrian is taking too long to finish their crossing, a car in front of us is slowing down or taking too long to complete their right turn, or the car in front of us is stopped and signalling left in the middle of the road, spending forever at the stop sign, failing to take a right turn on red, stopping at a yellow light, failing to accelerate immediately after the light turned green, etc, etc.
In your driverless car, you won't even notice, you'll be too busy playing Angry Birds to see your surroundings.
When driverless cars are commonplace, a GPS outage will leave millions of drivers stranded away from home because they will no longer know how to get home on their own, not even if they are within walking distance. GPS is bad enough, but at least they generally know which roads they take, but when driverless cars are the norm, drivers won't pay attention at all to where they are going.
There will be people diving in front of driverless cars attempting to empty the deep pockets of the manufacturers.
People already dive in front of regular cars, just try driving around any major city. People care more about answering that text message than they do about looking for traffic.
The driverless car will likely have stored video to show what really happened.
Human train engineers make mistakes all the time. Just recently we've had two "going around the corner too fast" fatal incidents. Those are two accidents that would not have happened with a robot at the wheel. Now, you might be correct and the robots might be less able to react to "random" events - but then how rare are random events compared with engineers dozing off, spacing out, or showing up impaired? In any case, most systems still stick a guy up there, even if he doesn't drive the train under normal circumstances... so that probably covers both cases. So sure, you still pay a driver, but you gain safety and you gain the ability to run trains closer together.. capacity.
I don't understand why we don't have driverless trains (aside from a few airport trains) today. It seems like such a simple problem - no need to steer (aside from negotiating track switches), well defined stop/go/speed signals that could easily be followed by an automated engineer, and far superior vision to detect obstacles on the tracks. Is there some other skill needed that only a human can provide?
Would anyone hire any of these graduates for a software engineering position? I don't think I would unless they had some real world work experience to back it up. It sounds like these short programs are producing coders, not engineers. There's a big difference between the two.
Companies are replacing many software engineers with low-paid outsourced "coders" with similar credentials to what these people will end up with. I suppose that in theory, the people coming out of these programs would be qualified to compete for those jobs.
But when they outsource to these low-paid coders, companies don't have to manage them directly -- the outsourcing company has project managers and more senior developers to do that. They don't need to use their high-paid engineer's time to manage unskilled coders.
If you're charging someone $15000 for a 10 week course
My spouse's employer recently paid that amount for a 2 day SAP course, and I'm pretty sure CA regulators are not going after the company providing the SAP course.
promising jobs at companies "like Facebook and Google,"
I do not see a promise or guarantee of employment anywhere in the article or in a brief search of their websites.
SAP courses tend to be B2B, which is entirely different than consumer oriented courses.
These bootcamps do make some claims that deserve greater scrutiny:
"12-weeks + From beginner to software engineer + San Francisco, CA"
"That said, the skills you pick up here are valuable around the world. Graduates walk out the door with an increasingly impressive array of project work that would impress employers in any country."
"Twelve weeks later, you’ll follow the footsteps of our trailblazing alumni, taking the methodologies and best practices you perfected at our coding bootcamp to your next job"
Would anyone hire any of these graduates for a software engineering position? I don't think I would unless they had some real world work experience to back it up. It sounds like these short programs are producing coders, not engineers. There's a big difference between the two.
If an attacker used software to make 10,000 attempts to decrypt a credit card number, for example, they would get back 10,000 different fake credit card numbers. “Each decryption is going to look plausible,”
This isn't done already???? I thought this was done all along with passwords and other short strings. I could see it being more difficult when the data is human generated passwords due to the bias in selecting words>syllables>numbers>punctuation, but still.
No, it's not normally done today. Generally if you try to decrypt a file using the wrong decryption key you'll either get random looking data, or no data at all.
Returning random data is not the same as returning a plausible (but incorrect) password since random data will include all sorts of non-printable characters that few users would include in a password. LIkewise, credit card numbers follow a set pattern with known prefixes and a checksum so an attacker could quickly weed out invalid numbers.
Help me understand this. If the 'wrong' results are truly random data that happens to look correct (as decrypting with the wrong key should be), then how does a match imply that a chosen password was weak? If the data is random isn't it equally as likely that any string would come up as a possible password? Why would a 'weak' password be more likely to come up than a 'strong' password?
Also, what would be the problem if the random password does match some elses? If your password is 'xyz', and I try password 'xyz' on my userid, it doesn't magically give me access to your account.
I think you'll have to go back to the post before me, he's the one that said:
Would have to be careful that the 'bad' results do not do things like open the lock though. For instant in the case of login list breaches.
Statistically speaking, if a randomly (or pseudorandomly) computed string matches someone else's password, then his password was not safe in the first place. A weak password is more likely to come up by an algorithm that's generating "plausible" passwords than a strong one, because a weak password is weak because it's easy to guess. That could be because it has a small keyspace (i.e. a 4 digit PIN only has 10,000 possible choices, so any random guess has a 1 in 10000 chance of being right), or because it suffers some other weakness than can be exploited (i.e. if the PIN is known to be a MMDD date, then there are only 366 possible choices).
That's what makes a password weak - it's easy to guess.
cryptanalysis can break your encryption even without access to your encryption algorithm
I doubt it. That may have been true back when people used substitution ciphers and encrypted plain text. Today's ciphers scramble large blocks and precompress to increase data entropy. I seriously doubt anybody but a top-notch cryptoanalyst can decrypt even the simplest attempt at a cipher from anybody who knows anything at all about cipher design.
Such a cryptoanalyst is likely to be found only at some high level government agency like the NSA and he will likely be too busy to spare any time to decrypt your inane emails to your mistress. Consequently, I would postulate that if you design your own cipher and avoid becoming the next Snowden, your data will be just as safe as if you had used AES.
Which is how we end up with things like the weak Zip File and early MS-Office encryption. Companies think they can roll their own, or take shortcuts and end up with weak security.
Published algorithms have withstood scrutiny by actual experts, don't assume that your home-grown super-secret encryption will stand up to scrutiny - it may leave patterns in the data that can be exploited to decypt it
So you decrypt something and it *looks* like real data.
So it would have to be a function that produces 'good' results and 'bad results' but the bad results look like good ones.
Would have to be careful that the 'bad' results do not do things like open the lock though. For instant in the case of login list breaches.
If randomly generated "fake" data matches someone else's password (or whatever is being encrypted), that other person didn't use a strong enough password. This system is just acting like a hash function -- criminal tries password A and he decrypts the data to some string, then he tries password B and the data gets decrypted to another string. If those randomly generated strings happen to match someone elses password on the system, the criminal could have saved himself some time by generating the password guesses himself.
What's the goal here - to make the returned data "not my data", or "incorrect data"? There is a world of difference between these two. "Not my data" is a simple thing to generate, but could still be correct data. IE, if the data protected is a card number, and the generated number matches someone else's card, then do we care or not? The criminal doesn't care, as long as their goal is met (get a valid card - it doesn't have to be yours). If we're talking about "invalid" data, then we need some mechanism to validate the generated data before it's returned. While this wouldn't meet the criminal's goal, it could open a possible DDOS attack vector on the validation service (ie, a brute force becomes a magnified reflection attack).
They aren't going to store a big database of valid credit card numbers so they can return someone else's card number, they'll just generate a random number that looks like it could be a real credit card number and passes the checksum test.
Yes, a criminal could take the credit card numbers from each decryption attempt and test them, but if he's willing to test millions of card numbers to look for a valid one, he could just generate the card numbers directly and not attempt the decryption in the first place.
People misunderstand what "security through obscurity" means. Most (all?) encryption relies on security through obscurity at some level.
Hiding your house key under a loose floorboard in your back deck is the kind of security through obscurity that can really work, assuming that there are no other clues that lead to the hiding place. However, hiding the prybar that you use to pry up the floorboard under the belief that hiding the method of access makes your key safer is not the kind of obscurity that works because if the attacker can find your hiding place, he can figure another way to get to the key.
Similarly, hiding or not writing down your password is security through obscurity that works. But trying to hide the implementation details of your cipher algorithm does not, because cryptoanalysis can break your encryption even without access to your encryption algorithm.
So, obscuring your real password among an endless number of fake passwords is the kind of obscurity that can work -- even if the attacker knows that your password is somewhere among the billions of fake ones, unless he has some clue to tell him what your real password looks like, just knowing that fakes are there doesn't help him.
TFA was murky, but generating bogus data? If one is brute forcing a data blob, how can it make stuff up? Authentication is another story.
It didn't seem all that murky:
. But he notes that not every type of data will be easy to protect this way since it’s not always possible to know the encrypted data in enough detail to produce believable fakes. “Not all authentication or encryption systems yield themselves to being ‘honeyed.’”
So it only works with data where it can generate believable fake data -- like credit card numbers or passwords.
So you decrypt something and it *looks* like real data.
So it would have to be a function that produces 'good' results and 'bad results' but the bad results look like good ones.
Would have to be careful that the 'bad' results do not do things like open the lock though. For instant in the case of login list breaches.
If randomly generated "fake" data matches someone else's password (or whatever is being encrypted), that other person didn't use a strong enough password. This system is just acting like a hash function -- criminal tries password A and he decrypts the data to some string, then he tries password B and the data gets decrypted to another string. If those randomly generated strings happen to match someone elses password on the system, the criminal could have saved himself some time by generating the password guesses himself.
So what is average/worst case access time for that tape cabinet? For BD, I don't know at all, but I guess for BD it is some tens of secs including disk change and spin-up. Perhaps much less with hardware optimized for this.
If that data needs to be accessed from web, then I think some tens of seconds maximum acceptable.
As I said, random access might be faster with Blu-ray, but they don't seem to be interested in random access:
It designed the system to store data that hardly ever needs to be accessed, or for so-called 'cold storage' (think duplicates of users' photos and videos that it keeps for backup)
With only 16 bluray drives in the system, it wouldn't stand up to much concurrent access from the web anyway.
I'm going into tinfoil hat territory, but I wonder if there is some advance in BD storage that FB is assuming, but the average person does not know about. If BDXL disks drop from $45.00 per disk to $1 a disk or even $2 a disk, that would change the game. Similarly, Sony/Panasonic's Blu-Ray successor that stores 300GB per disk would also be a big thing, should each disk be priced at a reasonable amount.
LTO technology keeps advancing too - LTO-7 will store 6.4TB natively on a tape.
NONE of those solutions, including the current one, have been tested for longevity.
I went a year between my honeymoon and getting pictures off of my 1st gen digital camera, stored in flash memory. About half were corrupt.
Their current solution (spinning disks) has been tested for longevity -- as long as they keep replacing failed disks (and migrating data to new storage arrays as technology obsoletes the old ones), data on spinning disks can be kept alive for as long as they can pay for it.
LTO-6 holds 2.5TB/tape (native, not compressed), so it's more space dense than Blu-ray since a single tape can replace fifty 50GB bluray disks. A 1 petabyte cabinet would only need 400 tapes, and LTO tape libraries of that size are readily available off the shelf - plus the software to manage it is also off the shelf.
Cost-wise, the tapes and disks are around the same, branded dual-layer blurays seem to cost $1 - $2, and LTO-6 tapes are around $60.
The only advantage I can see for blu-rays is in random access performance, but for a rarely used cold archive system, you'd think that wouldn't matter.
If there were a legitimate and reasonably priced download service
Bullshit. As various people and groups have shown, they have provided very easy methods to get their work at extremely cheap prices and people still go out and steal the work.
You can use iTunes if you want. 99 cents for a song and people still complain. Or, if you prefer, RadioHead said they will allow people to download their song (album?) but would appreciate a "donation" for the song. The amount of money they received didn't even cover the cost of the electricity.
People can use semantics or whatever excuse they choose to explain why they're stealing someone's work without compensating that person, but in the end, they're just that, an excuse. The more you continue to steal someone's work, the more justification you give to them to make it more restrictive.
Perhaps $.99 per song is not a "reasonable price" to someone that many have thousands of songs on their device.
Radiohead must pay more for electricity than most bands if $6M doesn't cover their electricity cost:
The donation-based model is effective for established bands because they already have a mass following and there will always be a fan who would be willing to pay for their music. The question is what would one pay for an album that they want if given a chance to get it for free. There lies the answer to what an album should be sold for. Traditionally it has been sold for $9.99 as a paid download or $14.99 at a retail store. The Radiohead and Nine Inch Nails fans who opted to pay on average were willing to give about $4 to download the album. That is a far cry from the traditional pricing model which dictates that an album is priced between $9.99 and $14.99. Record labels watch out because this is an indication that the pricing on albums is not in unison with market demand and what a music fan perceives as the true value of an album.
According to the NIN band, 800,000 transactions generated $1.6 million in sales revenue in the first week of the "Ghosts I-IV" album's availability, despite the fact that the 36-song version of the album is widely available on torrent sites and file sharing P2P networks. Radiohead's "In Rainbows" generated approximately $6 million in revenues which went directly to the band, with 1,200,000 downloads.
Slashdot Mirror
Exactly. Today, you can't "really" do a cross country trip unless you are extremely careful about where you go, where you stop, and do your research on charging stations, hours of operation, hotels nearby, etc. They need to continue building up to the point where the average person can just say, "roadtrip" and go. That will take time, and probably means easily swappable batteries at locations (similar to how in the US they have swappable propane tanks at stores and you just switch yours out with a full one for a fee. Those locations would need some serious grid power so they can charge the empties. Until they have that, this whole "charging" thing is going to continue to be a problem. Having stunts like this try to convince people that it is viable isn't really all that productive when anyone can see it isn't viable for most people - yet.
Why do you "need" swappable batteries to do what the Tesla did without swappable batteries? 20 minute charge time sounds reasonable for the rare long distance trip, (especially if charge stations are available at restaurants and hotels so you can charge while you sleep or eat) but their goal is to drop the charge time to 5-10 minutes, which should eliminate the need to swap out batteries -- which sounds like a logistical nightmare if battery swap stations have to stock a dozen or more expensive batteries to cover all of the cars on the road, and the station might be out of your battery type when you go in for a swap.
A gasoline tanker could drive itself across the country easily if the fuel hose attached to its own tank. Lifting yourself out of the Earth's gravity well has always been 95% of the battle. Every pound in extra weight requires multiple pounds of fuel.
What makes this a gimmick just because other conventionally fueled vehicles may be able to make the trip without refueling? Those vehicles are not electric.
And what does earth's gravity well have anything to do with it? The Tesla drove coast-to-coast, it didn't launch itself into orbit.
You needn't use a gasoline tanker if you just want a vehicle that can do the trip without refueling -- a 48mpg Prius could do it with an extra fuel tank -- it would take around 60 gallons (375 lbs) of extra fuel (in addition to the the 12 gallon fuel tank).
You do know that 25 KM is not a long distance, it's only 17 miles if you're not competent with metric measurements.
And only 15.5 miles if you are competent with Metric to English conversions.
Surely people should also understand how to repair the cars they drive every day. It's not that hard, they just need to learn how to use basic hand tools and diagnostic tools, and then everything is is a simple step by step process. Sure there are tip and techniques that mechanics develop over time as they have more experience, but hey, anyone fresh out of a 12 week "Become an auto mechanic" boot camp can rebuild an engine.
And for that matter, everyone should become a plumber, electrician, HVAC engineer, etc. If you don't know how to build and repair the technology you use every day, how can you hope to survive?
I know, there once was a time when some basic mechanical knowledge was needed, but nowadays one can expect to go years (or decades) without ever opening the hood of their car -- my wife hasn't looked under the hood to her car, ever, after 10+ years of car ownership -- she used to take it in for oil changes every 5000 miles, but her new car tells her when it needs an oil change (every 10,000 miles) -- so just like computers, people can treat them as a "black box" without knowing anything about how to build or repair them.
No one's going to have paper maps in their cars, and navigation systems may just say "Sorry, I can't find your location" if they try to pull up a map.
Remember: GPS is not functional when driving through parking garages or tunnels.
How are you going to navigate Le tunnel sous la Manche; if your driverless car
cannot tolerate GPS unavailability?
I believe the driverless cars are going to have to put through heavy scrutiny
for safety, before they become available to consumers.
INCLUDING options for safe operation -- and backup options for the human to navigate their vehicle,
in case GPS is unavailable.
Short distance navigation is easy through simple inertial sensors, or distance sensing, but navigating 15 miles from work to the office may not be possible if the designers decided that there's no reason to read road signs or other pattern mapping to match the real world with maps. GPS is reliable and ubiquitous, so why spend money developing a backup for something that will never fail.
Inertial navigation for cars, on road network? Overengineer much? Theres this invention called a map out there. Turn left you are now on this street, turn right you are now here. Not exactly rocket science. For driving cars, GPS is a convenience, life will not stopp if you dont have it.
For people driving cars GPS is just a convenience, but what about self-driving cars?
And how often do GPS outages happen? There is also GLONASS and a few others out there. If they are all out it means you are in a war zone, being jammed, and your maps not working is probably least of your problems.
That's my point -- GPS is so reliable that there's no need to spend money on a backup system, aside from something to take you a block or two in the city when you lose sight of the satellites. So if the GPS network does go down, then cars won't be able to navigate, and the people in those cars won't have been paying attention to where their cars take them for years, so they won't be able to navigate either. No one's going to have paper maps in their cars, and navigation systems may just say "Sorry, I can't find your location" if they try to pull up a map.
When driverless cars are commonplace, a GPS outage will leave millions of drivers stranded away from home because they will no longer know how to get home on their own
Wait.... GPS outage? If humans can find their way around without GPS; I see no reason a driverless car shouldn't be able to.
That's the problem - people are becoming reliant on GPS and can't find their way around without GPS. One of my coworkers has lived here for almost a year and can't find his way to a restaurant 3 miles away (that he's been to a dozen times) without GPS.
Hell... they can have a huge map database in the car.
All the car needs to do is use its last known position plus data from sensors and dead-reckoning based navigation to identify its current position.
Most Inertial sensors are only good for a short time before they become too inaccurate to use. Manufacturers could have the car use pattern mapping to match its surroundings with onboard maps, but when GPS available "all the time", why bother implementing something that will rarely be used.
Certainly, the driverless car would be unsafe, if it relied on continuous perfect GPS reception to work.
There are many places --- such as inside parking garages, or on roads in deep forested areas: where a usable GPS signal cannot be received. Plenty of times in urban areas; it's ordinary for GPS signals to be interfered with so much so that GPS devices give up and say satellite connection lost.
I've never driven on a road where my standalone GPS couldn't get a signal -- even within cities and driving in forested areas. I've had it take a while to get a lock in cities, but once the GPS gets a lock, it's always been able to maintain it.
Sure there is... how else would you propose we signal, when the car just in front of us is driving at 10 miles per hour on a 30 mph road, when a pedestrian is taking too long to finish their crossing, a car in front of us is slowing down or taking too long to complete their right turn, or the car in front of us is stopped and signalling left in the middle of the road, spending forever at the stop sign, failing to take a right turn on red, stopping at a yellow light, failing to accelerate immediately after the light turned green, etc, etc.
In your driverless car, you won't even notice, you'll be too busy playing Angry Birds to see your surroundings.
When driverless cars are commonplace, a GPS outage will leave millions of drivers stranded away from home because they will no longer know how to get home on their own, not even if they are within walking distance. GPS is bad enough, but at least they generally know which roads they take, but when driverless cars are the norm, drivers won't pay attention at all to where they are going.
There will be people diving in front of driverless cars attempting to empty the deep pockets of the manufacturers.
People already dive in front of regular cars, just try driving around any major city. People care more about answering that text message than they do about looking for traffic.
The driverless car will likely have stored video to show what really happened.
Human train engineers make mistakes all the time. Just recently we've had two "going around the corner too fast" fatal incidents. Those are two accidents that would not have happened with a robot at the wheel. Now, you might be correct and the robots might be less able to react to "random" events - but then how rare are random events compared with engineers dozing off, spacing out, or showing up impaired? In any case, most systems still stick a guy up there, even if he doesn't drive the train under normal circumstances... so that probably covers both cases. So sure, you still pay a driver, but you gain safety and you gain the ability to run trains closer together.. capacity.
I don't understand why we don't have driverless trains (aside from a few airport trains) today. It seems like such a simple problem - no need to steer (aside from negotiating track switches), well defined stop/go/speed signals that could easily be followed by an automated engineer, and far superior vision to detect obstacles on the tracks. Is there some other skill needed that only a human can provide?
Would anyone hire any of these graduates for a software engineering position? I don't think I would unless they had some real world work experience to back it up. It sounds like these short programs are producing coders, not engineers. There's a big difference between the two.
Companies are replacing many software engineers with low-paid outsourced "coders" with similar credentials to what these people will end up with. I suppose that in theory, the people coming out of these programs would be qualified to compete for those jobs.
But when they outsource to these low-paid coders, companies don't have to manage them directly -- the outsourcing company has project managers and more senior developers to do that. They don't need to use their high-paid engineer's time to manage unskilled coders.
If you're charging someone $15000 for a 10 week course
My spouse's employer recently paid that amount for a 2 day SAP course, and I'm pretty sure CA regulators are not going after the company providing the SAP course.
promising jobs at companies "like Facebook and Google,"
I do not see a promise or guarantee of employment anywhere in the article or in a brief search of their websites.
SAP courses tend to be B2B, which is entirely different than consumer oriented courses.
These bootcamps do make some claims that deserve greater scrutiny:
"12-weeks + From beginner to software engineer + San Francisco, CA"
"That said, the skills you pick up here are valuable around the world. Graduates walk out the door with an increasingly impressive array of project work that would impress employers in any country."
"Twelve weeks later, you’ll follow the footsteps of our trailblazing alumni, taking the methodologies and best practices you perfected at our coding bootcamp to your next job"
Would anyone hire any of these graduates for a software engineering position? I don't think I would unless they had some real world work experience to back it up. It sounds like these short programs are producing coders, not engineers. There's a big difference between the two.
If an attacker used software to make 10,000 attempts to decrypt a credit card number, for example, they would get back 10,000 different fake credit card numbers. “Each decryption is going to look plausible,”
This isn't done already???? I thought this was done all along with passwords and other short strings. I could see it being more difficult when the data is human generated passwords due to the bias in selecting words>syllables>numbers>punctuation, but still.
No, it's not normally done today. Generally if you try to decrypt a file using the wrong decryption key you'll either get random looking data, or no data at all.
Returning random data is not the same as returning a plausible (but incorrect) password since random data will include all sorts of non-printable characters that few users would include in a password. LIkewise, credit card numbers follow a set pattern with known prefixes and a checksum so an attacker could quickly weed out invalid numbers.
Help me understand this. If the 'wrong' results are truly random data that happens to look correct (as decrypting with the wrong key should be), then how does a match imply that a chosen password was weak? If the data is random isn't it equally as likely that any string would come up as a possible password? Why would a 'weak' password be more likely to come up than a 'strong' password?
Also, what would be the problem if the random password does match some elses? If your password is 'xyz', and I try password 'xyz' on my userid, it doesn't magically give me access to your account.
I think you'll have to go back to the post before me, he's the one that said:
Would have to be careful that the 'bad' results do not do things like open the lock though. For instant in the case of login list breaches.
Statistically speaking, if a randomly (or pseudorandomly) computed string matches someone else's password, then his password was not safe in the first place. A weak password is more likely to come up by an algorithm that's generating "plausible" passwords than a strong one, because a weak password is weak because it's easy to guess. That could be because it has a small keyspace (i.e. a 4 digit PIN only has 10,000 possible choices, so any random guess has a 1 in 10000 chance of being right), or because it suffers some other weakness than can be exploited (i.e. if the PIN is known to be a MMDD date, then there are only 366 possible choices).
That's what makes a password weak - it's easy to guess.
I doubt it. That may have been true back when people used substitution ciphers and encrypted plain text. Today's ciphers scramble large blocks and precompress to increase data entropy. I seriously doubt anybody but a top-notch cryptoanalyst can decrypt even the simplest attempt at a cipher from anybody who knows anything at all about cipher design.
Such a cryptoanalyst is likely to be found only at some high level government agency like the NSA and he will likely be too busy to spare any time to decrypt your inane emails to your mistress. Consequently, I would postulate that if you design your own cipher and avoid becoming the next Snowden, your data will be just as safe as if you had used AES.
Which is how we end up with things like the weak Zip File and early MS-Office encryption. Companies think they can roll their own, or take shortcuts and end up with weak security.
Published algorithms have withstood scrutiny by actual experts, don't assume that your home-grown super-secret encryption will stand up to scrutiny - it may leave patterns in the data that can be exploited to decypt it
So you decrypt something and it *looks* like real data.
So it would have to be a function that produces 'good' results and 'bad results' but the bad results look like good ones.
Would have to be careful that the 'bad' results do not do things like open the lock though. For instant in the case of login list breaches.
If randomly generated "fake" data matches someone else's password (or whatever is being encrypted), that other person didn't use a strong enough password. This system is just acting like a hash function -- criminal tries password A and he decrypts the data to some string, then he tries password B and the data gets decrypted to another string. If those randomly generated strings happen to match someone elses password on the system, the criminal could have saved himself some time by generating the password guesses himself.
What's the goal here - to make the returned data "not my data", or "incorrect data"? There is a world of difference between these two. "Not my data" is a simple thing to generate, but could still be correct data. IE, if the data protected is a card number, and the generated number matches someone else's card, then do we care or not? The criminal doesn't care, as long as their goal is met (get a valid card - it doesn't have to be yours). If we're talking about "invalid" data, then we need some mechanism to validate the generated data before it's returned. While this wouldn't meet the criminal's goal, it could open a possible DDOS attack vector on the validation service (ie, a brute force becomes a magnified reflection attack).
They aren't going to store a big database of valid credit card numbers so they can return someone else's card number, they'll just generate a random number that looks like it could be a real credit card number and passes the checksum test.
Yes, a criminal could take the credit card numbers from each decryption attempt and test them, but if he's willing to test millions of card numbers to look for a valid one, he could just generate the card numbers directly and not attempt the decryption in the first place.
I guess it DOES have some benefit, huh?
People misunderstand what "security through obscurity" means. Most (all?) encryption relies on security through obscurity at some level.
Hiding your house key under a loose floorboard in your back deck is the kind of security through obscurity that can really work, assuming that there are no other clues that lead to the hiding place. However, hiding the prybar that you use to pry up the floorboard under the belief that hiding the method of access makes your key safer is not the kind of obscurity that works because if the attacker can find your hiding place, he can figure another way to get to the key.
Similarly, hiding or not writing down your password is security through obscurity that works. But trying to hide the implementation details of your cipher algorithm does not, because cryptoanalysis can break your encryption even without access to your encryption algorithm.
So, obscuring your real password among an endless number of fake passwords is the kind of obscurity that can work -- even if the attacker knows that your password is somewhere among the billions of fake ones, unless he has some clue to tell him what your real password looks like, just knowing that fakes are there doesn't help him.
TFA was murky, but generating bogus data? If one is brute forcing a data blob, how can it make stuff up? Authentication is another story.
It didn't seem all that murky:
. But he notes that not every type of data will be easy to protect this way since it’s not always possible to know the encrypted data in enough detail to produce believable fakes. “Not all authentication or encryption systems yield themselves to being ‘honeyed.’”
So it only works with data where it can generate believable fake data -- like credit card numbers or passwords.
So you decrypt something and it *looks* like real data.
So it would have to be a function that produces 'good' results and 'bad results' but the bad results look like good ones.
Would have to be careful that the 'bad' results do not do things like open the lock though. For instant in the case of login list breaches.
If randomly generated "fake" data matches someone else's password (or whatever is being encrypted), that other person didn't use a strong enough password. This system is just acting like a hash function -- criminal tries password A and he decrypts the data to some string, then he tries password B and the data gets decrypted to another string. If those randomly generated strings happen to match someone elses password on the system, the criminal could have saved himself some time by generating the password guesses himself.
So what is average/worst case access time for that tape cabinet? For BD, I don't know at all, but I guess for BD it is some tens of secs including disk change and spin-up. Perhaps much less with hardware optimized for this.
If that data needs to be accessed from web, then I think some tens of seconds maximum acceptable.
As I said, random access might be faster with Blu-ray, but they don't seem to be interested in random access:
It designed the system to store data that hardly ever needs to be accessed, or for so-called 'cold storage' (think duplicates of users' photos and videos that it keeps for backup)
With only 16 bluray drives in the system, it wouldn't stand up to much concurrent access from the web anyway.
I'm going into tinfoil hat territory, but I wonder if there is some advance in BD storage that FB is assuming, but the average person does not know about. If BDXL disks drop from $45.00 per disk to $1 a disk or even $2 a disk, that would change the game. Similarly, Sony/Panasonic's Blu-Ray successor that stores 300GB per disk would also be a big thing, should each disk be priced at a reasonable amount.
LTO technology keeps advancing too - LTO-7 will store 6.4TB natively on a tape.
NONE of those solutions, including the current one, have been tested for longevity.
I went a year between my honeymoon and getting pictures off of my 1st gen digital camera, stored in flash memory. About half were corrupt.
Their current solution (spinning disks) has been tested for longevity -- as long as they keep replacing failed disks (and migrating data to new storage arrays as technology obsoletes the old ones), data on spinning disks can be kept alive for as long as they can pay for it.
LTO-6 holds 2.5TB/tape (native, not compressed), so it's more space dense than Blu-ray since a single tape can replace fifty 50GB bluray disks. A 1 petabyte cabinet would only need 400 tapes, and LTO tape libraries of that size are readily available off the shelf - plus the software to manage it is also off the shelf.
Cost-wise, the tapes and disks are around the same, branded dual-layer blurays seem to cost $1 - $2, and LTO-6 tapes are around $60.
The only advantage I can see for blu-rays is in random access performance, but for a rarely used cold archive system, you'd think that wouldn't matter.
If there were a legitimate and reasonably priced download service
Bullshit. As various people and groups have shown, they have provided very easy methods to get their work at extremely cheap prices and people still go out and steal the work.
You can use iTunes if you want. 99 cents for a song and people still complain. Or, if you prefer, RadioHead said they will allow people to download their song (album?) but would appreciate a "donation" for the song. The amount of money they received didn't even cover the cost of the electricity.
People can use semantics or whatever excuse they choose to explain why they're stealing someone's work without compensating that person, but in the end, they're just that, an excuse. The more you continue to steal someone's work, the more justification you give to them to make it more restrictive.
Perhaps $.99 per song is not a "reasonable price" to someone that many have thousands of songs on their device.
Radiohead must pay more for electricity than most bands if $6M doesn't cover their electricity cost:
http://entrepreneur.pro/articl...
The donation-based model is effective for established bands because they already have a mass following and there will always be a fan who would be willing to pay for their music. The question is what would one pay for an album that they want if given a chance to get it for free. There lies the answer to what an album should be sold for. Traditionally it has been sold for $9.99 as a paid download or $14.99 at a retail store. The Radiohead and Nine Inch Nails fans who opted to pay on average were willing to give about $4 to download the album. That is a far cry from the traditional pricing model which dictates that an album is priced between $9.99 and $14.99. Record labels watch out because this is an indication that the pricing on albums is not in unison with market demand and what a music fan perceives as the true value of an album.
According to the NIN band, 800,000 transactions generated $1.6 million in sales revenue in the first week of the "Ghosts I-IV" album's availability, despite the fact that the 36-song version of the album is widely available on torrent sites and file sharing P2P networks. Radiohead's "In Rainbows" generated approximately $6 million in revenues which went directly to the band, with 1,200,000 downloads.