Comment 19 for bug 560246

Revision history for this message
BavarianPH (bavarianph) wrote : Re: [Bug 560246] Re: Launchpad requires the REFERER header on form submission breaking with noscript and other privacy/spam browser plugins

Dear users & readers,

Ubuntu is a world-class OS & more, & it is free.

Could we just give launchpad what they want?

Download Firefox add-on "Change Referer Button"

This add-on app keeps the user in control as to whom

they choose to reveal the Referer Header to.

Ubuntu already knows who we are, they are not nearly

as secretive as other apps or OSs, they deserve our free

support.

BavarianPH,
Ubuntu Forever

On 6/2/11, Paul Ebermann <email address hidden> wrote:
> At least, when you give this error message, throw the user back to the
> same form, with all the data he tried to submit before already filled
> in.
>
> This way, if he is now enabling the referrer, he does not have to type
> in the whole bug report (or whatever this was) again.
>
> --
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (596225).
> https://bugs.launchpad.net/bugs/560246
>
> Title:
> Launchpad requires the REFERER header on form submission breaking with
> noscript and other privacy/spam browser plugins
>
> Status in Launchpad itself:
> Triaged
>
> Bug description:
> It appears that Launchpad blocks access if your browser does not send
> a Referer header. See:
>
> https://answers.launchpad.net/launchpad/+faq/1024
>
> The FAQ claims that this is done to prevent CSRF. This sounds like a
> dubious decision, for three reasons:
>
> 1) Requiring a Referer header is bad for privacy. The Referer header can
> be used to track people's actions on the web and thus is a potential privacy
> risk which I prefer to avoid. It is none of site A's business what site B I
> was browsing previously. It's not just me; you are blocking a non-trivial
> user population. Some client-side privacy tools block the Referer, for good
> and valid privacy reasons. Some privacy-sensitive users configure their
> browsers to avoid sending Referer headers. See, e.g.,
> http://www.ecommerce-blog.org/archives/neweggcoms-usability-blunder/
> Some proxies and firewalls strip the Referer from all HTTP requests, as a
> security risk and a privacy risk. By blocking those users, you are either
> harming user privacy or losing out on useful participation from people who
> care about privacy.
>
> 2) The RFC (RFC 2068) specifically envisions that users should be able
> to disable sending Referer headers, and recommends that web browsers
> provide a way so that users can enable/disable this, because of its
> privacy implications. Your Referer check means that your site will
> not be accessible from RFC 2068-compatible browsers.
>
> 3) Requiring a Referer header does not prevent CSRF. The Referer
> header is not reliable for security purposes; there are a number of
> techniques that can be used to forge Referer headers. If the Referer
> check is the only defense against CSRF, then Launchpad is probably
> vulnerable to CSRF. If Launchpad is using a proper defense against
> CSRF (e.g., double-cookie submission, CSRF tokens), then it is secure
> without the Referer check and blocking people who don't send a Referer
> header is gratuitous. I'm not sure why it would be necessary to force
> users to lower their privacy settings if they want to use Launchpad.
>
> Can this decision be revisited, please?
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/launchpad/+bug/560246/+subscribe
>