Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP referer #13

Closed
amilopowers opened this issue Oct 1, 2015 · 18 comments
Closed

HTTP referer #13

amilopowers opened this issue Oct 1, 2015 · 18 comments

Comments

@amilopowers
Copy link

I think your addon should stop Firefox from sending HTTP headers (referer).

network.http.sendRefererHeader;0

Regards,
amilopowers

@Gitoffthelawn
Copy link

I don't think you really want to block all HTTP headers... you won't see many websites if you do that! :-)

I think you are just asking to block HTTP referers (aka HTTP referrers). I think it's a reasonable request.

Note that Privacy-Settings currently allows toggling the setting for secure cross-site referers, but not for regular referers.

Since blocking referers can (currently) break a few sites, there are a number of browser extensions that block referers and handle exceptions quite well.

On the other hand, if more people blocked _all referers_, fewer web developers would create sites that require that easily-spoofed parameter. Since it is trivial to spoof an HTTP referer, it's not a good development practice to require any specific referer.

@amilopowers
Copy link
Author

Oh yes I am sorry I mean HTTP referrers!

Yes it does rarely break some sites but I browse for like a half a year on all my devices without them and I remember a single broken page. I mean I think it was that.

Since most people aren't aware that something like that even exists I doublt that it makes a difference on devs.

@Gitoffthelawn
Copy link

Can you change the title of this issue? Thanks!

I agree, deciding to not transmit HTTP referers usually has no negative effects (I would estimate more than 99% of the time). Fewer and fewer sites use them as a "protection" mechanism, since they are so ineffective for that use.

That said, when a website is not working as expected, it creates another test-case to determine what went wrong.

@amilopowers amilopowers changed the title HTTP headers HTTP referer Oct 1, 2015
@amilopowers
Copy link
Author

Done.

Btw: There are the possible values 0,1 or 2 for referers. I dont know what 1 means. That might be an option as well.

@berrythesoftwarecodeprogrammar

Refcontrol https://addons.mozilla.org/en-US/firefox/addon/refcontrol/ is the best option for this. set the default policy to block referrer and just allow/spoof for sites where its needed

@berrythesoftwarecodeprogrammar

however there could be more private defaults set in firefox
this site explains a few config options http://www.ghacks.net/2015/01/22/improve-online-privacy-by-controlling-referrer-information/

network.http.sendRefererHeader

    0 - never send the referring URL.
    1 - send only when links are clicked.
    2 - send for links and images (default).

network.http.referer.XOriginPolicy

    0 - always send referrer (default).
    1 - only send if base domains match.
    2 - only send if hosts match.

network.http.referer.spoofSource

    false - send the referrer (default).
    true - spoof the referrer and use the target URI instead.

network.http.referer.trimmingPolicy

    0 - send full URI (default).
    1 - scheme, host, port and path.
    2 - scheme, host and port.

@berrythesoftwarecodeprogrammar

personally i think ill use:

network.http.sendRefererHeader=1
network.http.referer.XOriginPolicy=2
network.http.referer.trimmingPolicy=2
network.http.referer.spoofSource=true

and just keep using refcontrol to block all and allow on a per site basis

@berrythesoftwarecodeprogrammar

you can test your settings here http://www.whatismyreferer.com/ (click the url at the bottom of the page)

@amilopowers
Copy link
Author

Thanks for clarification! I chose everywhere the safest option. Don't care if it breaks pages or not.

@jomo
Copy link
Contributor

jomo commented Oct 12, 2015

The problem is that you don't necessarily notice when a page 'breaks'.
For example Atlassian's JIRA bug tracker simply won't let you log in without any useful error message (at least it used to).

I haven't had any issues with XOriginPolicy = 2 + leaving the rest on default.
That way you aren't giving sites any new information they don't already have, especially when switching sites.

@schomery
Copy link
Owner

I am testing adding integer prefs to the extension (the minimum possible though as it is more confusing that Boolean prefs). Knowing this, what would be the minimum prefs to have for referer case and what are the suggested values for the buttons:

screen shot 2016-01-20 at 12 37 32

@jomo
Copy link
Contributor

jomo commented Jan 20, 2016

I can't think of anything relevant for security in regards to the Referer, so it's only a privacy concern.

  • You probably want sendRefererHeader = 0 for maximum privacy, this obsoletes the other options.
    Please note this will break some sites.
  • spoofSource would have been useful for sites that break (i.e. server error) without a Referer if it wouldn't break other sites.
  • There are sites that don't work properly without a somewhat valid Referer (sometimes required for images or POST requests) so XOriginPolicy = 2 is a good choice (see HTTP referer #13 (comment)) if you're not on full privacy
  • trimmingPolicy doesn't help any of the issues explained above.

tl;dr: use sendRefererHeader = 0 for privacy modes and XOriginPolicy = 2 for compatible modes else. For other options use the defaults.

@Gitoffthelawn
Copy link

I like the idea of adding integer prefs, although, as you mention, it will be a bit more confusing.

Whatever you do with referrers, remember that many systems use extensions that modify referrers on a per-site basis. For those systems, make sure you don't interfere with those extensions.

@geokis
Copy link

geokis commented Mar 23, 2016

I think the idea to control with Privacy-Settings more complex options is really great.
But I understand the necessity to keep the addon simple to use.

So maybe you can expand the Addon with an Advanced Settings section and a FAQ on GitHub with explanations like from @berrythesoftwarecodeprogrammar and some warnings about breaking sites.

I created a little mockup, how it could be implemented:


asu


asdu

@schomery
Copy link
Owner

I am thinking it might be more flexible if we have advanced settings listed in a browser tab. Having them on the panel might be confusing to some users. We are going to have a link to this page in the panel though.
#42

@geokis
Copy link

geokis commented Mar 24, 2016

Browser tab ?

Personally, I would prefer to have the advanced settings integrate in the PrivacySettings panel as additional index tab:

reiter

@berrythesoftwarecodeprogrammar

browser tab like done in Configuration Mania im guessing. if you want to keep a panel maybe have the quick settings + things people are likely to toggle/mess with regularly on the panel and have a link to the full settings page

@schomery
Copy link
Owner

schomery commented Apr 5, 2016

Preferences related to HTTP referrer are now covered in the advanced panel; #42

@geokis advanced settings page requires more space than what we have in the main panel. For now lets have it opened in a browser tab.

@schomery schomery closed this as completed Apr 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants