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

[Leo Savernik]

Summarizing what has been said so far followed by the adapted rfc:

- tabs stay separate for java/javascript/plugins ui-wise
- having all global java/js/plugins under [Java/JavaScript Settings] 
unprefixed
- having per-domain settings under [domain] where domain is the domain name or 
some ip address (either ipv4 or ipv6, shouldn't matter)
- per-domain js settings are prefixed with "javascript."
- make bool isWindowBlaEnabled(...) be enum BlaPolicy windowBlaPolicy(...)

Well, I think I have gathered enough information to be able to implement this. 
Following old Mozilla's tried and tested way I opened bug #49145 for 
tracking. If I should not have done this, cry out loudly ;-)

[...]
>
> 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: 0 allow (default), 1 ignore
WindowResizePolicy: 0 allow (default), 1 ignore
WindowFocusPolicy: 0 allow (default), 1 ignore
WindowStatusPolicy: 0 allow (default), 1 ignore
>
> For the per-domain settings the ECMADomainSettings key should be 
scrapped and replaced with dedicated per-domain config keys which contain the 
same option with the same values as above except that they are prefixed by 
"javascript.". Not having a corresponding javascript.WindowBlaPolicy options 
means to inherit the global one.
>
> Example:
[foo.bar.com]
javascript.EnableJavaScript=true
javascript.WindowOpenPolicy=0
javascript.WindowMovePolicy=1
javascript.WindowResizePolicy=1
>
> 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 advantages of doing this are:

1.) No special parsing code needed.  Use KConfig to obtain the settings.  Your 
code will only have to check if a specific host name entry exists and use the 
settings there.  If there is no entry for a specific property under the group 
or there is no domain specific entry at all, use the global/default setting.

2.) No position dependency.  One does not have to worry about where a speicifc 
entry belongs which makes it much easier to read and hence administer 
manually.

3.) Can easily be converted/manipulated into a new format without loosing the 
user's settings in the future using kconf_update tool.

4.) Easier to extend than the other format because properties can be added 
without having to worry about positions etc...
(bluntly copied from Dawit's mail without permission ;-) )
>
> 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 );
+   enum MovePolicy windowMovePolicy( const QString& hostname = QString::null 
);
+   enum ResizePolicy windowResizePolicy( const QString& hostname = 
QString::null );
+   enum FocusPolicy windowFocusPolicy( const QString& hostname = 
QString::null );
+   enum StatusPolicy windowStatusPolicy( const QString& hostname = 
QString::null );
>
[...]

You might notice that i switched the allow/ignore values to be more consistent 
with WindowOpenPolicy