I blame myself for not noticing earlier. Bookshout’s announcement and demo video was a part of the last even of the day at TOCFrankfurt and at that time I was in the back, with my laptop plugged in, finally checking my emails.
So, I missed the video which would have given me a clearer idea of how Bookshout’s importer is supposed to work.
Instead, I, along with many following on twitter, ended up confused as to how they were doing it, wondering what was being pulled in and how. In the end I just figured they were using some sort of bookmarklet-type solution and left it at that.
It wasn’t until the next day that it came up in conversation that Bookshout’s importer asks for the reader’s Amazon account and password.
Still reeling in disbelief I wandered out into the walkways (the only places in Frankfurt’s Buchmesse where the wifi seemed to be working) and checked out the video.
Sure enough, there it was, right in the video. Later I confirmed it in the client itself.
The mind boggles.
Because this is a phenomenally bad idea.
This isn’t like handing over your Gmail address and password to let a service scan your contacts (although that was and remains also a very bad idea).
Amazon is a payment processor. Every single Amazon account is backed by one or more credit cards. Handing over to any third party service your Amazon account and password is like handing your credit card over to a stranger and letting them take it into a back room where you can’t see what they’re doing with it.
Which is to say that it is a Very Bad Idea.
Even if you trust Bookshout implicitly you have no idea how secure their solution is. They may not be storing your details but they use them somehow. We don’t know if they post them to a server where the work is done, whether they cache them to increase the reliability of the process, how secure the password is throughout the process. We don’t know nearly enough for us to decide whether we can trust Bookshout. If they use their own servers as a proxy for the process, then those machines become a prime target for hackers. Compromising them would give them instant access to a host of Amazon accounts and their associated credit cards.
The servers and processes of payment processors like Amazon are audited and vetted. Nobody is auditing Bookshout’s importer. Certainly nobody with experience in securing components that deal with financially sensitive information. Bookshout is a new company with an unproven security track record. Anybody who implicitly trusts that they haven’t made mistakes is being a fool.
Treating Bookshout’s password phishing as a legitimate tactic also trains users into thinking that it is an acceptable tactic in general. The more services that ask for your Amazon login details and get away with it, the easier you make it for criminals to set up fake services (or even real services built specifically to harvest Amazon accounts) to steal those details and misuse them.
We need to make it clear to the public and to the industry that this tactic is both risky and irresponsible. I’d even go so far as to say that the sooner it is stopped the less likely it is to inspire others to make the same mistake.
Updated 13 October 2012.
Jason Illian of Bookhout has replied to some of these points over in the comments on the Tools Of Change blog. I tried to post some of the following in the comments but it hasn’t appeared yet.
He only replied to some of the points, mind you. Not all of them. He doesn’t address the precedence issue (if Bookshout is allowed to do it, others will follow). And, like others, he claims that because you can’t access full credit card numbers through your Amazon account, it must be safe to give them access to it.
Never mind that even revealing the last four digits of your credit card is not really secure.
As far as I know, Amazon has since closed part of that loop by not giving out the last 4 digits of a card over the phone unless they have had some sort of confirmation of identity, but this opens it right up again.
It highlights the real problem: you can’t predict how, exactly, account access will be abused. You can’t tell the difference between innocuous information and sensitive information. Very few can because we never have a full picture of how all of the various services in our lives interact with the information in our lives. It’s the reason why security on the web is such a mess.
(Well, that and the fundamentally insecure design of all web technologies and the complete disregard for security shown by most developers. And a surprising number of people responsible for developing standards and specifications don’t seem to give a hoot either.)
It’s the nature of a payment processor to store sensitive information, not just the credit card number, but also addresses, order histories, and more. That is to say, when security-minded grumps like me talk about credit card info, we aren’t just talking about the credit card number.
That’s without getting into the damage that can be done just using the ecommerce system as other commenters have pointed out.
An Amazon account can be used for anything ranging from ecommerce, to payment on third-party sites, to maintaining and controlling anything on Amazon Web Services.
It simply is not safe under any circumstance to give your Amazon account and password to a third party service. This is an unarguable fact.
Give it to your wife and kids, sure, but not a third party service.
Even if we do trust Bookshout completely and implicitly, letting them ask for Amazon account details normalises the practice. Which means they won’t be the only ones doing it. And users have no way of telling the good actors (like Bookshout) from the bad actors (criminals) from the incompetent actors (which would be most of them). If we condone the practice, users are going to trust them all.
We can’t make exceptions just because we like the people responsible. Bookshout can’t go the Mint route and rely on a host of outside auditing. And, as I understand it, the account aggregation done by Mint is based on that of Quicken’s (they used to use Yodlee, but switched after Intuit bought them) and many banks have historically bent over backwards to support Quicken due to its market share. Both Mint.com’s and Intuit’s track record and focus on security places them in a completely different category and position to Bookshout.
Recent blog posts
- Can we float more indie boats?
- Measure for measure: the Digital Census since 2009
- A chuffed market's Children's Conference: #PorterMeets Charlotte Eyre
- #FutureChat recap: Publishing innovation
- Night of the Social Media: #PorterMeets Jonathan Maberry
- Alta Editions' cookbook innovation recipe
- WhereWereYouThen.com: Mining the memories of Ken Follett's readers
- The FutureBook Innovation Awards are open for business
- #FutureChat recap: Torchin' for books data
- Reedsy: Bending into digital self-publishing
- ISBNs in the aggregate refer to titles
1 week 5 days ago
- A question about ISBNs
1 week 6 days ago
- Not impressed by a data collection argument
2 weeks 3 days ago
- Understanding the reality of bookstore inventories
2 weeks 4 days ago
- Thanks for the input
5 weeks 6 days ago
- In this case, compliance is expensive
5 weeks 6 days ago
- I totally agree with JA Konrath's 12 points
6 weeks 3 days ago
- Tone vs Substance
7 weeks 2 days ago
7 weeks 2 days ago
7 weeks 2 days ago
Tweets from @thefuturebook
TheFutureBook Thanks to all who participated in today's #FutureChat -- Recap next week! t.co/Mk9Tmlms25 @TheBookseller
TheFutureBook One hour to #FutureChat, this week on "opening up to indies": t.co/Mk9Tmlms25 - Join us at 4pBST / 11aET / 3pGMT @TheBookseller
TheFutureBook Come along for our #FutureChat today on "opening up to indies" 5pCEST / 4pBST / 3pGMT / 11aET 8aPT t.co/Mk9Tmlms25 @TheBookseller