Content Restrictions

3 views
Skip to first unread message

Gervase Markham

unread,
Mar 13, 2007, 1:43:46 PM3/13/07
to
There was a request in the weekly status meeting yesterday to mention
any features you are working on for Firefox 3. I don't know whether that
only means features in the PRD, but anyway, I plan to implement Content
Restrictions for Firefox 3.
http://www.gerv.net/security/content-restrictions/

The idea is to provide a good "backstop" for when XSS holes are found in
websites. Nothing short of disabling JavaScript, bug-free server-side
code or reading the web designer's mind can fully protect against XSS,
but I think this gives designers a good second shot at mitigating the
impact if a hole is found.

If you've read it before, please have another look. I've removed a lot
of restriction types on the basis that they were making promises I don't
think we could keep. The new proposal is therefore a lot simpler.

The spec has been designed to be easy to implement, according to my
(certainly imperfect) knowledge of the Mozilla security capabilities
model, and to have no requirement for end user interaction.

I plan to implement it in stages, with the higher-value restrictions
first. Those are the ones listed first in the document. It could be that
some of the restrictions are hard to implement or aren't useful in
practice; we'll discover this as we go along.

Further comments on the spec would be welcome.

Gerv

Tony Mechelynck

unread,
Mar 13, 2007, 3:07:10 PM3/13/07
to

Dou you think it could make sense to:
a) have a UI option (or set of options) to toughen the restrictions (for
paranoid users ;-) )? Slackening them would still never be possible. I'm
concious that having such a possibility implies a not-always-easy balancing
task between "toughening the security" and "not breaking a page's rendering".
Or is that already covered by options such as "disallow scripting in
mail/news" etc., which already exist as UI options?
b) disallow remote scripts which aren't in the same domain as the page they're
applied to? (maybe e.g. "script-file=no-remote" -- I guess
script-file=external,no-remote could make sense too by disallowing *both*
scripting internal to the page and remote to the site). Or would that be
covered by the "domain" attribute? No, on closer look I guess that's a
different thing altogether. In a similar vein, what about disabling external
scripts other than those located by a relative URL (which would implicitly
exclude other-site scripts)?


Best regards,
Tony.
--
Pushing 40 is exercise enough.

Gervase Markham

unread,
Mar 13, 2007, 7:49:47 PM3/13/07
to
Tony Mechelynck wrote:
> Dou you think it could make sense to:
> a) have a UI option (or set of options) to toughen the restrictions (for
> paranoid users ;-) )?

No. Because that would basically be a button marked "Break Websites".
The site designer knows what he wants the JS on the page to be able to
do; preventing it from doing even that would just break stuff.

> b) disallow remote scripts which aren't in the same domain as the page
> they're applied to? (maybe e.g. "script-file=no-remote" -- I guess
> script-file=external,no-remote could make sense too by disallowing
> *both* scripting internal to the page and remote to the site). Or would
> that be covered by the "domain" attribute? No, on closer look I guess
> that's a different thing altogether.

No, it's that thing - it just restricts all requests, not just requests
for script. I'd have to think about whether it makes sense to have an
option to only restrict script loads. Thanks for the idea.

> In a similar vein, what about
> disabling external scripts other than those located by a relative URL
> (which would implicitly exclude other-site scripts)?

That's also an interesting idea.

Gerv

Fergy

unread,
Mar 14, 2007, 4:31:23 AM3/14/07
to
On Mar 13, 6:43 pm, Gervase Markham <g...@mozilla.org> wrote:
> There was a request in the weekly status meeting yesterday to mention
> any features you are working on for Firefox 3. I don't know whether that
> only means features in the PRD, but anyway, I plan to implement Content
> Restrictions for Firefox 3.http://www.gerv.net/security/content-restrictions/

>
> The idea is to provide a good "backstop" for when XSS holes are found in
> websites. Nothing short of disabling JavaScript, bug-free server-side
> code or reading the web designer's mind can fully protect against XSS,
> but I think this gives designers a good second shot at mitigating the
> impact if a hole is found.
>
> If you've read it before, please have another look. I've removed a lot
> of restriction types on the basis that they were making promises I don't
> think we could keep. The new proposal is therefore a lot simpler.
>
> The spec has been designed to be easy to implement, according to my
> (certainly imperfect) knowledge of the Mozilla security capabilities
> model, and to have no requirement for end user interaction.
>
> I plan to implement it in stages, with the higher-value restrictions
> first. Those are the ones listed first in the document. It could be that
> some of the restrictions are hard to implement or aren't useful in
> practice; we'll discover this as we go along.
>
> Further comments on the spec would be welcome.
>
> Gerv

