Comments (15)
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.
from user.js.
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 :)
from user.js.
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.
from user.js.
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).
from user.js.
@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.
from user.js.
from user.js.
@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.
from user.js.
@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.
from user.js.
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
from user.js.
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!
from user.js.
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 ;)
from user.js.
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.
from user.js.
Every member of this ghacksuserjs organization can close issues.
from user.js.
@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!
from user.js.
@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!
from user.js.
Related Issues (20)
- changelog v126 [important: read upcoming changes for FF128] HOT 38
- Typo in user.js HOT 2
- Clipboard pref default changed HOT 1
- Add I still dont care about cookies to optional extensions HOT 1
- ToDo: work out WTF this all means and fixup if required HOT 5
- Privacy-Preserving Attribution (FF 128) HOT 14
- Make Updater.sh shell agnostic HOT 3
- Is it necessary to disable canvas from the browser if it offers to disable or allow them on the site? As well as browser security settings presets HOT 3
- add FPP granularOverrides for the FYI factor HOT 30
- Overrides won't work HOT 6
- ToDo: diffs FF126-FF127 HOT 14
- v128 SOCKS change HOT 2
- RFP: exclude timezone as UTC/GMT and use my real one HOT 2
- How to enable click to copy? HOT 2
- Quarantined domains aren't enforced if a certain add-on is disabled HOT 3
- extensions.enabledScopes HOT 1
- Noob (likely invalid) question about TZP'ing vanilla AF (also vanilla FF + RFP) HOT 6
- Are `network.dns.disablePrefetch`/`network.dns.disablePrefetchFromHTTPS` master switches of `dom.prefetch_dns_for_anchor_http_document`/`dom.prefetch_dns_for_anchor_https_document`? HOT 2
- So i installed arkenfox user.js and for some reason now i have these thick lines on the edges of the screen and even that i did a backup they are still in there it kinda looks like it is in box. HOT 1
- ToDo: diffs FF127-FF128 HOT 27
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from user.js.