[wp-meta] [Making WordPress.org] #5093: Proposal to allow users to remove URLs that they have added to their posts in the support forums

[Making WordPress.org]

#5093: Proposal to allow users to remove URLs that they have added to their posts
in the support forums
----------------------------+---------------------
 Reporter:  carike          |       Owner:  (none)
     Type:  defect          |      Status:  new
 Priority:  high            |   Milestone:
Component:  Support Forums  |  Resolution:
 Keywords:  has-patch       |
----------------------------+---------------------

Comment (by bedas):

 Would like to add a word here on a few details.

 **A)** I think it is not up to GDPR, lawyers or anyone else to determine
 what is the persons "private" stuff. I tend to agree even with the
 statement that the URL to the website may be considered "private", what is
 however most important is to remember that the content written by any user
 is ''not'' our property, it is the property of the user who wrote it
 (again, this may differ in law enforcements however this is my opinion).

 Just like comments, a user should have the right to remove ''everything''
 they wrote from online instances, by default, as a basic right. This
 includes, but is not limited to, links.

 WordPress is a leading CMS and setting a standard that may go above what
 GDPR asks us to do can have a positive impact.
 Even "evil" Facebook allows to delete your content and removes content
 (mostly) once you delete either said content or your account, which does
 not seem to happen in WordPress (please correct me if I am wrong on this).

 Understandably this is a help forum, and removing content would kind of
 dispose of the goal (to keep a log for other users to find the same
 solution), however, with the modern times, users do not research, they ask
 anew. So the "loss of information" - even if deleting a full topic - is
 actually not that big and the impact is probably close to zero.

 Users ask ''again'', even if they found a solution, often they ask the
 same question again "just to be sure".
 That said, this is perhaps off topic but I believe that the "threads are
 not deleted even if you request us to" approach may not be the most
 respectful way to deal with data that, bottom line, ''is neither ours nor
 WordPress's property''.

 **B)** I have worked for years in a (PRO/PAID WordPress Plugin) company
 providing Support for WordPress users, and the way this issue was dealt
 with there, was as follows:
 - if a user request deletion of their thread, we complied with it. No
 Questions Asked.
 - a custom code logic applied to the threads masked all URLs by default
 and made them visible only to Moderators and OP. Only if a specific
 "prefix" (in our case an `@`) was added to the URL, then the URL was
 public.
 - the masking logic automatically excluded major domains like Stack
 Overflow, Google, WordPress, etc from the masking process.
 - this masking process of course applied to everything what had the syntax
 `anything.anything`. Similarly to WhatsApp when you type
 `anything.anything` and that gets converted to an URL, this sometimes
 resulted in funny issues due to typos (when a user mistakenly forgot the
 space after a dot). These issues however are minimal, and can be resolved
 by Mods quickly.
 - last but not least the user in the forums was able to edit their posts
 until marked as resolved. After that, the users where welcome to contact
 us for further edit or removal.

 This effectively ensured that no "private" url got public by accident, it
 allowed to make specific URLs publicly readable if needed, and as well
 automatically ensured that most of the common external sites (as said,
 like SO, WP, etc) where public so other readers could follow the links to
 potential solutions.
 If it helps, I am sure said Company will be more than willing to share
 their code solution with WordPress or even commit directly, as they are
 directly involved and contributing to the platform almost daily. I can, if
 this is desired or/and welcome, reach out and ask for inputs.

 Concluding, I believe it is utmost important to respect the peoples
 content, and to understand that their written content, wether an ask for
 help or else, in no way ever changes property. It is and stays the OPs
 property, I believe, and the OP should free to do with that content what
 they consider best.

 Implementing such solution as above described would not add work to
 Moderators, rather, it would probably save a lot of time.
 Of course the difference between "paid" and "volunteer" forums is, that
 here we couldn't "employ" someone responding to needs of peoples on
 demand. But I think the approach with the prefixing already would solve
 99% of the "please remove URL" issues, and the option to delete even after
 OP marked a topic as resolved, could simply be ignored in the WP case.
 After all, no one but the OP can mark as resolved, so perhaps just adding
 a last notice there, saying "If you mark as resolved, you won't be able to
 remove Urls or else edit the postings" would complete the resolution.

 Finally, posting an URL that the OP shared in our reply to the OP is (IMO)
 a plain simple no-go. We should always anonymise and never directly copy
 paste the OP's URLs.
 That is simply good practice I believe.
 Public Urls ''can'' in fact be a minor security issue. What if I
 mistakenly post my ''customised'' login URL? While security thru obscurity
 is not a ''solution'', it is ''part of a solution'' (because since the WP
 login Urls are widely known, renaming them can have a huge impact on brute
 force bots, because they would not know my customised login url. Publicly
 sharing them would effectively "destroy" this (tiny) measure. Mainly thou
 I think it is just a form of respect to not copy-paste in replies the URL
 shared by Users (specially, if that URL was only part of the "I need help
 with" field.

 I hope this helps and sorry the long-ish post, and of course, this is
 mostly based on my opinion and experience. Not trying to force it on
 anyone ;)

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/5093#comment:33>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org