Optionally add noreferrer to external links

Product Support

AI-generated summary

The discussion revolves around whether Discourse should optionally add noreferrer to external links. brett_zink noticed noreferrer was mentioned in 1.7 release notes but couldn’t find it in code or settings. zogstrip confirmed it was removed, and codinghorror explained that noreferrer has minimal practical value — mainly denying referrer data, which is often irrelevant (e.g., HTTP→HTTPS doesn’t send it). He noted weak intranet leakage concerns but wouldn’t prioritize it unless paying customers request it. sam suggested a theme component could implement it if needed. techAPJ couldn’t recall the removal reason. riking proposed using <meta>-based referrer policies for better scope control, suggesting dynamic policies like strict-origin-when-cross-origin for private areas. frictionel questioned why noopener is added to oneboxes but not regular links, pointing out inconsistencies in user cards. codinghorror called it an oversight. techAPJ clarified that noopener should only apply to TL3+ users if tl3 links no follow is enabled — a bug was fixed in b75b6de. frictionel argued that trust should be placed in the target site, not the user posting the link, since external sites can become compromised. codinghorror countered that this implies a warning pop-up on external links — a concept previously discussed here.

1

The 1.7 release notes mention that noreferrer was added. I don’t see it in the options or in the codebase anywhere.

I categorized this as support, because maybe i’m missing the config somewhere? But maybe it’s a bug?

2

It has been removed a while ago

@techAPJ do you remember why?

3

I vaguely remember, mostly I think because it is pointless?

  • noopener is for security

  • nofollow is for search engine safety

  • noreferrer .. has no purpose other than “screw you, we’re not sending the referrer” .. plus http to https doesn’t send it anyway.

There is a pretty weak case to be made for it in terms of intranet leakage, but I would be unwilling to spend any engineering time on this unless a few paying customers request it.

4

This can be achieved quite easily with a theme component if someone really wants this.

5

Sorry, I can’t remember exactly why I removed it. There must be a discussion for it here on meta but I am unable to find it right now.

6

Speaking of referrers

7

For a dynamic web app like Discourse, referer policy is probably more useful to be set at a page scope rather than for individual links.

To dynamically set referer policy, use the <meta> element, and the last set policy prevails, which makes it very easy to code.

An example policy:

  • " no-referrer-when-downgrade " by default
  • " strict-origin-when-cross-origin " when viewing private messages or secure categories

With a site setting to change it to always be “strict-origin-when-cross-origin”, turned on by default for login required sites.

If we decide Discourse doesn’t need its own referer information, strict-when-cro can be upgraded to “strict-origin” to save bandwidth.

8

I’m curious, why is rel="noopener" added in oneboxes but not normal external links?

58

22

They also seem to be missing in the user-card.

9

Possibly an oversight cc @techapj

10

rel="noopener" not being added in normal external links is actually correct behaviour because @codinghorror is TL4 and tl3 links no follow is disabled.

rel="nofollow noopener" being added for @zogstrip (TL4) is a bug and onebox should respect the site setting tl3 links no follow.

There is a bug report for this here:

If the user is TL3 or above, rel="nofollow noopener" not being present is correct / as expected.

11

Fixed via:

https://github.com/discourse/discourse/commit/b75b6de982013fdfd08b8aecb1c701b35c787599

12

This seems to be a no-brainer: Why not trust a link that someone posted who is trusted by Discourse? But I was thinking about it a little more and this is the wrong question.

How can you or @codinghorror or anyone be certain that the external site isn’t compromised? And if not now can’t it be malicious at some point in the future?

So it’s not about trusting the user who posted the link but rather trusting the target site.

Tell me that i’m wrong.

13

Then it sounds like you want a generic “warn that you are visiting an external website and there might be dragons” pop-up on clicking any link.. not really a fan of that, but it is discussed here.