Alter sensitive data replacement mechanism

[jonoaldersonwp]

When users submit forum threads with sensitive data (system filepaths, etc), I believe that we automatically detect and replace those strings with 'xxx' and similar.

E.g.,

• ​https://wordpress.org/support/topic/google-parameter-vedxxxxx/
• ​https://wordpress.org/support/topic/fatal-error-2-3-0/
• ​https://wordpress.org/support/topic/firefox-cookie-xxx-has-been-rejected-for-invalid-domain/
• ​https://wordpress.org/support/topic/fatal-error-uncaught-valueerror-unknown-format-specifier-w/

This has the unfortunate side-effect of making the wordpress.org rank highly in Google for variations of 'xxx'; in the last month we got ~80,000 clicks for such terms.

This is problematic, as there's an obvious mismatch in intent, which might lead Google to believe that our site provides a poor user experience, which could negatively impact performance domain-wide.

To address this, I suggest that we:

1. Entirely remove (rather than replace) sensitive string in URLs
2. Replace sensitive strings in titles and body with [REDACTED] (rather than xxx and similar)
3. Retrospectively apply 2 (but not 1, to avoid breaking URLs) to existing forum threads.

[ocean90]

The x is just a typical replacement character used by the users.

[dd32]

Yeah, this isn't something WordPress.org does.

Most forum mods use [redacted] or removed for privacy.

I'm not sure there's anything really to do here, without proactively changing all instances of xxx in all user-generated-content to be abc or with multiplication signs.. neither of which seems appropriate to me.

Perhaps we could look at adding sensitive data redaction which replaces /home/[^/]+/ with ellipse for logged out uses (and emails, and maybe even some URLs). We could also look at not having -xxx- in slugs.

[jonoaldersonwp]

Darn, that indeed makes things trickier!

Matching a few of those common patterns (/home/[^/]+/, etc) would definitely help, and would reduce the surface area considerably.