Making sure I understand...

Discussions about the Application Boundaries Enforcer (ABE) module
Tom T.
Field Marshal
Posts: 3620
Joined: Fri Mar 20, 2009 6:58 am

Re: Making sure I understand...

Post by Tom T. » Sat May 12, 2012 1:41 am

GµårÐïåñ wrote:I'll simply answer all of it by saying, when you try to use a more "common" term if you will, you are introducing ambiguity and causing it to mean more than one thing and that has a far more reaching severe effect in the long term than just taking time to get it right. .....This is why when you say PC everyone thinks, oh windows machine, no, its not. Its a personal computer which can be linux, mac, or windows.

I respectfully beg to differ.

IBM's early entry into the personal computer market was the IBM PC, a trademarked name, and it ran MS-DOS.
Other OEMs, seeing the popularity of this system, would make theirs compatible, calling it "PC-compatible".
Prospective buyers of a personal computer often asked "Is it PC-compatible?"

So yes, PC strictly refers to Windows-based machines.
As in the long-running ad campaign of Apple vs. Vista.

First guy says, "I'm a PC."
Second guy says, "And I'm a Mac". (He's much cooler, of course.)

First guy didn't say, "I'm Windows"; he said "I'm a PC".
And if PC applied to Mac, then the ad makes no sense, because then they're both PCs.

It is widely understood that a PC is a Windows-based personal computer. If you have a Mac, or a *nix-powered machine, you definitely have a "personal computer".
But you don't have a PC.

As said below, "Semantics matter." ;)

OK, yes, this is proving your point about misuse of terms. But that is not what's happening in this suggestion. We're making it *easier to understand*, not introducing ambiguity.

Your analogy of site vs. object fits the suggestion well, because both the tie and the source of the tie are in the suggested rule:

Source tie@dad (rules out shoe or shirt)
Accept at son (the current syntax would require "Accept from son", which is the counter-intuitive part. But son is indeed the recipient, not the sender, of the tie. The Request model of the current syntax is based on "Son makes HTTP request to dad for tie. Allow dad to accept HTTP requests from son for tie.")
Deny (tie from brother or uncle, implied)
So now you say something that should be obvious,

We're trying to make it *more* obvious, as above.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/12.0

User avatar
Giorgio Maone
Site Admin
Posts: 8735
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: Making sure I understand...

Post by Giorgio Maone » Sat May 12, 2012 8:16 am

Chiming in with a warning: I didn't read the whole thread, but it seems lately it is about what "Site" means.

Well, in ABE context, it just means the final endpoint of a HTTP request or, in other words, its destination.

I admit it would have been slightly clearer if, instead of "Site" (which as far as I know about English just means "Place", with no connotation about movement or direction) I had used "Destination", which unfortunately is quite long but would have made the rules more self-explanatory like:

Code: Select all

Destination .mybank.com
Accept POST from .mybank.com api.financialservices.com
Accept GET
Deny

I just believed that "Accept" and "from" already hinted about the direction...
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0

Tom T.
Field Marshal
Posts: 3620
Joined: Fri Mar 20, 2009 6:58 am

Re: Making sure I understand...

Post by Tom T. » Sat May 12, 2012 9:40 am

Giorgio Maone wrote:Chiming in with a warning: I didn't read the whole thread, but it seems lately it is about what "Site" means.

Well, in ABE context, it just means the final endpoint of a HTTP request or, in other words, its destination.

What I have been gleaning from the many posts by users, some of them not at all novices, is that it's the "request" portion that causes the confusion. That is not intuitive to the user who doesn't understand that ABE's context is based on a request model.

So, if I may use GµårÐïåñ's excellent simplified analogy,

Code: Select all

Site tie@dad.com
Accept from son.com
Deny

To those who understand the request model, this rule permits tie@dad.com to accept a request from son.com for a tie, which Dad then sends (lends?) him.

In non-tech English, without knowledge of the request model, it's "very clear" (sic) that Dad is accepting a tie from Son.

Perhaps to emphasize:

Code: Select all

Site $10@Giorgio.net
Accept from Tom.com
Deny

You and I understand this to mean that you (Giorgio) will accept a request from me (Tom) to ask you to send me ten dollars.
The user not familiar with the HTTP Request model simply reads this as: Giorgio will accept ten dollars from Tom.
Does that help? ... it's *exactly* what has confused a number of posters; I won't waste your time by pointing to all of them.
I just believed that "Accept" and "from" already hinted about the direction...

The direction of the request, yes. But only if one understands that request model.

