info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Shortened HTTP Referer header project
564 views
Skip to first unread message
Brian Smith
Feb 26, 2013, 9:51:18 PM2/26/13
to dev-p...@lists.mozilla.org, dev-tech-network, Gervase Markham
>From https://wiki.mozilla.org/Privacy/Features/Shortened_HTTP_Referer_header
> 4. Requirements
>
> [a] Test plan must be created and implemented
> [b] Use cases must be clearly outlined and it must
> be clear how the feature addresses each.
> [c] Initially, Phase 1 (user-set) should not change
> default behavior until user initiates change.
> [d] Default referer behavior for sites should not
> change until sites activate attenuation features.
Should these requirements be updated?
I think we should try to jump straight to making origin-only Referer headers the default by removing requirements [c] and [d], in the interests of expediency.
As I noted in the <meta referrer> bug [1], the lack of <meta referer=origin> support looks like a major performance issue, especially on very popular sites like google.com and facebook.com that currently use a redirect to limit the Referer to the origin in Firefox, but which link directly to the target in Chrome.
The spec for <meta referer> seems to be this wiki page:
http://wiki.whatwg.org/wiki/Meta_referrer
I disagree with some aspects of the spec. In particular, I think the spec. should explicitly mention that the Referer header should be limited by whatever user preferences are in effect. For example, if the user has chosen to set the default to "never" then all values must be interpreted as "never". As another example, if a browser vendor chooses to set the default to "origin" then "default" and "always" should not cause the browser to send path/query/hash in the Referer header.
With that out of the way, I propose that Firefox use the following interpretation of the values of the <meta referrer> header:
"never" - As specified in the wiki; do not send the Referer header. (This is the current behavior of Firefox for HTTPS -> HTTP nagivations.)
"origin" - As specified in the wiki. (This would change Firefox's HTTPS -> HTTP behavior to disclose the scheme, host, and port where it currently does not do so, and it would change Firefox's behavior to disclose less in all other cases.)
"default" - For HTTPS -> HTTP navigations, do not send any Referer header; otherwise, treat like "origin". (This discloses less information in the Referer header than what is specified in the wiki.)
"always" - Same as "origin". (This discloses less information in the Referer header than what the wiki recommends.)
any other value (or missing): Same as "default", which is what the wiki specifies.
IMPORTANT NOTE: In case it isn't clear, my proposal is suggesting that we shorten our default Referer header by default to sends only the origin (e.g. http://example.org:123/ instead of http://example.org:123/path?query#fragment), and that we allow sites to opt in to sending the origin for HTTPS -> HTTP navigations.
I can foresee the argument that we shouldn't interpret "always" or "default" differently than what the wiki specifies, because a site could always use the query parameters and redirects trick to disclose the information we are trying to prevent disclosure of. That is true, but in order to use that redirect trick, they would have to suffer a performance penalty. I think that is OK, as long as we are able to allow sites that do something reasonably privacy-preserving (stripping the path, query, and fragment) to avoid that penalty. Also note that Google's and Facebook's use of the redirect shows that prohibiting the sending of the Referer header for HTTPS -> HTTP cases for values "origin" and "always" is not really a way to enforce privacy-preserving behavior. The only way to really enforce "completely" privacy-preseving behavior would be to set the default to "never", which is likely to break too much stuff. (And, regardless, strengthening the default value to "never" can be done later, after we've experimented with limiting Referer to just the origin.)
Obviously, we'd have to do a lot of measurements to see what, if anything would break with this new default policy. But, I think spending effort on that testing would be much better than spending effort on UI for new values of the Referer prefs.
Thoughts?
Cheers,
Brian
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=704320
> 4. Requirements
>
> [a] Test plan must be created and implemented
> [b] Use cases must be clearly outlined and it must
> be clear how the feature addresses each.
> [c] Initially, Phase 1 (user-set) should not change
> default behavior until user initiates change.
> [d] Default referer behavior for sites should not
> change until sites activate attenuation features.
Should these requirements be updated?
I think we should try to jump straight to making origin-only Referer headers the default by removing requirements [c] and [d], in the interests of expediency.
As I noted in the <meta referrer> bug [1], the lack of <meta referer=origin> support looks like a major performance issue, especially on very popular sites like google.com and facebook.com that currently use a redirect to limit the Referer to the origin in Firefox, but which link directly to the target in Chrome.
The spec for <meta referer> seems to be this wiki page:
http://wiki.whatwg.org/wiki/Meta_referrer
I disagree with some aspects of the spec. In particular, I think the spec. should explicitly mention that the Referer header should be limited by whatever user preferences are in effect. For example, if the user has chosen to set the default to "never" then all values must be interpreted as "never". As another example, if a browser vendor chooses to set the default to "origin" then "default" and "always" should not cause the browser to send path/query/hash in the Referer header.
With that out of the way, I propose that Firefox use the following interpretation of the values of the <meta referrer> header:
"never" - As specified in the wiki; do not send the Referer header. (This is the current behavior of Firefox for HTTPS -> HTTP nagivations.)
"origin" - As specified in the wiki. (This would change Firefox's HTTPS -> HTTP behavior to disclose the scheme, host, and port where it currently does not do so, and it would change Firefox's behavior to disclose less in all other cases.)
"default" - For HTTPS -> HTTP navigations, do not send any Referer header; otherwise, treat like "origin". (This discloses less information in the Referer header than what is specified in the wiki.)
"always" - Same as "origin". (This discloses less information in the Referer header than what the wiki recommends.)
any other value (or missing): Same as "default", which is what the wiki specifies.
IMPORTANT NOTE: In case it isn't clear, my proposal is suggesting that we shorten our default Referer header by default to sends only the origin (e.g. http://example.org:123/ instead of http://example.org:123/path?query#fragment), and that we allow sites to opt in to sending the origin for HTTPS -> HTTP navigations.
I can foresee the argument that we shouldn't interpret "always" or "default" differently than what the wiki specifies, because a site could always use the query parameters and redirects trick to disclose the information we are trying to prevent disclosure of. That is true, but in order to use that redirect trick, they would have to suffer a performance penalty. I think that is OK, as long as we are able to allow sites that do something reasonably privacy-preserving (stripping the path, query, and fragment) to avoid that penalty. Also note that Google's and Facebook's use of the redirect shows that prohibiting the sending of the Referer header for HTTPS -> HTTP cases for values "origin" and "always" is not really a way to enforce privacy-preserving behavior. The only way to really enforce "completely" privacy-preseving behavior would be to set the default to "never", which is likely to break too much stuff. (And, regardless, strengthening the default value to "never" can be done later, after we've experimented with limiting Referer to just the origin.)
Obviously, we'd have to do a lot of measurements to see what, if anything would break with this new default policy. But, I think spending effort on that testing would be much better than spending effort on UI for new values of the Referer prefs.
Thoughts?
Cheers,
Brian
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=704320
Brian Smith
Feb 26, 2013, 10:22:08 PM2/26/13
to dev-p...@lists.mozilla.org, dev-tech-network, Gervase Markham
Brian Smith wrote:
> Also note that Google's and Facebook's use of
> the redirect shows that prohibiting the sending of the Referer
> header for HTTPS -> HTTP cases for values "origin" and "always" is
> not really a way to enforce privacy-preserving behavior.
Also, note that Google and Facebook must redirect to a *non-HTTPS* location for this hack to work. So, implementing my proposal should make it easier for them to switch on HSTS (Strict Transport Security) on more of their domains, and it should eliminate unnecessary HTTPS -> HTTP -> HTTPS transitions (e.g. https://facebook.com/ -> http://facebook.com?redirectTo=https://example.org -> https://example.org) in many cases. (Currently on facebook.com and google.com, a passive MitM cannot learn the target URL and an active MitM can alter the target of your link click.)
> Also note that Google's and Facebook's use of
> the redirect shows that prohibiting the sending of the Referer
> header for HTTPS -> HTTP cases for values "origin" and "always" is
> not really a way to enforce privacy-preserving behavior.
So, I think this proposal is +1 security, +1 performance, and +1 privacy, though with unknown compatibility risk.
Cheers,
Brian
Sid Stamm
Feb 27, 2013, 11:51:48 AM2/27/13
to Brian Smith, dev-p...@lists.mozilla.org, dev-tech-network, Gervase Markham
On 2/26/13 6:51 PM, Brian Smith wrote:
>> From
>> https://wiki.mozilla.org/Privacy/Features/Shortened_HTTP_Referer_header
>
>> 4. Requirements
>>
>> [a] Test plan must be created and implemented [b] Use cases must be
>> clearly outlined and it must be clear how the feature addresses
>> each. [c] Initially, Phase 1 (user-set) should not change default
>> behavior until user initiates change. [d] Default referer behavior
>> for sites should not change until sites activate attenuation
>> features.
>
> Should these requirements be updated?
If you think they're not correct, and you wanna drive work on this
>> From
>> https://wiki.mozilla.org/Privacy/Features/Shortened_HTTP_Referer_header
>
>> 4. Requirements
>>
>> [a] Test plan must be created and implemented [b] Use cases must be
>> clearly outlined and it must be clear how the feature addresses
>> each. [c] Initially, Phase 1 (user-set) should not change default
>> behavior until user initiates change. [d] Default referer behavior
>> for sites should not change until sites activate attenuation
>> features.
>
> Should these requirements be updated?
feature, go for it. They're pretty stale (I wrote them probably a year
ago).
> I think we should try to jump straight to making origin-only Referer
> headers the default by removing requirements [c] and [d], in the
> interests of expediency.
>
>
> I disagree with some aspects of the spec. In particular, I think the
> spec. should explicitly mention that the Referer header should be
> limited by whatever user preferences are in effect.
I agree with you here. I think, as with all site-specified configs
> I disagree with some aspects of the spec. In particular, I think the
> spec. should explicitly mention that the Referer header should be
> limited by whatever user preferences are in effect.
(their specs may or may not say how they interact with other features),
the user or user agent can always override the site's policy. My put is
that we should apply multiple layers of referrer policies to a URI in
this "trim down one layer at a time":
1. Start with raw referrer URI (ruri)
2. If there's a site-specific user-set option: strip this policy's
disallowed bits from ruri
3. If there's a browser-global user-set option: strip this policy's
disallowed bits from ruri
4. If there's a browser-global default option: strip this policy's
disallowed bits from ruri
5. If there's a site-specified policy: strip this policy's disallowed
bits from ruri
6. Use whatever's left of ruri
(There's probably a more efficient mechanism to obtain the smallest
allowable referrer, but this was just how I process it in my brain.)
> With that out of the way, I propose that Firefox use the following
> interpretation of the values of the <meta referrer> header:
>
> "never" - As specified in the wiki; do not send the Referer header.
> (This is the current behavior of Firefox for HTTPS -> HTTP
> nagivations.)
>
> "origin" - As specified in the wiki. (This would change Firefox's
> HTTPS -> HTTP behavior to disclose the scheme, host, and port where
> it currently does not do so, and it would change Firefox's behavior
> to disclose less in all other cases.)
>
> "default" - For HTTPS -> HTTP navigations, do not send any Referer
> header; otherwise, treat like "origin". (This discloses less
> information in the Referer header than what is specified in the
> wiki.)
>
> "always" - Same as "origin". (This discloses less information in the
> Referer header than what the wiki recommends.)
>
> any other value (or missing): Same as "default", which is what the
> wiki specifies.
>
> IMPORTANT NOTE: In case it isn't clear, my proposal is suggesting
> that we shorten our default Referer header by default to sends only
> the origin (e.g. http://example.org:123/ instead of
> http://example.org:123/path?query#fragment), and that we allow sites
> to opt in to sending the origin for HTTPS -> HTTP navigations.
It seems you're recommending throwing away fragment and path from all
referrers with no way to get it back...
If we're worried about breakage, we could implement something less
abrasive than that now (default policy doesn't change, for example) and
then experiment with changing the defaults. In the short term we would
get controls into the hands of users/add-ons that want them (and sites)
and in the long term we could explore adjusting the default.
-Sid
Sid Stamm
Feb 27, 2013, 11:51:48 AM2/27/13
to Brian Smith, dev-tech-network, Gervase Markham, dev-p...@lists.mozilla.org
On 2/26/13 6:51 PM, Brian Smith wrote:
>> From
>> https://wiki.mozilla.org/Privacy/Features/Shortened_HTTP_Referer_header
>
>> 4. Requirements
>>
>> [a] Test plan must be created and implemented [b] Use cases must be
>> clearly outlined and it must be clear how the feature addresses
>> each. [c] Initially, Phase 1 (user-set) should not change default
>> behavior until user initiates change. [d] Default referer behavior
>> for sites should not change until sites activate attenuation
>> features.
>
> Should these requirements be updated?
>> https://wiki.mozilla.org/Privacy/Features/Shortened_HTTP_Referer_header
>
>> 4. Requirements
>>
>> [a] Test plan must be created and implemented [b] Use cases must be
>> clearly outlined and it must be clear how the feature addresses
>> each. [c] Initially, Phase 1 (user-set) should not change default
>> behavior until user initiates change. [d] Default referer behavior
>> for sites should not change until sites activate attenuation
>> features.
>
> Should these requirements be updated?
If you think they're not correct, and you wanna drive work on this
feature, go for it. They're pretty stale (I wrote them probably a year
ago).
feature, go for it. They're pretty stale (I wrote them probably a year
ago).
> I think we should try to jump straight to making origin-only Referer
> headers the default by removing requirements [c] and [d], in the
> interests of expediency.
>
>[snip]
> headers the default by removing requirements [c] and [d], in the
> interests of expediency.
>
>
> I disagree with some aspects of the spec. In particular, I think the
> spec. should explicitly mention that the Referer header should be
> limited by whatever user preferences are in effect.
> I disagree with some aspects of the spec. In particular, I think the
> spec. should explicitly mention that the Referer header should be
> limited by whatever user preferences are in effect.
I agree with you here. I think, as with all site-specified configs
(their specs may or may not say how they interact with other features),
the user or user agent can always override the site's policy. My put is
that we should apply multiple layers of referrer policies to a URI in
this "trim down one layer at a time":
1. Start with raw referrer URI (ruri)
2. If there's a site-specific user-set option: strip this policy's
disallowed bits from ruri
3. If there's a browser-global user-set option: strip this policy's
disallowed bits from ruri
4. If there's a browser-global default option: strip this policy's
disallowed bits from ruri
5. If there's a site-specified policy: strip this policy's disallowed
bits from ruri
6. Use whatever's left of ruri
(There's probably a more efficient mechanism to obtain the smallest
allowable referrer, but this was just how I process it in my brain.)
(their specs may or may not say how they interact with other features),
the user or user agent can always override the site's policy. My put is
that we should apply multiple layers of referrer policies to a URI in
this "trim down one layer at a time":
1. Start with raw referrer URI (ruri)
2. If there's a site-specific user-set option: strip this policy's
disallowed bits from ruri
3. If there's a browser-global user-set option: strip this policy's
disallowed bits from ruri
4. If there's a browser-global default option: strip this policy's
disallowed bits from ruri
5. If there's a site-specified policy: strip this policy's disallowed
bits from ruri
6. Use whatever's left of ruri
(There's probably a more efficient mechanism to obtain the smallest
allowable referrer, but this was just how I process it in my brain.)
> With that out of the way, I propose that Firefox use the following
> interpretation of the values of the <meta referrer> header:
>
> "never" - As specified in the wiki; do not send the Referer header.
> (This is the current behavior of Firefox for HTTPS -> HTTP
> nagivations.)
>
> "origin" - As specified in the wiki. (This would change Firefox's
> HTTPS -> HTTP behavior to disclose the scheme, host, and port where
> it currently does not do so, and it would change Firefox's behavior
> to disclose less in all other cases.)
>
> "default" - For HTTPS -> HTTP navigations, do not send any Referer
> header; otherwise, treat like "origin". (This discloses less
> information in the Referer header than what is specified in the
> wiki.)
>
> "always" - Same as "origin". (This discloses less information in the
> Referer header than what the wiki recommends.)
>
> any other value (or missing): Same as "default", which is what the
> wiki specifies.
>
> IMPORTANT NOTE: In case it isn't clear, my proposal is suggesting
> that we shorten our default Referer header by default to sends only
> the origin (e.g. http://example.org:123/ instead of
> http://example.org:123/path?query#fragment), and that we allow sites
> to opt in to sending the origin for HTTPS -> HTTP navigations.
> interpretation of the values of the <meta referrer> header:
>
> "never" - As specified in the wiki; do not send the Referer header.
> (This is the current behavior of Firefox for HTTPS -> HTTP
> nagivations.)
>
> "origin" - As specified in the wiki. (This would change Firefox's
> HTTPS -> HTTP behavior to disclose the scheme, host, and port where
> it currently does not do so, and it would change Firefox's behavior
> to disclose less in all other cases.)
>
> "default" - For HTTPS -> HTTP navigations, do not send any Referer
> header; otherwise, treat like "origin". (This discloses less
> information in the Referer header than what is specified in the
> wiki.)
>
> "always" - Same as "origin". (This discloses less information in the
> Referer header than what the wiki recommends.)
>
> any other value (or missing): Same as "default", which is what the
> wiki specifies.
>
> IMPORTANT NOTE: In case it isn't clear, my proposal is suggesting
> that we shorten our default Referer header by default to sends only
> the origin (e.g. http://example.org:123/ instead of
> http://example.org:123/path?query#fragment), and that we allow sites
> to opt in to sending the origin for HTTPS -> HTTP navigations.
Asa Dotzler
Mar 1, 2013, 3:39:21 PM3/1/13
to
us tackle with Firefox.
I agree that this is +1 security, performance, and privacy and I think
we s could mitigate and manage compatibility better if our initial
approach was simply to implement the feature for websites (and perhaps
Firefox users through a preference setting) without actually changing
the default way Firefox handles referrers.
Over time, and as we learn more about the impact of the changes, we can
consider changing Firefox's default behavior.
- A
Dan Auerbach
Mar 6, 2013, 4:16:13 PM3/6/13
to dev-p...@lists.mozilla.org
> dev-privacy mailing list
> dev-p...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-privacy
I am excited that there is movement on this list about updating referer
policies. I agree with Brian's approach, but also with Ada's idea that
we need not limit sending full URLs by default on the first pass, though
think it would be a good goal.
Regarding user preference settings, this patch I wrote has been sitting
for a couple of months:
https://bugzilla.mozilla.org/show_bug.cgi?id=822869. Now that the
third-party cookie change is out of the spotlight, I'd love to get back
to work on getting this patch pushed over the coming week or two. I am
happy to take suggestions and guidance for refactoring and testing, and
will look at this more today, i.e. rebuild Firefox with the patch and
make sure that it still works, and think about refactoring and testing.
I'd also be happy to take a stab at editing the wiki
(https://wiki.mozilla.org/Privacy/Features/Shortened_HTTP_Referer_header) based
on the current list discussion and proposals that I've read related both
to user options and website options for sending limited referers.
One concrete question: Sid, in the wiki, you list both scheme and port
as pieces of the URL that you'd want included in the referer. It seems
to me that the common use cases will be http and https, in which case
port will almost always give no additional information. Is there any
reason I'm missing for why this is important?
Thanks,
--
Dan Auerbach
Staff Technologist
Electronic Frontier Foundation
d...@eff.org
415 436 9333 x134
Dan Auerbach
Mar 6, 2013, 4:19:25 PM3/6/13
to dev-p...@lists.mozilla.org
On 03/06/2013 01:16 PM, Dan Auerbach wrote:
> On 03/01/2013 12:39 PM, Asa Dotzler wrote:
> On 03/01/2013 12:39 PM, Asa Dotzler wrote:
>> _______________________________________________
>> dev-privacy mailing list
>> dev-p...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-privacy
> I am excited that there is movement on this list about updating referer
> policies. I agree with Brian's approach, but also with Ada's
(Asa -- apologies!)
>> dev-privacy mailing list
>> dev-p...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-privacy
> I am excited that there is movement on this list about updating referer
> policies. I agree with Brian's approach, but also with Ada's
Sid Stamm
Mar 6, 2013, 7:20:06 PM3/6/13
to Dan Auerbach
On 03/06/2013 01:16 PM, Dan Auerbach wrote:
> One concrete question: Sid, in the wiki, you list both scheme and port
> as pieces of the URL that you'd want included in the referer. It seems
> to me that the common use cases will be http and https, in which case
> port will almost always give no additional information. Is there any
> reason I'm missing for why this is important?
Not all HTTP and HTTPs servers operate on the same port. Port only
> as pieces of the URL that you'd want included in the referer. It seems
> to me that the common use cases will be http and https, in which case
> port will almost always give no additional information. Is there any
> reason I'm missing for why this is important?
needs to be included if it's nonstandard (that's the current URL
behavior in Firefox). But if it is nonstandard, that's important. Two
HTTPS servers running on port 443 and 444 should have different origins,
and thus be different referrers.
So maybe it should be scheme://host[:port] where port is optional, but
required when it is nonstandard for the given scheme.
-Sid
Dan Auerbach
Mar 6, 2013, 7:35:40 PM3/6/13
to dev-p...@lists.mozilla.org
should be there when it's non-standard.
>
>
> -Sid
> _______________________________________________
> dev-privacy mailing list
> dev-p...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-privacy
> dev-privacy mailing list
> dev-p...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-privacy
Ben Bucksch
Feb 9, 2014, 8:56:50 PM2/9/14
to
(This is re-opening a thread that started in Feb 2013.)
https://bugzilla.mozilla.org/show_bug.cgi?id=822869
In Nov 2013, we got a number of new referer options that allow to limit
the referer to the hostname only, or to the same domain only.
https://bugzilla.mozilla.org/show_bug.cgi?id=970136
A request to not pass any information between sites, but keep maximum
compatibility.
https://bugzilla.mozilla.org/show_bug.cgi?id=970092
There's a request to make a shortened referer the default for Firefox.
I argue this is important for privacy to not leak any data from site B
to site A. So, I think the option proposed in bug 970136 should be the
default.
https://bugzilla.mozilla.org/show_bug.cgi?id=822869
In Nov 2013, we got a number of new referer options that allow to limit
the referer to the hostname only, or to the same domain only.
https://bugzilla.mozilla.org/show_bug.cgi?id=970136
A request to not pass any information between sites, but keep maximum
compatibility.
https://bugzilla.mozilla.org/show_bug.cgi?id=970092
There's a request to make a shortened referer the default for Firefox.
I argue this is important for privacy to not leak any data from site B
to site A. So, I think the option proposed in bug 970136 should be the
default.
Brian Smith
Dec 4, 2014, 10:30:46 PM12/4/14
to Dan Auerbach, Ben Bucksch, dev-p...@lists.mozilla.org
On Sun, Feb 9, 2014 at 8:26 PM, Dan Auerbach <dtaue...@gmail.com> wrote:
> Increasing the granularity of referer options seems like a positive
> thing overall and I have no objection to this proposal. However, I'm
> curious if you have empirical evidence to the extent to which sending
> the current host's root keeps certain hosts happy? I ask because my
> intuition is that the vast majority of cases where a referer "needs"
> to be sent occur in requests within the same domain (e.g. CSRF+HTTPS
> protection, hotlinking prevention), and hence setting
> network.http.referer.XOriginPolicy ought to do the trick.
>
> In any case, now that 822869 has finally landed (woo!) it would be
> nice to do some testing to arrive at the most restrictive policy we
> can get away with with a minimum of breakage. I'd love to hear from
> the privacy team at Mozilla about the best way to test and push this
> forward.
Hello friends,
I have written down the beginnings of an improved Referrer policy here:
https://briansmith.org/referrer-01.html
It goes quite far beyond the policy I suggested last year in this
thread. Although I wrote it in a way that is more oriented towards
preventing security problems, it also has (IMNSHO) very good privacy
properties as well.
I believe that now there is sufficient infrastructure in Firefox
Nightly, thanks to Sid Stamm's recent work, to implement such a
policy. Now seems like a great time to do so, especially considering
that the W3C WebAppSec working group is trying to standardize
browsers' referrer policies now; see
https://www.w3.org/TR/referrer-policy/.
I am curious about what others think.
Cheers,
Brian
> Increasing the granularity of referer options seems like a positive
> thing overall and I have no objection to this proposal. However, I'm
> curious if you have empirical evidence to the extent to which sending
> the current host's root keeps certain hosts happy? I ask because my
> intuition is that the vast majority of cases where a referer "needs"
> to be sent occur in requests within the same domain (e.g. CSRF+HTTPS
> protection, hotlinking prevention), and hence setting
> network.http.referer.XOriginPolicy ought to do the trick.
>
> In any case, now that 822869 has finally landed (woo!) it would be
> nice to do some testing to arrive at the most restrictive policy we
> can get away with with a minimum of breakage. I'd love to hear from
> the privacy team at Mozilla about the best way to test and push this
> forward.
Hello friends,
I have written down the beginnings of an improved Referrer policy here:
https://briansmith.org/referrer-01.html
It goes quite far beyond the policy I suggested last year in this
thread. Although I wrote it in a way that is more oriented towards
preventing security problems, it also has (IMNSHO) very good privacy
properties as well.
I believe that now there is sufficient infrastructure in Firefox
Nightly, thanks to Sid Stamm's recent work, to implement such a
policy. Now seems like a great time to do so, especially considering
that the W3C WebAppSec working group is trying to standardize
browsers' referrer policies now; see
https://www.w3.org/TR/referrer-policy/.
I am curious about what others think.
Cheers,
Brian
Ben Bucksch
Dec 5, 2014, 6:30:30 AM12/5/14
to Brian Smith, Dan Auerbach, dev-p...@lists.mozilla.org
Brian Smith wrote, On 05.12.2014 04:30:
> https://briansmith.org/referrer-01.html
> https://www.w3.org/TR/referrer-policy/
Thanks, Brian, for taking on this problem.
You're saying, simplified:
1. Within the same origin, you will send the entire URL as Referer.
2. Outside the origin, there'll be no Referer at all,
3. unless it's for image and JS loads within the page, and there
you send only the hostname instead of the entire URL.
The policy makes sense. I support it entirely.
Going forward, I think Referer should be dropped entirely.
1. CSRF
Launchpad and MDN maintain that they need the Referer to prevent
Cross-Site Request Forgery (CSRF). Your policy will hopefully keep them
working, because the referer within the same site is sent. We'll have to
look out for OpenID etc..
https://bugzilla.mozilla.org/show_bug.cgi?id=446344#c58
I think what sites need is just an enum: Only one of the values:
"Same-Host", "Same-Domain", "Cross-site".
Either way, we need to think about giving sites another way to avoid the
attacks. Referer gives them that, but there are plenty of alternate
approaches. It may not need to use Origin at all, but be an entirely
different way. For the site, it's just important that it's automatic
across their site, that they don't have to adapt each and every form on
their site.
> https://briansmith.org/referrer-01.html
> https://www.w3.org/TR/referrer-policy/
Thanks, Brian, for taking on this problem.
You're saying, simplified:
1. Within the same origin, you will send the entire URL as Referer.
2. Outside the origin, there'll be no Referer at all,
3. unless it's for image and JS loads within the page, and there
you send only the hostname instead of the entire URL.
The policy makes sense. I support it entirely.
Going forward, I think Referer should be dropped entirely.
1. CSRF
Launchpad and MDN maintain that they need the Referer to prevent
Cross-Site Request Forgery (CSRF). Your policy will hopefully keep them
working, because the referer within the same site is sent. We'll have to
look out for OpenID etc..
https://bugzilla.mozilla.org/show_bug.cgi?id=446344#c58
I think what sites need is just an enum: Only one of the values:
"Same-Host", "Same-Domain", "Cross-site".
Either way, we need to think about giving sites another way to avoid the
attacks. Referer gives them that, but there are plenty of alternate
approaches. It may not need to use Origin at all, but be an entirely
different way. For the site, it's just important that it's automatic
across their site, that they don't have to adapt each and every form on
their site.
Gervase Markham
Dec 9, 2014, 5:38:44 AM12/9/14
to
On 05/12/14 03:30, Brian Smith wrote:
> I am curious about what others think.
Sounds good, but the $64,000 question is the effect on web compat.
> I am curious about what others think.
Clearly, you've tried to take that into account via anecdote, but
presumably not by testing?
Perhaps we could implement this and try it on nightly and Aurora and see
what breaks. We'd need good console logging for situations where we had
changed behaviour.
Gerv
Mike West
Dec 9, 2014, 6:44:17 AM12/9/14
to Gervase Markham, ben.buck...@beonex.com, dtaue...@gmail.com, Brian Smith, dev-p...@lists.mozilla.org
On Tue, Dec 9, 2014 at 11:38 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 05/12/14 03:30, Brian Smith wrote:
> > I am curious about what others think.
>
> Sounds good, but the $64,000 question is the effect on web compat.
> Clearly, you've tried to take that into account via anecdote, but
> presumably not by testing?
>
The $64,[insert a few more zeros] question regarding web compatibility is
> On 05/12/14 03:30, Brian Smith wrote:
> > I am curious about what others think.
>
> Sounds good, but the $64,000 question is the effect on web compat.
> Clearly, you've tried to take that into account via anecdote, but
> presumably not by testing?
>
the (not particularly visible) effect on monetization. I've been talking
with folks here at Google for a little while about a coincidentally similar
proposal;
http://lists.w3.org/Archives/Public/public-webappsec/2014Dec/0027.html
sketches out some of the concerns I've heard.
> Perhaps we could implement this and try it on nightly and Aurora and see
> what breaks. We'd need good console logging for situations where we had
> changed behaviour.
>
a good thing to do! I hope, however, that you'll be able to take
ecosystem/monetization/[buzzword] concerns into consideration when doing
so. Those impacts aren't often clear strictly from the client side.
-mike
--
Mike West <mk...@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
0 new messages