Page 3 of 4

Re: Making sure I understand...

Posted: Fri Jun 27, 2014 4:33 am
by barbaz
Sorry to jump in this discussion so late but a couple of (crazy?) thoughts:
1) What about using 'Target' as an alias for Site? How does that compare in terms of intuitiveness to 'Request'?

Code: Select all

Target .analytics-si.te
Accept from .friend1.com .friend2.com
Deny

Target .bank.com
Accept from SELF+
Deny

# backwards
Target .foo.net
Accept from .advertising-si.te
Deny
2) If "Request" is added as an alias for Site, could you please also allow it to be shortened to 'Req'?

Re: Making sure I understand...

Posted: Fri Jun 27, 2014 10:22 am
by Thrawn
barbaz wrote: 1) What about using 'Target' as an alias for Site? How does that compare in terms of intuitiveness to 'Request'?
Well, it's probably similar, but IMHO, 'Request' has the advantage of actually describing what ABE is controlling: HTTP requests. And to say that you "request xxx" is valid grammar.

Any advantage of 'Target'?
2) If "Request" is added as an alias for Site, could you please also allow it to be shortened to 'Req'?
That's easy; it would be:

Code: Select all

grammar ABE;

options {
   language=JavaScript;
   output=AST; 
}

tokens {
  T_ACTION;
  T_METHODS;
}

ruleset   : rule* EOF ;
rule      : subject predicate+ -> subject predicate+ ;
predicate : action methods? origin? -> T_ACTION action T_METHODS methods? origin? ;
methods   : (method+ | ALL) ;
method    : (HTTPVERB | SUB | inclusion) ;
inclusion : INC (LPAR (INC_TYPE COMMA)* INC_TYPE? RPAR)? ;
origin    : T_FROM oresources ;
subject   : T_SITE resources ;
oresources: (oresource+ | ALL) ;
resources : (resource+ | ALL) ;
oresource: resource | 'SELF' | 'SELF+' | 'SELF++' ;
resource  : REGEXP | GLOB | URI | LOCATION ;
action    : A_DENY | A_LOGOUT | A_SANDBOX  | A_ACCEPT ;

T_SITE    : 'Site' | 'Req' 'uest'? ;
T_FROM    : ('f' | 'F') 'rom' ;
A_DENY    : 'Deny' ;
A_LOGOUT  : 'Logout' | 'Anon' 'ymize'? ;
A_SANDBOX : 'Sandbox' ;
A_ACCEPT  : 'Accept' ;

fragment URI_START : 'a'..'z' | '0'..'9' ;
fragment URI_PART  : 'a'..'z' | 'A'..'Z' | '0'..'9' | '_' | '-' | '.' | 
        '[' | ']' | ':' | '/' | '@' | '~' | ';' | ',' | 
        '?' | '&' | '=' | '%' | '#' ;
LOCATION  : 'LOCAL' ;
URI       : URI_START URI_PART+ ;
GLOB      : (URI_START | '*' | '.') (URI_PART | '*')* ;
REGEXP    : '^' ~'\n'+ ;

ALL       : 'ALL' ;
SUB       : 'SUB' ;
INC       : 'INC' 'LUSION'? ;
INC_TYPE   : 'OTHER' | 'SCRIPT' | 'IMAGE' | 'CSS' | 'OBJ' | 'SUBDOC' | 'XBL' | 'PING' | 'XHR' | 'OBJSUB' | 'DTD' | 'FONT' | 'MEDIA' ;
HTTPVERB  : 'A'..'Z' 'A'..'Z'+ ;

COMMA     : ',' ;
LPAR      : '(' ;
RPAR      : ')' ;

WS        :  (' '|'\r'|'\t'|'\u000C'|'\n') {$channel=HIDDEN;} ;
COMMENT : '#' ~'\n'* {$channel=HIDDEN;} ;
By the way, logs in the Browser Console will still show 'Site' due to ABE.js line 735 (ABERule.prototype.toString). Which is probably fine; the same thing happens with 'Anon' and 'Logout' collapsing into 'Anonymize'.

Re: Making sure I understand...

Posted: Fri Jun 27, 2014 3:49 pm
by barbaz
Thrawn wrote:Any advantage of 'Target'?
'Target' very clearly gives the sense of something that requests will be directed to; IOW, it's hard to take 'Target' as meaning request source. People throw things at a "real" target (the target doesn't throw things at people :shock: ), just like HTTP requests are being sent to, not from, the Site.
'Request' doesn't convey that quite as strongly.
Just IMO. YMMV.
Thrawn wrote:
2) If "Request" is added as an alias for Site, could you please also allow it to be shortened to 'Req'?
That's easy; it would be:
[...]
Thanks.

Re: Making sure I understand...

Posted: Fri Jun 27, 2014 4:17 pm
by Giorgio Maone
What about Destination (as opposite to "Origin" which is already a web security accepted term, and specifically related to the "From" clause)?

Re: Making sure I understand...

Posted: Fri Jun 27, 2014 4:35 pm
by barbaz
Giorgio Maone wrote:What about Destination (as opposite to "Origin" which is already a web security accepted term, and specifically related to the "From" clause)?
Yes, that too makes it hard to misunderstand & thus generate backwards ABE rules.
The main disadvantage of 'Destination' is as you said earlier it's really long. I suppose it could be (optionally) shortened to something like 'Dest'...

Re: Making sure I understand...

Posted: Sat Jun 28, 2014 10:43 am
by Thrawn
'Dest' 'ination'? sounds good to me :).

Re: Making sure I understand...

Posted: Mon Jun 30, 2014 12:51 am
by Thrawn
The most important thing, it seems to me, is to get people out of the mindset of script-blocking, where you restrict the privileges of a potentially-hostile site, and get them into the ABE mindset, restricting access to a potentially-sensitive site.

