Closed Bug 7380 Opened 25 years ago Closed 11 years ago

Backend support for all page prefs on a URL by URL basis

Categories

(Core :: Preferences: Backend, enhancement)

Product:
Core
Component:
Preferences: Backend
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: CodeMachine, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: helpwanted) 

There is a growing call for users to be able to choose preferences that differ
on a URL by URL basis.  Examples of this from a quick search are Javascript
on/off on a domain by domain basis (bug #858), the n.p.m.wishlist threads
"Images OFF for specific web sites?" (which has some useful commentary),
"enhancement propositions" (which contains a proposal for selective cookie
acceptance), "download filters" (which contains a proposal for different
download directories), "site-specific java toggle and global (or sound toggle"
(javascript again), and the n.p.m.ui thread "Disable Javascript from specific
domains." (you guessed it).

So you could see that, even in my quick search of newsgroups, there is quite a
demand for this sort of functionality.

Turning off Javascript is popular but it shouldn't be the entire scope of this
enhancement.  The following is a list I've compiled from my head and the NC4.6
prefs dialog:

Security:  JavaScript, Java, Cookie Acceptance, Chrome Replacement.
Display: User Style Sheet, Colours, Fonts, AutoLoad Images
Other: Preferred Language, FTP Password Passing, How Often Compared To Network

Note that if you did this with proxies it would provide a more general solution
to "no proxy for:"

Obviously this would have a significant effect on Prefs, but also probably in
places like Netlib and Layout.

Handling the problem for all URLs, yet allowing regexps allows domain/file
extension matching.  A media type might also parameterise a set of prefs,
although this is not possible for all of them.

The major issue then is how to handle this in Preferences.  The aim would
certainly be to not make it harder for users who don't use it.  So how?

(a) Simply enhance all relevant widgets to allow a hierachy of patterns and pref
values (where the root node means "Default" and the most specific node is used).

If you wanted to go this route you might allow specifications of a list of
"patterns", to allow a pattern to be centrally changed.

(b) Split off these preferences from the others, with a different section, and
provide one hierachy of pattern vs. all pattern-by-pattern pref values.  You
would use stuff like tri-checkboxes to inherit the parent nodes values, and
could override some of them.  This might be simpler than (a) since many prefs
might have the same pattern hierachy.

(c) (b) is a bit constraining, since it is a single-inheritance hierachy, and
all prefs must follow a specific hierachy.  Instead you might compromise, and
allow hierachys for multiple prefs.  Hierachies for one pref would be (a) and
for all would be (b), but you could choose anywhere in between.

You would start at the root node, see if any other patterns match below it, and
if so, go down into that subtree, and so on until you can't match any children
or have reached a leaf.  Preventing multiple patterns matching at the same level
is an issue to consider.
As an addendum, I'm not in the slightest expecting this to be implemented for
the initial Moz or NS5, but it's a sort of heads up that you can point people to
who make this request, and allowing thinking about this sort of issue before it
gets implemented in an ad hoc fashion.

Perhaps it could be assigned to noone if Bugzilla allows it, as I think most
rfes not taken up by the module owner should be.  If this is not possible I
might put in an RFE to Bugzilla to allow it.  I would think this would be a
better solution than marking the rfes "later" or "resolved" or "will not be
fixed" or whatever.
Component: Apprunner → Pref UI
QA Contact: leger → cpratt
Target Milestone: M14
Move this out to M14 for now until I can slap some marketing people around ...
Summary: Support all prefs on a URL by URL basis. → [RFE] Support all prefs on a URL by URL basis
A small part of this -- the cookie part -- has already been implemented in 5.0.
Which is very cool (this is the most important imho).  When I've looked at the
Pref UI recently it looked very much like the 4.5 settings, so if it's there
I've missed it.  How will the UI for this work in 5?  I presume it will work
using scheme a, since the others are only really necessary where you have
multiple prefs on a URL basis.

It's probably fairly sensible to ensure that cookie acceptance is based on the
site rather than the URL, but I worry a bit that from a reusability point of
view this might be suboptimal.  One intention of this bug is to highlight the
fact that these are all really the same thing and should be implemented
as uniformly as possible.

Hence it would be better to try and design as much reusable framework as
possible.  This includes the prefs widgets, the back-end prefs stuff and
algorithms for determining the value.  So for example, prefs would have a call:

CookieAcceptance( "http://www.mozilla.org/status/" ) that would return the
relevant value in {Yes, OriginatingServerOnly, On} and so on.  Then there would
be another call JavaScriptOn( "http://www.mozilla.org/status" ) that would use
the same searching algorithms (explained briefly in the original report), just
for a different preference.  Or maybe it would be one procedure and take a
parameter as to which preference it concerned.  If this is not possible, feel
free to tell my why and I'll proceed to go away.  =)

Anyway, I doubt this is happening at the moment, and while it may be able to be
changed later, with all the talk of XPCOM scriptability and JS in XUL files, I'm
a bit worried that it might become impossible later.

Also, I should add "background sound on/off" onto the list of these prefs.
Here's a look at the preferences and how I feel they differ.

JavaScript - URL-By-URL
Java - URL-By-URL
Cookies - Site-By-Site
Chrome Replacement - URL-By-URL
Style Sheet - URL-By-URL
Colours - URL-By-URL  \_ (Covered by style sheets?)
Fonts - URL-By-URL    /
Auto-Load Images - URL-By-URL ( + Media Type?)
Preferred Language - URL-By-URL
FTP Password - Site-By-Site
How Often Compared To Network - URL-By-URL + Media Type
Background-Sound - URL-By-URL (+ Media Type?)
Download Directory - URL-By-URL + Media Type

There's a little bit of differentiation.  This could well mean there could be
multiple or one parameterised prefs panel(s), however I still think the
pref lookup interface should be uniform, especially since this allows changing
it later.  The call should probably include media type too, something like:

ComplexPref( PrefDownloadDir, "ftp://foo.bar.com/stuff.tar.gz",
"application-xcompressed" )
Bug# 858 discusses the JavaScript capability issue specifically.
Depends on: 858
Yeah, I mentioned it in my original report.  =)  Marked a depends relationship
of this bug on 858 since it looks like 858 won't be closed as a duplicate of
this (I guess since 858 might be implemented in v5) whereas this almost
certainly won't.
Whether to activate automatic form filling is another option here.
As might be bug #8648, what to do when a redirected/not found site is found.
And bug #15145 on preventing image (GIF, MNG) animations.
Bug #15148 discusses affecting these options through the UI while browsing.
How about a menu (called security or options or something) whith the following
structure.

