CNET ran an interesting article yesterday on how a PayPal dispute ended in the destruction of a violin. In summary, the allegation is that the purchaser disputed the authenticity of his $2,500 puchase, PayPal agreed, and they instructed the purchaser to destroy the violin it in order to obtain a refund.
People are asking a lot of questions about this one, and while I haven’t heard directly from the seller, her letter is posted on Regretse. (The buyer’s identity has not been disclosed.) The dispute appears to focus on the violin label. I’m certainly not qualified to discuss violin labels and associated traditions, but these folks are and have something interesting to say.
I was a bit surprised to hear that PayPal had the instrument destroyed rather than returned to the vendor, but I found this in PayPal’s user agreement:
If a buyer files a Significantly Not as Described (SNAD) Claim for an item they purchased from you, you will generally be required to accept the item back and refund the buyer the full purchase price plus original shipping costs. You will not receive a refund on your PayPal fees. Further, if you lose a SNAD Claim because we, in our sole discretion, reasonably believe the item you sold is counterfeit, you will be required to provide a full refund to the buyer and you will not receive the item back (it will be destroyed). PayPal Seller protection will not cover your liability.
Merchants take heed — “in our sold discretion” gives PayPal at lot of power.
In response to my query, a PayPal spokesperson replied via email,
A lot of small businesses rely upon PayPal, and this type of incident causes concern among merchants. For example, one commenter on Regretsy pointed out,
This scheme of PayPal’s makes a great way to perpetuate fraud. Want to swap the fake Vuitton bag you bought on Canal Street for a real one? Just buy that real one on eBay, pay through PayPal and report the ‘fake’!
Credit card transactions in general place the burden of proof on the merchant. For example, if I ordered goods and subsequently advised the credit card issuer that the product didn’t arrive, the merchant would face a chargeback unless they were able to provide strong evidence to the contrary. PayPal adds an additional layer. If a buyer who has purchased through PayPal using a credit card is not satisfied and disputes the charge through their credit card issuer, the burden of proof falls to PayPal.
My point is not to excuse PayPal of their responsibilities. They’re in the payment game and need to treat all parties fairly as well as manage their own risk. However, it’s also not fair to assume that these type of disputes or the potential for merchant losses are specific to PayPal. It’s also not realistic for sellers to assume that PayPal will protect them from all potential fraud scenarios.
I’m happy to see PayPal take a strong stand against counterfeit goods, but I just wonder if destroying a violin — even if the label was wrong — was the right answer in this case. I suspect executives at PayPal are asking that same question.
Brian Krebs has a great article on his blog about the recent cyber attack on a city water utility in Illinois. Wired and others have also been covering the story as it evolves. I’m not going to rehash the news. Who did it might perhaps be marginally interesting, as might be their motive. While I’m not suggesting we excuse criminal behaviour, burning out a water pump by turning it on and off is most certainly not the worst thing one could do upon seizing remote control of a water facility.
For those new to the topic, the security of Supervisory Control and Data Acquisition (SCADA) systems has been a concern for years. For example, Andrew Hildick-Smith’s 2005 paper discusses Security for Critical Infrastructure SCADA systems. I’m not convinced that I completely agree with Mr. Hildick-Smith’s approach, but the fact that he wrote this paper as a practical assignment for a security certification back in 2005 illustrates that this problem is certainly not unknown.
Assuming reports are correct and that an intruder was able to hack into a SCADA system from outside, this incident is another example of how basic security fundamentals are being ignored in the critical infrastructure sectors. Given the current state of SCADA systems, neither the devices nor the computers that control them should be accessible from any other network, and they also require protection against insider threats. The risk is simply too high.
The net is buzzing about Stuxnet variant ‘duqu’. Let’s put it in perspective.
Stuxnet received a lot of attention because it was the first publicized case of malware targeting a physical control system, and anything that touches a nuclear reactor is a big deal. But this type of threat certainly wasn’t unforceen. The potential for malware and other network-centric threats to impact SCADA systems has been discussed within the security community for years. Stuxnet was simply the first to capture the spotlight.
The source code has been widely available online since July, so it’s no surprise that derivatives are starting to appear. Cyber criminals of all sorts have undoubtedly downloaded, modified, and experimented with it. The vast majority of malware created today is simply a derivative of existing malware; those capable of creating something completely new are far and few between. This new variant, code-named ‘duqu’, is probably the work of an individual or small group. A government or large criminal organization would not rework the Stuxnet code. They’d study it, learn from it, and then create something completely different to avoid detection.
Organizations with SCADA systems should be concerned about a much broader range of threats rather than focusing on Stuxnet or duqu. They need to ensure that their systems are adequately protected against malware and a long list of other insider and outsider threats.
More generally, rather than focusing on specific peices of malware, we should be asking why we continue to build systems that, from a security perspective, are fundamentally flawed. We continue to make the same mistakes over and over again, and then we’re surprised when a security breach occurs.
Microsoft issued 13 security bulletins that address 22 vulnerabilities. Out of these vulnerabilities, three are rated critical by Microsoft.
“The DNS vulnerability could result in a complete system compromise,” said Joshua Talbot, security intelligence manager, Symantec Security Response. “Because no user interaction is needed, a vulnerable service simply needs to be up and running for the vulnerability to be exploited.”
“Internet Explorer is affected by two critical vulnerabilities being patched, both of which can be exploited by a drive-by download,” Talbot added. “The fact that vulnerabilities such as these continue to be so common is one reason why web-based attacks are so prevalent. There is a very large attack surface.”
“We haven’t seen nearly this many low profile patches – ones that primarily result in information-disclosure or cause denial-of-service conditions – in quite some time,” Talbot concluded. “Half of all the vulnerabilities patched this month are of that type, which is rare.”
According to the BBC, “Android phones are potentially leaking data that, if stolen, could be used to get the information they store online.” Researchers have discovered that the authentication tokens used to access Google services are sent in the clear and are subject to theft and unauthorized use.
Google has apparently made changes to fix part of the problem. Android users should update their phones as soon as possible.