So this will only protect the user and the website owner if the owner
specifies the the content restrictions? I would love for Firefox to
have built in per site/domain javascript/flash/gif/java/ads/cookie
blocking like you get with extensions(adblock, noscript, cookie-
mananger). But instead of blocking everything and letting the user
white list sites they want to use you would provide default rules that
block annoying and insecure behavior but still let regular websites
keep on working. This way normal users would never have to know that
Firefox is quietly protecting them. For the power users you could make
an extension that makes those default rules accessible so they can
adapt them to their needs.

Gervase Markham

unread,
Mar 14, 2007, 5:43:22 AM3/14/07
to
Fergy wrote:
> So this will only protect the user and the website owner if the owner
> specifies the the content restrictions?

Yes - only the website owner knows what he wants his content to be able
to do.

I would love for Firefox to
> have built in per site/domain javascript/flash/gif/java/ads/cookie
> blocking like you get with extensions(adblock, noscript, cookie-
> mananger).

Of those, only per-site JavaScript blocking would have any effect on XSS
(the problem that this proposal addresses), and it would do so at the
expense of having no script run at all.

I'm not saying your proposal is a bad one, only that it's addressing a
different problem.

> But instead of blocking everything and letting the user
> white list sites they want to use you would provide default rules that
> block annoying and insecure behavior but still let regular websites
> keep on working. This way normal users would never have to know that
> Firefox is quietly protecting them.

Define "annoying and insecure". :-)

Gerv

Dao

unread,
Mar 14, 2007, 3:07:29 PM3/14/07
to
Gervase Markham schrieb:

> Tony Mechelynck wrote:
>> Dou you think it could make sense to:
>> a) have a UI option (or set of options) to toughen the restrictions
>> (for paranoid users ;-) )?
>
> No. Because that would basically be a button marked "Break Websites".
> The site designer knows what he wants the JS on the page to be able to
> do; preventing it from doing even that would just break stuff.
>
>> b) disallow remote scripts which aren't in the same domain as the page
>> they're applied to? (maybe e.g. "script-file=no-remote" -- I guess
>> script-file=external,no-remote could make sense too by disallowing
>> *both* scripting internal to the page and remote to the site). Or
>> would that be covered by the "domain" attribute? No, on closer look I
>> guess that's a different thing altogether.
>
> No, it's that thing - it just restricts all requests, not just requests
> for script. I'd have to think about whether it makes sense to have an
> option to only restrict script loads.

I think it makes sense.

1) Some sites have different hosts for images, and I wouldn't want to
add them to a white-list. (After skimming briefly through your updated
draft, I'm not even sure if that would be possible.) It seems like a
needless step when you really want to ban external scripts only.

2) Why shouldn't one allow users to include their own (external) images
but not scripts? I'm thinking of forums / bulletin boards and
myspace-like sites.

Dao

unread,
Mar 14, 2007, 5:30:33 PM3/14/07
to
Gervase Markham schrieb:

> Further comments on the spec would be welcome.
>
> Gerv

I believe your grammar isn't expressive enough and lacks consistency
overall. Script, script-file, hierarchy, ... that's all a bit hard to
follow.

So here's my initial EBNF proposal, which is based on and hopefully
something like a superset of your ideas:


PolicyHeader = "Content-" PolicyType ": " Policy ;
PolicyType = "Ban" | "Permission" ;
(* the default Ban policy is "none=none" *)
(* the default Permission policy is "all=all" *)
(* permissions override bans *)
Policy = Rules [ ";version=" VersionNumber ] ;
(* VersionNumber regexp: /^[1-9]\d*(\.\d+)?$/ *)
Rules = Rule { "," Rule } ;
Rule = ResourceRule | SpecialRule ;
GeneralKey = "all" | "none";
GeneralValue = "all" | "none";
ResourceRule = ( GeneralKey | Resource) "="
( GeneralValue | ScopeCompound ) ;
Resource = "scripts" | "objects" ;
(* for HTML, "objects" are the OBJECT, IMG, (I)FRAME
and EMBED elements *)
ScopeCompound = Scope { "+" Scope } ;
(* "+" is a conjunction *)
Scope = "document-head" |
"same-host" | "different-host" | Host ;
(* Host is a domain (punycode in the IDN case)
or an IP address *)
SpecialRule = CookieRule | HierarchyRule ;
CookieRule = ( GeneralKey | "cookies" ) "="
( GeneralValue | "write" | "read" ) ;
HierarchyRule = ( GeneralKey | "script-access" ) "="
( GeneralValue | "parent" | "children" ) ;


Examples:

Content-Ban: scripts=different-host,cookies=read
Content-Permission: scripts=234.182.0.12

