Block cookies/images from whole domain

Discussion of features in Seamonkey
guanxi
Posts: 399
Joined: April 6th, 2003, 11:15 am

Block cookies/images from whole domain

Post by guanxi »

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.
Sander
Posts: 634
Joined: November 5th, 2002, 5:35 am
Location: The Netherlands, when not travelling

Post by Sander »

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)
old jasonb
Moderator
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Re: Block cookies/images from whole domain

Post by old jasonb »

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.)
Sander
Posts: 634
Joined: November 5th, 2002, 5:35 am
Location: The Netherlands, when not travelling

Post by Sander »

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.
guanxi
Posts: 399
Joined: April 6th, 2003, 11:15 am

Post by guanxi »

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.
old jasonb
Moderator
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post by old jasonb »

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.)
CappuchinoMan
Posts: 223
Joined: November 14th, 2002, 5:50 pm

Post by CappuchinoMan »

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.
old jasonb
Moderator
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post by old jasonb »

As an additional note, I agree that blocking "this and everything underneath" should be a checkbox. In cookperm.txt (and in the cookie manager) it should take the form of *.domain.com. Only if the wildcard is there does it act for everything underneath it.
dwitte
Posts: 11
Joined: January 25th, 2003, 10:18 am

Post by dwitte »

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.
guanxi
Posts: 399
Joined: April 6th, 2003, 11:15 am

Post by guanxi »

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).
Sander
Posts: 634
Joined: November 5th, 2002, 5:35 am
Location: The Netherlands, when not travelling

Post by Sander »

guanxi wrote:Sander:
Good point re: the images. Perhaps it should apply to cookies only, which was the example in my mind.
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. :)

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.
old jasonb
Moderator
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post by old jasonb »

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.
Sander
Posts: 634
Joined: November 5th, 2002, 5:35 am
Location: The Netherlands, when not travelling

Post by Sander »

and duped. :) search strategy: "manager add" to find another dupe, then following that.
dwitte
Posts: 11
Joined: January 25th, 2003, 10:18 am

Post by dwitte »

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.
guanxi
Posts: 399
Joined: April 6th, 2003, 11:15 am

Post by guanxi »

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!
Post Reply