InformAction Forums

[OFF TOPIC]
OK, let's do it this way from now on:

[RFE], [BUG], [RESOLVED], [FIXED], [UNRELATED] and [REOPENED] are free for any reporter or moderator to set.

[WONTFIX], [MAYBE], [TODO] and [INVALID] are reserved for me and shouldn't be reverted by anyone, not just because the last word on these matters is mine (I'm the one who either has to do the work or accept the patch), but because such "answers" often carry a certain degree of emotional weight on reporters, who might feel thrown away (not the case at hand, but you can see a lot of this stuff on Mozilla's Bugzilla instance), and I prefer to take all the responsibility for such kind of conversations on my own shoulders, for the good or for the bad.

Feel free to pester me by PM if some thread needs my attention for setting/removing these ones.

Thanks everybody for your cooperation
[/OFF TOPIC]

Coming to this very topic, I find the idea interesting and technically feasible (even if it may seem the contrary, NoScript doesn't need to [pre]fetch a page in order to block or allow scripts, as it works directly on the JS interpreter and just checks for the code's origin site).
The gotcha is that it would need to allow the whole site, not just the page which is about to load (but it doesn't seem in contrast with the OP's wish).
Another gotcha is context menu cluttering.
All in all, this can be taken in account as a low-priority TODO for an optional feature to be enabled/disabled from the NoScript Options|Appearance panel ([MAYBE]).

Giorgio Maone wrote:[OFF TOPIC]
OK, let's do it this way from now on:

[RFE], [BUG], [RESOLVED], [FIXED] and [REOPENED] are free for any reporter or moderator to set.

[WONTFIX], [MAYBE], [TODO] and [INVALID] are reserved for me

What about [UNRELATED] -- there is in fact an issue, but clearly (per OP eventual admission) it proves to have nothing to do with NS?

Giorgio Maone wrote:The gotcha is that it would need to allow the whole site, not just the page which is about to load (but it doesn't seem in contrast with the OP's wish).

Regardless of OP's wish, GµårÐïåñ and I, and probably others, had concerns about the safety of such action, realizing that many users won't understand the risks they're taking. Please include that in the deliberations, thanks.

Giorgio Maone wrote:Feel free to pester me by PM if some thread needs my attention for setting/removing these ones.

Well, you *have* been awfully busy lately, what with the relocation, new ISP, NoScript 3.x for the desktop, etc., with many issues on the board still outstanding/unresolved, including a few pestered by PM , so in the interest of trying to lighten the workload.... but it's good to have the policy clarified, thanks.

This request is basically saying "give me the option to go allow scripts globally" on any link without actually loading the site or knowing what's on it. I mean how is that even a useful RFE and make sense? If you KNOW or TRUST the site, then it should be in your whitelist making this feature moot. If you DON'T then why in the world would you want to walk into it without any protection sight unseen, and if they want to do that, fine, go there and allow it globally or temp allow the whole site, but to add it as an outright feature makes no sense and seem quite in contradiction to the premiss of NS.

Anyone care to share their logic on how this even fits remotely within the NoScript's security model? And by anyone I mean Giorgio? With so many better and worthwhile RFE's being rejected for 'adding unnecessary complexity' or being contrary to NS mission, adding the extra work to implement such a fringe and frankly mind boggling RFE without even a discussion as to why is perplexing in the least. Are we suddenly going or partaking in the YesScript philosophy here?

(Since you asked .)

To me, the request makes sense. Believe I've outlined the reasons in my second post.
(And my first post outlines a very good pitfall too.)
Not asking to Allow Globally.
Asking to Allow one particular domain prior to actually loading it.

> If you KNOW or TRUST the site, then it should be in your whitelist

For you perhaps, though I maintain no whitelist (other then the defaults).

I fail to see how this is like YesScript.

I think it is a perfectly valid request.

If it were there, I may or may not end up using it.
If it were not there, so be it, I'm not about to morn its non-existence.

It has been said, "maybe". So neither a yes nor a no.
If something down & dirty were put together, & put out to try, I would.
And with a bit of time, I'd find out if it were of any real value to me.

Are there other features (& fixes) I would like to see instead of this, certainly.

Perfect (real) example again.

I get an email from newegg.
I do not want to allow newegg.
I click the link. Page opens, lists items for sale. (Every day is a "sale".)
I peruse the list, something catches my eyes.

At that point, I'll want to TA newegg.com.
If I had a context-menu, TA+go, newegg.com, in a tab, I would use it.

Done.

(I don't necessarily want to TA the <newegg> page I was on, though I do want to TA the <newegg> link opened from it.)

@therube, with all due respect, and I mean this sincerely regardless of how glib this reply might sound; although I appreciate your input and respect your position, my object has a technical dimension that you neither grasp nor address, so I will await the discussion with Giorgio.

But if you wish to play in the sandbox, feel free to answer how a site with "allow all" still cascades, as been discussed a bazillion times on this site, and yet somehow we are to allow the whole site in question without pre-fetching it to know what it has, or cascade allow all-ing it, or whitlisting it - unless we go allow globally. Can you answer that?

Doubtful, hence my objection and request for clarification of the HOW we plan to do this without messing things up. And if you don't see how that is adopting a YesScript (jump first, then protect approach, discussed extensively in the past on the forum) then again affirms the lack of technical understanding I was looking for in this matter.

On a side note, having a conversation with yourself has been very helpful in bumping your post count though, so cheers on that.

I thought this was just about allowing the domain of the link, not an allow-all on all domains the linked website might reference. So you know the domain which domain you are allowing by looking at the link (of course if the link is just redirecting then there's not much benefit).

/edit: Ok, re-read the first post again, seems like I was wrong. But the way I envisioned it, it might be less problematic IMHO.

dhouwn wrote:I thought this was just about allowing the domain of the link, not an allow-all on all domains the linked website might reference. So you know the domain which domain you are allowing by looking at the link (of course if the link is just redirecting then there's not much benefit).

That's exactly my interpretation and my reason for MAYBEing it. Just a straightforward "Temporarily allow site.com and open link", with no need for looking at the destination page structure, for the sole purpose of saving one reload.

dhouwn wrote:/edit: Ok, re-read the first post again, seems like I was wrong.

On the contrary, it still seem to me we are right:

edindex wrote:When a site is known by the user to be safe prior to clicking a link from email or another site, it would be nice to be able to set permission to "Temporarily Allow" from the context menu to save having to reload every new site.

Where do these words imply a cascading "Temporarily allow all" (which I could only WONTFIX)?
Of course I'm not a native speaker, so I might have misunderstood.
@edindex: could you please clarify?

If we are simply adding a right click option to mimic the "allow when opened from bookmark" behavior, then the infrastructure is already there and pretty straight forward. Although frankly given how many cross site scripting and cdn domains are used today, specially on the bigger sites, short of continuing to temp allow manually or whitelisting, its a fairly useless approach.

But unless you are "temp allowing all" the whole site to get the desired effect you want, then just doing the main domain and saving one reload is a waste of effort as we know MANY sites, simply allowing the primary domain won't do squat for function. So that to me says, they want the site to be functional and not just save a single reload, which means "temp allowing all" behavior which we have over years of discussion concluded cannot be done as we can't predict the content that will be added when some are allowed and require re-allowing, aka, cascading.

See what I mean now? and feel the RFE just doesn't make sense to save a single reload. Specially that if you use the sticky menu, you can allow all you want and then get one reload. So the value saving here is???

Giorgio Maone wrote:

dhouwn wrote:I thought this was just about allowing the domain of the link, not an allow-all on all domains the linked website might reference. So you know the domain which domain you are allowing by looking at the link (of course if the link is just redirecting then there's not much benefit).

That's exactly my interpretation and my reason for MAYBEing it. Just a straightforward "Temporarily allow site.com and open link", with no need for looking at the destination page structure, for the sole purpose of saving one reload.

dhouwn wrote:/edit: Ok, re-read the first post again, seems like I was wrong.

Giorgio Maone wrote:On the contrary, it still seem to me we are right:

edindex wrote:When a site is known by the user to be safe prior to clicking a link from email or another site, it would be nice to be able to set permission to "Temporarily Allow" from the context menu to save having to reload every new site.

Where do these words imply a cascading "Temporarily allow all" (which I could only WONTFIX)?
Of course I'm not a native speaker, so I might have misunderstood.
@edindex: could you please clarify?

The problem, as Guardian and I have been trying to get across -- and perhaps there are language barriers all around -- is that merely allowing SiteX.com does not necessarily make SiteX work. This is the "cascading script" issue. Once you allow or TA SiteX.com, then and only then does it call, say, SiteXcdn.net. Which is necessary to make SiteX work.

There are thousands of examples of sites that only call to a static, CDN, or "img" site once the main site has been allowed. Others may call Akamai.
Others call *required* scripts that do not show in the first menu (home page not yet allowed), but show in the menu when the home site has been allowed.

So the bottom line is: The RFE, for *the home site only*, might be safe and effective for sites that need no further permissions. But:

edindex wrote:When a site is known by the user to be safe prior to clicking a link from email or another site, it would be nice to be able to set permission to "Temporarily Allow" from the context menu to save having to reload every new site.

Best Practice is never to click links in emails. Are you sure that it goes where it says? -- especially with Firefox-New.x shortening or blurring URLs (Whose idea was that, anyway? )
Use "Copy Link Location" from the context menu. You can even paste it in a new tab or window, but examine it before hitting Enter.

You trust your friends? I've had two very trusted friends send me emails containing malicious links, because their machines were infected to send the mal-mail to everyone in their address book. Are you sure that every machine owned by everyone you know is 100%-clean? How do you know?
****************************
If you "know a site to be trustworthy", well, that's why NS has a Whitelist. Put it there, and never be bothered again.

The only saving I can see is in clicking from one site to another whose name you trust but haven't ever visited before, and that's just once. And assumes that the one script is sufficient permission. Once there, whitelist the new site. You'll never bothered again, and much simpler than creating an RFE, more complications for NS, more opportunities for things to go wrong, because someone won't use a whitelist or can't be bothered with a *one-time-only* page reload (before adding to w/l).

But it might be ineffective on the ever-growing number of "cascading script sites". I admit that I don't w/l every site that I visit only once in a great while -- I do like to keep the w/l minimal -- but a number of them require more than one script to TA anyway, so we're back to the cascading issue -- or to page reloads, if the "safe version" of the RFE is implemented. Which renders the RFE moot.

And the only way to make it effective on said growing number of cascading-script sites is to allow the home site and every script it calls once allowed -- which, as Giorgio said, is dangerous, almost equal to "allow globally" and an automatic WONTFIX.

This is the best that I can explain it. I hope it helps.

I've had more than my fair say on this issue, have nothing more to add, and will accept whatever is the final decision.

The problem ... is that merely allowing SiteX.com does not necessarily make SiteX work.

So? I don't think that's the point.
I have already decided (in my mind) I'm going to allow X (& AFAICT from the OP, this only relates to a single site).
Now it just becomes a matter of when.
Either I say allow X & then I go to it, or I go to X then allow it.

There are, could be, efficiencies in doing the former.

And whether X works correctly, fully, or not, again is not material IMO, as that is not the requested feature.

The same way, Allow sites opened through bookmarks, does not ensure that the site will work correctly.
It only does what it says, nothing more.

Note that Recently blocked sites already works in just this manner.
You can Allow a site whilst not actually on that site.