Cookies > Menu A
JavaScript > Menu A
Images > Menu A

Menu A (cookies example)
  > Disable/Enable (inteligent) Cookies
  > Never use cookies on these sites > Menu B
  > Always allow cookies on these sites > Menu B

Having never and always up is needed, so people can switch in and out of cookie
accept mode, yet still have access to these lists.

Menu B
 > Add current site
 > Edit sites
 > -----
 > www.microsoft.com
 > www.msn.com
 > www.dodgy-cookies.com

Edit sites would bring up an edit>bookmarks style box.

You could also have a 'zones' option, much like IE's run using the same sort of
idea. You would define a zone with a name and checkboxes for javascript, cookies
etc

Is this practicle?
What you describe is already implemented for cookies I believe.  See
Edit/Display Cookies, the "Website Setup" tab.

This bug is about a general architecture for all these sorts of things but also
(a) allowing it to work down to the URL level and take media type into account,
and (b) to allow you to specify a tree, eg x is allowed, but not x/y, except
x/y/z which is allowed.
Another option is whether to cache, bug #11644, which would be interested in
both URL and media type.
*** Bug 14823 has been marked as a duplicate of this bug. ***
From 7380:

===
It would be awsome to have a simple regular expression blocklist to
block banners and the like. It might even be useful as a net nanny.
This would solve alot of trouble coused by using the proxy variant.

It could visually work in some diffrent ways:
 1. Show the object but do not load it until clicked on (like the do not
    autoload images).
 2. Do not load or show the object at all.

These would preferably be a selectable otion per regexp.
Maby a deny - allow sheme whoud be useful in some situations.

/Dr
===