Even 'Access' might be a suitable keyword.

Code: Select all

Access bank.com
Accept from trusted.net
Deny
Or 'Protect' - although that is really only descriptive when using ABE in its original fashion of CSRF protection. Still, maybe that would make people think.

Re: Making sure I understand...

Posted: Tue Jul 01, 2014 3:51 am
by barbaz
Thrawn wrote:Or 'Protect' - although that is really only descriptive when using ABE in its original fashion of CSRF protection. Still, maybe that would make people think.
no, "Access" is better because that's *exactly* what ABE is guarding when it's used as an anti CSRF tool - IOW, ABE rules for anti CSRF are basically defining what is legitimate "access" to a sensitive site. "Protect" is not intuitive to me for any use case because you're not accepting/blocking protection from origin sites.

for comparison, correct and backwards ABE rules with Access instead of Site

Code: Select all

Access .analyticsdom.ain
Accept from .friendlysi.te
Deny

# backwards
Access .friendlysi.te
Accept from .analyticsdom.ain
Deny

Re: Making sure I understand...

Posted: Thu Jul 03, 2014 10:44 am
by forecehh
i dont read whole topic,just some last post
i would like to see rule like this more understanding to me

Code: Select all

at .analyticsdom.ain
Just Accept .friendlysi.te
Deny
or

Code: Select all

on .analyticsdom.ain
Just Accept .friendlysi.te
Deny

Re: Making sure I understand...

Posted: Thu Jul 03, 2014 10:32 pm
by Thrawn
Hmm. Syntax like that sounds (to me) very prone to the original problem of people reading it backwards...

Re: Making sure I understand...

Posted: Tue Nov 10, 2015 1:31 am
by Thrawn
Bump.

There have been several suggestions of aliases for 'Site' that may be more intuitive for newcomers to ABE. From what I've briefly tested, it would just be a tiny change to the grammar file and recompilation.

Personally I favor either 'Req(uest)' or 'Access'.
'Dest(ination)' could work too.

Re: Making sure I understand...

Posted: Sat Nov 14, 2015 1:29 am
by Phil
In short: My preferred option would be:

Code: Select all

Access to ajax.googleapis.com
Allow from mysite.com
In long...

I agree that the original "Site" is extremely prone to being misinterpreted.

I think "Request" is good, but I think "Request to" would be even better, as it provides an explicit "to" and "from" which really reinforces the direction:

Code: Select all

Request to ajax.googleapis.com
Allow from mysite.com
To elaborate: there's been a lot of talk about which terms best imply sending or receiving; but resorting to implication seems crazy when we can simply add the word "to" and make it explicit (as well as fitting perfectly with the "from" in the lines which follow).

"Access" also seems good. I can't quite decide if it's better than "Request" (the latter has the advantage of being an obvious keyword for people with technical knowledge, and slightly more specific in terms of what it really means). However I would again suggest that "Access to" is a considerable improvement upon just "Access", and in this form I think it's my preferred option:

Code: Select all

Access to ajax.googleapis.com
Allow from mysite.com
"Resource" was briefly debated, and I must agree with Thrawn who pointed out that this term is precisely what is used in the documentation!
A rule looks like this:

Site <resource>

A <resource> is typically an URI pattern (literal, glob or regexp) designing a request destination (site), or a wildcard token such as ALL or SELF.
If it's appropriate for the documentation, I can't understand why it wouldn't be considered for the rule syntax. (If it's not appropriate for the rules, the documentation should be changed.)

As such, "Resource" seems reasonable to me. It's probably not as good as "Request to" or "Access to"; however, if it were not possible to have the " to" suffix, I think "Resource" is perhaps on a par with "Request" and "Access" as a single-word option?

Code: Select all

Resource ajax.googleapis.com
Allow from mysite.com
I think that some of the other suggested aliases remain confusing and prone to misinterpretation by users who do not already understand that it is a request model.

In that context, I think "On" and "At" are exactly as ambiguous as "Site".

"Target" would be very nearly as ambiguous as "Site". People can just as easily think "This rule is targetting mysite.com" for the former, as they can think "This rule is for site mysite.com" for the latter.

I think "Destination" is simply confusing if you don't understand that you're referring to a Request. It's not an intuitive replacement at all. "Source" was also suggested. I think the fact that both "Source" and "Destination" have been proposed as labels for the same thing is indicative of just how confusing this can be, and why maximum clarity should be the goal. I therefore think neither "Source" nor "Destination" are good options.

Re: Making sure I understand...

Posted: Sat Nov 14, 2015 1:38 am
by Phil
Gah. My apologies for the "Allow" / "Accept" problem in my previous post. I keep doing that, and I can't edit the post to fix it.

Changing it to "Accept" does make me question my preferred option, though. We "allow access" but we "accept requests", so with that in mind I think I actually prefer:

Code: Select all

Request to ajax.googleapis.com
Accept from mysite.com

Re: Making sure I understand...

Posted: Sat Nov 14, 2015 1:54 am
by Phil
One more note: I did consider whether "Request for <resource>" was an even more readable variant of "Request to <resource>", but I concluded that it would introduce (once more) an ambiguity problem for the reader, because as an English phrase "Request for site.com" could be interpreted as "Request on behalf of site.com", whereas I believe that no such misinterpretation is possible with the "Request to" approach. I therefore think "Request to" is the most unambiguous option.

Re: Making sure I understand...

Posted: Sat Nov 14, 2015 6:43 pm
by barbaz
@Phil: I like your idea but I think it maybe better for the keyword to be something like "RequestTo" (without a space).
And to reiterate, +1 because this one could still alias as "Req" to save advanced users a small amount of typing. :mrgreen: