[wp-trac] [WordPress Trac] #43546: Add to the privacy tools UX a means to export personal data by username or email address

WordPress Trac noreply at wordpress.org
Tue May 8 19:52:49 UTC 2018

#43546: Add to the privacy tools UX a means to export personal data by username or
email address
 Reporter:  allendav               |       Owner:  allendav
     Type:  enhancement            |      Status:  assigned
 Priority:  normal                 |   Milestone:  4.9.6
Component:  General                |     Version:  trunk
 Severity:  normal                 |  Resolution:
 Keywords:  gdpr needs-unit-tests  |     Focuses:

Comment (by iandunn):

 Replying to [comment:63 johnstonphilip]:
 > Is it a bad idea to have the full, publicly-available ZIP file link in
 an email? My first thought is that the direct link to the ZIP file
 shouldn't ever automatically leave/exist-outside-of a logged-in WP

 The discussion about that was across comment:14, comment:25, comment:32,
 and comment:34.

 The filename contains a lengthy cryptographically-secure psuedorandom
 number, which makes discovery via brute force impossible for all practical
 considerations (see comment:34 for the details). I think that's
 essentially how Google Docs, YouTube, etc protect documents that are
 intended to be shared with a limited number of people, but where account
 authorization is not practical.

 One of the reasons it isn't behind a login flow is because it has to serve
 people who don't have accounts, like commenters. We could potentially
 require logged-in users to log in, though, and only have it publicly
 accessible for commenters. That would require some kind of proxy like `ms-
 files.php`, though. So, it's not trivial, but doable if it seems like it's
 worth it.

 I personally don't feel like there's enough reason to worry, but I'd like
 to hear what you think after reading the comments above.

 > Could there also be a link in the downloaded index.html file that the
 user could click to day "I got it", which would delete the file from the
 server immediately, ahead of the cron?

 That's a good idea. Similar to the above, I don't personally feel like
 it's necessary, but it might be easier than the `ms-files.php` proxy. So,
 if we decide we need additional hardening, that might be a better option.

 It's also worth noting that people can use the
 `wp_privacy_export_expiration` filter if they want to shrink the attack
 window, although that would have a negative impact on UX.

 What do you think about all of that?

Ticket URL: <https://core.trac.wordpress.org/ticket/43546#comment:64>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

More information about the wp-trac mailing list