I wrote a week or so back about the failure of liability sharing and the consequent failure in market information. In that case, it circulated around the expectation that the banks have to back up the consumer every time something goes wrong. Is the TJX case enough to trigger the long awaited pass-on of liability to the other parties who share some responsibility?
Chris at EC points to Storefront:
Following lawsuits in February against some of the nation's largest retailers for illegally revealing too much credit card information on printed receipts, two of those retailers are now suing their POS vendors.In the initial lawsuits filed early this year, some 50 of the nation's top retailers... were accused of printing full credit numbers and expiration dates on printed customer receipts, violating a provision of the Fair and Accurate Credit Transactions Act (FACTA) ...
In the last couple of weeks, two of those retail defendants—Charlotte Russe and Shoe Pavillion—have sued their POS vendors, saying that the retailer relied on them and if the retailer is liable, then the POS vendor should pay for it.
Is this a good thing? I think, yes. The alternates are not good: the vendor has no liability for actions, a law is passed that suits nobody, and things get worse.
Nick commented "Let the suing begin!" Better to suck up some court time and create an environment where -- no matter how small -- a vendor of security stuff has to work *with the customer's and the end-customer's risk model* and also take on some of the liability when it goes wrong.
Posted by iang at May 2, 2007 11:24 AM | TrackBackfor some topic drift ... having worked on the original payment gateway using SSL to "hide" payment related information as fraud countermeasure (for what has since come to be called electronic commerce)
http://www.garlic.com/~lynn/subnetwork.html#gateway
but then got involved in x9a10 financial standard working group that in the mid-90s had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments.
http://www.garlic.com/~lynn/x959.html#x959
one of the things looked at in x9a10 is defining x9.59 financial standard protocol to eliminate risk/fraud associated with exposure of things like account numbers, expiration dates, etc. recent post noting that eliminating the risk associated with exposing account numbers and expiration dates ... somewhat obsoleted the earlier work on electronic commerce that used SSL cryptography to hide the same information.
http://www.garlic.com/~lynn/2007i.html#65
which also goes back to long series of posts started here with regard to the naked payment/transaction metaphor
(i.e. naked transactions tend to require quite a bit more hiding and protection than transactions that are more robust and armored)
http://www.garlic.com/~lynn/subintegrity.html#payments
then there is the somewhat related recent posts that somewhat raises the question whether or not some of the fraud problems is because of semantic confusion attempting to understand what various security procedures actually accomplish
http://www.garlic.com/~lynn/2007i.html#74
http://www.garlic.com/~lynn/aadsm26.htm#65