4 ms·

> You misunderstand what personally identifiable information is. Not to belabor a point discussed elsewhere, but those were not arbitrarily chosen types of PI

by 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.
    - joshuamorton 7y ago
      > 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. It would be impossible to follow the GDPR otherwise, all data would implicitly be PII, since all data is associated with an IP address and GDPR defines IP as PII. > GDPR doesn't apply only to storage, though? This doesn't matter, because you can always collect data for business critical purposes, which fraud protection reasonably is.
- DevKoala 7y ago
  As someone who had to implement GDPR for a DSP, that doesn't make the data PII.
  - lucb1e 7y ago
    Digital Signal Processor? Delaware State Police? Defense Support Program? DSP is a little ambiguous here.
    - ceefry 7y ago
      Given context of GDPR, I'm assuming Demand Side Platform ("buying" half of programmatic advertising).
- Kalium 7y ago
  > 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: I'm afraid I don't understand. Maybe you can help me? Seems to me you could not store things, you could require a signed and expiring token from the /are/these/mouse_movements/human service, or you could treat the request as super risky without that signed token. I'm sure there are others, I am known to suffer failures of imagination at times. > 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 clearly wrong, but doesn't the logic here only work if the mouse movements are identifiable in the same sort of way that a phone number is? What happens if that's not accurate and mouse movements from a session are not so personally identifiable? What have I failed to understand? Wouldn't this logic also make transaction timestamps PII?
  - lucb1e 7y ago
    You keep using that ridiculously apologetic tone that really rubs me the wrong way while making constructive remarks. If you could lose the former without the latter, I might actually appreciate your replies. But then, I'm reasonably sure that it's meant to annoy. > Seems to me you could not store things, you could require a signed and expiring token That's actually a good idea.
    - Kalium 7y ago
      OK. You didn't read the law I was talking about that was specifically and clearly linked in the initial comment to which I responded. The comment in question made a specific claim about a specific law in a specific jurisdiction to which I responded narrowly and specifically. My comment referred clearly to the law in question and summarized points from it. All points about other laws in other locations are irrelevant to the specific points I was offering discussion of. > That's actually a good idea. It is... provided that a handful of mouse movements actually qualify as PII. Which, as claimed here under CalOPPA, seems like it might be doubtful. As others have pointed out, there's room to doubt that a few mouse movements would be considered PII under any current regulatory regime (there are multiple notable ones, they don't agree on all points). As an approach, it's useful for things like SAML and OAuth protocols when you're dealing with different systems controlled by different parties and need to delegate trust through an untrusted party. It's rarely the best way to move data around inside a system, though, unless you have some compelling reason to introduce this level of blinding.
- disiplus 7y ago
  but you are giving stipe pii when you buy something directly. at that point the mouse movement is nothing. and if you dont buy something the mouse movement is not pii.
  - lucb1e 7y ago
    > but you are giving stipe pii when you buy something directly. at that point the mouse movement is nothing 1) but that's not how the law works 2) law aside, I'm also not sure it holds up ethically to say "you're giving them <some info necessary to fulfill your payment>, what's wrong with giving them <unnecessary other data>". Now, if you say "but it's not unnecessary, it's for anti-fraud!" then sure, that's a different argument: then the argument is not that you might as well give it because of something else you gave but because it's necessary for fraud. They could still do the courtesy of telling users before tracking them (which might bring us back to the legal argument, which tells us that is is indeed necessary to do so).
