71–80 of 84 posts
Earlier quoted context omitted.
@cperciva – it is and it isn't. Implicit vs explicit. This answer expands: http://stackoverflow.com/a/3978372
This reminds me of the WAT talk. It's also crazy enough that I wouldn't want to trust that every browser in the world will always share that same behaviour.
http://www.whatwg.org/specs/web-apps/current-work/multipage/...
Earlier quoted context omitted.
I think highly of you, but my irritation here has more to do with being shouted down about getting crazy third party JS services off banking applications than it does with who runs this particular static iframe. I think this issue is LITERALLY this simple: people are accustomed to third-party applications that work by "just copy this tiny snippet of JS code into your layout template", and all the cool kids do it, so…
Agreed, people are far too casual about dropping random javascript into their web sites. (I tried to make this point last year when I blogged about how Iran should have forged an SSL certificate for ssl.google-analytics.com instead of *.google.com, but that blog post didn't get much attention sadly.)
It surely gives food for thought.
If I was Stripe I'd be politely asking you to take this down. It's using their trademark (presumably) without permission and encouraging their users to do something very inadvisable. Offering to host this seems like a really bad idea. I know you're well meaning and trustworthy, but this shouldn't be run by a third party. For long term reliability reasons as much as security.
I showed it to people at Stripe before announcing it.
Stripe is meant for developers, and it is quite easy to integrate using their javascript api. If you can code a form you write basic javascript you can integrate stripe.
Exactly. Stripe is probably one of the easiest integrations I've ever done. In fact, their tutorials are so well written and their signup so frictionless that I'd say that any interested website creator should have little trouble setting up a form actually using stripe instead of an iframe.
Please don't use this. There is nothing stopping paymentiframe.com from taking your customer's credit card numbers.
By using this, you're saying that you trust cperciva more than you trust Stripe. I'm confident that neither are going to try and deliberately steal your credit card numbers. But furthermore, you are saying that cperciva is going to protect paymentiframe.com from hacks better than stripe is going to protect theirs. Myself, I'd place a lot of trust on cperciva, the former FreeBSD security officer, a guy who has written…
Sure, but you can just compare the two sites' external measures of security, and they're not even close.
Stripe domains:
- Pass optional HTTP security headers (like X-Frame-Options on manage.stripe.com)
- Are pinned to Chrome's HSTS list (http://src.chromium.org/viewvc/chrome?view=rev&revision=...) and pass a Strict-Transport-Security header
Earlier quoted context omitted.
By using this, you're saying that you trust cperciva more than you trust Stripe. I'm confident that neither are going to try and deliberately steal your credit card numbers. But furthermore, you are saying that cperciva is going to protect paymentiframe.com from hacks better than stripe is going to protect theirs. Myself, I'd place a lot of trust on cperciva, the former FreeBSD security officer, a guy who has written…
> Myself, I'd place a lot of trust on cperciva Sure, but you can just compare the two sites' external measures of security, and they're not even close. Stripe domains: - Pass optional HTTP security headers (like X-Frame-Options on manage.stripe.com) - Are pinned to Chrome's HSTS list ( http://src.chromium.org/viewvc/chrome?view=rev&revision=... ) and pass a Strict-Transport-Security header
I feel like Colin built this little thingy to solve a real problem --- that by adding Stripe to his site, he was giving Stripe control over his site, and his site hosts information more sensitive than credit cards --- and people are piling on because his solution to his little problem doesn't solve every other imaginable security problem.
This would be less galling if the kinds of sites using Stripe today weren't almost uniformly rife with application security flaws that defeat most of the good intentions that Stripe has.
http://www.wepay.com/api