Wonder how quickly somebody is going to create one about the downfall of the downfall meme...
250 karma · joined October 27, 2009
The possibility exists for it to be abstracted.
Most were coded before common sanitization and security practices were observed during dev, not to mention built in to frameworks.
"Probably over 100 people came to the YC meetup in Seattle. Crazy success. Note to self: Hackers suck at RSVP'ing." http://twitter.com/webwright/status/9666575618
I couldn't make it, unfortunately.
It's expensive as heck (the smallest instance scalr allows is an EC2 large), but it works great.
Scalr monitors one of several stats you can specify (RAM, CPU, queue size, HTTP response) and will spin up instances (you can specify a max) as necessary.
Granted the app has to be built to support such multiple app servers, which may be easier in some cases than others.
Sounds like the cloud server was rather inconvenient, couldn't handle immediate load, and required your manual intervention. Always tough to predict traffic spikes from Twitter. ;)
Have you had a vulnerability assessment done? Do you protect against SQL Injection? Do you protect against Cross-Site Scripting? How about Cross-Site Request Forgery? What preventative measures have you taken to lock down your servers?
I know most users don't care about all of those and you're trying to be friendly by saying you use "bank-level" encryption, but some more info would be nice for those of us that care.
We ultimately chose to go with recurly, but are going to look at chargify again once they stabilize a little bit. Recurly is not on the list, but in the process of doing so (I just emailed them ~10 minutes ago specifically about being a validated service provider).
Longer answer (disclaimer: I'm a former PCI QSA). You can, of course, do whatever you want to with the credit card data at the risk of not being PCI compliant. Small startups are rarely at risk for a breach, but I'd personally prefer not to be in a position to deal with that liability. As it relates specifically to those companies, they need to apply to be on that list. I know that Recurly is currently working on it and Chargify is still in private beta, so I'm assuming it's something they're working on. That said, I have confidence that some of these companies will "do it right" and obtain PCI compliance/validated service provider status by the time it becomes a legitimate concern.
I've talked to both Recurly and Chargify directly. Recurly is apparently PCI Level 2 compliant and working on the external audit to reach level 1. Chargify is outsourcing storage ( http://chargify.com/blog/adding-payment-gateways-while-maint... ) which addresses a lot of concerns, but I'm not sure if they've gone through the necessary compliance process otherwise. As for CheddarGettar, the only mention of PCI compliance I can find on their site is this - http://support.cheddargetter.com/discussions/questions/39-pc... - which doesn't really indicate an understanding of what is actually required to be compliant. I can't comment on Spreedly as I didn't look at their solution, but I do know one of the devs previously worked at a large PCI shop.
So a service provider like these guys can technically be PCI compliant, but not be on the service provider list if they haven't applied to be. If you use them, though, they best be on the list by the time you reach the point that the PCI assessor (they don't like to be called auditors. ;)) is knocking on your door. This isn't likely to be for a while for most startups, though.
In some of the early data I've seen in a survey I'm doing (shameless plug: http://www.untitledstartup.com/2010/02/payment-security-surv... ), most companies are implementing their own system directly to paypal or similar, but have not actually gone through the process necessary to become PCI Level 4 certified. Most feel that the benefit of keeping the payment flow on their site is more important than the relatively small risk of being compromised. Can't say I agree, but I'm more paranoid than most.
This image on their home page gave me chills, though. http://a1.sqimg.com/static/6c1cc3c1ad109e13d0be182c75c470762...
But that's likely only because I'm a half-paranoid security geek.
Google's is probably the easiest since you can easily just supply a username/password (note: I believe they support OAuth as well, which would be the preferred means of accessing sensitive data instead of asking users for their password) and utilize their contacts API. http://code.google.com/apis/contacts/
When I looked at this several months back, it seemed there had been a few libraries to abstract this at one point, but they eventually gave up. Possibly because the other systems don't/didn't place as nice as google. But there is: http://developer.yahoo.com/addressbook/ and http://msdn.microsoft.com/en-us/library/bb447750.aspx
Head -> Desk
Ah, the risks of developing on top of Twitter.
Not to mention several state and federal regulations depending on the data being uploaded...
It's amazing the number of different things I'm considering using Redis for as well.
Yes, you'd have to then request their profile info so {1:6, other:0.5*dozen}.
Granted, it's easy enough to lookup wifi AP's, but one has to wonder how well this works. ... And if they've had a security evaluation done. ;)