Who is to say that what gets printed or counted is the same thing the voter marked?
The voter should be able to ensure that what gets printed is what he or she marked.
Ensuring that the ballots are counted as cast is another problem, but one that we know how to solve well enough to ensure that large-scale manipulations of the vote will be found. Once you've got clearly-marked paper ballots that the voter has verified correct, the rest of what follows is well-understood, and your next anti-fraud focus should be on voter registration processes.
What you ideally want to do is to start with the bits for which there are provably very few solutions because then you minimize the risk of producing flaws elsewhere by having to leave out parts.
I'm not sure I agree with this statement -- given that any security system is only as strong as the weakest link, you need to get it all right (or right enough, anyway), and why not start with the low-hanging fruit? But, regardless of that, I'm interested to hear what you think are the bits that provably have very few solutions, and what you think should be done to address them. It sounds like you've put some thought into it; I'd like to hear it.
You're ignoring the overhead imposed by streaming protocols. The total bandwidth consumed by streaming is higher than that consumed by delivering the same bits via TCP. Of course, you can stream over TCP, but only if you have a large local buffer and only if your connection is enough faster than the minimum bitrate needed so that you can fill that buffer and keep it filled. You don't really have to download the entire one-hour video in 15 seconds -- but there's tremendous value in being able to download one minute of video in one second. It allows the most bandwidth-efficient transfer protocols to be used while still allowing users to get started watching instantly, and without any worries about running out of buffered data.
Plus it's nice if you want to be able to continue watching while you're not on-line.
It is a little ambiguous on just what constitutes a derivative project, at least in v2
What constitutes a derivative work is extremely well-defined -- by decades of case law. Note that what the GPL says constitutes a derivative work doesn't really matter -- "derivative work" is a term of art in copyright law and the GPL doesn't get to redefine it in any significant way, other than perhaps to weaken the term a little.
With WebRTC, developers will be able to build voice and video applications using nothing more than HTML and JavaScript. This is a powerful technology which can...
... implement some truly awesome spy technology. Implemented both by site owners and site hackers.
Right, I'm sure none of the browser vendors will ever think of implementing a user prompt before turning on the microphone and camera. Just like none of the mobile browsers ask the user before providing location information to web sites, and none of the browsers have any tools for removing or limiting the scope of cookies, or...
Jeez, people. Paranoia is well and good, but you should at least come up with something that won't obviously be addressed right up front.
Better the devil you know than the demon you don't.
Ah, forgot to address this part... and it's important because it truly is the core flaw in all of your arguments. NFC is not an unknown demon. It's a slight -- very slight -- spin on a time-tested and very well-known technology. It's entirely possible that you personally don't know it well, but there are lots of things you don't know, perhaps even as many as I don't know. But this payment technology is well-known and well-understood. The only change is that we're now embedding it in a phone rather than a plastic card... and that change is entirely to the positive from a security perspective: The chip now has an external power source, rather than having to rely on the reader, which facilitates security countermeasures that weren't previously possible. It also has a nearly always-available communications channel which it can use to communicate with the issuing bank, and it's also connected to a user-friendly UI which is generally under the control of the owner of the payment account, both of which enable still further security countermeasures.
No... preferring what is effectively the same amount of security for greater cost and trouble is foolish. (Again, I am referring to physical security.)
I'm not sure what, precisely, you mean by "physical security" in this context, nor why you're focusing on it to the exclusion of all the other relevant security characteristics. I will only say that secure elements in credit cards have successfully reduced card-present credit card fraud to effectively zero. Rather than being a net cost, the technology has proven to save billions. This isn't theory, it's easily-researchable, documented fact.
I'm not even convinced that the phones are more secure because you physically need the phone to make a transaction. I have no doubt that the security certificate, or equivalent, of a given phone can be cloned and used in another device.
It can if you're willing to destroy the device and have access to a few million dollars worth of hardware. The best known direct physical attack has been the same for nearly 20 years -- an electron force probe used to painstakingly peel back the layers of security cladding to gain access to the EEPROM. Other attacks have come and gone, notably several side-channel attacks, including thermal analysis, power analysis, differential power analysis and EM analysis, but modern chips employ countermeasures to defend against all of these.
Will there be other attacks in the future? Undoubtedly. This arms race has been going on for nearly three decades, and going in earnest for almost two, and it's not going to end just because we embed the chips in phones rather than in plastic cards. However, neither is putting the chips in phones going to suddenly change the nature of the race, and time has proven that the attackers rarely manage to obtain any truly exploitable advantage.
Of course, part of the reason for that is because the magstripe-based system has been so utterly insecure that any chip-based security encouraged fraudsters to go after the easy targets. But there are now large sections of the industrialized world that use chips, and it certainly isn't the case that all of their criminals have moved out -- and yet those criminals have still not been successful at compromising the chip-based security in any significant way.
"In order to pay with your phone you'll have to enter a PIN"
In other words, just exactly as I said... no more secure than a card.
What part of the world do you live in? Where I live, credit cards don't require PINs. In theory the clerk is supposed to verify my signature against the signature on the back of the card but (a) no one does, (b) no one would know how if they wanted to and (c) who's to say that's actually my signature on the card?
"The amount of fraud that is enabled and actually carried out due to the fact that magstripes provide zero security is on the order of tens of billions of dollars per year. Every time you use your card, you risk the stripe being copied and your card being replicated (this is called "skimming" in the industry lingo)."
But you have already shown that the phones are no more secure than cards. All you need is the PIN, and you're in. That's all I needed to know, to know that this is all just smoke and mirrors... and it is exactly what I have been saying, all along.
If you need a PIN to use your credit card then you're right that NFC doesn't greatly increase your security.
It might add a little security, depending on the details of the existing system, because it means that the PIN entry device remains under your control. The UK chip & PIN card-present fraud that has occurred has pretty much all involved fake card terminals which collected PINs (which were then used to steal money through ATMs, which unfortunately still use the magstripe rather than the chip). If your phone is the PIN entry device, that risk is in some ways mitigated -- and in some ways still present if someone compromises your phone unless the SE can take control of the UI as I mentioned in my original post.
But, all in all, if your current credit card requires a PIN, then no, putting it in the phone won't add security. OTOH, in the parts of the world where credit cards currently DO require a PIN, the chip payment infrastructure is already in place, so the only hardware cost of rolling out NFC is the secure elements in the phones, which is trivial.
It will provide some convenience and ease of use, including the ability to put multiple payment instruments on one device, rather than carrying a wallet full of cards. It will also probably allow you some ability to customize the security/convenience tradeoff. Right now in the UK, chip & PIN cards allow (IIRC) seven transactions of less than 15 pounds each, or 50 pounds total, whichever comes first, before requiring a PIN. On your phone, this will probably be configurable, so if you prefer to have to authenticate every single transaction, you can, or maybe you can set the limits even higher.
"That flaw really sucks, and it boggles the mind that it could have slipped through..."
No, it doesn't. That was my point. It is pretty much standard procedure for those who implement security technology to make mistakes. We have learned that lesson the hard way. It has happened nearly every time. It has just taken time to discover the flaws.
The point is that in practice it's a minor flaw that doesn't enable a significant amount of fraud.
"And it's orders of magnitude more secure than magstripes."
Really? In what way? Are you saying that if someone has your telephone, this won't work for them?
Yes. In order to pay with your phone you'll have to enter a PIN (modulo possible convenience options that allow a certain number of low-value transactions between PIN verifications -- as is presently done in the UK). Someone who finds your phone won't know your PIN. The PIN shouldn't be stored anywhere in the handset, only in the SE, and every copy of the PIN in handset memory should be zeroed as soon as it's presented to the SE.
Of course, those "shoulds" in the last sentence are obvious areas for implementation flaws. But contrast that to your chipless magstripe card: Anyone who obtains your card can use it. No passwords, no encryption, no security whatsoever.
You are saying that somehow the physical security is better than with cards?
The physical security of your magstripe cards is nearly irrelevant to the security of your credit account. There are many ways for someone to steal from your account without having your card.
The amount of fraud that is enabled and actually carried out due to the fact that magstripes provide zero security is on the order of tens of billions of dollars per year. Every time you use your card, you risk the stripe being copied and your card being replicated (this is called "skimming" in the industry lingo).
So yes, an NFC-enabled phone will be far, far more secure than what you use now. There will undoubtedly be flaws, and fixes, and flaws, and fixes, but the net result of that security arms race will be less fraud.
Pardon me if I remain skeptical.
Skepticism of security technology is good. Preferring no security over imperfect security is foolish.
Regardless of what hardware is either in the phone or in the terminal, NFC still has to do handshakes, ACKs, and send financial transactions over RF... and it will be sniffable. Will the encryption and security be up to the task? I am doubtful. Not because the cryptography is weak, but because there is nearly always some kind of flaw in the implementation.
This is technology that has been deployed for millions of users for years now, including in contactless form. To date, the only significant flaw that has been found is the offline PIN verification attack against the UK chip & PIN implementation. That flaw really sucks, and it boggles the mind that it could have slipped through, but even with that flaw there is far less card-present fraud in the UK than in countries without this technology.
Skepticism is well and good -- especially where security is concerned -- but this is proven technology. It's not perfect, but it's definitely good enough. And it's orders of magnitude more secure than magstripes.
Mobile handsets are well on their way to becoming general-purpose computing platforms, with all of the security problems that entails. I think we have reason to be hopeful that it won't get as bad as Windows-based PCs are, but the fact is that the security of the handset is never going to be something we can really rely on.
To me, that means that if we want to use them for payment, we need to have a device in the phones which can securely store and use cryptographic keys, and contain and execute software that can be trusted to make appropriate security decisions. NFC is almost* exactly what's required for that, because the NFC chips are smart card chips -- small 8 or 16-bit computers in packages that have been specifically designed for years to resist intrusion. Are they perfect? No, nothing is. But they are the result of a decades-long arms race between attackers and designers, and they really are pretty darned secure. When competent security engineers who accurately understand their security strengths and weaknesses craft solutions and protocols using them, the result is orders of magnitude more secure than the main processor on a mobile handset.
I don't really care whether you use RF or audio or direct electrical connection to facilitate communication between reader and phone, to make it anything like secure you need a secure processor to handle the crypto. So you need the chip, period. But that's okay, because the incremental cost of an NFC chip added to a mobile phone is trivial.
And if you're adding an SE (or even just upgrading the SIM to make it featureful enough to handle the payment ops), the cost of the additional RF hardware needed by NFC is practically irrelevant, so why not do RF? I know Zoosh says this ultrasonic thing works in noisy environments -- but I'm really skeptical that it works in noisy ultrasonic environments. I'm also skeptical about the claimed low cost of merchant terminals, especially given that NFC-capable devices are already being produced in volume.
* The reason for my hedge "almost" is that I/O still has to pass through the main handset. In the case of communications with various back-end servers, whether via NFC or the cellular network or audio or whatever else, that's mostly okay because those back-end servers can have HSMs and do end-to-end security with the SE. "Mostly", because we'll still need the handset to provide the UI for users to authenticate, approve transactions, etc. What would really be awesome is if the phone had a mode where the SE could take control of the UI and cut the main handset OS out of the loop -- and maybe also have an LED on the phone that is hard-wired ONLY to the SE so that when that light is on you know the SE is in control. But there are many, many reasons why that is infeasible with current-generation SEs, and those coming for the next few years. And when it does become possible, the increased level of software complexity will undoubtedly come with exploitable security defects. It's a hard problem.
Still, even without my ideal situation, the result of combining an SE, well-designed protocols and a handset UI/network, etc. will provide a huge increase in security vs current electronic payment systems.
Even if your strategy wasn't impractical, what would make you think that Google would want to make Java public domain?
I don't think Google would make the Java tools and libraries public domain. I think Google would release them under an MIT-style open source license, as they've done with the Go language.
This is not a test case for the GPL, it's a straight-forward copyright violation case
The really clever bit about the GPL is that any test case is a straight-forward copyright infringement case. People who violate the GPL find themselves in the unenviable position of having to try to use the GPL to justify their actions, because it's the only thing that gives them any shred of permission to use the code. All it takes, then, is for the court to evaluate the situation and realize that the GPL didn't actually give them permission because they didn't meet its requirements.
Ah, thanks. Not a NOP, then. And I'm all in favor of minimizing federal regulatory scope. With rare exceptions (those whose interstate nature makes it impossible for states to address) crime is and should be primarily a state-level issue, and this is particularly true when the crime in question is one that people actively debate.
So, in summary, it is not a good idea to rely on physical theory, which has the status of Hypotheses when it comes to practical implementations, when we have actual mathematical theory (which is still hard fact when implemented digitally) that already solves the problem well.
Except that we don't really have "actual mathematical theory", either. No one currently knows how to factor products of large primes efficiently, but it has not been proven that integer factorization is NP-complete, nor are we entirely sure what NP-completeness means (c.f. P=NP). Worse, we haven't even proven that factorization is the only way to defeat RSA -- it's possible there's another way. Finally, RSA and other asymmetric ciphers also suffer from practical implementation issues. RSA in particular is very vulnerable to side-channel attacks like power analysis and thermal analysis. There are many other known weaknesses that we know how to work around (e.g. chosen ciphtertext attacks, which are defeated by using optimal asymmetric encryption padding -- though the original version of OAEP has proven to have some weaknesses, addressed by newer versions), and there are undoubtedly many weaknesses that we don't yet even know about.
I'm not knocking RSA, DSA, El-Gamal, ECC, etc., they are very valuable tools. But to say that this shows they are inherently better than quantum crypto is nonsense. Security is just plain hard. The ONLY cipher that we have real, solid mathematically-provable reasons to trust is the venerable one-time pad, and even THAT has proved in practice to be less than perfectly secure due to implementation errors (c.f. Venona).
This law makes it legal everywhere... except where state legislatures or voters vote to make it illegal. So all of the states that already ban it will vote to ban it (or maybe they'll just argue that having already banned it they have already made the vote and don't need another), and all of those that allow it will continue to allow it. Net effect, zero.
I don't really care about on-line gambling one way or another, but it seems silly to waste time and effort on a law that will ultimately change nothing. I suspect that the Representative's intent was to legalize it everywhere, period, using the fact that federal law overrides state laws, but had to insert the opt-out provision as a compromise to mollify opponents, but the net effect is to make the bill pointless.
Most importantly there is not renewable technology that will create the base load.
Sure there is... hydro provides an awesome base load generation capacity, and there are a lot more places you can build dams than geothermal plants.
Of course, most of the people who hate nuclear power hate hydro as well.
I agree hydro is the most viable of renewable technologies, but in the developed world anyway most of the available hydro sites have already been taken. I doubt there is much expansion in hydro. Thats before the issues of erosion etc are considered
In the mountain west of the US (where I live), there are plenty of sites for more hydro power, but it's politically infeasible to use them, both because of the opposition of groups like the Sierra Club and because in many case it would require moving small towns. Most of the towns in question are *very* small -- less than a thousand people, often less than a hundred, but the combination of the residents' complaints and the backing of people who oppose building dams on principle means that it's unlikely the US will ever build another significant dam.
In some places we could add hydro generating stations that tap flowing rivers without a dam, but those are less effective and less reliable.
All in all, I'd say that your bottom line is 100% correct -- in the developed world the hydro we have is basically all we're going to get. Any growth in renewable power generation has to come from solar, wind, waves and geothermal. IMO those can't provide the generation capacity we require, not without significant technological breakthroughs in both generation and storage.
Provided you're on an operating system that supports user accounts, which to my understanding means a PC. Do Apple's iPad and the various Android tablets support user accounts yet?
You can associate search setting with Google accounts, and even have multiple Google accounts logged in and switch quickly between them... just click on the little drop-down in the upper right corner and click "Switch Accounts" to choose which account and settings you want to use. So you don't necessarily need OS-level accounts.
If you read the article carefully, the claim that most of the weapons come from the US isn't true. In particular:
The ATF figures show that 21,313 firearms recovered in Mexico in 2009 were submitted for tracing by the agency. Of these, 10,945 were manufactured in the U.S. and 3,268 were imported into the U.S. from third countries before ending up in Mexico. The origin of 7,100 firearms couldn't be determined.
Of 7,971 firearms recovered in Mexico in 2010 and traced by ATF, 4,186 were manufactured in the U.S. and 2,105 were imported into the U.S. The origin of 1,680 firearms couldn't be determined.
Collectively, the data show that of the 29,284 firearms recovered in Mexico in 2009 and 2010 and submitted to the ATF for tracing, 20,504 or 70% passed through the U.S. at some point. The period is the most recent for which data are available.
The ATF said it traced the guns based on information provided by Mexican authorities. The Mexican government doesn't submit every firearm it recovers for tracing.
If you do a search for articles from previous years, they actually gave the total numbers of guns collected by the Mexican authorities, not just the number submitted to the ATF. The Mexican government only has the ATF trace the guns that appear likely to have originated in the US. These are mostly semi-automatic rifles and handguns, because fully-automatic weapons -- which are much more highly prized by the cartels -- are not available on the US market except in very small numbers and for very, very high prices (usually 15 to 20x their normal value). So all of the full-auto AK-47s, the grenade launchers, the RPGs, the various light and heavy machine guns, the small artillery pieces... none of that stuff is sent to the ATF for tracing because everyone knows it couldn't have come from the US. And that stuff accounts for the vast majority of weapons collected. IIRC (I suppose I ought to look it up myself), roughly 30% of guns recovered by Mexican officials are submitted for tracing. Of those submitted, about 2/3 are from the US, which means the total percentage of US guns among those recovered is about 20%.
But even the 20% figure is misleading. The vast majority of those are the least dangerous of the guns used by the cartels -- semi-automatic handguns. Of the few full-auto rifles, nearly all of them come from one of two sources -- the Mexican military, who purchased them from the US, and the ATF through their "Operation Gunrunner", which Congress is investigating.
So on the gun side, no, most of the weapons aren't from the US, only about a fifth of them are, and even that overrepresents the contribution of US guns to Mexican violence. The reason for this is obvious: Given all of the actual military arms available on the international black market and all over South America, cartels can buy more and better guns for less money elsewhere.
On the money side, you're absolutely right. The US drug markets are the reason the Mexican cartels exist in the form they do.
Slashdot Mirror
If this is the case, wouldn't CONFIG_USE_PREFETCH be a better solution?
It seems likely that any CPU which has the prefetch instruction also does hardware pre-fetching.
Who is to say that what gets printed or counted is the same thing the voter marked?
The voter should be able to ensure that what gets printed is what he or she marked.
Ensuring that the ballots are counted as cast is another problem, but one that we know how to solve well enough to ensure that large-scale manipulations of the vote will be found. Once you've got clearly-marked paper ballots that the voter has verified correct, the rest of what follows is well-understood, and your next anti-fraud focus should be on voter registration processes.
What you ideally want to do is to start with the bits for which there are provably very few solutions because then you minimize the risk of producing flaws elsewhere by having to leave out parts.
I'm not sure I agree with this statement -- given that any security system is only as strong as the weakest link, you need to get it all right (or right enough, anyway), and why not start with the low-hanging fruit? But, regardless of that, I'm interested to hear what you think are the bits that provably have very few solutions, and what you think should be done to address them. It sounds like you've put some thought into it; I'd like to hear it.
So a better description is that a billion unique devices visited Google in one month.
That's still pretty freaking amazing.
You're ignoring the overhead imposed by streaming protocols. The total bandwidth consumed by streaming is higher than that consumed by delivering the same bits via TCP. Of course, you can stream over TCP, but only if you have a large local buffer and only if your connection is enough faster than the minimum bitrate needed so that you can fill that buffer and keep it filled. You don't really have to download the entire one-hour video in 15 seconds -- but there's tremendous value in being able to download one minute of video in one second. It allows the most bandwidth-efficient transfer protocols to be used while still allowing users to get started watching instantly, and without any worries about running out of buffered data.
Plus it's nice if you want to be able to continue watching while you're not on-line.
It is a little ambiguous on just what constitutes a derivative project, at least in v2
What constitutes a derivative work is extremely well-defined -- by decades of case law. Note that what the GPL says constitutes a derivative work doesn't really matter -- "derivative work" is a term of art in copyright law and the GPL doesn't get to redefine it in any significant way, other than perhaps to weaken the term a little.
With WebRTC, developers will be able to build voice and video applications using nothing more than HTML and JavaScript. This is a powerful technology which can ...
... implement some truly awesome spy technology. Implemented both by site owners and site hackers.
Right, I'm sure none of the browser vendors will ever think of implementing a user prompt before turning on the microphone and camera. Just like none of the mobile browsers ask the user before providing location information to web sites, and none of the browsers have any tools for removing or limiting the scope of cookies, or...
Jeez, people. Paranoia is well and good, but you should at least come up with something that won't obviously be addressed right up front.
Better the devil you know than the demon you don't.
Ah, forgot to address this part... and it's important because it truly is the core flaw in all of your arguments. NFC is not an unknown demon. It's a slight -- very slight -- spin on a time-tested and very well-known technology. It's entirely possible that you personally don't know it well, but there are lots of things you don't know, perhaps even as many as I don't know. But this payment technology is well-known and well-understood. The only change is that we're now embedding it in a phone rather than a plastic card... and that change is entirely to the positive from a security perspective: The chip now has an external power source, rather than having to rely on the reader, which facilitates security countermeasures that weren't previously possible. It also has a nearly always-available communications channel which it can use to communicate with the issuing bank, and it's also connected to a user-friendly UI which is generally under the control of the owner of the payment account, both of which enable still further security countermeasures.
No... preferring what is effectively the same amount of security for greater cost and trouble is foolish. (Again, I am referring to physical security.)
I'm not sure what, precisely, you mean by "physical security" in this context, nor why you're focusing on it to the exclusion of all the other relevant security characteristics. I will only say that secure elements in credit cards have successfully reduced card-present credit card fraud to effectively zero. Rather than being a net cost, the technology has proven to save billions. This isn't theory, it's easily-researchable, documented fact.
I'm not even convinced that the phones are more secure because you physically need the phone to make a transaction. I have no doubt that the security certificate, or equivalent, of a given phone can be cloned and used in another device.
It can if you're willing to destroy the device and have access to a few million dollars worth of hardware. The best known direct physical attack has been the same for nearly 20 years -- an electron force probe used to painstakingly peel back the layers of security cladding to gain access to the EEPROM. Other attacks have come and gone, notably several side-channel attacks, including thermal analysis, power analysis, differential power analysis and EM analysis, but modern chips employ countermeasures to defend against all of these.
Will there be other attacks in the future? Undoubtedly. This arms race has been going on for nearly three decades, and going in earnest for almost two, and it's not going to end just because we embed the chips in phones rather than in plastic cards. However, neither is putting the chips in phones going to suddenly change the nature of the race, and time has proven that the attackers rarely manage to obtain any truly exploitable advantage.
Of course, part of the reason for that is because the magstripe-based system has been so utterly insecure that any chip-based security encouraged fraudsters to go after the easy targets. But there are now large sections of the industrialized world that use chips, and it certainly isn't the case that all of their criminals have moved out -- and yet those criminals have still not been successful at compromising the chip-based security in any significant way.
"In order to pay with your phone you'll have to enter a PIN"
In other words, just exactly as I said... no more secure than a card.
What part of the world do you live in? Where I live, credit cards don't require PINs. In theory the clerk is supposed to verify my signature against the signature on the back of the card but (a) no one does, (b) no one would know how if they wanted to and (c) who's to say that's actually my signature on the card?
"The amount of fraud that is enabled and actually carried out due to the fact that magstripes provide zero security is on the order of tens of billions of dollars per year. Every time you use your card, you risk the stripe being copied and your card being replicated (this is called "skimming" in the industry lingo)."
But you have already shown that the phones are no more secure than cards. All you need is the PIN, and you're in. That's all I needed to know, to know that this is all just smoke and mirrors... and it is exactly what I have been saying, all along.
If you need a PIN to use your credit card then you're right that NFC doesn't greatly increase your security.
It might add a little security, depending on the details of the existing system, because it means that the PIN entry device remains under your control. The UK chip & PIN card-present fraud that has occurred has pretty much all involved fake card terminals which collected PINs (which were then used to steal money through ATMs, which unfortunately still use the magstripe rather than the chip). If your phone is the PIN entry device, that risk is in some ways mitigated -- and in some ways still present if someone compromises your phone unless the SE can take control of the UI as I mentioned in my original post.
But, all in all, if your current credit card requires a PIN, then no, putting it in the phone won't add security. OTOH, in the parts of the world where credit cards currently DO require a PIN, the chip payment infrastructure is already in place, so the only hardware cost of rolling out NFC is the secure elements in the phones, which is trivial.
It will provide some convenience and ease of use, including the ability to put multiple payment instruments on one device, rather than carrying a wallet full of cards. It will also probably allow you some ability to customize the security/convenience tradeoff. Right now in the UK, chip & PIN cards allow (IIRC) seven transactions of less than 15 pounds each, or 50 pounds total, whichever comes first, before requiring a PIN. On your phone, this will probably be configurable, so if you prefer to have to authenticate every single transaction, you can, or maybe you can set the limits even higher.
"That flaw really sucks, and it boggles the mind that it could have slipped through..."
No, it doesn't. That was my point. It is pretty much standard procedure for those who implement security technology to make mistakes. We have learned that lesson the hard way. It has happened nearly every time. It has just taken time to discover the flaws.
The point is that in practice it's a minor flaw that doesn't enable a significant amount of fraud.
"And it's orders of magnitude more secure than magstripes."
Really? In what way? Are you saying that if someone has your telephone, this won't work for them?
Yes. In order to pay with your phone you'll have to enter a PIN (modulo possible convenience options that allow a certain number of low-value transactions between PIN verifications -- as is presently done in the UK). Someone who finds your phone won't know your PIN. The PIN shouldn't be stored anywhere in the handset, only in the SE, and every copy of the PIN in handset memory should be zeroed as soon as it's presented to the SE.
Of course, those "shoulds" in the last sentence are obvious areas for implementation flaws. But contrast that to your chipless magstripe card: Anyone who obtains your card can use it. No passwords, no encryption, no security whatsoever.
You are saying that somehow the physical security is better than with cards?
The physical security of your magstripe cards is nearly irrelevant to the security of your credit account. There are many ways for someone to steal from your account without having your card.
The amount of fraud that is enabled and actually carried out due to the fact that magstripes provide zero security is on the order of tens of billions of dollars per year. Every time you use your card, you risk the stripe being copied and your card being replicated (this is called "skimming" in the industry lingo).
So yes, an NFC-enabled phone will be far, far more secure than what you use now. There will undoubtedly be flaws, and fixes, and flaws, and fixes, but the net result of that security arms race will be less fraud.
Pardon me if I remain skeptical.
Skepticism of security technology is good. Preferring no security over imperfect security is foolish.
Regardless of what hardware is either in the phone or in the terminal, NFC still has to do handshakes, ACKs, and send financial transactions over RF... and it will be sniffable. Will the encryption and security be up to the task? I am doubtful. Not because the cryptography is weak, but because there is nearly always some kind of flaw in the implementation.
This is technology that has been deployed for millions of users for years now, including in contactless form. To date, the only significant flaw that has been found is the offline PIN verification attack against the UK chip & PIN implementation. That flaw really sucks, and it boggles the mind that it could have slipped through, but even with that flaw there is far less card-present fraud in the UK than in countries without this technology.
Skepticism is well and good -- especially where security is concerned -- but this is proven technology. It's not perfect, but it's definitely good enough. And it's orders of magnitude more secure than magstripes.
Mobile handsets are well on their way to becoming general-purpose computing platforms, with all of the security problems that entails. I think we have reason to be hopeful that it won't get as bad as Windows-based PCs are, but the fact is that the security of the handset is never going to be something we can really rely on.
To me, that means that if we want to use them for payment, we need to have a device in the phones which can securely store and use cryptographic keys, and contain and execute software that can be trusted to make appropriate security decisions. NFC is almost* exactly what's required for that, because the NFC chips are smart card chips -- small 8 or 16-bit computers in packages that have been specifically designed for years to resist intrusion. Are they perfect? No, nothing is. But they are the result of a decades-long arms race between attackers and designers, and they really are pretty darned secure. When competent security engineers who accurately understand their security strengths and weaknesses craft solutions and protocols using them, the result is orders of magnitude more secure than the main processor on a mobile handset.
I don't really care whether you use RF or audio or direct electrical connection to facilitate communication between reader and phone, to make it anything like secure you need a secure processor to handle the crypto. So you need the chip, period. But that's okay, because the incremental cost of an NFC chip added to a mobile phone is trivial.
And if you're adding an SE (or even just upgrading the SIM to make it featureful enough to handle the payment ops), the cost of the additional RF hardware needed by NFC is practically irrelevant, so why not do RF? I know Zoosh says this ultrasonic thing works in noisy environments -- but I'm really skeptical that it works in noisy ultrasonic environments. I'm also skeptical about the claimed low cost of merchant terminals, especially given that NFC-capable devices are already being produced in volume.
* The reason for my hedge "almost" is that I/O still has to pass through the main handset. In the case of communications with various back-end servers, whether via NFC or the cellular network or audio or whatever else, that's mostly okay because those back-end servers can have HSMs and do end-to-end security with the SE. "Mostly", because we'll still need the handset to provide the UI for users to authenticate, approve transactions, etc. What would really be awesome is if the phone had a mode where the SE could take control of the UI and cut the main handset OS out of the loop -- and maybe also have an LED on the phone that is hard-wired ONLY to the SE so that when that light is on you know the SE is in control. But there are many, many reasons why that is infeasible with current-generation SEs, and those coming for the next few years. And when it does become possible, the increased level of software complexity will undoubtedly come with exploitable security defects. It's a hard problem.
Still, even without my ideal situation, the result of combining an SE, well-designed protocols and a handset UI/network, etc. will provide a huge increase in security vs current electronic payment systems.
Even if your strategy wasn't impractical, what would make you think that Google would want to make Java public domain?
I don't think Google would make the Java tools and libraries public domain. I think Google would release them under an MIT-style open source license, as they've done with the Go language.
This is not a test case for the GPL, it's a straight-forward copyright violation case
The really clever bit about the GPL is that any test case is a straight-forward copyright infringement case. People who violate the GPL find themselves in the unenviable position of having to try to use the GPL to justify their actions, because it's the only thing that gives them any shred of permission to use the code. All it takes, then, is for the court to evaluate the situation and realize that the GPL didn't actually give them permission because they didn't meet its requirements.
Ah, thanks. Not a NOP, then. And I'm all in favor of minimizing federal regulatory scope. With rare exceptions (those whose interstate nature makes it impossible for states to address) crime is and should be primarily a state-level issue, and this is particularly true when the crime in question is one that people actively debate.
Hmm. I thought it already was up to the states. Was there a federal statute I wasn't aware of?
So, in summary, it is not a good idea to rely on physical theory, which has the status of Hypotheses when it comes to practical implementations, when we have actual mathematical theory (which is still hard fact when implemented digitally) that already solves the problem well.
Except that we don't really have "actual mathematical theory", either. No one currently knows how to factor products of large primes efficiently, but it has not been proven that integer factorization is NP-complete, nor are we entirely sure what NP-completeness means (c.f. P=NP). Worse, we haven't even proven that factorization is the only way to defeat RSA -- it's possible there's another way. Finally, RSA and other asymmetric ciphers also suffer from practical implementation issues. RSA in particular is very vulnerable to side-channel attacks like power analysis and thermal analysis. There are many other known weaknesses that we know how to work around (e.g. chosen ciphtertext attacks, which are defeated by using optimal asymmetric encryption padding -- though the original version of OAEP has proven to have some weaknesses, addressed by newer versions), and there are undoubtedly many weaknesses that we don't yet even know about.
I'm not knocking RSA, DSA, El-Gamal, ECC, etc., they are very valuable tools. But to say that this shows they are inherently better than quantum crypto is nonsense. Security is just plain hard. The ONLY cipher that we have real, solid mathematically-provable reasons to trust is the venerable one-time pad, and even THAT has proved in practice to be less than perfectly secure due to implementation errors (c.f. Venona).
This law makes it legal everywhere... except where state legislatures or voters vote to make it illegal. So all of the states that already ban it will vote to ban it (or maybe they'll just argue that having already banned it they have already made the vote and don't need another), and all of those that allow it will continue to allow it. Net effect, zero.
I don't really care about on-line gambling one way or another, but it seems silly to waste time and effort on a law that will ultimately change nothing. I suspect that the Representative's intent was to legalize it everywhere, period, using the fact that federal law overrides state laws, but had to insert the opt-out provision as a compromise to mollify opponents, but the net effect is to make the bill pointless.
Most importantly there is not renewable technology that will create the base load.
Sure there is... hydro provides an awesome base load generation capacity, and there are a lot more places you can build dams than geothermal plants.
Of course, most of the people who hate nuclear power hate hydro as well.
I agree hydro is the most viable of renewable technologies, but in the developed world anyway most of the available hydro sites have already been taken. I doubt there is much expansion in hydro. Thats before the issues of erosion etc are considered
In the mountain west of the US (where I live), there are plenty of sites for more hydro power, but it's politically infeasible to use them, both because of the opposition of groups like the Sierra Club and because in many case it would require moving small towns. Most of the towns in question are *very* small -- less than a thousand people, often less than a hundred, but the combination of the residents' complaints and the backing of people who oppose building dams on principle means that it's unlikely the US will ever build another significant dam.
In some places we could add hydro generating stations that tap flowing rivers without a dam, but those are less effective and less reliable.
All in all, I'd say that your bottom line is 100% correct -- in the developed world the hydro we have is basically all we're going to get. Any growth in renewable power generation has to come from solar, wind, waves and geothermal. IMO those can't provide the generation capacity we require, not without significant technological breakthroughs in both generation and storage.
However, I was pointing out that Stallman's contributions were not just physical but philosophical.
Umm, the GP's point was that Stallman wrote GCC and GNU EMACS. How is that not a physical contribution?
Most importantly there is not renewable technology that will create the base load.
Sure there is... hydro provides an awesome base load generation capacity, and there are a lot more places you can build dams than geothermal plants.
Of course, most of the people who hate nuclear power hate hydro as well.
Provided you're on an operating system that supports user accounts, which to my understanding means a PC. Do Apple's iPad and the various Android tablets support user accounts yet?
You can associate search setting with Google accounts, and even have multiple Google accounts logged in and switch quickly between them... just click on the little drop-down in the upper right corner and click "Switch Accounts" to choose which account and settings you want to use. So you don't necessarily need OS-level accounts.
Please bear in mind that most of the funding and the weapons for the Drug Cartels come from the US.
http://online.wsj.com/article/SB10001424052702304259304576375961350290734.html
If you read the article carefully, the claim that most of the weapons come from the US isn't true. In particular:
The ATF figures show that 21,313 firearms recovered in Mexico in 2009 were submitted for tracing by the agency. Of these, 10,945 were manufactured in the U.S. and 3,268 were imported into the U.S. from third countries before ending up in Mexico. The origin of 7,100 firearms couldn't be determined.
Of 7,971 firearms recovered in Mexico in 2010 and traced by ATF, 4,186 were manufactured in the U.S. and 2,105 were imported into the U.S. The origin of 1,680 firearms couldn't be determined.
Collectively, the data show that of the 29,284 firearms recovered in Mexico in 2009 and 2010 and submitted to the ATF for tracing, 20,504 or 70% passed through the U.S. at some point. The period is the most recent for which data are available.
The ATF said it traced the guns based on information provided by Mexican authorities. The Mexican government doesn't submit every firearm it recovers for tracing.
If you do a search for articles from previous years, they actually gave the total numbers of guns collected by the Mexican authorities, not just the number submitted to the ATF. The Mexican government only has the ATF trace the guns that appear likely to have originated in the US. These are mostly semi-automatic rifles and handguns, because fully-automatic weapons -- which are much more highly prized by the cartels -- are not available on the US market except in very small numbers and for very, very high prices (usually 15 to 20x their normal value). So all of the full-auto AK-47s, the grenade launchers, the RPGs, the various light and heavy machine guns, the small artillery pieces... none of that stuff is sent to the ATF for tracing because everyone knows it couldn't have come from the US. And that stuff accounts for the vast majority of weapons collected. IIRC (I suppose I ought to look it up myself), roughly 30% of guns recovered by Mexican officials are submitted for tracing. Of those submitted, about 2/3 are from the US, which means the total percentage of US guns among those recovered is about 20%.
But even the 20% figure is misleading. The vast majority of those are the least dangerous of the guns used by the cartels -- semi-automatic handguns. Of the few full-auto rifles, nearly all of them come from one of two sources -- the Mexican military, who purchased them from the US, and the ATF through their "Operation Gunrunner", which Congress is investigating.
So on the gun side, no, most of the weapons aren't from the US, only about a fifth of them are, and even that overrepresents the contribution of US guns to Mexican violence. The reason for this is obvious: Given all of the actual military arms available on the international black market and all over South America, cartels can buy more and better guns for less money elsewhere.
On the money side, you're absolutely right. The US drug markets are the reason the Mexican cartels exist in the form they do.
I'm pretty sure Google has the Chrome trademark. Since the maker is suing because their "Chromium" is too much like "Chrome"
For that matter, I'm pretty sure Google owns the trademarks on Chromium and Chromium OS as well.