4 ms·

> charge-control.js was the front-end JavaScript that users add into their existing checkout page. It essentially just monkey patches You can't do that. Essent

> charge-control.js was the front-end JavaScript that users add into their existing checkout page. It essentially just monkey patches You can't do that. Essentially you advocated using a man-in-the-middle library. Running that running javascript client-side would completely break PCI compliance. Stripe literally couldn't stop you from operating, but they could break integration with you (i.e. not allow you to collect money via their own API). They could also refuse services to anyone who used your middle-man application. What you should have done instead is have a backend application that operates after the token is created. Once you have a token, do fraud scrubbing and throw away the token if it fails. You can't break PCI compliance, if you do, then you open yourself, your clients, and everyone else on the chain who knew you existed and did nothing to litigation----or worse, simply being banned by VISA, thus dying completely as a company. I've known a few payment processing companies who inadvertently went against a regulation, and VISA banned them for life. It's a monetary death sentence, and VISA tends to track everyone associated with building the company and refusing to work with them in the future too because it is seen as risky. I don't really blame Stripe for seeing "client side javascript" then immediately burning any bridges.

nodesocket 10y ago
Back up. I never transmitted any credit card details. All the inputs were heuristics about the end-user (ip address, GeoIP location, user-agent, referer, language, etc) or transaction meta-data (price, etc). Card number, expiration, CVV were NOT part of the inputs in Charge Control.
- grecy 10y ago
  > I never transmitted any credit card details. PCI compliance is only partially concerned with transmitting CC details, and is very much concerned with "YOU SHALL FOLLOW THE RULES". The rules say you are not allowed to do what you were doing. It's completely irrelevant if what you were doing is not a security or data transmission issue, it's simply against the rules. PCI compliance is an absolute nightmare, and is not something to be reasoned with, trust me. Logical thought and analysis has no place in PCI compliance. Follow the rules or else.
  - smallnamespace 10y ago
    > Logical thought and analysis has no place in PCI compliance. Only at a local level. If you're writing standards that are going to be rolled out to the whole world and are difficult to change, and where the potential downside is people losing a lot of money, then a 'better safe than sorry' heuristic is the correct choice. Monkey-patching into your payments library at runtime certainly doesn't seem like a 'safe' practice that PCI ought to endorse at all. It's essentially impossible to write a standard that perfectly anticipates every edge case. And if it were possible, the list of rules would be even longer and more difficult to follow.
  - ThatGeoGuy 10y ago
    I wonder if in part PCI compliance is designed this way as to avoid details or holes in the overall system from creeping up to the surface after years and years of usage and technologies evolving. I mean, sure, today he's just getting IP addresses, user-agents, and languages, but tomorrow we may be able to harvest something more, and in combination with what was given before, _just_the_credit_card_info on it's own isn't as valuable to an attacker as everything combined. Perhaps in it's own sick way, the rules as absolute is a design that prevents "feature"-creep from pushing its way into the PCI-compliance standards system. Maybe in limited circumstances we could adopt this sort of attitude to prevent feature-creep in other technologies from undermining the original intent of the work. I say this with full respect for the fact that in reality, if somebody tells me to "follow the rules" because "that's how it's done", I'm usually quite upset at their attitude about the whole thing.
    - misingnoglic 10y ago
      That's probably just an added benefit of their hugely bureaucratic system.
  - nodesocket 10y ago
    I'd be curious if you can point to a specific section of PCI that states that a 3rd party cannot collect user meta-data. If that is true Google Analytics and Intercom could not track on checkout pages.
- deleted 10y ago
  [deleted]

nodesocket 10y ago

Back up. I never transmitted any credit card details. All the inputs were heuristics about the end-user (ip address, GeoIP location, user-agent, referer, language, etc) or transaction meta-data (price, etc). Card number, expiration, CVV were NOT part of the inputs in Charge Control.

grecy 10y ago
> I never transmitted any credit card details. PCI compliance is only partially concerned with transmitting CC details, and is very much concerned with "YOU SHALL FOLLOW THE RULES". The rules say you are not allowed to do what you were doing. It's completely irrelevant if what you were doing is not a security or data transmission issue, it's simply against the rules. PCI compliance is an absolute nightmare, and is not something to be reasoned with, trust me. Logical thought and analysis has no place in PCI compliance. Follow the rules or else.
- smallnamespace 10y ago
  > Logical thought and analysis has no place in PCI compliance. Only at a local level. If you're writing standards that are going to be rolled out to the whole world and are difficult to change, and where the potential downside is people losing a lot of money, then a 'better safe than sorry' heuristic is the correct choice. Monkey-patching into your payments library at runtime certainly doesn't seem like a 'safe' practice that PCI ought to endorse at all. It's essentially impossible to write a standard that perfectly anticipates every edge case. And if it were possible, the list of rules would be even longer and more difficult to follow.
- ThatGeoGuy 10y ago
  I wonder if in part PCI compliance is designed this way as to avoid details or holes in the overall system from creeping up to the surface after years and years of usage and technologies evolving. I mean, sure, today he's just getting IP addresses, user-agents, and languages, but tomorrow we may be able to harvest something more, and in combination with what was given before, _just_the_credit_card_info on it's own isn't as valuable to an attacker as everything combined. Perhaps in it's own sick way, the rules as absolute is a design that prevents "feature"-creep from pushing its way into the PCI-compliance standards system. Maybe in limited circumstances we could adopt this sort of attitude to prevent feature-creep in other technologies from undermining the original intent of the work. I say this with full respect for the fact that in reality, if somebody tells me to "follow the rules" because "that's how it's done", I'm usually quite upset at their attitude about the whole thing.
  - misingnoglic 10y ago
    That's probably just an added benefit of their hugely bureaucratic system.
- nodesocket 10y ago
  I'd be curious if you can point to a specific section of PCI that states that a 3rd party cannot collect user meta-data. If that is true Google Analytics and Intercom could not track on checkout pages.
deleted 10y ago
[deleted]