Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: On CURLOPT_AUTOREFERER privacy
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt <litt_at_acm.org>
Date: Mon, 17 Oct 2022 10:09:32 -0400
On 17-Oct-22 09:46, Daniel Stenberg via curl-library wrote:
> Hello,
>
> When setting the CURLOPT_AUTOREFERER option, libcurl automatically
> sets the referer: header in following request (like when following
> redirects) to the URL of the previous transfer.
>
> This can be considered a minor privacy leak, especially when
> folllowing requests cross-orgin and to an insecure protocol such as HTTP.
>
> I propose we change this accordingly:
>
> 1 - make CURLOPT_AUTOREFERER default to only set the orgin in the
> header,
> which means hiding the path and query parts.
>
> 2 - offer a new value (2) for CURLOPT_AUTOREFERER to make it behave
> like it
> does today: including the full URL
>
> Longer term, we could consider supporting the Referrer-Policy header
> which allows sites to decide this policy.
>
> My initial PR for this work: https://github.com/curl/curl/pull/9750
>
Why change the default behavior?
I know that some sites change their behavior depending on where the
browser is coming from. Even to the level of the path. (Though it's
hard to referer in the general case, a per-response path, like a hash,
is one substitute for the more visible cookie...)
The default is OFF, so if someone set this option, they want the data -
privacy or not. It's a good assumption that someone expects the full
referer header. Doesn't make sense to break them. (Consider such an
app linked against libcurl, which then is upgraded to the new semantics
for the old option.)
I agree that a version that strips the origin is a good idea, but it
should have the new value.
Curl is generally careful about breaking compatibility. I don't see a
strong argument for doing so here. As you say, this is a "minor"
privacy issue. Long-standing at that.
Yes, long-term Referrer-Policy seems like a good idea.
Ah, for simpler times...
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Received on 2022-10-17
Date: Mon, 17 Oct 2022 10:09:32 -0400
On 17-Oct-22 09:46, Daniel Stenberg via curl-library wrote:
> Hello,
>
> When setting the CURLOPT_AUTOREFERER option, libcurl automatically
> sets the referer: header in following request (like when following
> redirects) to the URL of the previous transfer.
>
> This can be considered a minor privacy leak, especially when
> folllowing requests cross-orgin and to an insecure protocol such as HTTP.
>
> I propose we change this accordingly:
>
> 1 - make CURLOPT_AUTOREFERER default to only set the orgin in the
> header,
> which means hiding the path and query parts.
>
> 2 - offer a new value (2) for CURLOPT_AUTOREFERER to make it behave
> like it
> does today: including the full URL
>
> Longer term, we could consider supporting the Referrer-Policy header
> which allows sites to decide this policy.
>
> My initial PR for this work: https://github.com/curl/curl/pull/9750
>
Why change the default behavior?
I know that some sites change their behavior depending on where the
browser is coming from. Even to the level of the path. (Though it's
hard to referer in the general case, a per-response path, like a hash,
is one substitute for the more visible cookie...)
The default is OFF, so if someone set this option, they want the data -
privacy or not. It's a good assumption that someone expects the full
referer header. Doesn't make sense to break them. (Consider such an
app linked against libcurl, which then is upgraded to the new semantics
for the old option.)
I agree that a version that strips the origin is a good idea, but it
should have the new value.
Curl is generally careful about breaking compatibility. I don't see a
strong argument for doing so here. As you say, this is a "minor"
privacy issue. Long-standing at that.
Yes, long-term Referrer-Policy seems like a good idea.
Ah, for simpler times...
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature