[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
session.
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