←back to thread

1134 points mtlynch | 4 comments | | HN request time: 0.09s | source
Show context
mtlynch ◴[] No.22936825[source]
Author here. Happy to answer any questions or hear feedback about this post.
replies(4): >>22937478 #>>22937646 #>>22937672 #>>22938279 #
TAForObvReasons ◴[] No.22937646[source]
Have you tried sequestering the payment logistics to a separate domain or subdomain? If you had a pay._____.com that processed payments using Stripe.js, and that redirected back to app._____.com (which would not be using stripe.js), would tracking continue into your app pages?

EDIT: didn't expect this to be so controversial (6 downvotes!)

replies(1): >>22937768 #
1. mtlynch ◴[] No.22937768[source]
That was one of the solutions I considered. I believe that would successfully limit Stripe's tracking, but it's just logistically complicated to stand up a whole second app just to serve one page and manage state between the payment app and my main app.
replies(1): >>22940721 #
2. somishere ◴[] No.22940721[source]
Could you simply use an iframe with a sandbox attribute? Idea being you dynamically create an iframe, fill it with content (styles, postmessage scripts, what have you), then dynamically set a semi-restrictive sandbox before loading Stripe's library. When you're done (i.e. have a payment token in the parent) just remove the iframe. This way everything Stripe related is sandboxed and the script is unloaded as soon as you're finished with it.

Good chance I'm missing something, or there's some kind of protections in place around this.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...

replies(1): >>22940823 #
3. mtlynch ◴[] No.22940823[source]
That was another solution I considered. I think that would work, but it seemed expensive to implement. I believe it would still require me to host a separate copy of my app or a standalone app that handles just payments. Stripe also creates its own child iframe for displaying payment UI, so at that point, my app would look like:

  Main app
    My sandboxed iframe
      Stripe's iframe
So managing all the bubbling up and down of messages felt like it was going to be complicated. Limiting Stripe to a single page and forcing the new HTTP requests to unload it is a bit hackier, but is really simple to implement. You can see it in the blog post - I only had to add ~5 lines of extra code to my app to make it work.
replies(1): >>22942923 #
4. somishere ◴[] No.22942923{3}[source]
My problem is primarily that I'm working with SPAs where a refresh really lowers the game.

I put together a proof-of-concept using a 'same-domain frame', no secondary domains or apps. The idea is separation over security, so you can unload without any side hustle. Tho without a second domain you're relying on Stripe being as trustworthy as they are, and not looking to actively undermine your sandboxing attempts [which I think is ok - we embedded their library in the first place].

https://codepen.io/theprojectsomething/full/ExVNEoZ