7 ms·

In my opinion, there's no moral issue with doing this. Fighting fraud and other kinds of cybercrime is an endless cat-and-mouse game. Although there are very ba

In my opinion, there's no moral issue with doing this. Fighting fraud and other kinds of cybercrime is an endless cat-and-mouse game. Although there are very bad associations with it, one simply does need to use fingerprinting and supercookies/"zombie cookies"/"evercookies" if they want even a fighting chance. I think if it's being solely used for such security purposes, isn't shared with or sold to anyone else, and is carefully safeguarded, then it's okay. The main risk I see from it is mission creep leading to it eventually being used for other purposes, like advertising or tracking for "market research" reasons. I don't personally think it's likely Stripe would do this, though.

mtlynch 7y ago
> I think if it's being solely used for such security purposes, isn't shared with or sold to anyone else, and is carefully safeguarded, then it's okay. The main risk I see from it is mission creep leading to it eventually being used for other purposes, like advertising or tracking for "market research" reasons. I don't personally think it's likely Stripe would do this, though. Is this view conditional on the type of data Stripe is currently collecting or would it apply to any data Stripe collects? Would this be true if Stripe began recording every keystroke in the app and hooked every XHR request to my backend server and sent copies to Stripe? I agree that Stripe has a sensible reason for using this data. If I started seeing a high rate of chargebacks, I'd consider enabling Stripe on more parts of my site so that Stripe could consume user behavior earlier on to detect fraud. My issue is that if there's no agreement about what data Stripe is allowed to collect and what their retention policies are, then the implicit agreement is that Stripe can just collect anything it has access to and hold it forever. As JavaScript running on my page, Stripe.js has access to basically all user data in my app. There are certain types of user data I would not be comfortable sharing with Stripe, even if it improved fraud detection, so I'd like there to be clear limits on what they're gathering.
- meowface 7y ago
  Yes, I would say it's conditional. They should be more explicit about what data they're collecting from users. Opaque enough to not reveal all of the exact techniques, but clear enough so site owners can make an informed decision. (Someone dedicated and experienced enough could probably reverse engineer Stripe.js and figure out everything it's doing if they really wanted, but they're also probably updating it regularly.)
  - adambyrtek 7y ago
    There's no need to rely on "security by obscurity". Stripe.js is just a thin client-side library everybody can analyse, so they might as well be fully transparent when it comes to data collection. I don't see the point of trying to obfuscate things, especially since the actual fraud-detection model works on the backend anyway.
    - meowface 7y ago
      With these kinds of adversarial things, I think it's a mix of frontend and backend. It's a library everyone can technically analyze, yes, but by 1) using ever-changing obfuscation that requires a lot of work to RE, and 2) constantly changing the client-side logic itself, it makes the work of the adversaries a lot harder and more tedious, and means either fewer of them will consistently succeed, or more of them will be forced to become more centralized around solutions/services that've successfully solved it, which means Stripe can focus-fire their efforts a bit more. Of course there's also a lot going on on the backend that'll never be seen, but the adversary is trying to mimic a legitimate user as much as they can, so if the JavaScript is totally unobfuscated and stays the same for a while, it's a lot easier for them to consistently trace exactly what data is being sent and compare it against what their system or altered browser is sending. It's cat-and-mouse across many dimensions. In such adversarial games, obscurity actually can and often does add some security. "Security by obscurity is no security at all" isn't exactly a fallacy, but it is a fallacy to apply it universally and with a very liberal definition of "security". It's generally meant for things that are more formal or provable, like an encryption or hashing algorithm or other cryptography. It's still totally reasonable to use obscurity as a minor practical measure. I'd agree with this part of https://en.wikipedia.org/wiki/Security_through_obscurity https://en.wikipedia.org/wiki/Security_through_obscurity: "Knowledge of how the system is built differs from concealment and camouflage. The efficacy of obscurity in operations security depends by whether the obscurity lives on top of other good security practices, or if it is being used alone. When used as an independent layer, obscurity is considered a valid security tool." For example, configuring your web server to not display its version on headers or pages is "security by obscurity", and certainly will not save you if you're running a vulnerable version, but may buy you some time if a 0-day comes out for your version and people search Shodan for the vulnerable version numbers - your site won't appear in the list. These kinds of obscurity measures of course never guarantee security and should be the very last line of defense in front of true security measures, but they can still potentially help you a little. In the "malware vs. anti-virus" and "game cheat vs. game cheat detection software" fights that play out every day, both sides of each heavily obfuscate their code and the actions they perform. No, this never ensures it won't be fully reverse engineered. And the developers all know that. Given enough time and dedication, it'll eventually happen. But it requires more time and effort, and each time it's altered, it requires a re-investment of that time and effort. Obfuscation and obscurity is arguably the defining feature and "value proposition" of each of those four types of software. A lot of that remains totally hidden on the backend (e.g. a botnet C2 web server only responding with malware binaries if they analyze the connection and believe it really is a regular infected computer and not a security researcher or sandbox), but a lot is also present in the client.