Content-Ban: all=all
Content-Permission:
scripts=document-head+same-host,objects=same-host,objects=static.example.com


I didn't take too much time to write that, yet I hope it makes sense.

Dao

Gervase Markham

unread,
Mar 15, 2007, 6:08:13 AM3/15/07
to
Dao wrote:
> I believe your grammar isn't expressive enough and lacks consistency
> overall.

Quite possibly. Better name suggestions welcomed.

> So here's my initial EBNF proposal, which is based on and hopefully
> something like a superset of your ideas:

Thanks very much for taking the time to write down your suggestions. I
really appreciate it.

It does seem like quite a significant change. Why switch from one to two
headers? I only think you need one. You start with full permissions,
because that's what browsers do today, then make a list of the
behaviours you want to restrict. Why make it more complex? What does it
buy you?

What happens when we add new things, and sites which start with
Content-Ban: all=all, Content-Permissions: <some stuff> break because
new things are banned that they didn't expect? You'd need
Content-Ban: reallyallthistimeIpromise=all.

> Policy = Rules [ ";version=" VersionNumber ] ;
> (* VersionNumber regexp: /^[1-9]\d*(\.\d+)?$/ *)

What's the advantage of sub-versions? When would they be used?

> Rules = Rule { "," Rule } ;
> Rule = ResourceRule | SpecialRule ;
> GeneralKey = "all" | "none";
> GeneralValue = "all" | "none";
> ResourceRule = ( GeneralKey | Resource) "="
> ( GeneralValue | ScopeCompound ) ;

What do "none=all", "all=all" and "none=none" mean? For each of the two
headers?

> Resource = "scripts" | "objects" ;
> (* for HTML, "objects" are the OBJECT, IMG, (I)FRAME
> and EMBED elements *)
> ScopeCompound = Scope { "+" Scope } ;
> (* "+" is a conjunction *)
> Scope = "document-head" |
> "same-host" | "different-host" | Host ;
> (* Host is a domain (punycode in the IDN case)
> or an IP address *)
> SpecialRule = CookieRule | HierarchyRule ;
> CookieRule = ( GeneralKey | "cookies" ) "="
> ( GeneralValue | "write" | "read" ) ;
> HierarchyRule = ( GeneralKey | "script-access" ) "="
> ( GeneralValue | "parent" | "children" ) ;

I guess the big problem I see here is that the added flexibility comes
at a large cost in implementation complexity, a reasonably large cost in
the complexity and fragility of the headers, and not a great increase in
usefulness in practice.

What additional capabilities does your proposal provide?

> Examples:
>
> Content-Ban: scripts=different-host,cookies=read
> Content-Permission: scripts=234.182.0.12

But that's really a further restriction, not a permission, isn't it?

> I didn't take too much time to write that, yet I hope it makes sense.

Mostly :-) Again, thanks for taking the time to engage with my proposal.

Gerv

Gervase Markham

unread,
Mar 15, 2007, 6:14:14 AM3/15/07
to
Dao wrote:
> Gervase Markham schrieb:

>> No, it's that thing - it just restricts all requests, not just
>> requests for script. I'd have to think about whether it makes sense to
>> have an option to only restrict script loads.
>
> I think it makes sense.

We have to make sure it's a promise we can keep. If there's some other
way of getting cross-domain data, then a local script can simply call
eval() on it and get the same effect as a cross-domain <script src="">.

Now, I _believe_, from the dicussions surrounding cross-site
XMLHttpRequest, that currently, <script src=""> is the only exception to
the cross-domain load security model (and we can't close the hole
because it would break too many sites). So perhaps having an option to
plug that hole would make sense.

Gerv

Dao

unread,
Mar 15, 2007, 1:48:20 PM3/15/07
to
Gervase Markham schrieb:

> Dao wrote:
>> I believe your grammar isn't expressive enough and lacks consistency
>> overall.
>
> Quite possibly. Better name suggestions welcomed.
>
>> So here's my initial EBNF proposal, which is based on and hopefully
>> something like a superset of your ideas:
>
> Thanks very much for taking the time to write down your suggestions. I
> really appreciate it.
>
> It does seem like quite a significant change. Why switch from one to two
> headers? I only think you need one. You start with full permissions,
> because that's what browsers do today, then make a list of the
> behaviours you want to restrict. Why make it more complex? What does it
> buy you?

You said we have to 'write the spec in terms of "restrictions" rather
than "capabilities"' because current user agents are fully capable. But
why not leave it to the author to restrict stuff and define capabilities
on top of that? That feels saner to me.

> What happens when we add new things, and sites which start with
> Content-Ban: all=all, Content-Permissions: <some stuff> break because
> new things are banned that they didn't expect? You'd need
> Content-Ban: reallyallthistimeIpromise=all.

