[wp-trac] [WordPress Trac] #65377: Remove redundant noreferrer from target=_blank links in Gutenberg (backport request)

[WordPress Trac]

#65377: Remove redundant noreferrer from target=_blank links in Gutenberg (backport
request)
--------------------------+-----------------------------
 Reporter:  TimoTijhof    |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Editor        |    Version:  6.9
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 I'm working on quantifying and fixing an ecosystem-wide problem where a
 big chunk of the open web has unintentionally erased itself from referral
 data due to outdated or misplaced use of `rel=noreferrer` or `Referrer-
 Policy: no-referrer`, typically through the default behavior of a CMS,
 plugin, or by the advise of a security scanner. You can read a draft of my
 essay on the topic at https://phabricator.wikimedia.org/T427561.

 In 2017, WordPress started automatically adding `rel=noreferrer` when
 saving new content to links using `target=_blank` (ticket #43187, ticket
 #37941, r42770). In 2020, this was removed again (ticket #49558, r49215).
 But, lots of WordPress sites still set rel=noreferrer on most links even
 in newly published articles. This turned out due to the Gutenberg editor
 separately having the same feature. An issue for that was filed six years
 ago at https://github.com/WordPress/gutenberg/issues/26914, and the fix
 landed a few weeks ago in Gutenberg 33.0.0.

 I'd like to ask for this to be included and backported to WordPress stable
 versions so that we can start to see things improve as soon as possible.

 **Question: Isn't this rare?**

 At glance, this issue appears specific to links created via the Gutenberg
 interface, where the editor chose to tick the "Open link in new tab"
 checkbox. If that was true, I think the magnitude of this issue would be
 much smaller, and a backport would not be warranted. However, it is common
 for articles to have every link in them open in a new tab, through no
 intentional act by the editor.

 How? The clipboard! It is of course useful to preserve `target=_blank` in
 pasted contents. E.g. if you copy from another Gutenberg tab, or from a
 published article on your own or a different website. For example, I've
 imported numerous articles I published elsewhere first, into my own blog,
 by copy-pasting in this way, and preserving choices such as this one, is
 useful.

 However, there are lots of contexts where this happens in a way that does
 not preserve any kind of editorial choice.

 Virtually all web apps these days slap target=_blank on all links in user-
 generated content so that the app stays open:

 * Obsidian
 * Fastmail
 * Gmail
 * Matrix/Element
 * Discord
 * Slack
 * Mastodon
 * Facebook
 * Self-hosted feed readers like FreshRSS and tiny-tiny-rss
 * etc

 For example, if you draft a post using markdown in the Obsidian app, all
 links have `target=_blank`. (This is how I originally encountered this. I
 found most posts on my personal blog opened in a new tab and had
 `rel=noreferrer` despite me never ticking "Open in new tab" in Gutenberg.)

 The same is true for Fastmail and Gmail. Regardless of how the email
 itself was written, when it is rendered by the webmail client, all links
 cary `target=_blank`. So if someone drafts a blogpost by email for you, or
 even if you just take one linked word from an email you received and paste
 it, it's got `target=_blank`. The same for anything you copy from a
 conversation in Slack or Discord.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65377>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform