What about network.http.enablePerElementReferrer ?

[ghost]

network.http.enablePerElementReferrer is commented out in user.js [ghacks]-0.11.js as well as in, here, ghacks-user.js-51.0 but with no additional information.

I read at https://www.anonymous-proxy.eu/firefox-privacy-tuning.php (mentioning this page because info on above setting is hard to find),

Mozilla's Firefox has introduced an experimental "per-element referrer" feature which is transmitting HTTP referrer for particular elements such as:
Hyperlink
Picture
Frame
Clickable area

That sites advises to set it to false (default=true). But not sure the setting is still experimental and not sure as well that site is right.

I've set it to false,

// Disable per-element HTTP referrer (HTTP referrer for particular elements such as Hyperlink, Picture, Frame, Clickable area)
// https://www.anonymous-proxy.eu/firefox-privacy-tuning.php
user_pref("network.http.enablePerElementReferrer", false); // Default=true

What would the experts say?

[atomGit]

https://developer.mozilla.org/ru/Firefox/Releases/42#HTML

Experimental support for the referrer attribute of the (bug 1166910), <iframe> (bug 1175736), and (bug 1174913) has been added. There is no effect by default, the network.http.enablePerElementReferrer being false by default.

the default is 'true'

you're right in that there seems to be little info regarding this

just reading the pref name, i might interpret it as meaning that, when you, for instance, click on an embedded object that links to elsewhere, the referrer sent would be the source of the embedded object rather than the site the object is embedded in, but i think it could be interpreted differently as well

if that scenario is correct, then, from a privacy POV, it would seem to make sense to leave it at it's default value (true)

not an expert though :)

[ghost]

if that scenario is correct, then, from a privacy POV, it would seem to make sense to leave it at it's default value (true)

Indeed. The problem is the "if". Amazing. A browser includes a setting which is tougher to interpretate than a woman's smile. Far from a near past where everything was classified. Now you have to guess.
Amazing.

[fmarier]

That feature is no longer experimental. It's now part of the specification.

It can be used to change the default referrer policy to either include more or less information in the referrer. So ignoring them could actually increase the amount of information leaked via the Referer header.

However, the user controls like http.referer.XOriginPolicy take precedence over this, so it's actually unnecessary from a user point of view. I suspect we will remove that pref at some point (given the feature is no longer experimental).

[ghost]

@fmarier are you sure you're not mistaking with network.http.referer.XOriginTrimmingPolicy? The specification page you mention doesn't state network.http.enablePerElementReferrer

I'm not an expert, just trying to make my way through a myriad of header settings ...

network.http.referer.XOriginPolicy
network.http.referer.spoofSource
network.http.referer.trimmingPolicy
network.http.referer.XOriginTrimmingPolicy
network.http.sendRefererHeader
network.http.enablePerElementReferrer
network.http.referer.userControlPolicy (FF 53+)

They are well detailed in ghacks-user.js-51.0 yet, for a non-expert, appear as a chaotic soup.

[Atavic]

@zymase > #5

[earthlng]

@zymase, first of all, welcome on board here :)

are you sure you're not mistaking with network.http.referer.XOriginTrimmingPolicy?

we had quite the birth struggle with revamping the Referrer section.
@Atavic already linked to it, if you want to read thru some of it.
Towards the end there, you can see why we decided to only use XOriginPolicy (and don't change XOriginTrimmingPolicy) for our "recommended Referer policy" for this user.js. We also came up with 3 recommended options for you to use, one of which (Option 2) can also be made more secure but with the risk of more breakage. We decided to go with the "less breakage" Option 2 as our default policy.

With network.http.enablePerElementReferrer=true sites can use the "per element referrer" to better protect their users when they click on links, etc on that site. (intended use!) But it can also be used to lessen the protection!
But if you have a good setting for Referrer's, then it doesn't matter what the site does or doesn't do. That means if you're using one of our 3 recommended options, you can safely ignore enablePerElementReferrer, or you can set it to false if you want - it doesn't matter.

I personally also have enablePerElementReferrer set to false, if that helps your decision making :)
I looked at the code for some of it's implementation (namely this for Implement img referrer attribute), and the changes are minuscule and unlikely to be exploitable, but call me paranoid if you want - it does run extra code and since I don't need the feature anyway (because I use XOriginPolicy=2), I might as well disable it.