The meaing of all=* should depend on the version, if specified.

>> Policy = Rules [ ";version=" VersionNumber ] ;
>> (* VersionNumber regexp: /^[1-9]\d*(\.\d+)?$/ *)
>
> What's the advantage of sub-versions? When would they be used?

1.1 could be an incremental update while 2.0 could remove obsolete stuff
/ break the API.

>> Rules = Rule { "," Rule } ;
>> Rule = ResourceRule | SpecialRule ;
>> GeneralKey = "all" | "none";
>> GeneralValue = "all" | "none";
>> ResourceRule = ( GeneralKey | Resource) "="
>> ( GeneralValue | ScopeCompound ) ;
>
> What do "none=all", "all=all" and "none=none" mean? For each of the two
> headers?

"none" can probably be removed on the left side since it doesn't do
anything.

Summary:

* Bans:
all=all everything is banned
all=none nothing is banned

* Permissions:
all=all everything is allowed (overrides all bans)
all=none no extra permissions (any given ban applies)

Contrary to my initial draft, the default policies have to be "all=none".

>> Resource = "scripts" | "objects" ;
>> (* for HTML, "objects" are the OBJECT, IMG, (I)FRAME
>> and EMBED elements *)
>> ScopeCompound = Scope { "+" Scope } ;
>> (* "+" is a conjunction *)
>> Scope = "document-head" |
>> "same-host" | "different-host" | Host ;
>> (* Host is a domain (punycode in the IDN case)
>> or an IP address *)
>> SpecialRule = CookieRule | HierarchyRule ;
>> CookieRule = ( GeneralKey | "cookies" ) "="
>> ( GeneralValue | "write" | "read" ) ;
>> HierarchyRule = ( GeneralKey | "script-access" ) "="
>> ( GeneralValue | "parent" | "children" ) ;
>
> I guess the big problem I see here is that the added flexibility comes
> at a large cost in implementation complexity, a reasonably large cost in
> the complexity and fragility of the headers, and not a great increase in
> usefulness in practice.
>
> What additional capabilities does your proposal provide?

I know what I can do according to my proposal, but I'm not sure about
yours. ;-)
Could you try to build my examples with your grammar? That's probably
the easiest way, since we both know our own proposals best. If needed,
we can define more examples in order to compare the results.

>> Examples:
>>
>> Content-Ban: scripts=different-host,cookies=read
>> Content-Permission: scripts=234.182.0.12
>
> But that's really a further restriction, not a permission, isn't it?

That's "ban all external scripts but those from 234.182.0.12". The first
part is a restriction and the second part is a permission.

Dao

Dao

unread,
Mar 15, 2007, 2:08:47 PM3/15/07
to
PolicyHeader = "Content-" PolicyType ": " Policy ;
(* for any PolicyType, the default Policy string
is "all=none" *)
PolicyType = "Ban" | "Permission" ;

(* permissions override bans *)
Policy = Rules [ ";version=" VersionNumber ] ;
(* VersionNumber regexp: /^[1-9]\d*(\.\d)?$/ *)

Rules = Rule { "," Rule } ;
Rule = ResourceRule | SpecialRule ;
GeneralKey = "all";

GeneralValue = "all" | "none";
ResourceRule = ( GeneralKey | Resource) "="
( GeneralValue | ScopeCompound ) ;
Resource = "scripts" | "objects" ;
(* for HTML, "objects" are the OBJECT, IMG, (I)FRAME
and EMBED elements *)
ScopeCompound = Scope { "+" Scope } ;
(* "+" is a conjunction *)
Scope = "document-head" |
"same-host" | "different-host" | Host ;
(* Host is a domain (punycode in the IDN case)
or an IP address *)
SpecialRule = CookieRule | HierarchyRule ;
CookieRule = ( GeneralKey | "cookies" ) "="
( GeneralValue | "write" | "read" ) ;
HierarchyRule = ( GeneralKey | "script-access" ) "="
( GeneralValue | "parent" | "children" ) ;


Examples:

1. Disable cookie access and ban all third-party scripts but those from
234.182.0.12:

Content-Ban: scripts=different-host,cookies=read
Content-Permission: scripts=234.182.0.12

2. Ban everything that's defined in version 1, except for same-host
originating scripts in the document head and embedded content
originating from the same host or static.example.com:

Content-Ban: all=all;version=1
Content-Permission:
scripts=document-head+same-host,objects=same-host,objects=static.example.com

Gervase Markham