mook 7y ago
In my opinion, there _is_ a moral issue. Not in that they collect this information for fraud prevention; that seems like a reasonable use for that data. It's in not having informed consent, in not having a clear document describing what is collected and when it is purged. And that document would need to be consumer-facing (since it's not the vendor's behaviour being tracked). Responding after being caught is… good, but not as good as not needing to be caught.
- jimmaswell 7y ago
  I am so sick of informed consent and cookie and GDPR etc. popups and banners and forms and checkboxes. I could not care less and neither could most people out there. This crap is ruining the internet for no tangible benefit to the inexplicable thunderous applause of people on tech websites. It didn't hurt anyone when Sears collected rewards data for advertising and it never hurt anyone when web companies used data from user interaction. A simple static webpage is going to end up impossible for anyone but a megacorp to run legally if we keep going down this nonsensical path. Imagine I mailed you an unsolicited letter and you were legally required to burn it and never say or benefit from what was inside just because I said so. That's the insanity of these "privacy" laws.
  - literallycancer 7y ago
    Or you could just not collect information you don't need? You don't have to ask consent if you just don't do it, you know. The pop-ups are annoying because the website owners want you to just click through. Ever seen one of those where you have to uncheck every single box? Yep, those violate the GDPR. The default setting should be no advertising or other bullshit data, and opt-in if you want it. Which no one ever does. Hence the violations. Get mad at the manipulative ad companies, not the people who for once produced an OK piece of regulation.
    - renewiltord 7y ago
      He's not the guy who is collecting data. He's the guy whose data is being collected. And I agree with him. True choice is not imposing this cost on everyone. Let me set it in my browser. Then I'll consent to practically everything and you can consent to nothing. And since it's set at your user agent you can synchronize that across devices easily. If I never see another damned cookie popup I'd be thrilled.
