[wp-trac] [WordPress Trac] #43545: Helper functions: Anonymizing data in a standardized way

WordPress Trac noreply at wordpress.org
Fri Mar 23 13:37:39 UTC 2018


#43545: Helper functions: Anonymizing data in a standardized way
--------------------------------+------------------------------
 Reporter:  dejliglama          |       Owner:
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  Options, Meta APIs  |     Version:  trunk
 Severity:  normal              |  Resolution:
 Keywords:  needs-patch gdpr    |     Focuses:
--------------------------------+------------------------------

Comment (by jesperher):

 Replying to [comment:11 azaozz]:
 > This sounds good but imho there are far too many options to anonymize
 things. It would be handy for translatable strings but not for numbers,
 tokens, etc. For example: what would be an anonymized `id` or `email` or
 `url`? All these should be empty strings.

 I kind of agree on numbers - when first creating the list, it was kind of
 a brainstorm on different types of data.

 For the ID part, i dont think we can anonymize that.
 But for the email part i still think this i very relevant, because of the
 way WordPress uses mail adresses, and how a lot of code normally us
 depending on the the data to be of a valid email type.
 Then i belive it is better, to create a "standard" of how it us
 anonymized, and help plugin developers to use this feature, istead of it
 beeing done on 1000 different ways.

 > I'd also argue that an anonymized IP address is `0.0.0.0` (if not an
 empty string). Don't see any value to try and keep partial user data for
 general purposes. If a plugin requires to retain specific data, it can
 choose to anonymize it in a specific way.

 We could maybe create a Ip_zero, and a IP_partially or something like
 that, to make both methods avaviable.


 >
 > I like the translatable `text` and `longtext`, but they seem too long?
 Something like `Deleted` and `Deleted by the author.` would be enough
 imho.

 You might be right on this.

 >
 > Also, two different filters, one of which is dynamic (a.k.a very hard to
 read/use) for few strings seem excessive :)

 I disagree.
 It is also used in that way other places in core, with dynamic hooks. Like
 on creating/saving posts.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/43545#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list