unread,
Mar 16, 2007, 8:16:41 AM3/16/07
to
Dao wrote:
> You said we have to 'write the spec in terms of "restrictions" rather
> than "capabilities"' because current user agents are fully capable. But
> why not leave it to the author to restrict stuff and define capabilities
> on top of that? That feels saner to me.

To simplify to make the point: if the current capabilities are 100%, I
think it's more understandable to say "Reduce to 75%" than it is to say
"Reduce to 50% and then increase to 75%".

>> What happens when we add new things, and sites which start with
>> Content-Ban: all=all, Content-Permissions: <some stuff> break because
>> new things are banned that they didn't expect? You'd need
>> Content-Ban: reallyallthistimeIpromise=all.
>
> The meaing of all=* should depend on the version, if specified.

That would solve the problem. However, doing it the other way around
allows you to add new types of restriction without changing the version
number or breaking compatibility.

I think this is particularly important because I expect browser vendors
to implement the different restrictions incrementally and patchily at
first. (This expectation comes from watching them implement every other
standard, and because I may well be doing the our implementation :-).

So if you want a model where you do a load of restrictions and then
loosen particular things, the browser really has to be able to do *all*
or at least most of the restrictions that the standard specifies.

> 1.1 could be an incremental update while 2.0 could remove obsolete stuff
> / break the API.

As noted above, incremental updates are fully backwardly-compatible in
my scheme.

> I know what I can do according to my proposal, but I'm not sure about
> yours. ;-)

Which bits aren't clear?

Gerv

Gervase Markham

unread,
Mar 16, 2007, 8:16:43 AM3/16/07
to
Thanks for your feedback. I've updated the spec to take into account a
lot of your ideas. I've also improved my BNF - thanks for the object lesson.
http://www.gerv.net/security/content-restrictions/ (0.9.1)

Here are your examples in my form (from the new spec):

> 1. Disable cookie access and ban all third-party scripts but those from
> 234.182.0.12:
>
> Content-Ban: scripts=different-host,cookies=read
> Content-Permission: scripts=234.182.0.12

Content-Restrictions: 1;script-host=234.182.0.12,cookies=read

> 2. Ban everything that's defined in version 1, except for same-host
> originating scripts in the document head and embedded content
> originating from the same host or static.example.com:
>
> Content-Ban: all=all;version=1
> Content-Permission:
> scripts=document-head+same-host,objects=same-host,objects=static.example.com

Content-Restrictions:
1;cookies=none,hierarchy=none,script=header,script=external,script-host=<host-of-page>,host=<host-of-page>,host=static.example.com

This also blocks all internal script; was that your intent?

I think my version, although a bit longer in this case, is more
declarative - it's much more obvious what is being done from reading the
list. But I also think that "Ban everything in version 1" is not how a
web designer will think.

Note that you are using magic values for the "objects" restriction,
which means that it's not possible to have a host called "same-host" or
"different-host". You might be able to fix that using characters which
are not permitted in host names.

I don't see the practical use of the "different-host" restriction that
you give in your BNF; why would one want to restrict loads to only come
from servers one might not control? How is this an improvement on "all"?

Gerv

Dao

unread,
Mar 16, 2007, 3:09:05 PM3/16/07
to
Gervase Markham schrieb:

> To simplify to make the point: if the current capabilities are 100%, I
> think it's more understandable to say "Reduce to 75%" than it is to say
> "Reduce to 50% and then increase to 75%".

But isn't a whiteliste a more secure solution than a blacklist?
You don't have to increase the capabilities after you've reduced it, but
at least you have the opportunity to do so. I, for example, would like
to start with blocking all and enable only what I need.

>> The meaing of all=* should depend on the version, if specified.
>
> That would solve the problem. However, doing it the other way around
> allows you to add new types of restriction without changing the version
> number or breaking compatibility.
>
> I think this is particularly important because I expect browser vendors
> to implement the different restrictions incrementally and patchily at
> first. (This expectation comes from watching them implement every other
> standard, and because I may well be doing the our implementation :-).
>
> So if you want a model where you do a load of restrictions and then
> loosen particular things, the browser really has to be able to do *all*
> or at least most of the restrictions that the standard specifies.

If spec x states that there's restriction type a, b and c, what's the
difference between banning "all;version=x" and banning "a,b,c"? In both
cases, a vendor can chose to implement spec x halfway; e.g. ban a and b
only. To me, "all" is just a helper for disabling all capabilities right
away.

>> 1.1 could be an incremental update while 2.0 could remove obsolete
>> stuff / break the API.
>
> As noted above, incremental updates are fully backwardly-compatible in
> my scheme.

Wait, you were talking about incemental implementations, but not
updating the spec incrementally. The latter would be backward compatible
either way, assuming it's really done incrementally. And either way, you
have to bump the version number. Now, again, I would bump x to x + 0.1
in order to reflect its incremental nature.

