Everybody knows how to make bulbs that are cheap and last forever. What's hard is making them so that they are simultaneously bright and energy-efficient and still last forever. If you make them brighter by making the filament thinner so that they burn hotter, it makes them more fragile. If you make them brighter by adding more filaments in parallel, they use more power. Bright, energy-efficient, robust—choose (at most) two.
You're assuming that the version Apple shipped is vulnerable to that CVE. Has anybody actually verified this? Apple has a habit of silently applying security fixes without pulling in a whole new version, to minimize the risk of inadvertently bringing in changes that break things.
Buy 11 months and get the twelfth month AND two-day shipping for free. This isn't just a bit more expensive. It's a lot more expensive—more than 30% more expensive when you compare month-to-month (full) Prime versus annual. As a result, the people who can least afford Prime are the ones who end up paying more. For shame, Amazon.
Some already pointed out that if Dutch wants to travel to Spain or France, will they be required to rent a car? There is a reason free market works best.
They would probably rent a generator pod (trailer) instead. Then again, this might just push companies to start developing of cars with an all-day driving range (say 800 miles per charge).
Of course, the misleading headline makes this story sound bigger than it is. The ban is exclusively on the sale of new cars, not on the sale of used cars, not on the use of existing cars, etc. I don't think that's likely to be a big deal by nine years from now.
Historically, T-cell therapy has been specific to a single person, because it had to be constructed using that person's own T cells. However, some teams are working on custom T cells that are modified to avoid expressing the genes that would normally cause them to attack unknown cells, thus allowing generic, off-the-shelf T cells to be introduced into anyone. Assuming it is possible to do that with CD4 cells, and assuming the immune system doesn't immediately attack and destroy those CD4 cells, it might be possible to build an off-the-shelf T-cell therapy based on what these folks are doing, in which case the cost will eventually be much, much lower.
The summary says "The therapy involves genetically engineered T cells, targeted to the solid tumors using the MAGE-A3 protein as a unique marker expressed in up to 30 percent of cancers." Seems pretty informative to me.
In journalism, they call that "burying the lede". That bit should have been in the very first sentence, or at the very latest, the second sentence. Instead, it is at the very end of the story, where it is almost guaranteed to get chopped off in the future by some well-meaning editor trying to save column inches.
I don't know if GP post is correct or not, it could be that when stress reaches a certain level an earthquake will occur. Obviously you'd never know down to the second, but could we ever know down to the day.. month... or year? How chaotic is it?
Imagine that you decide to build a bedspring out of soda cans. Randomly, a can will collapse, causing the bed to shift. If you want to predict when it will happen, you have to know the thickness of every can, how much stress it can take before collapsing, and how much pressure it will be under, given a person lying in a particular position on top of the mattress that sits atop the bed of soda cans. More importantly, you have to know whether one can's collapse will cause any of the cans around it to suddenly be under enough additional force to trigger their collapse.
As I understand it, earthquakes are kind of like that. At millions of points along a fault, various rock structures prevent the plates from slipping past one another. Periodically, those break or shift, allowing the plates to continue sliding. An earthquake occurs when the stress becomes sufficient to cause one of those rock structures to break or shift so that the plates can move again. The size of the earthquake is proportional to the amount of pressure that was on that structure prior to when it broke or shifted. So to predict an earthquake accurately, you would need to know the stress on not the fault as a whole, but at least ostensibly on every single rock structure of a given size or larger within the fault system.
The most unpredictable are probably fault systems like the New Madrid system, where the continent has a weak spot, and huge blocks of rock just suddenly slip in random directions. There's not a plate boundary involved, so the direction of slip could be entirely arbitrary, and predicting the magnitude would involve figuring out how much friction there is between countless fault blocks. It would also likely require predicting when water will erode some chunk of limestone just enough to allow an underground cave to collapse.
So maybe, but I wouldn't hold my breath while waiting.
Maybe it'd be possible to deliberately set off an imminent quake, doing this could save a lot of lives as you could get everyone to safety 1st.
In theory, if you could accurately use something like ground-penetrating sonar to detect deformation of rock that indicates substantial amounts of stress on specific rock formations, yes, you could use an explosion to relieve that pressure and cause an earthquake on your own timetable—maybe even before the stress builds up to the point where the quake would be catastrophic.
Unfortunately, I doubt it is currently possible to detect deformation with enough accuracy to guess when rock will give, or how much force it will release when it does. And even if it were possible to do so, by relieving the stress in one spot, you're likely to very rapidly introduce additional stress somewhere else, almost at random, possibly pushing some other rock structure beyond its breaking point and triggering an even bigger quake in some distant part of the fault system. So you might relieve the stress and get a 3.0 quake in San Francisco instead of a 6.0 later, but you might cause a magnitude 8.0 quake in Seattle or Tokyo.
That doesn't mean it isn't worth investigating, or that it isn't worth doing eventually, but we probably shouldn't attempt it until somebody finds a way to measure the stress along the fault at enough points and with enough accuracy to predict the outcome with some certainty.
"There is a 95% probability of an earthquake of magnitude 6.0 or greater in Southern California within the next 5 years" is absolutely useless unless you are prepared to abandon the whole area.
Not really. If we had some guarantee, that would be sufficient grounds for red tagging any buildings built on alluvial fill that don't comply with current earthquake code until they can be brought up to code, which would probably save lives.
Of course, knowing California governments, they'd probably red-tag buildings that are built on bedrock and suffered negligible damage in previous quakes, mandating expensive changes that weaken the structures and make them more likely to sustain damage in future quakes....
You certainly can offer an opt-out mechanism if you want. That said, as long as there's no PII, there's typically no legal reason why you would have to do so (at least in the U.S.). Most folks who do single-app crash logging don't provide an opt-out mechanism these days (statistically), and there's really no difference between that and an error code except in whether the app dies....
That's why I love doing mostly in-house development.
There you can just slap a "report this error to help desk" button in your application, that then generates a ticket with the complete relevant information in your ticket system.
Lots of companies do that for their public apps, too. It is generally a good practice.
If the program generates a fault, it's because a human wrote it. Error messages describing a fault are for the person the user calls for help. One could argue that they're for the user to read to the person the user calls for help, but that's just semantics; they're ultimately for the person the user calls for help, then, for the developer tasked with fixing the issue (and introducing two more).
Actually, that's the sort of data that you should send automatically to an analytics/logging server. The information you give to the user should be as simple as possible, telling them what they need to do if they want to get back up and running, and if those instructions require more than about ten words, the error dialog should provide a button that takes the user to a web page that contains those instructions.
Your helpdesk system should be tied to the error logging service so that when the user calls up and asks for help, the helpdesk people can say, "Yes, I see that the app experienced an I-D-ten-T error" or whatever, and can then provide assistance (to the extent that it is possible to do so).
Why hasn't Google blurred or removed this persons' farm from their maps? Oh and by the way the more this story is circulated the more idiots will go and harass this person in Kansas. If anything and anyone has a 'right to be forgotten' on the Internet, it's this poor 85 year old woman in Kansas.
It would probably be sufficient to have map text that says "Exact center of the United States". That would raise enough eyebrows every time anybody sees it to make most people realize that their data is probably wrong.:-)
As a rule, I do not believe OSes themselves allow open ended access to any device by an unprivileged user process (e.g. a browser process), USB or otherwise. So it would seem the OS model for hardware would be in the way. Incidentally, this problem should be taken as a huge red flag as why this may be an ill-conceived idea.
Actually, allowing unprivileged code to control most USB devices has actually been the norm for the better part of two decades. For example, OS X requires code to be privileged if it wants to control a keyboard HID device, and it won't allow user-space control of or access to mounted mass storage devices, but beyond that, it allows any random app to take over any random USB device. IIRC, sandboxed apps (e.g. anything in the MAS) require apps to declare what devices they can control, but they're still allowed to control them (within the aforementioned limitations).
BTW, if I skimmed the whitepaper correctly, only code from a specific domain would be allowed to directly access a given device model. I'm assuming that the JS code in question would then present some sort of interface that would allow arbitrary pages to control the device in a limited manner, e.g. via postMessage calls into the driver. Maybe somebody working on that team could clarify the intended usage model?
In principle, you're right. In practice, that won't work for subjects like this. You can spend your whole life studying crypto and still not fully understand everything. Even if we assume that the public is receptive to new facts about crypto (which isn't a given in a world of giant media echo chambers), making the general public informed about something as complex as crypto is just plain infeasible. For the public to make truly informed decisions on this subject, they would need to understand myriad concepts, including (but not limited to):
public-key cryptography
man-in-the-middle attacks
key escrow
forward secrecy
the history of security exploits against servers (e.g. Heartbleed)
the history of organized (and possibly government-sponsored) cyber attacks from various foreign countries
the fact that a hardware vendor has no more ability to crack into third-party software running on their hardware than the government does
the mathematical infeasibility of cracking crypto keys of various lengths using various algorithms
the use of cryptography as a tool for political dissidents, Christians living in anti-Christian states
the importance of cryptography in preventing corporate espionage (particularly by state-sponsored hackers)
...
If I spent an entire semester in an upper-division CS class teaching those subjects, I'd barely scratch the surface of what you need to understand before you can truly make an informed decision on the subject. And that's a semester when speaking to an audience of people who already understand how to write software, who understand how computers work, and who have a decent higher-level math background. If you truly want everybody to understand it well enough to form an informed opinion, you'd also have to teach the subject to people whose math background stopped before Algebra I and who think of Internet Explorer as "the Internet". This would be roughly like teaching a house cat to drive a car; it might be possible, but you'd spend so many decades getting there that you'd hopelessly piss off the cat.
And if the public as a whole doesn't understand all of the things I just listed above (plus hundreds of others), then they are simply not qualified to understand the ramifications of decisions that the government might make about crypto. The best they can possibly hope to do is to vote based on which subset of experts they trust more, which basically boils down to a popularity contest, and brings us right back around to my original assertion—that the only people whose opinions should matter to politicians on such a highly technical subject are people with a solid understanding of the issue (on at least one, if not both sides). Everybody else's opinion is almost guaranteed to not contribute usefully to the discussion.
And just to be clear, this isn't an "I'm smarter than the public" thing. Nobody knows everything about everything. If I go complaining to a politician about bridge construction standards, that politician should almost entirely ignore my opinion (unless I study it enough to bring facts to the table that they hadn't seen previously and which can be verified by experts in the field). They should also largely ignore my opinions on military tactics, automotive safety standards, economics (in general), and countless other topics for precisely the same reason. It simply isn't reasonable to expect the public to be experts in the field. That's why politicians are supposed to talk to experts and to get their opinions on the subject, and why we need politicians who are smart enough to at least halfway understand those explanations.
What we seem to have in Congress right now are a bunch of technophobes who likely think that "The Internet is down" whenever IE crashes, and they're making technology policy. They not only don't understand it, but also don't want to understand it. They don't care about facts. They don't care that what they're
You're thinking fingerprints are equivalent in security, when in reality they're not.
You're making incorrect assumptions about my understanding. I'm well aware that fingerprints are almost worthless as a security measure, because a skilled attacker can fake them trivially. Everybody on Slashdot should know this by now. If a user chooses to enable fingerprint access, either he/she doesn't know how easy it is to get past them or doesn't care.
Either way, the two-day limit (plus the random bugs where it requires a passcode for no obvious reason) doesn't significantly improve the security of the fingerprint scheme. First, it doesn't typically take two days to fake a fingerprint, and second, anybody who knows about the two-day limit also knows to unlock the device quickly, making the two-day limit almost completely moot except in the very rare situation where all of the following are true:
Someone loses a phone.
The phone had fingerprints on it.
The phone is out of cellular range at the time, preventing use of "Find my iPhone" to get its location and remotely wipe it.
Nobody finds it for several days (i.e. it is lost in an unusual spot).
The device does not get rained on and destroyed before it is found.
The device is found by a malicious person who, rather than turning it in, trying to find the owner, or wiping it, instead tries to get info off of the device.
That person knows how to fake a fingerprint.
In every other situation, this feature doesn't help. If the phone is still in your possession, there's no risk. If there are no prints, an attacker can't fake them. If somebody finds it within the first two days, all bets are off. If the phone is in cellular range, you can back it up and wipe it remotely (or just locate it). If is outdoors and gets destroyed by rain, you've protected nothing. If the person turns it in to the police, your data was never at risk. And if the person doesn't know how to fake a fingerprint, they're probably going to just try PINs until it wipes itself, so your data was never at risk. I mean, I'm sure this will happen at least once or twice before the heat death of the universe. Maybe even three times. You're more likely to get struck by lightning.
Okay, okay, so there's also the case where somebody steals your phone, then magically fails to find a valid print anywhere on it, and follows you around until they can grab your prints off of a glass at a bar, but that pretty much only happens in spy movies....
IMO, from a security perspective, the time limit is purely a feel-good measure, and its only real effect is allowing people to incorrectly assume that their passcode doesn't matter, resulting in unfortunate situations like this one. If a user is going to weaken security by the use of a fingerprint, it should always work. Users perceive an authentication that randomly doesn't work as buggy, not more secure. Even those of us who do understand the security implications of fingerprint readers, time limits aren't likely to be perceived as a non-negligible security win. So why would a company put their users through that?
Alternatively, why not give customers the choice of whether to require a passcode after n days? They're already giving users the choice about whether to weaken their security by using a fingerprint. Why not let customers choose whether the extremely rare situation I described is worth worrying about? Odds are, most customers will choose to require a password only after a reboot/software update, because the almost infinitesimal difference in security isn't worth the huge hassle. And they're not wrong for doing so.
That needs to be repeated: the majority of Americans WANT BREAKABLE ENCRYPTION. The majority of people think Apple was in the wrong - something like 60/40 according to polls. So not an absolute majority, but not an insignificant one. Especially when it comes to politicians measuring which way the wind is blowing.
What I don't think you understand here is that the opinion of the majority of Americans is completely irrelevant to what government actually does. Completely. Most politicians couldn't give two s**ts about what the public thinks. And although that is usually counterproductive, in situations like this, it is actually the right policy. The average American doesn't have any idea what encryption is or does; they just know that it magically keeps them safe. As such, their opinion on how crypto algorithms should be designed isn't important, because their opinion is not an informed opinion.
To use an analogy here, the majority of Americans want flying cars. The fact that they won't know how to drive flying cars doesn't matter to them. The fact that it isn't currently technologically feasible to build flying cars doesn't matter to them, either. If government listened to those demands, they would pass a law saying that 25% of cars next year must fly. Doing so won't give us flying cars; it will just cause all American automakers to shut down because of their inability to comply with that law. Politicians know this, because they have listened to people whose opinions actually are informed, and as a result, they won't pass such a law no matter how many Americans might jump up and whine, "But I want my flying car NOW!"
There are exactly two groups of people whose opinions matter in this case: law enforcement and the technology industry. Law enforcement's opinions matter because they're in the trenches, and they think they know what tools they need to get their jobs done. The opinions of people in the tech industry matter because they're the ones who can say whether or not what they are asking for A. is feasible, and B. can be done in a way that doesn't completely destroy the security of the system as a whole. Nobody else's opinion matters in this debate, because nobody else has sufficient knowledge of the ramifications of such a law (including, apparently, much of Congress).
It would be laughable to allow government positions to be decided by a bunch of uninformed people merely because they scream their ignorance at a louder volume than the rest of us. That's the surest way to governmental collapse, and is the reason that most politicians quickly erect an intern-powered bozo filter around their inbox....
Geeks are losing this battle. The simple problem is that people want encryption to be like a safe: a thing you use to keep The Bad Guys out, but which The Good Guys can still bust open if necessary. People flat-out don't want unbreakable encryption or perfectly secure phones. See that earlier story about the dad trying to get Apple to unlock his late son's iPhone. People side with the father. They want it to be possible to break into encrypted things.
No, people want to be in control of their lives. Some of them wrongly believe that banning encryption will give them more control. We merely must educate them about the fact that doing so will actually give them far less control.
In some cases, governments go too far in trying to create the illusion of control, such as many of the things our government did after 9/11. However, the people grasping for power after 9/11 were mostly unopposed. The airline industry has always been on the verge of bankruptcy, and they weren't about to try to fight the government to keep them from forcing all of those changes, because they wouldn't have survived. In contrast, the government is now going up against the three largest companies on the planet Earth (Apple, Google, and Microsoft)—companies that make essentially 100% of the world's smart
Implementing a 'secure' token in software on an internet connected computer that also runs god knows what else has always been a shoddy idea; popular purely because it's cheaper than dedicated hardware; and possibly not quite as awful as your average password. It's never been, or even pretended to be, an actually trustworthy approach.
Exactly. And many of us have been saying that for years. The unfortunate problem is that many people see these sorts of technologies, and think to themselves, "This makes me secure", whereas in practice, the security benefit of any software-based second factor is zero if somebody has successfully 0wn3d your hardware. With that said, this statement doesn't go far enough. In practice, the security benefit of any second factor is zero if either communication endpoint is insecure, regardless of what the second factor is, and regardless of how many factors are involved.
Suppose I'm an attacker. If I can compromise your browser, I can show a fake error page. Therefore, if I want to do a transaction on your account, I can just wait for you to perform one, use your OTP to perform some nefarious action, then issue an error page, forcing you to enter a new OTP, then let the user perform the action again and allow the action to go through. Even better, I could perform the user action first, show an error page to trick the user into providing a new OTP, and then perform the nefarious action second. That way, I can show the legitimate response page at the end, as though the nefarious action hadn't happened, hiding the fact that I just transferred your entire account balance to an account in Switzerland or whatever. A sufficiently sophisticated attacker could actually fake all of the response screens sufficiently to mask their actions until days or weeks later, when your bank sends you a snail-mail letter telling you that you're bouncing checks.
That's why the first rule of computer security, IMO, should be, "If you can't trust both endpoints, you can't trust the data."
The takeaway for anyone who wants to be more secure is this: Always use your landline phone as your second factor, and make sure that it is POTS-based and not a VoIP home phone. In some cases a POTS line can be trunked in a way that could make it possible to redirect calls somewhere else through software-based attacks, so for a truly skilled attacker, even that isn't 100% safe, but it is orders of magnitude safer than a cell phone.
The takeaway for banks and other institutions is that Internet-connected devices make poor second factors, and they should really collaborate to come up with a common platform for second-factor authentication using shared hardware tokens (e.g. OATH with OTPs) and require their customers to use them. Ideally, they should do so in a way that the customer can use a single second factor for all their accounts at various banks, relying on the passwords to ensure that someone who steals the fob won't gain access to all of the user's accounts. And ideally, they should come up with a way to provide (with some reasonable degree of certainty) a hash check on the password to ensure that the user doesn't use the same password on multiple sites. This could be a good browser feature.
The takeway for OS designers is pretty extensive; I'd recommend that anybody involved in any sort of operating-system security read the original white paper, because it would take too long to summarize the chain of attacks involved.
Not necessarily. Sure, this article is strictly about malicious programmers taking advantage of text message sharing to let a compromised computer obtain the text messages sent to a phone, but with Apple's Continuity feature, it is also possible to take phone calls on your Mac or on other non-phone iOS devices, as long as the iPhone is on the same Wi-Fi network.
If it is possible for someone writing a malicious Mac app to then control that audio stream, then in theory it would be possible for an attacker to do the same thing with callback-based two-factor. However, your phone would probably ring, so even if someone could pull that off, there's a good chance that users would quickly discover that they were being compromised, which would reduce (but not eliminate) the utility of this approach as a means of compromise.
More recent iPhones and iPads with fingerprint recognition effectively offer multiple passwords. Such devices can be configured to accept multiple fingerprints. You can teach the device the child's prints and the parent's.
In the actual story, it is revealed that in fact, they did precisely this. Unfortunately, Apple's half-assed fingerprint reader configuration refuses to let you unlock it with a fingerprint after 48 hours. When someone dies, chances are, you're dealing with funeral arrangements for way longer than this, so the last thing you're going to be thinking about is unlocking the phone within 48 hours. Worse, you can't change the passcode with just a print. You need the original passcode. And iPhone devices randomly lock you out so that you have to have the passcode even if you just used it with a fingerprint an hour before.
So basically, this whole problem is because Apple's fingerprint scheme is wholly inadequate as an alternate form of authentication, with severe flaws in its design that effectively reduce it to a password-only scheme—both randomly (without warning) and after such a short period of time that it is basically guaranteed to fail at the sorts of times when you most need it to work.
That and the fact that Apple's cloud backup is fundamentally defective by design, refusing to perform backups unless the device is A. asleep and B. connected to Wi-Fi, which is likely to not happen if somebody is in a hospital. It isn't even a user-controllable option, so those of us with unlimited data can't even choose to allow the iOS device to back itself up over the cellular connection.
With that said, assuming the device has not yet been turned completely off, it should be possible to swipe up from the bottom, go to a location with a known (trusted) Wi-Fi connection, turn on Wi-Fi, and wait for a backup to happen automatically. If the device has been allowed to power itself down, there's basically nothing anyone can do to retrieve data from the device.
The problem with that is that, as security researchers will tell you, as soon as the additional security becomes optional, the majority of people will not use it, and the majority of people who do will be those with something to hide. So at that point, it becomes trivial to determine who has something to hide. Security isn't just about preventing bad people from accessing sensitive information. It is also about preventing bad people from knowing that the sensitive information exists in the first place.
Slashdot Mirror
Everybody knows how to make bulbs that are cheap and last forever. What's hard is making them so that they are simultaneously bright and energy-efficient and still last forever. If you make them brighter by making the filament thinner so that they burn hotter, it makes them more fragile. If you make them brighter by adding more filaments in parallel, they use more power. Bright, energy-efficient, robust—choose (at most) two.
You're assuming that the version Apple shipped is vulnerable to that CVE. Has anybody actually verified this? Apple has a habit of silently applying security fixes without pulling in a whole new version, to minimize the risk of inadvertently bringing in changes that break things.
Buy 11 months and get the twelfth month AND two-day shipping for free. This isn't just a bit more expensive. It's a lot more expensive—more than 30% more expensive when you compare month-to-month (full) Prime versus annual. As a result, the people who can least afford Prime are the ones who end up paying more. For shame, Amazon.
They would probably rent a generator pod (trailer) instead. Then again, this might just push companies to start developing of cars with an all-day driving range (say 800 miles per charge).
Of course, the misleading headline makes this story sound bigger than it is. The ban is exclusively on the sale of new cars, not on the sale of used cars, not on the use of existing cars, etc. I don't think that's likely to be a big deal by nine years from now.
For now.
Historically, T-cell therapy has been specific to a single person, because it had to be constructed using that person's own T cells. However, some teams are working on custom T cells that are modified to avoid expressing the genes that would normally cause them to attack unknown cells, thus allowing generic, off-the-shelf T cells to be introduced into anyone. Assuming it is possible to do that with CD4 cells, and assuming the immune system doesn't immediately attack and destroy those CD4 cells, it might be possible to build an off-the-shelf T-cell therapy based on what these folks are doing, in which case the cost will eventually be much, much lower.
In journalism, they call that "burying the lede". That bit should have been in the very first sentence, or at the very latest, the second sentence. Instead, it is at the very end of the story, where it is almost guaranteed to get chopped off in the future by some well-meaning editor trying to save column inches.
Imagine that you decide to build a bedspring out of soda cans. Randomly, a can will collapse, causing the bed to shift. If you want to predict when it will happen, you have to know the thickness of every can, how much stress it can take before collapsing, and how much pressure it will be under, given a person lying in a particular position on top of the mattress that sits atop the bed of soda cans. More importantly, you have to know whether one can's collapse will cause any of the cans around it to suddenly be under enough additional force to trigger their collapse.
As I understand it, earthquakes are kind of like that. At millions of points along a fault, various rock structures prevent the plates from slipping past one another. Periodically, those break or shift, allowing the plates to continue sliding. An earthquake occurs when the stress becomes sufficient to cause one of those rock structures to break or shift so that the plates can move again. The size of the earthquake is proportional to the amount of pressure that was on that structure prior to when it broke or shifted. So to predict an earthquake accurately, you would need to know the stress on not the fault as a whole, but at least ostensibly on every single rock structure of a given size or larger within the fault system.
The most unpredictable are probably fault systems like the New Madrid system, where the continent has a weak spot, and huge blocks of rock just suddenly slip in random directions. There's not a plate boundary involved, so the direction of slip could be entirely arbitrary, and predicting the magnitude would involve figuring out how much friction there is between countless fault blocks. It would also likely require predicting when water will erode some chunk of limestone just enough to allow an underground cave to collapse.
So maybe, but I wouldn't hold my breath while waiting.
In theory, if you could accurately use something like ground-penetrating sonar to detect deformation of rock that indicates substantial amounts of stress on specific rock formations, yes, you could use an explosion to relieve that pressure and cause an earthquake on your own timetable—maybe even before the stress builds up to the point where the quake would be catastrophic.
Unfortunately, I doubt it is currently possible to detect deformation with enough accuracy to guess when rock will give, or how much force it will release when it does. And even if it were possible to do so, by relieving the stress in one spot, you're likely to very rapidly introduce additional stress somewhere else, almost at random, possibly pushing some other rock structure beyond its breaking point and triggering an even bigger quake in some distant part of the fault system. So you might relieve the stress and get a 3.0 quake in San Francisco instead of a 6.0 later, but you might cause a magnitude 8.0 quake in Seattle or Tokyo.
That doesn't mean it isn't worth investigating, or that it isn't worth doing eventually, but we probably shouldn't attempt it until somebody finds a way to measure the stress along the fault at enough points and with enough accuracy to predict the outcome with some certainty.
Not really. If we had some guarantee, that would be sufficient grounds for red tagging any buildings built on alluvial fill that don't comply with current earthquake code until they can be brought up to code, which would probably save lives.
Of course, knowing California governments, they'd probably red-tag buildings that are built on bedrock and suffered negligible damage in previous quakes, mandating expensive changes that weaken the structures and make them more likely to sustain damage in future quakes....
I think Charles Proxy might be the solution to your problem, at least in theory. I haven't tried it personally.
You certainly can offer an opt-out mechanism if you want. That said, as long as there's no PII, there's typically no legal reason why you would have to do so (at least in the U.S.). Most folks who do single-app crash logging don't provide an opt-out mechanism these days (statistically), and there's really no difference between that and an error code except in whether the app dies....
I just skimmed the article, so I'm not sure who is in control over the lists or whatever—just that a list would exist. :-)
Lots of companies do that for their public apps, too. It is generally a good practice.
Actually, that's the sort of data that you should send automatically to an analytics/logging server. The information you give to the user should be as simple as possible, telling them what they need to do if they want to get back up and running, and if those instructions require more than about ten words, the error dialog should provide a button that takes the user to a web page that contains those instructions.
Your helpdesk system should be tied to the error logging service so that when the user calls up and asks for help, the helpdesk people can say, "Yes, I see that the app experienced an I-D-ten-T error" or whatever, and can then provide assistance (to the extent that it is possible to do so).
It would probably be sufficient to have map text that says "Exact center of the United States". That would raise enough eyebrows every time anybody sees it to make most people realize that their data is probably wrong. :-)
Actually, allowing unprivileged code to control most USB devices has actually been the norm for the better part of two decades. For example, OS X requires code to be privileged if it wants to control a keyboard HID device, and it won't allow user-space control of or access to mounted mass storage devices, but beyond that, it allows any random app to take over any random USB device. IIRC, sandboxed apps (e.g. anything in the MAS) require apps to declare what devices they can control, but they're still allowed to control them (within the aforementioned limitations).
BTW, if I skimmed the whitepaper correctly, only code from a specific domain would be allowed to directly access a given device model. I'm assuming that the JS code in question would then present some sort of interface that would allow arbitrary pages to control the device in a limited manner, e.g. via postMessage calls into the driver. Maybe somebody working on that team could clarify the intended usage model?
Except in the non-public areas of women's dorms, the YWCA, etc.
Err... semifinal.
Slight correction to the demifinal paragraph: "It simply isn't reasonable to expect the public to be experts in every field."
In principle, you're right. In practice, that won't work for subjects like this. You can spend your whole life studying crypto and still not fully understand everything. Even if we assume that the public is receptive to new facts about crypto (which isn't a given in a world of giant media echo chambers), making the general public informed about something as complex as crypto is just plain infeasible. For the public to make truly informed decisions on this subject, they would need to understand myriad concepts, including (but not limited to):
If I spent an entire semester in an upper-division CS class teaching those subjects, I'd barely scratch the surface of what you need to understand before you can truly make an informed decision on the subject. And that's a semester when speaking to an audience of people who already understand how to write software, who understand how computers work, and who have a decent higher-level math background. If you truly want everybody to understand it well enough to form an informed opinion, you'd also have to teach the subject to people whose math background stopped before Algebra I and who think of Internet Explorer as "the Internet". This would be roughly like teaching a house cat to drive a car; it might be possible, but you'd spend so many decades getting there that you'd hopelessly piss off the cat.
And if the public as a whole doesn't understand all of the things I just listed above (plus hundreds of others), then they are simply not qualified to understand the ramifications of decisions that the government might make about crypto. The best they can possibly hope to do is to vote based on which subset of experts they trust more, which basically boils down to a popularity contest, and brings us right back around to my original assertion—that the only people whose opinions should matter to politicians on such a highly technical subject are people with a solid understanding of the issue (on at least one, if not both sides). Everybody else's opinion is almost guaranteed to not contribute usefully to the discussion.
And just to be clear, this isn't an "I'm smarter than the public" thing. Nobody knows everything about everything. If I go complaining to a politician about bridge construction standards, that politician should almost entirely ignore my opinion (unless I study it enough to bring facts to the table that they hadn't seen previously and which can be verified by experts in the field). They should also largely ignore my opinions on military tactics, automotive safety standards, economics (in general), and countless other topics for precisely the same reason. It simply isn't reasonable to expect the public to be experts in the field. That's why politicians are supposed to talk to experts and to get their opinions on the subject, and why we need politicians who are smart enough to at least halfway understand those explanations.
What we seem to have in Congress right now are a bunch of technophobes who likely think that "The Internet is down" whenever IE crashes, and they're making technology policy. They not only don't understand it, but also don't want to understand it. They don't care about facts. They don't care that what they're
You're making incorrect assumptions about my understanding. I'm well aware that fingerprints are almost worthless as a security measure, because a skilled attacker can fake them trivially. Everybody on Slashdot should know this by now. If a user chooses to enable fingerprint access, either he/she doesn't know how easy it is to get past them or doesn't care.
Either way, the two-day limit (plus the random bugs where it requires a passcode for no obvious reason) doesn't significantly improve the security of the fingerprint scheme. First, it doesn't typically take two days to fake a fingerprint, and second, anybody who knows about the two-day limit also knows to unlock the device quickly, making the two-day limit almost completely moot except in the very rare situation where all of the following are true:
In every other situation, this feature doesn't help. If the phone is still in your possession, there's no risk. If there are no prints, an attacker can't fake them. If somebody finds it within the first two days, all bets are off. If the phone is in cellular range, you can back it up and wipe it remotely (or just locate it). If is outdoors and gets destroyed by rain, you've protected nothing. If the person turns it in to the police, your data was never at risk. And if the person doesn't know how to fake a fingerprint, they're probably going to just try PINs until it wipes itself, so your data was never at risk. I mean, I'm sure this will happen at least once or twice before the heat death of the universe. Maybe even three times. You're more likely to get struck by lightning.
Okay, okay, so there's also the case where somebody steals your phone, then magically fails to find a valid print anywhere on it, and follows you around until they can grab your prints off of a glass at a bar, but that pretty much only happens in spy movies....
IMO, from a security perspective, the time limit is purely a feel-good measure, and its only real effect is allowing people to incorrectly assume that their passcode doesn't matter, resulting in unfortunate situations like this one. If a user is going to weaken security by the use of a fingerprint, it should always work. Users perceive an authentication that randomly doesn't work as buggy, not more secure. Even those of us who do understand the security implications of fingerprint readers, time limits aren't likely to be perceived as a non-negligible security win. So why would a company put their users through that?
Alternatively, why not give customers the choice of whether to require a passcode after n days? They're already giving users the choice about whether to weaken their security by using a fingerprint. Why not let customers choose whether the extremely rare situation I described is worth worrying about? Odds are, most customers will choose to require a password only after a reboot/software update, because the almost infinitesimal difference in security isn't worth the huge hassle. And they're not wrong for doing so.
What I don't think you understand here is that the opinion of the majority of Americans is completely irrelevant to what government actually does. Completely. Most politicians couldn't give two s**ts about what the public thinks. And although that is usually counterproductive, in situations like this, it is actually the right policy. The average American doesn't have any idea what encryption is or does; they just know that it magically keeps them safe. As such, their opinion on how crypto algorithms should be designed isn't important, because their opinion is not an informed opinion.
To use an analogy here, the majority of Americans want flying cars. The fact that they won't know how to drive flying cars doesn't matter to them. The fact that it isn't currently technologically feasible to build flying cars doesn't matter to them, either. If government listened to those demands, they would pass a law saying that 25% of cars next year must fly. Doing so won't give us flying cars; it will just cause all American automakers to shut down because of their inability to comply with that law. Politicians know this, because they have listened to people whose opinions actually are informed, and as a result, they won't pass such a law no matter how many Americans might jump up and whine, "But I want my flying car NOW!"
There are exactly two groups of people whose opinions matter in this case: law enforcement and the technology industry. Law enforcement's opinions matter because they're in the trenches, and they think they know what tools they need to get their jobs done. The opinions of people in the tech industry matter because they're the ones who can say whether or not what they are asking for A. is feasible, and B. can be done in a way that doesn't completely destroy the security of the system as a whole. Nobody else's opinion matters in this debate, because nobody else has sufficient knowledge of the ramifications of such a law (including, apparently, much of Congress).
It would be laughable to allow government positions to be decided by a bunch of uninformed people merely because they scream their ignorance at a louder volume than the rest of us. That's the surest way to governmental collapse, and is the reason that most politicians quickly erect an intern-powered bozo filter around their inbox....
No, people want to be in control of their lives. Some of them wrongly believe that banning encryption will give them more control. We merely must educate them about the fact that doing so will actually give them far less control.
In some cases, governments go too far in trying to create the illusion of control, such as many of the things our government did after 9/11. However, the people grasping for power after 9/11 were mostly unopposed. The airline industry has always been on the verge of bankruptcy, and they weren't about to try to fight the government to keep them from forcing all of those changes, because they wouldn't have survived. In contrast, the government is now going up against the three largest companies on the planet Earth (Apple, Google, and Microsoft)—companies that make essentially 100% of the world's smart
Exactly. And many of us have been saying that for years. The unfortunate problem is that many people see these sorts of technologies, and think to themselves, "This makes me secure", whereas in practice, the security benefit of any software-based second factor is zero if somebody has successfully 0wn3d your hardware. With that said, this statement doesn't go far enough. In practice, the security benefit of any second factor is zero if either communication endpoint is insecure, regardless of what the second factor is, and regardless of how many factors are involved.
Suppose I'm an attacker. If I can compromise your browser, I can show a fake error page. Therefore, if I want to do a transaction on your account, I can just wait for you to perform one, use your OTP to perform some nefarious action, then issue an error page, forcing you to enter a new OTP, then let the user perform the action again and allow the action to go through. Even better, I could perform the user action first, show an error page to trick the user into providing a new OTP, and then perform the nefarious action second. That way, I can show the legitimate response page at the end, as though the nefarious action hadn't happened, hiding the fact that I just transferred your entire account balance to an account in Switzerland or whatever. A sufficiently sophisticated attacker could actually fake all of the response screens sufficiently to mask their actions until days or weeks later, when your bank sends you a snail-mail letter telling you that you're bouncing checks.
That's why the first rule of computer security, IMO, should be, "If you can't trust both endpoints, you can't trust the data."
The takeaway for anyone who wants to be more secure is this: Always use your landline phone as your second factor, and make sure that it is POTS-based and not a VoIP home phone. In some cases a POTS line can be trunked in a way that could make it possible to redirect calls somewhere else through software-based attacks, so for a truly skilled attacker, even that isn't 100% safe, but it is orders of magnitude safer than a cell phone.
The takeaway for banks and other institutions is that Internet-connected devices make poor second factors, and they should really collaborate to come up with a common platform for second-factor authentication using shared hardware tokens (e.g. OATH with OTPs) and require their customers to use them. Ideally, they should do so in a way that the customer can use a single second factor for all their accounts at various banks, relying on the passwords to ensure that someone who steals the fob won't gain access to all of the user's accounts. And ideally, they should come up with a way to provide (with some reasonable degree of certainty) a hash check on the password to ensure that the user doesn't use the same password on multiple sites. This could be a good browser feature.
The takeway for OS designers is pretty extensive; I'd recommend that anybody involved in any sort of operating-system security read the original white paper, because it would take too long to summarize the chain of attacks involved.
Not necessarily. Sure, this article is strictly about malicious programmers taking advantage of text message sharing to let a compromised computer obtain the text messages sent to a phone, but with Apple's Continuity feature, it is also possible to take phone calls on your Mac or on other non-phone iOS devices, as long as the iPhone is on the same Wi-Fi network.
If it is possible for someone writing a malicious Mac app to then control that audio stream, then in theory it would be possible for an attacker to do the same thing with callback-based two-factor. However, your phone would probably ring, so even if someone could pull that off, there's a good chance that users would quickly discover that they were being compromised, which would reduce (but not eliminate) the utility of this approach as a means of compromise.
In the actual story, it is revealed that in fact, they did precisely this. Unfortunately, Apple's half-assed fingerprint reader configuration refuses to let you unlock it with a fingerprint after 48 hours. When someone dies, chances are, you're dealing with funeral arrangements for way longer than this, so the last thing you're going to be thinking about is unlocking the phone within 48 hours. Worse, you can't change the passcode with just a print. You need the original passcode. And iPhone devices randomly lock you out so that you have to have the passcode even if you just used it with a fingerprint an hour before.
So basically, this whole problem is because Apple's fingerprint scheme is wholly inadequate as an alternate form of authentication, with severe flaws in its design that effectively reduce it to a password-only scheme—both randomly (without warning) and after such a short period of time that it is basically guaranteed to fail at the sorts of times when you most need it to work.
That and the fact that Apple's cloud backup is fundamentally defective by design, refusing to perform backups unless the device is A. asleep and B. connected to Wi-Fi, which is likely to not happen if somebody is in a hospital. It isn't even a user-controllable option, so those of us with unlimited data can't even choose to allow the iOS device to back itself up over the cellular connection.
With that said, assuming the device has not yet been turned completely off, it should be possible to swipe up from the bottom, go to a location with a known (trusted) Wi-Fi connection, turn on Wi-Fi, and wait for a backup to happen automatically. If the device has been allowed to power itself down, there's basically nothing anyone can do to retrieve data from the device.
The problem with that is that, as security researchers will tell you, as soon as the additional security becomes optional, the majority of people will not use it, and the majority of people who do will be those with something to hide. So at that point, it becomes trivial to determine who has something to hide. Security isn't just about preventing bad people from accessing sensitive information. It is also about preventing bad people from knowing that the sensitive information exists in the first place.