That is basically the same idea as this, with the pref in question being
"download images" and the URI being the image's (rather than the site's).
When I said "from 7380" I actually meant "from bug 14823". This _is_ 7380...
Turning off auto-load images for this would be a way to prevent loading.  Of
course, you might want to remove the content entirely, ie no alt text, which
would be different.
Yet another option would be to block by the text content of an page to expand
the net nanny ability.
Also an option for frames autoloding might be of interest.
And an option for redirects and meta http-equiv refreshes.
I think it would be difficult to visualize a tree.
I would recomend a first match list instead:

Deny/Allow/Click   Type      Regexp               Media type
----------         ----      ----------           ----------
Allow              Java      http://java.com/.*   .*
Deny               Java      .*                   .*
Allow              Auto-load .*advanced.*         .*
Click              Auto-load .*adv.*.gif          .*
Deny               Cookies   .*
Deny               Content   .*porno.*            .*

...Um, you get the picture. Not perfect but...
Hi,
This is a very useful feature, but to stop it from becoming a geek-only thing,
it should be:
a. very easy to reach.
b. have a lot of defaults.

How about this:
1. User is browsing www.tunz-o-images.com, and doesn't want to load them.
2. User clicks Edit, and below "Prefs" he sees "Customize this site".
3. He gets an incredibly banal wizard, where he can choose from a few options:
 -- Don't load images for this site.
 -- Don't open popup windows from this site.
 -- Place files downloaded from this site into [browse]
 -- Ask for a password before showing this site: [editbox]
 -- Customise...

4. Customise should give a crippled pref window.  There's not much to cripple,
though.  For example, where my dad works, he has to access some sites from
one http proxy, and some others from another one (some wierd MedLine license)