>> I know what I can do according to my proposal, but I'm not sure about
>> yours. ;-)
>
> Which bits aren't clear?

The "domain" stuff was a bit confusing, but that's better after your
latest update.

Dao

unread,
Mar 16, 2007, 3:31:08 PM3/16/07
to
Gervase Markham schrieb:

> Thanks for your feedback. I've updated the spec to take into account a
> lot of your ideas. I've also improved my BNF - thanks for the object
> lesson.
> http://www.gerv.net/security/content-restrictions/ (0.9.1)

Do you really think specifying the version should be a must?
In any case, it shouldn't be a magic number. For the sake of consistency
I chose "version=" as in "application/javascript;version=1.7".

Maybe "hierarchy" should be "script-access" or even "script-access-to"
(for clarifying that you mean the content accessing stuff rather than
being accessed). "hierarchy" isn't self-explaining enough, imho.

Also, I think "head" or "document-head" fits better than "header". But
you're the native speaker, after all.

> Here are your examples in my form (from the new spec):
>
>> 1. Disable cookie access and ban all third-party scripts but those from
>> 234.182.0.12:
>>
>> Content-Ban: scripts=different-host,cookies=read
>> Content-Permission: scripts=234.182.0.12
>
> Content-Restrictions: 1;script-host=234.182.0.12,cookies=read

There's still the "same host" missing.

>> 2. Ban everything that's defined in version 1, except for same-host
>> originating scripts in the document head and embedded content
>> originating from the same host or static.example.com:
>>
>> Content-Ban: all=all;version=1
>> Content-Permission:
>> scripts=document-head+same-host,objects=same-host,objects=static.example.com
>
>
> Content-Restrictions:
> 1;cookies=none,hierarchy=none,script=header,script=external,script-host=<host-of-page>,host=<host-of-page>,host=static.example.com
>
>
> This also blocks all internal script; was that your intent?

I missed internal/external completely.

> Note that you are using magic values for the "objects" restriction,
> which means that it's not possible to have a host called "same-host" or
> "different-host". You might be able to fix that using characters which
> are not permitted in host names.

I think you should do that as well. Requiring to enter the same host
explicitly isn't a good thing.

> I don't see the practical use of the "different-host" restriction that
> you give in your BNF; why would one want to restrict loads to only come
> from servers one might not control? How is this an improvement on "all"?

I was using it for /banning/ different hosts. But you can also do it the
other way around.

Gervase Markham

unread,
Mar 20, 2007, 7:43:10 AM3/20/07
to
Dao wrote:
> Gervase Markham schrieb:
>
>> To simplify to make the point: if the current capabilities are 100%, I
>> think it's more understandable to say "Reduce to 75%" than it is to
>> say "Reduce to 50% and then increase to 75%".
>
> But isn't a whiteliste a more secure solution than a blacklist?

Only if the full list of things you are trying to enumerate (e.g.
websites) is unknown and variable.

If you have a fixed list of 20 known things, saying "These 10 are good"
is just as secure as saying "These 10 are bad".

In our case, we start with a fixed list. But in the future, the list may
get bigger, with new things being added. When new things are added, they
will be things that the browser currently allows that we wish to
optionally restrict. Therefore, it is correct that the default be
"permit" (for backwards compatibility), and the style of list be a list
of restrictions ("blacklist") rather than a whitelist.

We are not designing a generic permissions-based security system here;
we are specifically designing a way for authors to prevent their pages
having capabilities that browsers normally permit.

> You don't have to increase the capabilities after you've reduced it, but
> at least you have the opportunity to do so. I, for example, would like
> to start with blocking all and enable only what I need.

But the meaning of "all" changes over time. Therefore, newer browsers
may block things you aren't expecting, and your sites break.

>>> The meaing of all=* should depend on the version, if specified.

As you say, the other alternative is to have several "alls":

Version 1 "all" means "block foo, bar and baz"
Version 2 "all" means "block foo, bar, baz and quux"
Version 3 "all" means "block foo, baz, quux, fred and wilma".

I don't like that type of definition of "all". And it's not necessary
(as I outlined above).

Gerv

Gervase Markham

unread,
Mar 20, 2007, 8:01:21 AM3/20/07
to
Dao wrote:
> Do you really think specifying the version should be a must?

You're probably right; we could have an optional "version=X" parameter,
which had to be the first one if present.

> Maybe "hierarchy" should be "script-access" or even "script-access-to"
> (for clarifying that you mean the content accessing stuff rather than
> being accessed). "hierarchy" isn't self-explaining enough, imho.