service_bus 7y ago
Why are 'evercookies' necessary. My browser is setup to record no history or cookies. It can be annoying to always have to dismiss the same popups you've dismissed before, but I've never had any issues with online payments or unnecessary captchas, including using stripe. What am I missing?
- meowface 7y ago
  Because fraudsters' browsers/clients/scripts are also set up to record no history or cookies, and otherwise evade detection/categorization as much as possible. Somewhat ironically, in order for them to accurately distinguish between privacy-conscious users like yourself and actual criminals, and to block criminals from making a purchase while not incorrectly blocking you, they need to collect additional data.
  - yjftsjthsd-h 7y ago
    > Because fraudsters' browsers/clients/scripts are also set up to record no history or cookies, and otherwise evade detection/categorization as much as possible Ah, right, bad guys use privacy-enhancing tech, so we'd better undermine it, even if it screws over legitimate users. You know what fraudsters also tend to use? Chrome. Let's block that, shall we?
  - service_bus 7y ago
    Right, but I'm saying my setup is no different from the 'fraudsters' you describe, yet I have a seamless shopping experience online. If I'm able to shop online without issues, why does everyone else 'need' an evercookie? I'm sure it's helpful, it's the idea that it's necessary is what I take issue with.
    - floatingatoll 7y ago
      If you don't commit fraud, the only two issues you'll see are that: 1) a small subset of sites will refuse to complete the transaction, as their anti-fraud thresholds are set to deny likely-fraudulent browsers such as yours; and, 2) you will be much more easily fingerprinted and tracked online due to your specific combination of extremely uncommon non-default settings in your browser (which may well mitigate #1 if you're originating from a residential IP address). If you purchase high-value audio gear or clothing or gift cards — basically, high value things can be resold on eBay immediately — you may find your transaction held for review while someone phone calls you to prove that you're you, but for everyday Amazon or etc. purchasing it's unlikely to matter at all.
lucb1e 7y ago
A blanket statement "we need privacy invasion to have any chance against fraud, it cannot be done without, period." without argumentation about why we need this against fraud isn't very constructive. For example, in my experience: user pays, website gets money, website releases product. It's the user that could be defrauded, not the website. I never heard of fraud issues from the website owners' perspective in the Netherlands where credit cards are just not the main method to pay online. Fraudulent Paypal chargebacks, sure, but iDeal.nl or a regular SEPA transfer just doesn't have chargebacks. It would appear that there is a way to solve this without tracking.
meowface 7y ago
Addendum: I have no clue if they actually are using fingerprinting or supercookies. I just know many anti-fraud service providers do.

mtlynch 7y ago

> I think if it's being solely used for such security purposes, isn't shared with or sold to anyone else, and is carefully safeguarded, then it's okay. The main risk I see from it is mission creep leading to it eventually being used for other purposes, like advertising or tracking for "market research" reasons. I don't personally think it's likely Stripe would do this, though. Is this view conditional on the type of data Stripe is currently collecting or would it apply to any data Stripe collects? Would this be true if Stripe began recording every keystroke in the app and hooked every XHR request to my backend server and sent copies to Stripe? I agree that Stripe has a sensible reason for using this data. If I started seeing a high rate of chargebacks, I'd consider enabling Stripe on more parts of my site so that Stripe could consume user behavior earlier on to detect fraud. My issue is that if there's no agreement about what data Stripe is allowed to collect and what their retention policies are, then the implicit agreement is that Stripe can just collect anything it has access to and hold it forever. As JavaScript running on my page, Stripe.js has access to basically all user data in my app. There are certain types of user data I would not be comfortable sharing with Stripe, even if it improved fraud detection, so I'd like there to be clear limits on what they're gathering.

meowface 7y ago
Yes, I would say it's conditional. They should be more explicit about what data they're collecting from users. Opaque enough to not reveal all of the exact techniques, but clear enough so site owners can make an informed decision. (Someone dedicated and experienced enough could probably reverse engineer Stripe.js and figure out everything it's doing if they really wanted, but they're also probably updating it regularly.)
- adambyrtek 7y ago
  There's no need to rely on "security by obscurity". Stripe.js is just a thin client-side library everybody can analyse, so they might as well be fully transparent when it comes to data collection. I don't see the point of trying to obfuscate things, especially since the actual fraud-detection model works on the backend anyway.
  - meowface 7y ago
    With these kinds of adversarial things, I think it's a mix of frontend and backend. It's a library everyone can technically analyze, yes, but by 1) using ever-changing obfuscation that requires a lot of work to RE, and 2) constantly changing the client-side logic itself, it makes the work of the adversaries a lot harder and more tedious, and means either fewer of them will consistently succeed, or more of them will be forced to become more centralized around solutions/services that've successfully solved it, which means Stripe can focus-fire their efforts a bit more. Of course there's also a lot going on on the backend that'll never be seen, but the adversary is trying to mimic a legitimate user as much as they can, so if the JavaScript is totally unobfuscated and stays the same for a while, it's a lot easier for them to consistently trace exactly what data is being sent and compare it against what their system or altered browser is sending. It's cat-and-mouse across many dimensions. In such adversarial games, obscurity actually can and often does add some security. "Security by obscurity is no security at all" isn't exactly a fallacy, but it is a fallacy to apply it universally and with a very liberal definition of "security". It's generally meant for things that are more formal or provable, like an encryption or hashing algorithm or other cryptography. It's still totally reasonable to use obscurity as a minor practical measure. I'd agree with this part of https://en.wikipedia.org/wiki/Security_through_obscurity https://en.wikipedia.org/wiki/Security_through_obscurity: "Knowledge of how the system is built differs from concealment and camouflage. The efficacy of obscurity in operations security depends by whether the obscurity lives on top of other good security practices, or if it is being used alone. When used as an independent layer, obscurity is considered a valid security tool." For example, configuring your web server to not display its version on headers or pages is "security by obscurity", and certainly will not save you if you're running a vulnerable version, but may buy you some time if a 0-day comes out for your version and people search Shodan for the vulnerable version numbers - your site won't appear in the list. These kinds of obscurity measures of course never guarantee security and should be the very last line of defense in front of true security measures, but they can still potentially help you a little. In the "malware vs. anti-virus" and "game cheat vs. game cheat detection software" fights that play out every day, both sides of each heavily obfuscate their code and the actions they perform. No, this never ensures it won't be fully reverse engineered. And the developers all know that. Given enough time and dedication, it'll eventually happen. But it requires more time and effort, and each time it's altered, it requires a re-investment of that time and effort. Obfuscation and obscurity is arguably the defining feature and "value proposition" of each of those four types of software. A lot of that remains totally hidden on the backend (e.g. a botnet C2 web server only responding with malware binaries if they analyze the connection and believe it really is a regular infected computer and not a security researcher or sandbox), but a lot is also present in the client.

