InformAction Forums

In NoScript Classic, clicking a media placeholder tempoarily allows that specific media.

In NoScript 10, it creates a permanent CUSTOM permission for that specific media.

Making placeholder-generated permissions temporary by default is more logical, as this type of allowing is often a one-off (e.g. to watch a specific video once on some video hosting site). And in the rare event I would want the permission to be permanent, it's easy to make it so in NoScript 10 - just go NoScript Options > Per-site Permissions, find the placeholder-generated entry and click the clock.

So could the permissions created through clicking placeholders please be temporary?

(I'm still not quite sure how this NoScript 10 is supposed to work, what to expect, but) +1 on the Temp Allow.

I think the default should be the safer choice for the user, which in my opinion is to temporary allow it. Alternatively, the user may want to choose analogously to the XSS dialog.

musonius wrote: ↑Mon Jun 24, 2019 8:38 pm Alternatively, the user may want to choose analogously to the XSS dialog.

Why is that "alternatively"? Making the default selection "Temporarily allow this specific media" doesn't require axing the permanent-allow radio buttons.

barbaz wrote: ↑Mon Jun 24, 2019 11:53 pm Why is that "alternatively"?

I'd prefer to simply change the permanent permission to a temporary one. I just wanted to say, that, if it is reasonable that users want a permanent permission nevertheless, it may be a good solution to ask the user similar to the XSS dialog, which lets the user choose between permanently blocking and blocking it just once.

If a Media Item is Blocked, & you Allow the Media Item (itself), It gets Allowed (set to Allowed on the Per Site Permissions List).
Wouldn't it make more sense to Temporarily Allow the item rather then outright Allow it?
(I guess I should say the "allowed" media item gets [permanently] set up as Custom [rather then Allowed, per se, but it amounts to, basically, the same thing].)

With Media in particular, often the item is served with a time limited pseudo-random URL, so even if Allowed, if you revisit the same item in the future, your stored Allowed URL is likely not going to be valid any longer in any case.


(Hmm. I guess you might say, how to do you Temporarily Allow the media item (considering you're actually Custom-ing it rather than Allowing it, & Custom becomes "permanent" rather then temporary. Well, you set it up as a TC, Temporary Custom. And if a user wants to make it "permanent", i.e., Custom, they go to Per Site Permissions, right-click [heh] the item, 'Set as Custom'.)?


(Maybe, if you allow the media item itself, full URL.mp3 or whatever it is, that gets Temporary Custom status.
Where if you allow media.site.com, that gets [full] Custom status.)

(Heh. Yeah, that too .)

Threads merged.

Bump.

I had forgotten about this. The current behavior is really unexpected and counter-intuitive. It didn't occur to me that the permissions created through the dialog would be permanent, and it took way too long to figure out why "Revoke temporary permissions" wasn't working!

Giorgio could you please implement this RFE? Thanks!

barbaz wrote: ↑Sat Aug 08, 2020 6:03 pm The current behavior is really unexpected and counter-intuitive.

Coming at it from another perspective, which is how I use the media placeholders, each placeholder is indeed a unique
one-time permission to download the media. It stands mostly orthogonal to the site permissions and is a particularly valuable part of the current NS 10 Webextensions development for me who battles against the pile of unwanted scripting that's overlaid on so many web pages now. Once you play the media you've played your risk out, so withdrawing the permission doesn't seem to me to be ensuring any reduction of risk. I didn't find permanent placeholders unexpected in the context of the NS10 Webextensions development.

As the NS placeholder routine stands, it gives the NS customer the option to either:

ONE: download the media inside the page context - ie 'click' for a lasting permission (useful for those who like to run everything inside the browser) that the user can return to even if they've navigated away in between first and subsequent visits to that particular page - including the situation where they may want to revoke temporary permissions for domains (certainly the safest way to keep temp permissions from mounting up in busy sessions) but save wasting decision time for media that they've already made the decision about.
I've included a trivial case which introduces a bug if a customer revokes custom media permissions - just to show how involved the media placeholder can be, and to show that Giorgio's solution is elegant and clean - where the media needs 2 consecutive placeholder permssions, and any preemptive revoking of those 2 unique permissions within a session can mangle the permissions sequence enough to turn the exercise into a waste of click time.
https://thenewdaily.com.au/news/good-ne ... ek-13-nov/
I allowed both placeholders consecutively, played the video in the web page - without granting any other permissions.
Then I removed the custom permissions from the NS per-site list and returned to play that cute rubbish again in the same session - moz didn't like that messing with its mime list.

OR

TWO: download the media for local playing, without granting any temp permission for it to be handled within the web page.
I prefer the second option because it generally doesn't need any consecutive permissions to be granted on that web page at all. Smooth and safest - and often avoids all the tricks and mess that webmasters like to put in the way of anyone wanting to simply play a bit of music or a news clip. In the exampe above, 'save as' dialog doesn't need the 2 consecutive placeholders.

This is a request for this standalone custom 'save as' permission to be preserved if it conflicts with any change to 'temporary' for media placeholder permissions.
And a smaller request for the unique permission to be preserved across sessions - as is the case now - for those who revisit particular media in their normal browser use.
As far as I can see, making placeholder unique ID temporary may turn out to be full o' bugs, while the media placeholders as they stand are robust across sessions with possibly the only problem being that the customer may need to clean up their 'custom' permissions from time to time to keep the list short enough.

Is it possible to add "Temp. Allow" for blocked objects (MEDIA, IFRAME)?
http://ipic.su/img/img7/fs/temp_media.1649789459.png
 
@barbaz
Sorry, I wrote in the wrong thread.

fatboy wrote: ↑Tue Apr 12, 2022 6:53 pm Is it possible to add "Temp. Allow" for blocked objects (MEDIA, IFRAME)?
http://ipic.su/img/img7/fs/temp_media.1649789459.png

This was initially posted in a completely unrelated thread. Moved to the existing thread requesting this.