an_addon_user wrote:FlashBlock defeatable? In what regard? If true, this would seem to further the case to implement this RFE so users can drop FlashBlock...
Very easily so and with NS, FlashBlock is neither necessary nor any more particularly effective as when they were told how easily their addon can be defeated they outright expressed, they don't care to fix it as
their tool is not a privacy tool and therefore does not need to account for every variation.
Again as stated, NS ALREADY blocks Flash on both trusted, untrusted (aka either/or AND permanent) which also allows you to temporarily allow something to use and then on another incarnation you still have to allow again, it won't retain the permission. So I am not sure why you think what you are saying in an RFE when in fact its already a feature and has been for ages. I told you how to use it, so you either didn't try or don't get it. Let me know which so I tailor the answer better.
Are you using a patched version of NoScript ... or perhaps did you misunderstand the RFE?
No, this is a function that has been at NoScript's core for a LONG time and I didn't misunderstand what you are improperly referring to as an RFE, its describing a feature already there. If you wish to know how to actually use it, let us know and we'll walk you through it, but otherwise, its there. Read this and if you still feel you are contributing something new, we'll talk:
http://noscript.net/features#contentblocking
Even with all embeddings blocked AND blocking on trusted sites as well, NoScript does not
ALWAYS block the embed. Yes, it will block the embed by default, but it will cease to block the embed if you have allowed the blocked embed previously (eg clicked the placeholder to get the original content to load). Then embed remains
ALLOWED (not blocked on page load) until the end of the session or until you clear temporary permissions. See the NoScript features page (link in OP), which states (emphasis added):
NoScript Features wrote:The [embed] will stay enabled until the end of the session or until you Revoke Temporary Permissions.
Try it:
- Load a page with a embed, eg a flash video
- See NoScript block the embed (expected behavior)
- Hit reload
- See the embed loads and is not re-blocked by NoScript (not desired, hence this RFE)
Yes I am aware of the post you are referring to but my experience has always been that when restrictions are applied to both trusted/untrusted sites, when temp allowing a resource by clicking on its placeholder, temporarily allows THAT particular embed and not ALL embeds for that domain by default. The one you allowed to temporarily run, YES, will remain allowed until you say to undo it, that's a logical behavior. YOU chose to temp allow it because you must have wanted to, so when you are done wanting to, then undo it or wait until it expires per session. That doesn't and shouldn't need an RFE to account for behavioral process of a user within the confines of predetermined and expected program behavior and function. NS is doing what is supposed to do and been instructed to do. Additionally, if you have the box checked that says ALWAYS ask me before temp allowing a blocked embed, then it will prompt you for permission EACH time. All the features combined are comprehensive enough that this so called RFE should not be necessary and is frankly contraindicated.
IIRC, this can also occur (perhaps in limited circumstances) if NoScript blocks a flash, you allow it, then you browse to another page (perhaps it must be on the same domain), and that new page includes the same flash from the old page. Regardless, this RFE is for an option to *ALWAYS* block and re-block embeds, even if manually allowed previously.
Note that it is the continued blocking after allowing an embed (eg clicking on the placeholder), that is requested by this RFE.
Given the options under Embeddings to block various types, applying them to trusted as well, checking to block every object from untrusted, and ask for confirmation before temp allowing has always yielded the most desired response to what you are asking. I have never personally seen a condition where having these settings you would have something wildly allow itself on the same domain or not simply because you temp allowed something. Additionally, you temp allow it, you can unallow it, you are expecting the program to somehow mind read when you are done doing whatever you temp allowed and block it again for you. How do you suggest it does that? On reload of the page, that happens when you temp allow, so that would by your logic reblock it, because you expect anything temp allowed to permanently revert back to blocked. Second reload? Closing the tab? Already sufficient implementation to allow for that. Your "RFE" makes no sense but you know what I am not the one writing the code and if Giorgio feels this is something he wants to add or can find a useful means to add it or has a practical place, so be it, his call to make. So I have put in my two cents, I will defer any further decision on your "RFE" to Giorgio.
If he hasn't read or responded on his own, I will point him via PM to take a look and post a response.