patch: .domain cookies from/to domain
Like the patch says, /* * Technically, cookies set with a domain of .example.com cannot be sent * back to the host example.com, even if example.com set them in the first * place. Do most user agents allow it? Yes. Does a large percentage of the * web require it in order to work at all? Yes. */ The downside might be the scenario of sub.example.com setting a cookie that example.com didn't expect to receive, but if everyone else does it... Unless someone tells me not to within the next few days, I'll commit something along the lines of this patch. PS I just committed a change today to fix up expiration/replacement of cookies, which was somewhat broken in general, and especially broken with respect to session cookies, so if anyone out there uses cookies much, please test!
On Mon, Dec 28, 2009 at 01:21:41AM +0000, corvid wrote:
Like the patch says, /* * Technically, cookies set with a domain of .example.com cannot be sent * back to the host example.com, even if example.com set them in the first * place. Do most user agents allow it? Yes. Does a large percentage of the * web require it in order to work at all? Yes. */
The downside might be the scenario of sub.example.com setting a cookie that example.com didn't expect to receive, but if everyone else does it...
AFAIS it would provide a very good way for tracking what pages a user is reading to big hosting sites. e.g. blogspot.com If you're using a unique IP, it may not add much, but if you're behind a NAT or proxy or similar, this cookie singles out you. Considering most browsers allow these cookies, chances of finding tracking code using this technique increases! Probably only opaqued by the much bigger privacy hole javascript provides. :)
Unless someone tells me not to within the next few days, I'll commit something along the lines of this patch.
I'd use a cookiesrc option set to NO by default instead of the #define. Maybe allowing to set it by site (as the rest of cookiesrc) is not a bad idea too. After all, people would enable it when they need a specific site to work. -- Cheers Jorge.-
Jorge wrote:
On Mon, Dec 28, 2009 at 01:21:41AM +0000, corvid wrote:
Like the patch says, /* * Technically, cookies set with a domain of .example.com cannot be sent * back to the host example.com, even if example.com set them in the first * place. Do most user agents allow it? Yes. Does a large percentage of the * web require it in order to work at all? Yes. */
The downside might be the scenario of sub.example.com setting a cookie that example.com didn't expect to receive, but if everyone else does it...
AFAIS it would provide a very good way for tracking what pages a user is reading to big hosting sites. e.g. blogspot.com
I believe in that case, subdomains of blogspot.com would already be able to read/write a .blogspot.com cookie.
If you're using a unique IP, it may not add much, but if you're behind a NAT or proxy or similar, this cookie singles out you.
Considering most browsers allow these cookies, chances of finding tracking code using this technique increases! Probably only opaqued by the much bigger privacy hole javascript provides.
:)
Unless someone tells me not to within the next few days, I'll commit something along the lines of this patch.
I'd use a cookiesrc option set to NO by default instead of the #define.
Maybe allowing to set it by site (as the rest of cookiesrc) is not a bad idea too. After all, people would enable it when they need a specific site to work.
Setting it by site sounds like a good idea.
I realized that there's an asymmetry in the dillo code with it accepting but not sending .example.com for a host example.com, when this asymmetry is not in the spec, AFAICT. Cookies are to be rejected if the "value for the request-host does not domain-match the Domain attribute", and "Host A's name domain-matches host B's if * both host names are IP addresses and their host name strings match exactly; or * both host names are FQDN strings and their host name strings match exactly; or * A is a FQDN string and has the form NB, where N is a non-empty name string, B has the form .B', and B' is a FQDN string. (So, x.y.com domain-matches .y.com but not y.com.)" So it seems that we "shouldn't" accept them in the first place.
I wrote:
Jorge wrote:
On Mon, Dec 28, 2009 at 01:21:41AM +0000, corvid wrote:
Like the patch says, /* * Technically, cookies set with a domain of .example.com cannot be sent * back to the host example.com, even if example.com set them in the first * place. Do most user agents allow it? Yes. Does a large percentage of the * web require it in order to work at all? Yes. */
The downside might be the scenario of sub.example.com setting a cookie that example.com didn't expect to receive, but if everyone else does it...
AFAIS it would provide a very good way for tracking what pages a user is reading to big hosting sites. e.g. blogspot.com
I believe in that case, subdomains of blogspot.com would already be able to read/write a .blogspot.com cookie.
If you're using a unique IP, it may not add much, but if you're behind a NAT or proxy or similar, this cookie singles out you.
Considering most browsers allow these cookies, chances of finding tracking code using this technique increases! Probably only opaqued by the much bigger privacy hole javascript provides.
:)
Unless someone tells me not to within the next few days, I'll commit something along the lines of this patch.
I'd use a cookiesrc option set to NO by default instead of the #define.
Maybe allowing to set it by site (as the rest of cookiesrc) is not a bad idea too. After all, people would enable it when they need a specific site to work.
Setting it by site sounds like a good idea.
I'm thinking about the exact form of this now. cookiesrc could look something like example.com ACCEPT_SESSION SEND_DOTDOMAIN_COOKIES but that's weird and hard to understand. Any thoughts on how to make something decent?
On Thu, Dec 31, 2009 at 11:18:06PM +0000, corvid wrote:
I wrote:
Jorge wrote:
On Mon, Dec 28, 2009 at 01:21:41AM +0000, corvid wrote:
Like the patch says, /* * Technically, cookies set with a domain of .example.com cannot be sent * back to the host example.com, even if example.com set them in the first * place. Do most user agents allow it? Yes. Does a large percentage of the * web require it in order to work at all? Yes. */
The downside might be the scenario of sub.example.com setting a cookie that example.com didn't expect to receive, but if everyone else does it...
AFAIS it would provide a very good way for tracking what pages a user is reading to big hosting sites. e.g. blogspot.com
I believe in that case, subdomains of blogspot.com would already be able to read/write a .blogspot.com cookie.
If you're using a unique IP, it may not add much, but if you're behind a NAT or proxy or similar, this cookie singles out you.
Considering most browsers allow these cookies, chances of finding tracking code using this technique increases! Probably only opaqued by the much bigger privacy hole javascript provides.
:)
Unless someone tells me not to within the next few days, I'll commit something along the lines of this patch.
I'd use a cookiesrc option set to NO by default instead of the #define.
Maybe allowing to set it by site (as the rest of cookiesrc) is not a bad idea too. After all, people would enable it when they need a specific site to work.
Setting it by site sounds like a good idea.
I'm thinking about the exact form of this now. cookiesrc could look something like example.com ACCEPT_SESSION SEND_DOTDOMAIN_COOKIES but that's weird and hard to understand.
Any thoughts on how to make something decent?
Maybe I'm missing the point in the previous discussion, but do we really need this configurable? Why do we need to handle the host example.com differently from e.g. foo.example.com? To me it seems reasonable what other browsers do here, even if the standard states it differently.
Johannes wrote:
To me it seems reasonable what other browsers do here, even if the standard states it differently.
I've discovered that the http-state working group is actively trying to come up with something that reflects what is good and sensible for clients and servers to do. So I'm reading through their mailing list archives and all that... What I can say so far is: I was very wrong when I thought that trying to follow the cookie RFCs was good or important.
I wrote:
Johannes wrote:
To me it seems reasonable what other browsers do here, even if the standard states it differently.
I've discovered that the http-state working group is actively trying to come up with something that reflects what is good and sensible for clients and servers to do. So I'm reading through their mailing list archives and all that...
Their algorithm is that you pretend that you don't see any leading dots, and the domain-matching is done such that the .domain cookie is sent with queries to both sub.domain and domain. So that's the currently "normal" thing... Interestingly (alarmingly), only RFC cookies specify path/domain when sent from user agent to server, and, as I've said, pretty much everything ignores RFCness, so for instance if there could be a NAME=VAL1 sub.domain cookie and a NAME=VAL2 domain cookie and you have one of them, it's the task of people writing the server code to make sure they can tell what it belongs to. And if a user agent accidentally accepts/sends a cookie for a tld or something, no one will realize this. Speaking of alarming, it seems that it's normal to accept cookies for /path1 sent from /path2. That's irritating in part because I just disallowed that the other day.
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de