The non-cognoscenti take "Accept from" LITERALLY (in plain English) -- the first site will accept something from the second site.

Hence they try rules like:

Code: Select all

Site .myfavesite.com
Accept from .google-syndication.com
Deny

... in the mistaken belief that to help support their favorite site, they will accept ads from G-S at that site, but nowhere else.
Their fave site is "Accepting (script) FROM g-s.

It becomes necessary to explain that no, we must control the sites FROM WHICH g-s may accept (and reply to -- that's the missing part) requests.
Most users focus on what we know to be the reply -- the script or object that is sent, at the site's (permitted) request.

Instinctive (non-tech) usage would create a rule like "Accept AT myfavesite.com", with the source being g-s.com.

It is difficult for someone like yourself, who started learning these things as a child, and can't remember not knowing them, to empathize with those to whom this is all new. That is true in all fields of knowledge.

I'll close with a bit of immodesty, partially compensated for by a confession of ignorance:

I have a professional level of knowledge of the English language. I learned to read at age three, and was reading from an encyclopedia at age five. I was allowed to skip the first year of required University freshman English, and received credit for the skipped courses, by scoring very highly on the Advanced Placement (AP) tests. I've worked as a private tutor, including helping students improve their scores on the standardized US college entrance exams, the SAT and ACT -- which test verbal skills very heavily.

And I was honored to be one of those chosen to preview the early drafts of Bruce Schneier's recent book, "Liars & Outliers: Enabling the trust that society needs to thrive". (John Wiley and Sons, February 2012). Mr. Schneier wrote 125,000 words of manuscript. I sent 55,000 words of critique, including usage, meaning, syntax, simple typos, etc. A number of my suggestions (not all, of course) were accepted and included in the book. If you look at the Acknowledgments on pgs. 347-348, you will find me listed there (under my real full name, which of course I ask you not to disclose, for the sake of privacy).

Confession: When first exposed to the ABE rules, I had the same initial reaction: It's backwards. :? I think you and I might even have had a brief discussion about it, and about using the request model -- which then made sense of it.

The point is that if someone this well-versed in the English language, but without your decades of tech learning and experience, could misunderstand this, then we cannot fault anyone else who reads it the "wrong" way. Especially if English is not their native language either, but even for native speakers.

Code: Select all

Source: $10@Giorgo.net
Accept at Tom.com
Deny

would be intuitively understood by anyone who speaks basic English. Not suggesting changing ABE, just Thrawn's idea of adding aliases that non-tech users would grasp immediately. Like this:

Code: Select all

Source: .google-syndication.com
Accept at .myfavesite.com
Deny

Sorry to have bored you with my creds, but I hope it helps.

ETA: "Destination" would still be regarded by the average user as being the site that they are presently visiting -- the landing site of the script or object that they are choosing to allow.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/12.0

Tom T.
Field Marshal
Posts: 3620
Joined: Fri Mar 20, 2009 6:58 am

Re: Making sure I understand...

Post by Tom T. » Sat May 12, 2012 11:31 am

Sorry, an afterthought re:
"Site" (which as far as I know about English just means "Place", with no connotation about movement or direction)

Exactly, and that's part of the problem: Both the first and second lines (usually) call for the entry of a site:

Code: Select all

Site .somesite.com
Accept from .someothersite.com
Deny

As you correctly note, "Site" itself does not imply direction, but "from" implies "receiving".

Better example: E-mail.

To: Giorgio Maone @ informaction.com
From: Tom T. @ someplace.com

Here, it's clear that Tom is a source, who sends e-mail TO Giorgio, AT Giorgio's address.
Both "source" (sender, From) and "to/at" (recipient) have clear directionality.
No wonder that users would expect the same directionality for ABE's "From" syntax, and write:

Site .forums.informaction.com
Accept from .noscript.net -- intending to allow noscript.net's scripting at this forum.

The e-mail addressing could just as well read:

Source: Tom T. @ someplace.com
At: informaction.com/gmaone ---- which is unequivocally directional.

Hence the intuitive directionality of

Code: Select all

Source .noscript.net
Accept at .hackademix.net .informaction.com .noscript.net
Deny

By now, you're wishing my parents had never taught me to read... ;)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/12.0

User avatar
Giorgio Maone
Site Admin
Posts: 8735
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: Making sure I understand...

Post by Giorgio Maone » Sat May 12, 2012 12:42 pm

The main problem here seems to be forgetting that ABE is a protection against CSRF (Cross Site Request Forgery).
Hence all its syntax revolves around the request-response paradigm of HTTP, with special regard to request.
Actually, ABE doesn't give a damn about the response (might it be a script, a stylesheet, a document, an image, a plugin content object and so on): it only cares about the request, i.e. the message sent to Site by the browser on behalf of ("from") the so called "Origin", which usually is the page where the link, or the image tag, or the object element and so on is embedded.

In other words, all this confusion is probably due to the bending of ABE (or Request Policy, for the matter) to a content blocker: neither ABE nor Request Policy have been designed as content blockers (the content, i.e. the response from Site, being blocked is just an obvious side effect of the request to Site never reaching it).

Just an example to explain why the response doesn't matter, and using "Source" and "At" would be misleading:

Code: Select all

Site .mybank.com
Accept POST from .mybank.com
Accept GET
Deny

What I want to protect here, for instance, are resources identified by URLs like https ://mybank.com/wiretransfer.do. I don't care whether loading this URL fetches down a HTML document, a flash movie or just a plain text "OK" response: what I want to prevent is the HTTP message (request) "POST https://mybank.com/wiretransfer.do ...[financial transaction data]..." from reaching the mybank.com server unless it is originated by a web page inside the bank website itself. Otherwise, if the site is vulnerable to CSRF, I might allow random web pages to perform financial transactions on my behalf by auto-submitting a form.

To stress it again:

Code: Select all

Site a.com
Accept from a.com b.com

Is not meant to "protect" you against malicious content from a.com, but to protect a.com against malicious requests from d.com, e.com and so on.
Any other usage is just a side effect, and I'm not going to alter the syntax in ways that make the primary anti-CSRF aim less clear.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0

Tom T.
Field Marshal
Posts: 3620
Joined: Fri Mar 20, 2009 6:58 am

Re: Making sure I understand...

Post by Tom T. » Sat May 12, 2012 10:36 pm

i understand, Giorgio. Thanks for the detailed explanation.

I was trying only to explain why many users were confused by the syntax. Perhaps those many words in my posts would help such users to understand the syntax, and your reply will explain the need to keep the current syntax.

Agree that many are using ABE as a content blocker (web bugs, etc.), as you have suggested on occasion. Will NS 3's built-on site-specific-permissions GUI render this unnecessary? ... and let us hope it arrives soon.

Thank you for your time.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/12.0

User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Making sure I understand...

Post by Thrawn » Mon May 14, 2012 3:40 am

Fair point from Giorgio about ABE being a request blocker rather than content blocker. Let's see if we can preserve that while still making the syntax more novice-friendly.

How about Request as an alias for Site? Is that intuitive to others?

Code: Select all

Request bank.com
Accept from SELF trusted.net
Deny

Request advertising.com
Accept from friendlyblog.com
Deny

# clearly wrong
Request friendlyblog.com
Accept from advertising.com
Deny
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (Linux; U; Android 2.2.1; en-gb; GT-S5570 Build/FROYO) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

User avatar
GµårÐïåñ
Lieutenant Colonel
Posts: 3339
Joined: Fri Mar 20, 2009 5:19 am
Location: PST - USA
Contact:

Re: Making sure I understand...

Post by GµårÐïåñ » Mon May 14, 2012 9:27 pm

I tried making the point from a more user-friendly aspect, Giorgio gave it from a technical perspective but keeping it understandable, so I think the point has been made and so I will now just bow out of this discussion. I didn't want anyone thinking I just left the discussion but rather don't have the time to go in circles, so I will leave it to you all and Giorgio to hammer it out further.
~.:[ Lï£ê ï§ å Lêmðñ åñÐ Ì Wåñ† M¥ Mðñê¥ ßå¢k ]:.~
________________ .: [ Major Mike's ] :. ________________
Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20100101 Firefox/12.0

Tom T.
Field Marshal
Posts: 3620
Joined: Fri Mar 20, 2009 6:58 am

Re: Making sure I understand...

Post by Tom T. » Tue May 15, 2012 4:42 am

I was going to wait to see if Giorgio replied to Thrawn's idea, but it's been > 24 hrs, so I'll just say that IMHO ONLY, adding "Request" as an alias for "Site" does fit with Giorgio's paradigm and philosophy, and probably would help the new ABE user. His counter-example is an even stronger argument:

Code: Select all

# clearly wrong
Request friendlyblog.com
Accept from advertising.com
Deny

Again IMHO, the new ABE user is more likely to realize that they're not requesting anything from friendlyblog, the site they're presently on, so whether or not it's understood that friendlyblog is issuing a request to adsite, intuitiveness matches HTTP Request/Response paradgim more closely.

'Bout all this writer has to say on the subject. Up to Giorgio of course; no objection here whichever way he decides.


ETA: This thread is an example of one in which the user started off with a "backwards" rule, not understanding the request/response model. Not singling anyone out for aspersion, as there are many other examples. Added only to provide a real-world case where the syntax was counter-intuitive to an apparently tech-knowledgeable user, understanding that it's still possible that the status quo must remain.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/12.0

User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Making sure I understand...

Post by Thrawn » Tue Jun 11, 2013 12:33 pm

Just thought I'd update this thread to mention that I still think adding 'Request' as an alias for 'Site' would be helpful for new ABE users. Coming from NoScript's usual content-blocking, which is oriented around the site in the address bar, it's confusing to have the keyword 'Site' applied to the various destinations of the third-party requests that the top-level site is making. 'Request' seems to fit better.

From what I can see, to implement this, it would need to be added at:
  • ABE.g, line 27
  • mT_SITE function in ABELexer.js, line 154
  • Maybe ABERule.toString function in ABE.js, line 738
  • And of course the documentation.
Any alternative suggestions for smoothing the mental transition from top-level-site-oriented rules to destination-oriented rules?
Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:21.0) Gecko/20100101 Firefox/21.0

User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Making sure I understand...

Post by Thrawn » Thu Jun 26, 2014 4:32 am

So, I took a shot at hacking this together myself, but I got lost in ANTLR... :(

No matter what I do in ABE.g and ABELexer.js:mT_SITE(), I can't get this.dfa10.predict (at ABELexer.js line 928) to recognise 'Request'. It returns code 18 and tries to interpret it as an HTTP verb.

Am I missing something obvious?
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0

User avatar
Giorgio Maone
Site Admin
Posts: 8735
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: Making sure I understand...

Post by Giorgio Maone » Thu Jun 26, 2014 8:41 am

Thrawn wrote:So, I took a shot at hacking this together myself, but I got lost in ANTLR... :(

You should never manually touch the auto-generated ABEParser.js and ABELexer.js files (I just minify them in a batch).
As far as I can tell (no time at this moment to double check), all you've got to do is changing line 27 of ABE.g into

Code: Select all

T_SITE    : ('Site' | 'Request');

and then use ANTLR to re-generate ABEParser.js and ABELexer.js.
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0

User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Making sure I understand...

Post by Thrawn » Thu Jun 26, 2014 9:54 am

Giorgio Maone wrote:and then use ANTLR to re-generate ABEParser.js and ABELexer.js.

Thanks for that.

Unfortunately I can't seem to make ANTLR work. I've tried 2.7.7 and 3.2; version 2 gives

Code: Select all

ANTLR Parser Generator   Version 2.7.7 (20130428)   1989-2005
chrome/content/noscript/ABE.g:1:1: unexpected token: grammar
error: Token stream error reading grammar(s):
chrome/content/noscript/ABE.g:23:25: expecting ''', found 'E'
chrome/content/noscript/ABE.g:1:1: rule grammar trapped:
chrome/content/noscript/ABE.g:1:1: unexpected token: grammar
TokenStreamException: unexpected char: '-'

and version 3 gives:

Code: Select all

error(10):  internal error: group JavaScript does not satisfy interface ANTLRCore: mismatched arguments on these templates [treeParser(grammar, name, scopes, tokens, tokenNames, globalAction, rules, numRules, bitsets, labelType, ASTLabelType, superClass, members, filterMode)] 

error(10):  internal error: group JavaScript does not satisfy interface ANTLRCore: mismatched arguments on these templates [treeParser(grammar, name, scopes, tokens, tokenNames, globalAction, rules, numRules, bitsets, labelType, ASTLabelType, superClass, members, filterMode)]


This is ANTLR installed via apt-get. Am I doing something wrong?
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0

User avatar
Giorgio Maone
Site Admin
Posts: 8735
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: Making sure I understand...

Post by Giorgio Maone » Thu Jun 26, 2014 10:48 am

I'm using 3.1.1 with the following command line:

Code: Select all

java -cp ..\code\antlr-3.1.1.jar org.antlr.Tool -fo output ABE.g


("output" is my output directory)

This grammar generates fine (beside an ignorable "Internal Error" message because of a JDK 8 incompatibility):

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' | 'Request') ;
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;} ;
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0

User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Making sure I understand...

Post by Thrawn » Fri Jun 27, 2014 3:54 am

Yep, 3.1.1 worked fine and I successfully tested it :). Nothing higher than that does, though. (By the way, the brackets around the T_SITE tokens are optional)

What do you think about this change?
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0

Post Reply