Thinking ahead, services could suffer Denial of Resources/Services attacks via:
1. Repeated join, post, 'request deletion' from individual or multiple data subjects acting in concert.
2. Individual data subjects may join, post, 'request deletion' to multiple services simultaneously.
Because the 'deletion' data is PII that should make it possible to identify these activities either by single services or services sharing intelligence.
That brings up an interesting issue. In order to operate effective anti-spam measures to deal with this, data controllers/processors would need to retain some PII. That retention would likely come under the heading of 'needed to operate the service'.
Hashing the identity items individually (email address, nick-name, real-name, telephone, etc.) would mean the anti-spam data was anonymous. The only time it could be linked to an identity would be when the data subject tries to join a service or request deletion using the same data.
Which brings up the other difficult issue with casual pseudonymous services: verifying the requester is the data subject.
Hi TJ,
In order to operate effective anti-spam measures to deal with this, data controllers/processors would need to retain some PII. That retention would likely come under the heading of 'needed to operate the service'.
That's the issue I've been wondering about WRT lug.org.uk's Mailman provision. There's also Mailman's variables like `accept_these_nonmembers' that build up email addresses over time.
Hashing the identity items individually (email address, nick-name, real-name, telephone, etc.) would mean the anti-spam data was anonymous.
Not if it's easy enough to hash all likely telephone numbers and check by brute force? Or determine if foo@bar.xyzzy in particuar is there?
-
Ralph Corderoy -
TJ