Block cookies/images from whole domain
-
- Posts: 399
- Joined: April 6th, 2003, 11:15 am
Block cookies/images from whole domain
I propose cookie/image blocker blacklist whole domains (*.domain.com) instead of just servers. And hey, I thought I'd follow my own advice and discuss a potentially controversial bug in a forum before firing up the Bugzilla spam engine.
* CURRENT STATE:
Bug 176950 adds the ability to blacklist the current server and all servers further down the hierarchy. For example, if you block a cookie from server.domain.com, you can choose to also blacklist cookies from *.server.domain.com.
* PROPOSED FEATURE
The option should be for the user to simply block *.domain.com. Why?
1) Depending on how the servers are named, the feature added in bug 176950 often won't help at all. For example, some services like hitbox name their servers as follows and we blacklist nothing useful:
10.clientname.hitbox.com
11.clientname.hitbox.com
etc.
2) The current state assumes non-geek users understand hierarchical server naming; they don't. In my experience, hierarchical naming is a consistent source of disconnect between geeks and most users: They don't get it, whether it's directory structures & paths, domain names, etc. I don't know why, because it seems simple to me, but it's my universal experience from many years of supporting them. They'll say, 'I already blocked hotbox.com, why isn't it working?'
They probably would understand 'block everything from hitbox.com': i.e. They may not understand the hierarchy, but they can see the image/cookie is from 'hitbox.com' and they're used to dealing with domain names.
3) Some real world experience: Before Moz, with NS 4.x I used CookiePal by Kookabura software (kburra.com). It blocked individual cookies or, if you checked a box in the cookie confirmation dialog, complete domains. I don't recall problems caused by blocking whole domains, but maybe I avoided the mistakes typical users would make.
* WHY IS THIS CONTROVERSIAL?
Well, controversial may be overstatement. In comment#14 of bug 176950, Dan Witte, the developer, wrote:
"it's difficult to have an automatic "block from this domain" kind of option,
because it's not trivial to determine what that domain should be; further, it
might not be intuitive to all users, and unneccessarily complicates things."
Instead of debating on Bugzilla, or just filing an RFE, I thought we'd discuss it first.
* CURRENT STATE:
Bug 176950 adds the ability to blacklist the current server and all servers further down the hierarchy. For example, if you block a cookie from server.domain.com, you can choose to also blacklist cookies from *.server.domain.com.
* PROPOSED FEATURE
The option should be for the user to simply block *.domain.com. Why?
1) Depending on how the servers are named, the feature added in bug 176950 often won't help at all. For example, some services like hitbox name their servers as follows and we blacklist nothing useful:
10.clientname.hitbox.com
11.clientname.hitbox.com
etc.
2) The current state assumes non-geek users understand hierarchical server naming; they don't. In my experience, hierarchical naming is a consistent source of disconnect between geeks and most users: They don't get it, whether it's directory structures & paths, domain names, etc. I don't know why, because it seems simple to me, but it's my universal experience from many years of supporting them. They'll say, 'I already blocked hotbox.com, why isn't it working?'
They probably would understand 'block everything from hitbox.com': i.e. They may not understand the hierarchy, but they can see the image/cookie is from 'hitbox.com' and they're used to dealing with domain names.
3) Some real world experience: Before Moz, with NS 4.x I used CookiePal by Kookabura software (kburra.com). It blocked individual cookies or, if you checked a box in the cookie confirmation dialog, complete domains. I don't recall problems caused by blocking whole domains, but maybe I avoided the mistakes typical users would make.
* WHY IS THIS CONTROVERSIAL?
Well, controversial may be overstatement. In comment#14 of bug 176950, Dan Witte, the developer, wrote:
"it's difficult to have an automatic "block from this domain" kind of option,
because it's not trivial to determine what that domain should be; further, it
might not be intuitive to all users, and unneccessarily complicates things."
Instead of debating on Bugzilla, or just filing an RFE, I thought we'd discuss it first.
-
- Posts: 634
- Joined: November 5th, 2002, 5:35 am
- Location: The Netherlands, when not travelling
I know a lot of useful sites, having useful images I want to see, which serve some images I don't want to see from seperate subdomains (ads.usefulsite.com). Automatically having blocked all images when I just want to block the banners is not a good idea.
The default as it is is good enough IMO - there aren't enough massively used providers of annoying content with tons of subdomains to make changing that worth it. (hitbox, doubleclick and fastclick - that's about it.)
(And of course, determining said domain will remain problematic. You don't want to block everything from .co.uk)
The default as it is is good enough IMO - there aren't enough massively used providers of annoying content with tons of subdomains to make changing that worth it. (hitbox, doubleclick and fastclick - that's about it.)
(And of course, determining said domain will remain problematic. You don't want to block everything from .co.uk)
-
- Moderator
- Posts: 0
- Joined: December 31st, 1969, 5:00 pm
Re: Block cookies/images from whole domain
guanxi wrote:I propose cookie/image blocker blacklist whole domains (*.domain.com) instead of just servers.
As of bug 176950, checked in on 4/4, that's exactly how Mozilla now behaves. Any image that you block will also block any other image from that domain or any of its subdomains. (E.g. Blocking an image from foo.bar blocks all images from *.foo.bar.)
-
- Posts: 634
- Joined: November 5th, 2002, 5:35 am
- Location: The Netherlands, when not travelling
Jason, you're not reading what's being asked. :) Instead of rightclicking on an image at ads.domain.com and blocking that domain plus (now) all subdomains of ads.domain.com, gunxi proposes to right from the start block everything from domain.com when clicking on that very same image (even though the image itself is not hosted at that toplevel of the domain).
The idea behind this is that there are some services (like doubleclick.net) which have a gazillion subdomains in use at different websites that you'd all want to block.
The idea behind this is that there are some services (like doubleclick.net) which have a gazillion subdomains in use at different websites that you'd all want to block.
-
- Posts: 399
- Joined: April 6th, 2003, 11:15 am
Sander:
Good point re: the images. Perhaps it should apply to cookies only, which was the example in my mind.
Parsing the correct domain shouldn't be too hard, AFAICT. With .com/.org/.net/.edu/etc. it's the top two levels. With the country TLDs (.uk, .us, etc) could we use the top three levels? Maybe we need a more complicated algorithm, and exceptions would always exist but the user would have the option and nothing is perfect.
Also, to clarify: I'm suggesting a checkbox; it shouldn't blacklist the whole domain automatically.
Good point re: the images. Perhaps it should apply to cookies only, which was the example in my mind.
Parsing the correct domain shouldn't be too hard, AFAICT. With .com/.org/.net/.edu/etc. it's the top two levels. With the country TLDs (.uk, .us, etc) could we use the top three levels? Maybe we need a more complicated algorithm, and exceptions would always exist but the user would have the option and nothing is perfect.
Also, to clarify: I'm suggesting a checkbox; it shouldn't blacklist the whole domain automatically.
-
- Moderator
- Posts: 0
- Joined: December 31st, 1969, 5:00 pm
Sander wrote:Jason, you're not reading what's being asked. :)
Yes, I am. Or at least one interpretation of it. <grin> The question was, "[How can I block] whole domains (*.domain.com) instead of just servers." That bug I mentioned does just that. It blocks *.domain.com, not just domain.com.
guanxi is slightly mistating the bug. He says that currently you can block "the current server and all servers further down the hierarchy". That's not completely true. Currently, you can block the current server and/or domain and all servers and/or subdomains down the hierarchy. It may be thought of to mean the same thing, but it's an important distinction. (Also, I'll admit I may have been guilty of treating "domain" in the original question as "subdomain".)
However, I do see the point. The further issue is, how can I block all cookies from domain.com even though the cookie I'm currently blocking is from host.domain.com? Currently, the only way to block something you haven't yet encountered is to hand-edit cookperm.txt. Ideally (and this is the RFE that should be introduced if it doesn't already exist - and I haven't actually looked for it), we should be able to manually add entries to the cookies manager via the GUI. (So, in this case, we could add domain.com and the entire domain (with its servers and subdomains) would be blocked.)
-
- Posts: 223
- Joined: November 14th, 2002, 5:50 pm
It's amazing that whoever's working on the code for cookie handling cannot pay attention to the gold standard of third party utilities, Cookie Pal. The current situation isn't very efficient, in my opinion. Not only do I agree that you need a checkbox choice for whether you want the whole domain blocked, the cookie dialog should ask whether to accept the cookie and have four choices, Yes, Always, No, Never. The cookie manager should show a log of the Time when the cookie was accepted or rejected so that the user can undo any problems from having blocked the wrong cookie.
-
- Moderator
- Posts: 0
- Joined: December 31st, 1969, 5:00 pm
-
- Posts: 11
- Joined: January 25th, 2003, 10:18 am
guanxi: thanks for taking this to mozillazine - it's a far better forum for user input than bugzilla, because it's more accessible.
perhaps I should clarify some things: guanxi said that bug 176950 was an "option you could select". this isn't the case - it replaces the old behavior of our permissions backend. previously, if you blocked the host "foo.com", only things from that host would be blocked - not "images.foo.com" for instance. our new behavior is to block all subdomains, so the latter example would now be blocked. I think this makes the permission backend more useful and logical; but of course I've only presented the good side of the coin.
as guanxi quoted me as saying, it's not trivial to determine the "canonical domain" for a given host - e.g. for x.foo.com, or x.foo.net it's simple; you just take the last two subdomain levels. but what about foo.co.nz? implementing this is fraught with difficulties - DNS is not a nice place to play, and putting this in the backend would be a significant effort. and for what? most users probably wouldn't understand it. I think this "feature" would be a case of "mozilla trying to be too smart".
if we implement the ability for users to add sites manually to the permissions list, that might be a good alternative. so if you have the "ask me before accepting a cookie" pref set, it allows you to specify the host to block manually. or you could have an option in the tools menu, "add permission entry for specified site...", maybe an extension of the cookie/image/popup selections in there now. however, these UI features will have to wait until we can devise a sensible implementation.
perhaps I should clarify some things: guanxi said that bug 176950 was an "option you could select". this isn't the case - it replaces the old behavior of our permissions backend. previously, if you blocked the host "foo.com", only things from that host would be blocked - not "images.foo.com" for instance. our new behavior is to block all subdomains, so the latter example would now be blocked. I think this makes the permission backend more useful and logical; but of course I've only presented the good side of the coin.
as guanxi quoted me as saying, it's not trivial to determine the "canonical domain" for a given host - e.g. for x.foo.com, or x.foo.net it's simple; you just take the last two subdomain levels. but what about foo.co.nz? implementing this is fraught with difficulties - DNS is not a nice place to play, and putting this in the backend would be a significant effort. and for what? most users probably wouldn't understand it. I think this "feature" would be a case of "mozilla trying to be too smart".
if we implement the ability for users to add sites manually to the permissions list, that might be a good alternative. so if you have the "ask me before accepting a cookie" pref set, it allows you to specify the host to block manually. or you could have an option in the tools menu, "add permission entry for specified site...", maybe an extension of the cookie/image/popup selections in there now. however, these UI features will have to wait until we can devise a sensible implementation.
-
- Posts: 399
- Joined: April 6th, 2003, 11:15 am
Like CappuchinoMan, I found the equivalent feature in Cookie Pal to be very efficient and problem free. CM also describes a much better interface than I did (with buttons: No/Never/Yes/Always). However, I'm certainly not criticizing the developer who donated the feature in the first place.
Unless there's more support for it, I'm not adding an RFE for blocking domains.
As for manually entering sites into the blacklist, it's not my favorite solution but some ideas:
o Make cookieperm.txt editable, with wildcard functionality (if it's not already) and omit the GUI. Users advanced enough to manually enter sites won't have a problem editing cookieperm.txt, and we need to limit the complexity of prefs gui.
o Maybe add an [Advanced ...] button deep in prefs that opens cookieperm.txt in the default text editor, to make it 'discoverable'.
o A different tack, though maybe this is what dwitte meant: when the cookie confirmation dialog appears, make the host field editable. So if it says, 'block all cookies from *.server.domain.com?' Allow the user to edit *.server.domain.com right then.
I still miss Cookie Pal (kburra.com/cpal.html).
Unless there's more support for it, I'm not adding an RFE for blocking domains.
As for manually entering sites into the blacklist, it's not my favorite solution but some ideas:
o Make cookieperm.txt editable, with wildcard functionality (if it's not already) and omit the GUI. Users advanced enough to manually enter sites won't have a problem editing cookieperm.txt, and we need to limit the complexity of prefs gui.
o Maybe add an [Advanced ...] button deep in prefs that opens cookieperm.txt in the default text editor, to make it 'discoverable'.
o A different tack, though maybe this is what dwitte meant: when the cookie confirmation dialog appears, make the host field editable. So if it says, 'block all cookies from *.server.domain.com?' Allow the user to edit *.server.domain.com right then.
I still miss Cookie Pal (kburra.com/cpal.html).
-
- Posts: 634
- Joined: November 5th, 2002, 5:35 am
- Location: The Netherlands, when not travelling
Ok, for cookies I can agree. Of course, with whitelisting coming to a favorite browser near you RSN I don't think I'll care very much anymore. :)guanxi wrote:Sander:
Good point re: the images. Perhaps it should apply to cookies only, which was the example in my mind.
Best solution for the general problem seems to me to be 1) adding gui for manually adding a domain from the cookie/image manager (a button "add domain..." would do - this will take away the scaryness of editing cookperm.txt - and, btw, is already be a RFE, or at least I distinctly having seen it), or possibly 2) doing this from the "more details" expanded cookie information dialog, although I don't think it would fit in really well there.
-
- Moderator
- Posts: 0
- Joined: December 31st, 1969, 5:00 pm
Sander wrote:btw, is already be a RFE, or at least I distinctly having seen it
I couldn't find anything (for cookies or images) after some searching. I filed bug 201060 as an RFE to hookup an Add function to the cookie manager.
-
- Posts: 11
- Joined: January 25th, 2003, 10:18 am
guanxi wrote: o A different tack, though maybe this is what dwitte meant: when the cookie confirmation dialog appears, make the host field editable. So if it says, 'block all cookies from *.server.domain.com?' Allow the user to edit *.server.domain.com right then.
Right, that's what I meant. I've seen an RFE for it at some point but I can't find it right now. This is the most elegant solution I can see right now.
The logical extension of this would be to have "add" & "edit" features in the respective permission managers, but if we do that, it'll be further into the future.
-
- Posts: 399
- Joined: April 6th, 2003, 11:15 am
So is cookieperm.txt manually editable? With wildcard support? I'm too busy to futz around and test it right now.
For the reference of anyone who hasn't found it yet, bug 33467 is the RFE for a GUI for editing the cookie mgr blacklist.
Finally, if anyone knows the bug dwitte referred to, for making editable the server name in the cookie confirmation dialog, please don't hesitate to pass it along!
For the reference of anyone who hasn't found it yet, bug 33467 is the RFE for a GUI for editing the cookie mgr blacklist.
Finally, if anyone knows the bug dwitte referred to, for making editable the server name in the cookie confirmation dialog, please don't hesitate to pass it along!