Making sure I understand...

Post a reply


In an effort to prevent automatic submissions, we require that you complete the following challenge.
Smilies
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :arrow: :| :mrgreen: :geek: :ugeek:

BBCode is ON
[img] is ON
[flash] is OFF
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: Making sure I understand...

Re: Making sure I understand...

by Thrawn » Sun Nov 15, 2015 10:12 pm

I don't know Antlr well enough to say for certain, either, but it's probably feasible if Giorgio wants to go that way.

Re: Making sure I understand...

by barbaz » Sun Nov 15, 2015 1:53 pm

I'm concerned not only about potential feasibility (I don't know antlr), but also about the possibility that some users thinking the space-separated "to" may be another Site.

Re: Making sure I understand...

by Phil » Sun Nov 15, 2015 3:05 am

Sure, that still works. That variant had occurred to me, but I ended up suggesting the space-separated "Request to" format because I felt that it enhanced the clarity even further. I would be very happy to see either version implemented, though; and if it's not easy to enable "Req" to be an alias for "Request to", then I certainly understand your preference for a single word approach.

Re: Making sure I understand...

by barbaz » Sat Nov 14, 2015 6:43 pm

@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:

Re: Making sure I understand...

by Phil » Sat Nov 14, 2015 1:54 am

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 [i]on behalf of[i] 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...

by Phil » Sat Nov 14, 2015 1:38 am

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...

by Phil » Sat Nov 14, 2015 1:29 am

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...

by Thrawn » Tue Nov 10, 2015 1:31 am

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...

by Thrawn » Thu Jul 03, 2014 10:32 pm

Hmm. Syntax like that sounds (to me) very prone to the original problem of people reading it backwards...

Re: Making sure I understand...

by forecehh » Thu Jul 03, 2014 10:44 am

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...

by barbaz » Tue Jul 01, 2014 3:51 am

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...

by Thrawn » Mon Jun 30, 2014 12:51 am

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...

by Thrawn » Sat Jun 28, 2014 10:43 am

'Dest' 'ination'? sounds good to me :).

Re: Making sure I understand...

by barbaz » Fri Jun 27, 2014 4:35 pm

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...

by Giorgio Maone » Fri Jun 27, 2014 4:17 pm

What about Destination (as opposite to "Origin" which is already a web security accepted term, and specifically related to the "From" clause)?

Top