Note that in the Target exploit, only encrypted PIN codes were harvested.
I may have written that a bit awkwardly. What I meant that the PIN codes that were harvested were all encrypted; not that only PIN codes were harvested.
Clearly you have a good understanding of the issues with EMV.
I was only talking about the "black box" nature and liability shift of EMV (in the context of TFA and the GP).
The EMV (chip and pin) box handles encryption completely within the box, thus making it a "black box" in the way the GP was talking about. TFA talks about using memory scanner malware to read card data (and assumingly PII). The black box nature of the EMV box mitigates this threat very well, unless the manufacturer does something really stupid like running XP Embedded or something like that. But more likely this box is running some RTOS or an OS that can not easily have malware injected into it.
The POS systems that currently read credit cards using USB card reading apparatus are extremely vulnerable, which is the point of TFA. Going to EMV takes the card/PIN encryption out of the realm of this particular vulnerability. Note that in the Target exploit, only encrypted PIN codes were harvested. That's because the encryption of debit card PIN codes is done via a separate "black box" PIN pad. So I don't think that there is any question that moving the encryption outside of the retail POS itself is a net gain to security and privacy. It also reduces skimming itself by having the card in the hands of the merchant staff much less, if at all.
In 2015, EMV becomes required in the US. Those retailers who don't black box their card readers will be 100% liable for fraud at their point-of-sale (including stolen cards).
If he's already helped enough to get from 124 years down to possibly "avoid jail completely", what will happen if they have "more use for him"? They should start paying him. A lot.
They don't need to be sued. Their merchant agreements make them liable for fraudulent charges and a fee for each card that has to be reissued. It will be in the billions, for sure.
- Improve additional checks to detect jailbroken devices - Obfuscate the assembly code and use anti-debugging tricks to slow the progress of attackers when they try to reverse engineer the binary
These two will be useless, and easily defeated. "Slowing the progress of attackers" is a meaningless statement in this context. Jailbreak detection is easily tricked, or removed from the code by a jailbroken phone.
Aside from that, if you do all of the other things they suggest correctly (as should have been suggested to the programmers in CS 101), you shouldn't need these two.
As others have said here, encryption from sender to receiver (including all hops in between) is what's really important, and would render encryption at the web/IMAP/POP level unnecessary. SMTP is used between all hops (unless, I assume, a message originates and ends at the same server), and survives from the early days of network computing when all of us who were on the net knew each other. It should not have survived to a public Internet, for reasons that became obvious pretty quickly.
Lack of security and spam are a direct result of the way SMTP works, and our youth is already moving to private "e-mail" infrastructures like Facebook and other social messaging private/direct messaging, so this won't be a problem for much longer. In a paper I wrote in 2007 I predicted the mass exodus from e-mail to social media messaging for these very reasons.
When my Tesla was delivered in 2012, I signed a "Data Usage Agreement" that essentially said that they would be collecting all of my data, all of the time, and using it for whatever they wanted (sort of).
I don't know what would have happened if I refused to sign that particular document, as and far as I know, every Tesla owner signed it.
From the day W7 came out, many XP users had no upgrade path; at least those who were smart enough to have not upgraded to Vista. You can't (and never could) perform an upgrade from XP to W7. You had to go through Vista first, or do a complete reinstall. I believe that was a deterrent for many.
Drew Carey used to tell a joke about how he loved to make cops get out of their cars in the rain, and he used to run stop signs just to see them do it: "Officer: Do you know why I pulled you over? Carey: Yep! Do you know why I ran the sign?"
From TFA: "... the Association says that purchase prices on Tesla's website routinely include a $7,500 federal TAX CREDIT, despite the fact that the Congressional Budget Office states that only 20 percent of shoppers qualify for the alternative vehicle credit."
The only "qualifications" necessary are: 1) You would otherwise be paying at least $7,500 in taxes for the year. (For those not informed about such things, this includes what is withheld from your paycheck)
2) You buy the car new
3) You keep the car for a year
I profer: 1) 99% of those spending this much money on a car has a $7,500 tax bill
2) The other 1% are just cash-rich and it won't bother them that the final bill will be $7,500 higher
I assume that when the Congressional Budget Office states that "only 20 percent of *shoppers*" qualify, they are talking about shoppers for Electric Vehicles in general; not specifically Teslas.
Getting back to TFA, isn't much of the "dirty" portion of nuclear plants front loaded? If so, you want to keep the plant open as long as possible in order to mitigate this "cost"; not shut it down so quickly. By doing so they did a disservice, in terms of net CO2 output, and helped make Nuclear energy "look" less clean.
That's not what it says. It says that we have agreements to protect the privacy of those other countries. It doesn't say anything about sharing information with them
When I first read the summary I thought Google was going to provide me a way to manage my own keys in a practical sense. I would like for my browser to automatically decrypt when I download from Google Drive using private keys stored on my local store (with a pass phrase, of course).
Slashdot Mirror
Note that in the Target exploit, only encrypted PIN codes were harvested.
I may have written that a bit awkwardly. What I meant that the PIN codes that were harvested were all encrypted; not that only PIN codes were harvested.
Clearly you have a good understanding of the issues with EMV.
I was only talking about the "black box" nature and liability shift of EMV (in the context of TFA and the GP).
The EMV (chip and pin) box handles encryption completely within the box, thus making it a "black box" in the way the GP was talking about. TFA talks about using memory scanner malware to read card data (and assumingly PII). The black box nature of the EMV box mitigates this threat very well, unless the manufacturer does something really stupid like running XP Embedded or something like that. But more likely this box is running some RTOS or an OS that can not easily have malware injected into it.
The POS systems that currently read credit cards using USB card reading apparatus are extremely vulnerable, which is the point of TFA. Going to EMV takes the card/PIN encryption out of the realm of this particular vulnerability. Note that in the Target exploit, only encrypted PIN codes were harvested. That's because the encryption of debit card PIN codes is done via a separate "black box" PIN pad. So I don't think that there is any question that moving the encryption outside of the retail POS itself is a net gain to security and privacy. It also reduces skimming itself by having the card in the hands of the merchant staff much less, if at all.
As far as the liability shift, here's a citation:
http://www.firstdata.com/downloads/thought-leadership/EMV_US.pdf
In 2015, EMV becomes required in the US. Those retailers who don't black box their card readers will be 100% liable for fraud at their point-of-sale (including stolen cards).
I'm just saying that if whatever he gave them is worth over 100 years it must have some incredible value. Somewhat tongue in cheek.
(Oops...on a different computer and forgot to login).
Perhaps you remembered because they spoofed the commercial in the (epic) movie "Airplane!"
If he's already helped enough to get from 124 years down to possibly "avoid jail completely", what will happen if they have "more use for him"? They should start paying him. A lot.
"That's funny: rmdingler never has a third cup of coffee at home."
Doh... spies nowadays.
I was told the KGB spies, under no matter the circumstances, were trained and able to break the speed limits in secret.
In Soviet Russia, speed limit must break you!
They don't need to be sued. Their merchant agreements make them liable for fraudulent charges and a fee for each card that has to be reissued. It will be in the billions, for sure.
I agree with all of them, except:
- Improve additional checks to detect jailbroken devices
- Obfuscate the assembly code and use anti-debugging tricks to slow the progress of attackers when they try to reverse engineer the binary
These two will be useless, and easily defeated. "Slowing the progress of attackers" is a meaningless statement in this context. Jailbreak detection is easily tricked, or removed from the code by a jailbroken phone.
Aside from that, if you do all of the other things they suggest correctly (as should have been suggested to the programmers in CS 101), you shouldn't need these two.
As others have said here, encryption from sender to receiver (including all hops in between) is what's really important, and would render encryption at the web/IMAP/POP level unnecessary. SMTP is used between all hops (unless, I assume, a message originates and ends at the same server), and survives from the early days of network computing when all of us who were on the net knew each other. It should not have survived to a public Internet, for reasons that became obvious pretty quickly.
Lack of security and spam are a direct result of the way SMTP works, and our youth is already moving to private "e-mail" infrastructures like Facebook and other social messaging private/direct messaging, so this won't be a problem for much longer. In a paper I wrote in 2007 I predicted the mass exodus from e-mail to social media messaging for these very reasons.
Sorry, I meant that I don't know how to opt out after the fact.
When my Tesla was delivered in 2012, I signed a "Data Usage Agreement" that essentially said that they would be collecting all of my data, all of the time, and using it for whatever they wanted (sort of).
I don't know what would have happened if I refused to sign that particular document, as and far as I know, every Tesla owner signed it.
I know of no way to opt out.
Ever since FB stopped listing FS checkins [snip]
FB still quotes my FS checkins and I've never had a problem with it.
From the day W7 came out, many XP users had no upgrade path; at least those who were smart enough to have not upgraded to Vista. You can't (and never could) perform an upgrade from XP to W7. You had to go through Vista first, or do a complete reinstall. I believe that was a deterrent for many.
The NSA *is* the "next attack". It's an enemy combatant's dream. They have succeeded beyond their wildest dreams.
Drew Carey used to tell a joke about how he loved to make cops get out of their cars in the rain, and he used to run stop signs just to see them do it:
"Officer: Do you know why I pulled you over?
Carey: Yep! Do you know why I ran the sign?"
From TFA:
"... the Association says that purchase prices on Tesla's website routinely include a $7,500 federal TAX CREDIT, despite the fact that the Congressional Budget Office states that only 20 percent of shoppers qualify for the alternative vehicle credit."
The only "qualifications" necessary are:
1) You would otherwise be paying at least $7,500 in taxes for the year. (For those not informed about such things, this includes what is withheld from your paycheck)
2) You buy the car new
3) You keep the car for a year
I profer:
1) 99% of those spending this much money on a car has a $7,500 tax bill
2) The other 1% are just cash-rich and it won't bother them that the final bill will be $7,500 higher
I assume that when the Congressional Budget Office states that "only 20 percent of *shoppers*" qualify, they are talking about shoppers for Electric Vehicles in general; not specifically Teslas.
Getting back to TFA, isn't much of the "dirty" portion of nuclear plants front loaded? If so, you want to keep the plant open as long as possible in order to mitigate this "cost"; not shut it down so quickly. By doing so they did a disservice, in terms of net CO2 output, and helped make Nuclear energy "look" less clean.
That's not what it says. It says that we have agreements to protect the privacy of those other countries. It doesn't say anything about sharing information with them
How much negotiating did Israel have to do to get our Telexes included in this?
How much do you want to bet?
Why yes, I do. And that means that at least my good friends and I are in good shape :-)
>Do we dare trust the browser?
If it's open source and I compile it myself, Yes I trust it.
When I first read the summary I thought Google was going to provide me a way to manage my own keys in a practical sense. I would like for my browser to automatically decrypt when I download from Google Drive using private keys stored on my local store (with a pass phrase, of course).