As to viewing the list of "site rules" or whatever - a bookmark-like window
would be just the thing.  There should be a 2 phase setup here - at first just
a text saying what was changed ("Disable Java.  Don't load images."), then a
"Change..." button giving you the crippled pref window.
I would suggest that the matching not be by lists of sites or urls or regexps,
but that it be implemented by a javascript call.  Surely, the default javascript
should do something simple like keep a list of sites or urls, but I think it'd
be neat for knowledgeable users to be able to get in there and hack.  ("The
emacs nature is good.")

I conclude this from my experimentation with this kind of thing.. I (ab)use the
proxy autoconfig capability of communicator to block out banner ads, and awhile
ago I wrote an implementation of javascript cookie filters (an early predecessor
of the fancy cookie support that's in Mozilla now.)  Now admittedly my scripts
are basically matching against lists of regexps, but it's nice to know that I
have a turing-complete language available.  (My js mail+news filters really do
have fancy logic.)

See the proxy autoconfig docs at
http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html .
I'm not sure filtering Nanny capability should be here.  Firstly, you might want
to lock off these preferences separate from the rest of the others.  Secondly,
blocking a page tends to make the other prefs irrelevant, and so they are not
orthogonal.  Thirdly, this could work on page content, whereas all the others
don't.  It could work similarly but I don't think there's benefit in allowing it
in the same tree.

You could use a match list instead of a tree, the functionality is the same.
The tree is basically meant to make it easier to visualise, for experts at
least.  You could use the tree as a match list by checking things in order at
the same level.  The tree basically aims to make this easier:

a & c ->
a & b ->
a ->

becomes:

a ->
  b ->
  c ->

Re: usability.  Ideally it should be fairly simple in the simple case.  This has
to be worked out.  I might try to hammer out a spec shortly.

Re: javascript.  I always intended on allowing boolean expressions, like with
the current filtering, but if this is done it should be complementary.  I do not
wish to learn Javascript to do this, as with most users (and I'm a programmer).
Re: Javascript. No java please, but implement it in a loadable module so the
ubergeeks can do whatever they want. I'm really concerned about speed here,
since this function would be called for every access and it might test alot of
things. So the default a c-module, with the ability exchange that module with
your favorite Java/Pyton/Whatever module.


Re: Nanny split off. Hmm, good point, maby it could be several lists:
Create list 1, Nanny, set password.
Create list 2, Bannerstopper
Create list 3, Misc.

Still, first item match in listorder. Otherwise you would be able to allow a
thing previosly denyed by the nanny. An ability to shuffle the list around would
be nice, but the password protected stay put (unless password given).
One problem: An allow in the nanny might contain things you want to deny in the
bannerstopper. So a new actiontype: "Next" to make it to go to the next list in
order (actiontypes = Allow, Deny, Click and now Next)
Bug #1582, whether to send the HTTP referring page, is another, although this
one could be parameterised on previous or current page.
Bug #1785 is another bug that this subsumes.  It is about Java, and illustrates
the value of having a "prompt" setting for certain sites, along with a "remember
this decision" facility.  Cookies already have this facility, BTW.
In http://www.deja.com/getdoc.xp?AN=538355205&fmt=text I propose a GUI for this
feature -- an extension of the prefs dialog to include what I called `browser
zones', to specify different prefs for different sites/URIs. The UI deals with
preferences for different mail accounts and news servers in a similar way, for
consistency.

It only makes sense to change *some* prefs on a URI-by-URI basis -- basically
ones related to display of content (images, fonts, cookies, JavaScript, etc).
These I arrange into a new prefs category -- subcategories can be adjusted for
each zone, or left as the default.

A given URI could belong to more than one zone at once, from matching more than
one set of rules; if the zones' preferences conflicted, the last one would
override earlier ones. So order of zones would be important.

Considering the similarity between mail accounts, news servers, and browser zones
may be of help when designing the underlying prefs architecture for this feature,
too.

Sticky points with the design:

* If I choose to have a dialog asking me what sort of cookie permissions I want
to give to a site (for example), I'm probably going to have to have a set of
default zones for those sites to be plonked into.

* I haven't considered the problem of changing prefs for messages on a message-
header-by-message-header basis. We're almost getting into the area of mail
filters here.

Hope this helps ...
Move to M20.
QA Contact: cpratt → sairuh
spam: in my testing realm, so reassigning qa contact to me, en masse.
*** Bug 26272 has been marked as a duplicate of this bug. ***
Bulk move of all Pref UI component bugs to new Preferences component.  Pref UI 
component will be deleted.
Component: Pref UI → Preferences
Gee, why not remove the bug entierly and admit it's never going to be done.
First you move it to M20, then you remove the votes by changeing the voting
rules to one vote per login, but only for this particular bug, not the others.

This sucks!
Please don't jump to conclusions.

M20 is not very far away, about 4 or 5 months.  I would be suprised to see it
begun to be implemented before that time, since it is significant work and I
expect Mozilla to stabilise around then.  This is an enhancement request, and it
doesn't have to be fixed immediately.  There are things I would much rather have
first like a rock-solid Mozilla release.  This will occur in time as it becomes
a higher priority.

The voting system for all Browser and MailNews has been changed bugs by whoever
is in charge of it.  Webtools still has the old system.  Maybe this is the only
bug you had multiple votes for, so therefore the only one you received a
notification for?

Venting your frustration does nothing to implement this feature.  Maybe write it
yourself, or find someone else willing to?
I think this is probably the place for my comments.  I was reluctant to open a 
new bug.

Basically, the idea I had was to have procmail-like filtering and mangling 
features on cookies.  Basically, procmail lets you match incoming e-mail based 
on headers and content and take specified actions, which can be pretty much 
anything... one of the most useful being mangling the message.  For example, if 
I get a cookie that expires in 2048, I'd like to squash that to three months 
from today.  Or squash it to being a session cookie, or any number of 
actions... perhaps throwing up a custom dialog letting me know so I can e-mail 
the admin.  Flexability is the key.

(That said, it doesn't have to look like the procmailrc format, it's just the 
example I used...)

I put it here because I think it could be easilly extended beyond just 
cookies... procmail-like filters on HTTP headers (and by definition, the set-
cookie header (*)) might do the trick.

(*) that might cause problems with javascript's setCookie method, but this is 
just a brainstorming comment.

I'm curious to see if anyone else thinks this is a viable idea.  

(May want to move this to the newsgroups, as well... Hm.)

Move to "Future" milestone.
Target Milestone: M20 → Future
don, you futured this, should it be nobody'd?

Deny/Allow/Prompt/Click.  As previously stated there are two pieces to this, FE 
and BE.  I suggest that this bug focus on backend support.  There are a few 
other bugs that would handle the front end including:
bug 42663 Preferences are inaccessible and app global [there's a huge debate 
about modality of prefs] of you put this in a sidebar it's easy to access and 
makes a bit more sense. wrt locking, I think each change you make would be live 
so having the sidebar open multiple times would cause it to refresh whenever a 
change is made [oh well, alternatives would be worse].

This really isn't a normal preference candidate because by its very nature it 
is not app global.  IE's zone dialog is rather unmanageable.
One important question: How should this persist? Since we're favoring regular 
expression based settings I don't think we can stick this into the history 
stuff.
One other useful feature would be the ability to define a condition and 
apply multiple things to it.
eg .*xxx.* : No Referer, No Java, No JavaScript, No Cookies

I think this stuff is a good candidate for a database.  For the expression to 
be able to affect multiple things, we could use the mailnews To: editfields 
which have completion (in drop down form).  All current rules would be in the 
list of completions (making it relatively easy to reuse a form).
Blocks: 15148, 42663
Keywords: helpwanted, qawanted
Summary: [RFE] Support all prefs on a URL by URL basis → [RFE] Backend support for all page prefs on a URL by URL basis
No longer blocks: 15148
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Assignee: don → vishy
I'll take this, since I'm interested in re-implementing site JS prefs (was bug
858) using a common per-site prefs mechanism, as well as P3P (bug 62399) and
possibly other features as well.
Assignee: vishy → mstoltz
Blocks: 62399
[from bug 60323: chatted with mstoltz and found that the frontend was covered by
bug 38966. it's currently closed, but i might reopen it as an enhancement.]
[x] Accept cookie and destroy it immediately. 

Some sites insist on cookie (hotmail), some use for tracking. This wouls satisfy 
both sides.
I do not think that "Accept cookie and destroy it immediately" could work.
The server (e.g. hotmail) sends a cookie to the browser and does not know that
it has been set until the next request from the browser contains that cookie.
So destroying the cookie "immediately" (before the next request) would be the
same as not accepting it at all.  Destroying it after one request (to the same
domain) may not work either, because the sites relying on a complex login
process involving several scripts and redirections will only check the value of
the cookie after 4 or 5 requests.  A better option could be to delete the cookie
after a specified amount of time or "as soon as you leave the site", which is in
itself hard to define.

By the way, this suggestion for cookies should probably go to a another bug,
because it is not directly related to this one, which focuses on the "prefs by
URL" backend and not specifically on cookies.

clearing milestone to nominate for moz0.9.
Keywords: mozilla0.9
Target Milestone: Future → ---
This could probably be accomplished using the PrefBranch interface, ccing bnesse.
Status: NEW → ASSIGNED
Mass adding mozilla0.9 keyword (mass changing milestone doesn't seem to work).
Setting milestone to Moz0.9.
Target Milestone: --- → mozilla0.9
Here's the interface I had in mind:
nsISitePref::GetCharPref(in url, in prefName, out prefValue);

which would return the value specific to "url" if there is one, or "default"
otherwise.
You might want to also have a media type parameter for some prefs.
Matty, right, Mitch is aware of this. You found the bug for the backend support
I was talking to you about in bug 24418. I don't believe we need special support
for media type here - as long as we have a pref that supports that somewhere
else, we can use it with this new interface.
Found it?  I filed it!
This proved more difficult than I thought, so I'm putting it off. Future.
Target Milestone: mozilla0.9 → Future
Can we at least get this in for javascript and java? IE has something like it
for scripting, at least, and it would REALLY help me. As far as UI goes, I like
the way we do it for cookies...
Who is 'we?' This bug is about the backend, and a backend already exists for
Javascript, and for Java though they use separate mechanisms.
Blocks: 96683
No longer blocks: 96683
Here's an idea for consideration, please think this through and consider the
various factors for perf, bloat, convenience, security, usability, and end user
satisfaction etc.

Perf hits can be minimised from regex impact by a few methods such as checking
to see if it is a regex before applying the rule to the content. code bloat is a
consideration but offset by combining the existing fragments of content control
into a single group of functions.  (Content Control is a nice 'section' to use
for doron's new popup control UI see bug #75371)  If the UI is well designed,
the convenience for the user is noticable and appreciated, ties together with
usability.  If I had this feature, I'd be able to block all images if mail
content has "click here" in it, and block a URI of
http://host.com/cgi-bin/redir.cgi?ad.doubleclick.com without blocking host.com

a) rule capability that applies to content acceptance and to rendering.
(intentionally split)

b) each rule can have component object such as:

  1) mail | news | navigator

c) each rule is based on selectors which may include but are not limited to nor
required to have (regex selectors possible):

  1) URI | mail header or body | media type | image size

d) and are focused on media objects of:

  1) images | cookies

e) each rule's actions can be:

  1) allow all | download but don't render | accept and bitbucket (cookies) |
don't accept

f) and can have a lifespan of:

  1) forever | N days | session


Some of these things are complex, they could be en/disabled w/ an [advanced] button.

Comments?

*** Bug 160741 has been marked as a duplicate of this bug. ***
What about user agent customization per bookmark/site?

For instance, some internet banks in Sweden have hardcoded checks on the user
agent of the browser and won't let Mozilla show any pages, even if it is able to
show the pages just fine if you change the user agent string that Mozilla
presents itself as. Unfortunatly you have to do this by editing prefs.js by hand
and you have to restart Mozilla between changes.
Can I add a request for per-site flash blocking.

At the moment, all flash seems to be displayed if you have the plugin installed.
I usually install the plugin when I visit a flash-only site and uninstall it
immediately afterwards just to stop ads.

Actually, a more generic "block XYZ plugin" per-site option might be better.
Plus an "allow from originating site only" option similar to current
cookie/image handling.
Would this enh. permit configuring a specific proxy to use for HTML email
(either by selection of proxyMethod=DIRECT, or setting no-proxy-for to *)?
The URL of the (parent/originating) HTML would be mailbox:*, while the URL of
the objects it references (that need to respect the mail-specific proxy) are
*:*. (everything).

If I'm behind a firewall in a corporate intranet, I wish to configure one proxy
for browsing the public internet.  But when reading HTML email, I only want
local (intranet, or same message attachments) references to resolve (in their
many forms: CSS, images, plugins, src-ed JS...).

Say you don't if it's spam or not and view a message anyway.  Viewing of such an
HTML email, especially accidently, should pose no possibility of generating hits
of any type to an external web site (zero feedback).  If I click on a link/href
within of course, this visits that URL in a browser window using the ordinary
browser proxy, not the mail-specific proxy.
How about allowing to block content according to html-element and its
attributes? You could choose script, object, table with class-attribute with
value "navbar" etc. Sometimes this would help to remove completely 
unnecessary white space which remains after blocking images with normal
methods. 
Re last 2 comments: Both suggestions exceed the scope of this bug (the latter is
not even related). Please see <http://www.mozilla.org/feedback.html>.
Blocks: 23923
Summary: [RFE] Backend support for all page prefs on a URL by URL basis → Backend support for all page prefs on a URL by URL basis
I use a filter from PC magazine called Cookie Cop 2.0 and it has an option to
make cookies from non-approved sites into session cookies. This works well for
me as all the sites work since they don't know the cookie has been modified and
I don't have to do any manual cleanup, just close and reopen IE.
Reporter, do you still see this in newer builds.
Everyone, is this bug still ongoing in development?

-R
> Reporter, do you still see this in newer builds.

huh? This is an enhancement request*, not a bug you can "see".
*and an important one IMHO
Reassigning from mstoltz to nobody.
Assignee: security-bugs → nobody
Status: ASSIGNED → NEW
Product: Browser → Seamonkey
Keywords: qawanted
Please consider features presented by these .XPI files, maybe their coders would give over to this project as they fit some of the features being looked at.  No Squint, NoScript, ABP.
Priority: P3 → --
QA Contact: bugzilla → prefs
Target Milestone: Future → ---
Component: Preferences → Preferences: Backend
Product: SeaMonkey → Core
QA Contact: preferences → preferences-backend
As filed we aren't going to fix this. There is a separate system of per-domain permissions.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.