4 ms·

> Mouse movements are not a first or last name, physical or email address, [or one of a dozen other obvious examples] You misunderstand what personally identif

• Kalium 7y ago
  > You misunderstand what personally identifiable information is. Not to belabor a point discussed elsewhere, but those were not arbitrarily chosen types of PII. They are how PII is defined in the specific law that was cited - CalOPPA. The comment to which I responded contains a link. The text of the law contains its definition of PII. Please accept my apologies. I can see I failed to communicate clearly and readers interpreted my statements as broad comment about what is or isn't PII across a union of all potentially relevant laws and jurisdictions. This was in no way, shape, form, or manner my intended meaning. Again, please accept my apologies for failing to be clear. > Mouse movements may not be PII if you don't link it to a session ID, but then it would be useless in fraud detection because you don't know whose transaction you should be blocking or allowing since it's no longer traceable to a person. Maybe it's just me, but I was under the distinction impression that some patterns of input are characteristic of humans and others of inhuman actors. Is it possible that a user could be identifiable as human or inhuman without having to know which specific human an input pattern corresponds to? Have I misunderstood something?
  • lucb1e 7y ago
    > [could one distinguish] human or inhuman without having to know which specific human an input pattern corresponds to? You can't rely on the client asking the server anonymously and adhering to the response. If you want to avoid a connection to a "specific human", it would go like this: Fraudulent lient: POST /are/these/mouse_movements/human HTTP/1.0 \r\n Content-Type: JSON \r\n [{"x":13,"y":148},...] Server: that's a robot Fraudulent client: discards server response and submits transaction anyway To make sure the server knows to block the transaction, it has to tie the mouse movements to the transaction, and thereby to a credit card number (afaik Stripe does only credit cards as payment option), at least during the processing of the submission before discarding the mouse movement data. I'm not arguing this is evil or mistrusting Stripe or anything, just that this is considered PII in my part of the world.
    • deleted 7y ago
      [deleted]
    • nl 7y ago
      To make sure the server knows to block the transaction, it has to tie the mouse movements to the transaction, and thereby to a credit card number (afaik Stripe does only credit cards as payment option), at least during the processing of the submission before discarding the mouse movement data. Which is absolutely fine by the law if it isn't stored tied to PII.
      • lucb1e 7y ago
        GDPR doesn't apply only to storage, though? Maybe I'm confusing it with the previous data protection directive but I'm pretty sure the new GDPR also defines PII processing to include things like transmitting and operating on it. But if there is some source (e.g. case law, data protection authority) that confirms that you can process two pieces of data and keep one as non-PII if you promise not to connect them in storage or forward them to another place in an identifiable manner, that would be interesting.
        • 7y ago
• onion2k 7y ago
  Mouse movements may not be PII if you don't link it to a session ID, but then it would be useless in fraud detection because you don't know whose transaction you should be blocking or allowing since it's no longer traceable to a person. Surely the point of mouse movement detection for anti-fraud is more "did the mouse move in an exact straight line to the exact center of an element and therefore isn't a human" or "the last 3 orders on this site used exactly the same pattern of mouse movements therefore is a recording" rather than some sort of "gait detection" to tell who someone is.
  • lucb1e 7y ago
    The purpose of processing the individual mouse positions over time may be exactly that, but I'm not sure that the intent matters. For example, a website asking for my social security number for the sole purpose of verifying whether it matches the checksum (Dutch SSNs contain a checksum) would still be processing my SSN, no? I'd be interested if I'm wrong, though.
• SkyPuncher 7y ago
  > Each individual letter of my name is also not identifiable, the letters of the alphabet are not PII, but when stored in in the same database row, the separate letters do form PII no matter that you stored them separately or even hashed or encrypted them. This is a correct statement, but it's implied suggestion that Stripe is doing this is incorrect. There are lots of ways around this: no storing specific keys and hashing input would be my initial impressions. My guess is Stripe is more concerned about the action patterns than the specific keys that a being pressed. > Mouse movements may not be PII if you don't link it to a session ID, but then it would be useless in fraud detection because you don't know whose transaction you should be blocking or allowing since it's no longer traceable to a person. This is an opinion and not a fact. I don't need to know the identity of the guy wearing a balaclava and carrying a pillow case to know if that guy is in a bank and reaching into his jacket pocket, there's a high likelihood he's robbing the place. When he shows up at the next place to rob, I don't have to have any PII on him to identify him as a robber. Might not be the same robber at both banks, but they both exhibit similar patterns. If they both limp or talk with a slur, I can reasonably connect the two without knowing the underlying identity.
  • lucb1e 7y ago
    > My guess is Stripe is more concerned about the action patterns than the specific keys that a being pressed. Don't they still need to process the data server-side to derive that pattern to make a decision on it?