RFC: Access Control over JavaScript Properties Globally and Per-Domain

[Leo Savernik]

Am Freitag, 11. Oktober 2002 15:59 schrieb David Faure:
> On Friday 11 October 2002 15:17, Leo Savernik wrote:
> [...]
>
> > I'm of the opinion that resizing/moving windows per javascript is 99.9%
> > annoying, that's why I only proposed global settings.
>
> Ok. Why not. But the window popup policy definitely has to become
> per-domain, so wouldn't it be more consistent to make it so that everything
> is both global and per-domain?
>
Martijn and you persuaded me that it's indeed handy.
> [...]
>
> > Then each option within the
> > per-domain settings should be prefixed with a "[x] use global" checkbox
> > initially checked and the options grayed out. If and only if the user
> > disables the "use global" this option for the specific per-domain setting
> > becomes editable and takes effect.
>
> It's simpler to just have radio-buttons ;)
>
Yess, indeed. You're so right here. I actually prefer simple solutions to 
complex ones ;-)
> [...]
>
> And I'd be very happy to see a patch that does the above ;-)

Ok, I could come up with a patch for more extensive per-domain settings, but 
before I code I'd like to propose the following short

RFC: Access Control over JavaScript Properties Globally and Per-Domain

1. Overview

Currently Java, JavaScript and Plugins are handled on separate tabs though 
their configuration data is saved under the common key [Java/JavaScript 
Settings]. Ui-wise that should stay that way, meaning that the per-domain 
settings for Java, JavaScript and Plugins (when finally implemented but 
outside if this proposal) are totally separated.

Config-wise the per-domain settings for Java and JavaScript are also saved 
under separate keys, with options separated with colons.

We leave the Java and Plugins setting as is, they are not part of this 
proposal.

The properties whose access is to be controlled are:
Property			Access		Possible options & additional information
window.open		invocation		Allow/Ask/Deny/Smart, already implemented globally
window.moveBy		invocation		Allow/Ignore
window.moveTo		invocation		Allow/Ignore
window.resizeBy		invocation		Allow/Ignore
window.resizeTo		invocation		Allow/Ignore
window.focus		invocation		Allow/Ignore
window.defaultStatus	setter			Allow/Ignore
window.status		setter			Allow/Ignore

2. New Configuration Keys

To save those settings globally, I propose the following additions to 
[Java/JavaScript Settings]:
WindowOpenPolicy as is
WindowMovePolicy: 1 allow (default), 0 ignore
WindowResizePolicy: 1 allow (default), 0 ignore
WindowFocusPolicy: 1 allow (default), 0 ignore
WindowStatusPolicy: 1 allow (default), 0 ignore

For the per-domain settings the ECMADomainSettings key should be extended the 
following way:
ECMASettings=<domain-settings>[,<domain-settings>]...

<domain-settings>=<domain>:<empty>:<javascript-policy>:<WindowOpenPolicy>:
	<WindowMovePolicy>:<WindowResizePolicy>:<WindowFocusPolicy>:
	<WindowStatusPolicy>

where <domain>:<empty>:<javascript-policy> should be handled as they are now 
and the other policies be either empty meaning that this policy inherits the 
global policy or one of the values that is valid for the global policies to 
override it for this specific domain.

Example:
ECMASettings=foo.bar.com::accept:0:0:0::

would set the policies for foo.bar.com to accept javascript, to allow popups, 
ignore window move and resize attempts as well as inherit the global 
behaviour for focus stealing and status text changes.

The advantage of this method is that any missing option will be treated as 
inheriting the global setting, thus migrating old configuration files to the 
new format will not need any special treatment.

For example, an old KDE 3.0 setting like:
foo.bar.com::accept
will implicitely be treated as
foo.bar.com::accept:::::
and written back as such when the configuration is saved.

3. GUI Representation

The JavaScript Web Popups Policy section of the JavaScript tab should be 
adapted to:

--- JavaScript Policies ---
 Web Popups: (*) allow ( ) ask ( ) deny ( ) smart
 Move Windows: (*) allow ( ) ignore
 Resize Windows: (*) allow ( ) ignore
 Bring Windows to Foreground: (*) allow ( ) ignore
 Change Status Bar Text: (*) allow ( ) ignore

The configuration defaults are checked.

The per-domain settings screen becomes:

Host or domain name: [______________]
JavaScript Policy: [Use global/Allow/Reject]
 Web Popups: (*) use global ( ) allow ( ) ask ( ) deny ( ) smart
 Move Windows: (*) use global ( ) allow ( ) ignore
 Resize Windows: (*) use global ( ) allow ( ) ignore
 Bring Windows to Foreground: (*) use global ( ) allow ( ) ignore
 Change Status Bar Text: (*) use global ( ) allow ( ) ignore

The per-domain defaults are checked.
If JavaScript Policy is set to deny, the succeeding options could be grayed 
out, otherwise they should stay available, even if the global JavaScript 
Policy setting is set to off.

4. API Concerns

The WindowOpenPolicy setting is actually not integrated into the 
khtml_settings class. I do not know the specific cause for this, but for 
per-domain management I propose that all the settings mentioned under 2. are 
integrated into khtml_settings.

The new preliminary API might look like:
    // Java and JavaScript
    bool isJavaEnabled( const QString& hostname = QString::null );
    bool isJavaScriptEnabled( const QString& hostname = QString::null );
    bool isJavaScriptDebugEnabled( const QString& hostname = QString::null );
    bool isPluginsEnabled( const QString& hostname = QString::null );
+   int windowOpenPolicy( const QString& hostname = QString::null );
+   bool isWindowMoveEnabled( const QString& hostname = QString::null );
+   bool isWindowResizeEnabled( const QString& hostname = QString::null );
+   bool isWindowFocusEnabled( const QString& hostname = QString::null );
+   bool isWindowStatusEnabled( const QString& hostname = QString::null );

End of RFC

CCing kde-usability guys for their opinion on the subject.

Well, if we can reach an agreement on that rfc, I'll try hard to come up with 
a patch as soon as KDE-CVS is opened for feature commits again. Btw, when 
will that be? The release schedule seems to be messed up, it pretends that 
the current week #41 still is in September, so what to trust now?

mfg
	Leo