- mistercow 7y ago
  Huh? Client sends data to bot-detection server, server sends back a signed response with a nonce and an expiration date saying "Yep, this is a human". Server stores the nonce to prevent replays. Client attaches the signed validation when submitting the transaction. The server that receives that verifies the signature and expiration date, then checks and invalidates the nonce. No association between the transaction and the mouse data necessary. I don't know if that's how Stripe is doing it, but you could do it that way.
  - TheDong 7y ago
    How is the nonce not an association? We have two possible options here: 1. Client sends mouse-data + card info to a server, server checks the mouse data, turns it into a fraudPercent, and only stores that percent. That seems to be what they're doing now. 2. Client sends mouse data, gets back a unique nonce, and then sends that nonce to the server with card info. The server could have either stored or discarded the mouse info. It's perfectly possible the nonce was stored with the mouse info. Those two things seem totally identical. The nonce by necessity must be unique (or else one person could wiggle their mouse, and then use that one nonce to try 1000 cards at once), and you can't know that they don't store the full mouse movement info with the nonce. You gain nothing by adding that extra step other than some illusion of security. Note, cloudflare + tor has a similar problem that they tried to solve with blind signatures (see https://blog.cloudflare.com/the-trouble-with-tor/ https://blog.cloudflare.com/the-trouble-with-tor/), but that hasn't gone anywhere and requires a browser plugin anyway. It's not a viable solution yet.
    - mistercow 7y ago
      If you're going to go as far as "it's perfectly possible that the nonce was stored with the mouse info", then your example following: > If you want to avoid a connection to a "specific human", it would go like this: doesn't work either. It's perfectly possible that the server stored that info with the IP address and session information, since it also has access to those, and that could then be connected up with the transaction. I don't understand at this point what standard you're trying to meet, because it sounds like by what you're saying, literally any data sent to a server is "PII" if at some point that server also can, in principle, know your name.

by Kalium 7y ago

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.
  - joshuamorton 7y ago
    > 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. It would be impossible to follow the GDPR otherwise, all data would implicitly be PII, since all data is associated with an IP address and GDPR defines IP as PII. > GDPR doesn't apply only to storage, though? This doesn't matter, because you can always collect data for business critical purposes, which fraud protection reasonably is.
DevKoala 7y ago
As someone who had to implement GDPR for a DSP, that doesn't make the data PII.
- lucb1e 7y ago
  Digital Signal Processor? Delaware State Police? Defense Support Program? DSP is a little ambiguous here.
  - ceefry 7y ago
    Given context of GDPR, I'm assuming Demand Side Platform ("buying" half of programmatic advertising).
Kalium 7y ago
> 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: I'm afraid I don't understand. Maybe you can help me? Seems to me you could not store things, you could require a signed and expiring token from the /are/these/mouse_movements/human service, or you could treat the request as super risky without that signed token. I'm sure there are others, I am known to suffer failures of imagination at times. > 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 clearly wrong, but doesn't the logic here only work if the mouse movements are identifiable in the same sort of way that a phone number is? What happens if that's not accurate and mouse movements from a session are not so personally identifiable? What have I failed to understand? Wouldn't this logic also make transaction timestamps PII?
- lucb1e 7y ago
  You keep using that ridiculously apologetic tone that really rubs me the wrong way while making constructive remarks. If you could lose the former without the latter, I might actually appreciate your replies. But then, I'm reasonably sure that it's meant to annoy. > Seems to me you could not store things, you could require a signed and expiring token That's actually a good idea.
  - Kalium 7y ago
    OK. You didn't read the law I was talking about that was specifically and clearly linked in the initial comment to which I responded. The comment in question made a specific claim about a specific law in a specific jurisdiction to which I responded narrowly and specifically. My comment referred clearly to the law in question and summarized points from it. All points about other laws in other locations are irrelevant to the specific points I was offering discussion of. > That's actually a good idea. It is... provided that a handful of mouse movements actually qualify as PII. Which, as claimed here under CalOPPA, seems like it might be doubtful. As others have pointed out, there's room to doubt that a few mouse movements would be considered PII under any current regulatory regime (there are multiple notable ones, they don't agree on all points). As an approach, it's useful for things like SAML and OAuth protocols when you're dealing with different systems controlled by different parties and need to delegate trust through an untrusted party. It's rarely the best way to move data around inside a system, though, unless you have some compelling reason to introduce this level of blinding.
disiplus 7y ago
but you are giving stipe pii when you buy something directly. at that point the mouse movement is nothing. and if you dont buy something the mouse movement is not pii.
- lucb1e 7y ago
  > but you are giving stipe pii when you buy something directly. at that point the mouse movement is nothing 1) but that's not how the law works 2) law aside, I'm also not sure it holds up ethically to say "you're giving them <some info necessary to fulfill your payment>, what's wrong with giving them <unnecessary other data>". Now, if you say "but it's not unnecessary, it's for anti-fraud!" then sure, that's a different argument: then the argument is not that you might as well give it because of something else you gave but because it's necessary for fraud. They could still do the courtesy of telling users before tracking them (which might bring us back to the legal argument, which tells us that is is indeed necessary to do so).
mistercow 7y ago
Huh? Client sends data to bot-detection server, server sends back a signed response with a nonce and an expiration date saying "Yep, this is a human". Server stores the nonce to prevent replays. Client attaches the signed validation when submitting the transaction. The server that receives that verifies the signature and expiration date, then checks and invalidates the nonce. No association between the transaction and the mouse data necessary. I don't know if that's how Stripe is doing it, but you could do it that way.
- TheDong 7y ago
  How is the nonce not an association? We have two possible options here: 1. Client sends mouse-data + card info to a server, server checks the mouse data, turns it into a fraudPercent, and only stores that percent. That seems to be what they're doing now. 2. Client sends mouse data, gets back a unique nonce, and then sends that nonce to the server with card info. The server could have either stored or discarded the mouse info. It's perfectly possible the nonce was stored with the mouse info. Those two things seem totally identical. The nonce by necessity must be unique (or else one person could wiggle their mouse, and then use that one nonce to try 1000 cards at once), and you can't know that they don't store the full mouse movement info with the nonce. You gain nothing by adding that extra step other than some illusion of security. Note, cloudflare + tor has a similar problem that they tried to solve with blind signatures (see https://blog.cloudflare.com/the-trouble-with-tor/ https://blog.cloudflare.com/the-trouble-with-tor/), but that hasn't gone anywhere and requires a browser plugin anyway. It's not a viable solution yet.
  - mistercow 7y ago
    If you're going to go as far as "it's perfectly possible that the nonce was stored with the mouse info", then your example following: > If you want to avoid a connection to a "specific human", it would go like this: doesn't work either. It's perfectly possible that the server stored that info with the IP address and session information, since it also has access to those, and that could then be connected up with the transaction. I don't understand at this point what standard you're trying to meet, because it sounds like by what you're saying, literally any data sent to a server is "PII" if at some point that server also can, in principle, know your name.