edit: I hope this helps to clarify a few things for you, but if not - I've opened this issue again, so feel free to ask more
edit2: we also have a test page for Referer Headers in the wiki, if you want to test different settings or our recommended options and how they behave. And our Required reading link plus this article can also help with understanding each setting a bit better.

[fmarier]

The specification page you mention doesn't state network.http.enablePerElementReferrer

The spec doesn't mention this because it's an implementation detail. It's a Firefox feature flag that was used to control when we rolled out this part of the spec.

[ghost]

@earthlng I'm using Option 2 and many thanks for developing this topic in latest ghacks user.js ver.52 Section 1600, which makes it easier to choose and, for a non-techie, makes related settings a bit easier to understand. What is confusing in this sum of header settings is their interaction, otherwise it wouldn't be more problematic than any other setting. Thanks as well for re-opening my thread. I ignored a dedicated sticky thread existed here for such concerns.

@fmarier I was about to say merci! perhaps presuming a culture given a name. Thanks as well. The implementation detail explains your knowledge and my ignorance. You learn every day.

At the end my -- our! -- enablePerElementReferrer remains controversial to the point of inducing a margin of subjective appreciation, which is normal since true and false have both the best and worst implications. That very point is a pain but it's the lot of our computer world when an innovation has been driven for the best and gets manipulated for the worst. We have to do with it.

Fine. Thanks guys.

[earthlng]

Thanks as well for re-opening my thread

np, I know Pants can be a PITA sometimes ;)

Fine. Thanks guys.

So no more questions? This is your ticket so please feel free to close this yourself

[ghost]

No more questions that I'm aware of for the time being (to make it long).
I thouhjt It was Roman-Nopantski who had closed the thread.
Whatever the pages of Github, looks like I haven't correctly understood of opening/closing a thread. In my mind I don't close doors of a house which isn't mine :) So the idea is that the registered can close the threads he opened himself only and the admin can close any thread? (that's an off-topic question!). Whatever I couldn't imagine closing someone else's thread, that would be rude, or wouldn't it considering the protocol of Github is not that of a private propriety, strico sensus! You learn every day, some faster than others (some users that is).

OK, I'll close the door!

[earthlng]

Pants was @Roman-Nopantski's nickname on ghacks.net before we moved this project to github.

So the idea is that the registered can close the threads he opened himself only and the admin can close any thread?

Yes that's correct. And I think we should handle it that way, unless we (as admins) close something with wontfix for example. I agree, it's rude to close someone else's thread and if we want something closed, we should ask the OP to do it himself.
We are also new to github and also still learning :)
I'm not entirely sure, but I think the original thread-creator can still comment even if we close an issue (wontfix for example) - feel free to test and confirm this, should it ever happen again ;)

[ghost]

I had in mind, would be rude a user closing another user's thread, not the admin (owner, whatever the denomination) of the Github "room" (I definitely lack the terminology). Old school here, "the boss is always right even when he's wrong" :)

Anyway, nice to discover this Ghacks-user.js dedicated Github "room". I read Pants' comments on Ghacks but I confess not having noticed a name, his, squeezed between Roman and Polanski. Perhaps was I expecting plain Pants, ironed :)

OK, OK. Well, the best to you, to us all, to a finely tuned Firefox to which you contribute in a much appreciated way.

[Atavic]

Every member of this ghacksuserjs organization can close issues.

[ghost]

@Atavic I had just that in mind after my last comment and as I was lost in musical-driven thoughts, the fact that earthing had been able to close my thread even though he isn't administrator ... now I understand.

I can see that, @Roman-Nopantski . Well, that'd be only another far analogy with the movie maker!

[ghost]

@Roman-Nopantski , that's what I figured out after Atavic's comment :
regardless of who started the issue, anyone can still comment in a closed thread unless it is locked.

Otto von Pantsmarck sounds nice, requires a monocle!

I don't care tracing you, Pants, even if I could. But true as well that when someone seems to have a strong character he/she triggers curiosity. What where, when and so on. I'd appreciate meeting you in a pub, discovering you are the Pants we know, and chat around a pint or two. i'm sure it'd be most interesting. But here we are, more or less anonymously and it's just fine when the topics concern less ourselves then our thoughts, mainly about computer stuff.

Re-opened just to answer. I won't close this time!