So, you're saying that because Google Analytics could conceivably touch credit card information (using Stripe's JS), it's perfectly fine for some random guy with a suspect domain-name to?
I disagree.
Sourcing static content from a static web server run by a security expert in order to segregate your application's secrets from those of Stripe: TOTALLY IRRESPONSIBLE.
I am not endorsing the use of third-party JavaScript on someone's payment page. I am also not endorsing the use of serving your payment form inside of a third-party iframe hosted on paymentiframe.com. I am not sure why you consider this opinion to be false.
It sure does make the argument simpler to pretend that you can just keep the Olark and Typekit and Optimizer bugs off your payments page and call it a day, but that doesn't actually do anything to protect most sites. Engage instead with my actual argument, which is that for virtually every app using these services, bugging your front page with Olark is even more unsafe than this iframe is.
As in, even if the "evil script" set it's domain to yourdomain.com, unless your pages on yourdomain.com ALSO do
document.domain = 'yourdomain.com';
The script on the subdomain can't access that content.
[EDIT] Whoever is downvoting this, can you demonstrate otherwise?
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/...
Listen, if you don't trust Stripe's JavaScript, just use their HTTP API instead from your server: https://stripe.com/docs/api
The best answer is "don't link to Javascript URLs that you don't control and audit on your website". Nobody likes that answer, but that doesn't make the second-best answer any more meaningful.
Exactly. There's no way I would be serving up third party javascript to a logged-in Tarsnap user, even inside an iframe, if it weren't for the fact that dealing with PCI auditing would irreparably damage my sanity.
Technically, the iframe is dynamic content, seeing as it's generated by a CGI script based on the parameters in the URL. :-)
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 it's not up for discussion. But static content hosting a form in an iframe? THAT'S CRAZY TALK.
It surely gives food for thought.
I frankly trust Colin Percival a lot more than I trust Olark. And I like Olark.
Your point is something Colin should address in his FAQ, and so it was good of you to make it, but it's also trivially knocked down.