I agree it's not the best name. But I don't like "script-access",
because it's too generic (and also sounds explicitly like a permission
rather than a restriction). If the name was "script-access-to", people
might write "script-access-to=cookie" or things like that.

It started off being called "frames" but I thought that was too
HTML-specific.

> Also, I think "head" or "document-head" fits better than "header". But
> you're the native speaker, after all.

These names seemed a little HTML-specific to me. But if people tell me
that "head" rather than "header" is a generic term for the
top/unrendered/whole-page-affecting sections of XML-based or derived
markup languages, then I'm happy to change.

>> Here are your examples in my form (from the new spec):
>>
>>> 1. Disable cookie access and ban all third-party scripts but those from
>>> 234.182.0.12:
>>>
>>> Content-Ban: scripts=different-host,cookies=read
>>> Content-Permission: scripts=234.182.0.12
>>
>> Content-Restrictions: 1;script-host=234.182.0.12,cookies=read
>
> There's still the "same host" missing.

Oh, right. Yes.

Content-Restrictions:
1;script-host=<my-host>,script-host=234.182.0.12,cookies=read
under 0.9.1;
script-host=this,script-host=234.182.0.12,cookies=read
under 0.9.2.

>> Note that you are using magic values for the "objects" restriction,
>> which means that it's not possible to have a host called "same-host"
>> or "different-host". You might be able to fix that using characters
>> which are not permitted in host names.
>
> I think you should do that as well. Requiring to enter the same host
> explicitly isn't a good thing.

Actually, you may be right. Often you don't easily know which machine of
a pool the user is interacting with. Much as I don't like magic values,
I think their usefulness is probably worth it.

Version 0.9.2 posted.

Gerv

Dao

unread,
Mar 20, 2007, 10:34:38 AM3/20/07
to
Gervase Markham wrote:
> Dao wrote:
>> Gervase Markham schrieb:
>>
>>> To simplify to make the point: if the current capabilities are 100%,
>>> I think it's more understandable to say "Reduce to 75%" than it is to
>>> say "Reduce to 50% and then increase to 75%".
>>
>> But isn't a whiteliste a more secure solution than a blacklist?
>
> Only if the full list of things you are trying to enumerate (e.g.
> websites) is unknown and variable.
>
> If you have a fixed list of 20 known things, saying "These 10 are good"
> is just as secure as saying "These 10 are bad".

I guess the common relation is more like "these 5 are good" / "these 15
are bad". That makes your list a bit larger and it will be easy to miss
a bad thing. The other way around, if you miss something from the
whitelist, you will probably notice that.

> In our case, we start with a fixed list. But in the future, the list may
> get bigger, with new things being added. When new things are added, they
> will be things that the browser currently allows that we wish to
> optionally restrict. Therefore, it is correct that the default be
> "permit" (for backwards compatibility), and the style of list be a list
> of restrictions ("blacklist") rather than a whitelist.

I got that, but you can avoid the compatibility problem by letting the
author change the initial state from "permit" to "prohibit" and, as
said, define capabilities on top of that. This wouldn't break
backwards-compatibility. This would even be compatible with your
approach, since you a) don't have to prohibit everything and b) can
leave out the second step / header (capabilities).

>> You don't have to increase the capabilities after you've reduced it,
>> but at least you have the opportunity to do so. I, for example, would
>> like to start with blocking all and enable only what I need.
>
> But the meaning of "all" changes over time. Therefore, newer browsers
> may block things you aren't expecting, and your sites break.

... only if the version isn't specified. That is, the browser would have
to tag features with the versions that they are defined in.

> >>> The meaing of all=* should depend on the version, if specified.
>
> As you say, the other alternative is to have several "alls":
>
> Version 1 "all" means "block foo, bar and baz"
> Version 2 "all" means "block foo, bar, baz and quux"
> Version 3 "all" means "block foo, baz, quux, fred and wilma".
>
> I don't like that type of definition of "all". And it's not necessary
> (as I outlined above).

Yes, it isn't. It's just a shortcut; could be left out. On the other
hand, you're not forced to use it.

Dao

unread,
Mar 20, 2007, 11:00:38 AM3/20/07
to
Gervase Markham wrote:
> Dao wrote:
>> Do you really think specifying the version should be a must?
>
> You're probably right; we could have an optional "version=X" parameter,
> which had to be the first one if present.

Why the first rather than the last one?
Regarding 0.9.2, why is VersionRule a Rule like all others? It's not a
content restriction after all.

