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?
1 Like
It has been removed a while ago
https://github.com/discourse/discourse/commit/2d0c99636af1a74d6046541361f0652c96e08030
@techAPJ do you remember why?
4 Likes
I vaguely remember, mostly I think because it is pointless?
-
noopeneris for security -
nofollowis 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 Likes
This can be achieved quite easily with a theme component if someone really wants this.
6 Likes
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.
1 Like
Speaking of referrers
3 Likes
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.
4 Likes
I’m curious, why is rel="noopener" added in oneboxes but not normal external links?
They also seem to be missing in the user-card.
Possibly an oversight cc @techapj
1 Like
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.
5 Likes
Fixed via:
6 Likes
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.
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.
3 Likes
This topic was automatically closed after 2319 days. New replies are no longer allowed.