mook 7y ago

In my opinion, there _is_ a moral issue. Not in that they collect this information for fraud prevention; that seems like a reasonable use for that data. It's in not having informed consent, in not having a clear document describing what is collected and when it is purged. And that document would need to be consumer-facing (since it's not the vendor's behaviour being tracked). Responding after being caught is… good, but not as good as not needing to be caught.

jimmaswell 7y ago
I am so sick of informed consent and cookie and GDPR etc. popups and banners and forms and checkboxes. I could not care less and neither could most people out there. This crap is ruining the internet for no tangible benefit to the inexplicable thunderous applause of people on tech websites. It didn't hurt anyone when Sears collected rewards data for advertising and it never hurt anyone when web companies used data from user interaction. A simple static webpage is going to end up impossible for anyone but a megacorp to run legally if we keep going down this nonsensical path. Imagine I mailed you an unsolicited letter and you were legally required to burn it and never say or benefit from what was inside just because I said so. That's the insanity of these "privacy" laws.
- literallycancer 7y ago
  Or you could just not collect information you don't need? You don't have to ask consent if you just don't do it, you know. The pop-ups are annoying because the website owners want you to just click through. Ever seen one of those where you have to uncheck every single box? Yep, those violate the GDPR. The default setting should be no advertising or other bullshit data, and opt-in if you want it. Which no one ever does. Hence the violations. Get mad at the manipulative ad companies, not the people who for once produced an OK piece of regulation.
  - renewiltord 7y ago
    He's not the guy who is collecting data. He's the guy whose data is being collected. And I agree with him. True choice is not imposing this cost on everyone. Let me set it in my browser. Then I'll consent to practically everything and you can consent to nothing. And since it's set at your user agent you can synchronize that across devices easily. If I never see another damned cookie popup I'd be thrilled.

service_bus 7y ago

Why are 'evercookies' necessary. My browser is setup to record no history or cookies. It can be annoying to always have to dismiss the same popups you've dismissed before, but I've never had any issues with online payments or unnecessary captchas, including using stripe. What am I missing?

meowface 7y ago
Because fraudsters' browsers/clients/scripts are also set up to record no history or cookies, and otherwise evade detection/categorization as much as possible. Somewhat ironically, in order for them to accurately distinguish between privacy-conscious users like yourself and actual criminals, and to block criminals from making a purchase while not incorrectly blocking you, they need to collect additional data.
- yjftsjthsd-h 7y ago
  > Because fraudsters' browsers/clients/scripts are also set up to record no history or cookies, and otherwise evade detection/categorization as much as possible Ah, right, bad guys use privacy-enhancing tech, so we'd better undermine it, even if it screws over legitimate users. You know what fraudsters also tend to use? Chrome. Let's block that, shall we?
- service_bus 7y ago
  Right, but I'm saying my setup is no different from the 'fraudsters' you describe, yet I have a seamless shopping experience online. If I'm able to shop online without issues, why does everyone else 'need' an evercookie? I'm sure it's helpful, it's the idea that it's necessary is what I take issue with.
  - floatingatoll 7y ago
    If you don't commit fraud, the only two issues you'll see are that: 1) a small subset of sites will refuse to complete the transaction, as their anti-fraud thresholds are set to deny likely-fraudulent browsers such as yours; and, 2) you will be much more easily fingerprinted and tracked online due to your specific combination of extremely uncommon non-default settings in your browser (which may well mitigate #1 if you're originating from a residential IP address). If you purchase high-value audio gear or clothing or gift cards — basically, high value things can be resold on eBay immediately — you may find your transaction held for review while someone phone calls you to prove that you're you, but for everyday Amazon or etc. purchasing it's unlikely to matter at all.

lucb1e 7y ago

A blanket statement "we need privacy invasion to have any chance against fraud, it cannot be done without, period." without argumentation about why we need this against fraud isn't very constructive. For example, in my experience: user pays, website gets money, website releases product. It's the user that could be defrauded, not the website. I never heard of fraud issues from the website owners' perspective in the Netherlands where credit cards are just not the main method to pay online. Fraudulent Paypal chargebacks, sure, but iDeal.nl or a regular SEPA transfer just doesn't have chargebacks. It would appear that there is a way to solve this without tracking.

meowface 7y ago

Addendum: I have no clue if they actually are using fingerprinting or supercookies. I just know many anti-fraud service providers do.