>> Maybe "hierarchy" should be "script-access" or even "script-access-to"
>> (for clarifying that you mean the content accessing stuff rather than
>> being accessed). "hierarchy" isn't self-explaining enough, imho.
>
> I agree it's not the best name. But I don't like "script-access",
> because it's too generic (and also sounds explicitly like a permission
> rather than a restriction). If the name was "script-access-to", people
> might write "script-access-to=cookie" or things like that.
>
> It started off being called "frames" but I thought that was too
> HTML-specific.

Maybe you can use the sandbox metaphor.

>> Also, I think "head" or "document-head" fits better than "header". But
>> you're the native speaker, after all.
>
> These names seemed a little HTML-specific to me. But if people tell me
> that "head" rather than "header" is a generic term for the
> top/unrendered/whole-page-affecting sections of XML-based or derived
> markup languages, then I'm happy to change.

I always think of page layouts when reading "header"; like a graphical
header.

>>> Here are your examples in my form (from the new spec):
>>>
>>>> 1. Disable cookie access and ban all third-party scripts but those from
>>>> 234.182.0.12:
>>>>
>>>> Content-Ban: scripts=different-host,cookies=read
>>>> Content-Permission: scripts=234.182.0.12
>>>
>>> Content-Restrictions: 1;script-host=234.182.0.12,cookies=read
>>
>> There's still the "same host" missing.
>
> Oh, right. Yes.
>
> Content-Restrictions:
> 1;script-host=<my-host>,script-host=234.182.0.12,cookies=read
> under 0.9.1;
> script-host=this,script-host=234.182.0.12,cookies=read
> under 0.9.2.

This reads like "restrict scripts to this host && restrict scripts to
234.182.0.12", which would ban all scripts unless "this" equals
234.182.0.12. ;)

Gervase Markham

unread,
Mar 21, 2007, 6:00:16 AM3/21/07
to
Dao wrote:
> Why the first rather than the last one?

Because you want to know what version you are using before you parse the
rest of the string.

> Regarding 0.9.2, why is VersionRule a Rule like all others? It's not a
> content restriction after all.

True; if it has to be first, it should be something different. I'll fix
the BNF.

>> I agree it's not the best name. But I don't like "script-access",
>> because it's too generic (and also sounds explicitly like a permission
>> rather than a restriction). If the name was "script-access-to", people
>> might write "script-access-to=cookie" or things like that.
>>
>> It started off being called "frames" but I thought that was too
>> HTML-specific.
>
> Maybe you can use the sandbox metaphor.

I don't like the word "sandbox". For a start, the actual object is a
very American thing; in the UK, we call it a "sandpit" :-)

More seriously, the idea of sandbox is too strong; it implies complete
constraint of action.

>> Content-Restrictions:
>> 1;script-host=<my-host>,script-host=234.182.0.12,cookies=read
>> under 0.9.1;
>> script-host=this,script-host=234.182.0.12,cookies=read
>> under 0.9.2.
>
> This reads like "restrict scripts to this host && restrict scripts to
> 234.182.0.12", which would ban all scripts unless "this" equals
> 234.182.0.12. ;)

I don't agree; it's a list of hosts. We could define an abbreviated syntax:

script-host=this|234.182.0.12

I suppose. But it would require Yet Another Separator Character.

Gerv

Dao

unread,
Mar 21, 2007, 8:07:50 AM3/21/07
to
Gervase Markham wrote:
> Dao wrote:
>> Why the first rather than the last one?
>
> Because you want to know what version you are using before you parse the
> rest of the string.

Using ";" as the separator allows you to escape from the strict serial
order. I.e. find ";", parse the version, then parse the rest.

>>> Content-Restrictions:
>>> 1;script-host=<my-host>,script-host=234.182.0.12,cookies=read
>>> under 0.9.1;
>>> script-host=this,script-host=234.182.0.12,cookies=read
>>> under 0.9.2.
>>
>> This reads like "restrict scripts to this host && restrict scripts to
>> 234.182.0.12", which would ban all scripts unless "this" equals
>> 234.182.0.12. ;)
>
> I don't agree; it's a list of hosts.

Technically, it's a list of restrictions to the host. Of course you can
implement it differently, but that won't be completely obvious.

Dao

unread,
Mar 21, 2007, 8:18:37 AM3/21/07
to
Gervase Markham wrote:
>> Regarding 0.9.2, why is VersionRule a Rule like all others? It's not a
>> content restriction after all.
>
> True; if it has to be first, it should be something different. I'll fix
> the BNF.

btw,
[ Version "," ]
equals
( Version "," | "" )

Gervase Markham

unread,
Mar 22, 2007, 7:43:15 AM3/22/07
to
Dao wrote:
> btw,
> [ Version "," ]
> equals
> ( Version "," | "" )

Thanks :-)

Gerv

Reply all
Reply to author
Forward
0 new messages