RFE: Re-UNTRUST TEMP CUSTOM on Reload or browser closure:

Bug reports and enhancement requests
Post Reply
Bounder
Posts: 19
Joined: Thu Nov 23, 2017 7:11 am

RFE: Re-UNTRUST TEMP CUSTOM on Reload or browser closure:

Post by Bounder »

It would be very nice to have the ability to apply a "Temporary CUSTOM" setting to an "UNTRUSTED" address, and then have it reliably return to "UNTRUSTED" every time the site is no longer required in the course of a browsing session (e.g; via "Revoke Temporary Permissions") or, every time automatically at the end of a session.

Currently, this has to be done manually - it is just way too easy to forget to manually re-blacklist an address.

I think that my feature request would take some more "rough edges" off a very granular system - enhancing it's useability somewhat.

Closing comment: NS 10 is advancing very nicely thank you very much Giorgio.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
barbaz
Senior Member
Posts: 10847
Joined: Sat Aug 03, 2013 5:45 pm

Re: RFE: Re-UNTRUST TEMP CUSTOM on Reload or browser closure

Post by barbaz »

(There is some relevant discussion in https://forums.informaction.com/viewtop ... =7&t=24430)
*Always* check the changelogs BEFORE updating that important software!
-
Bounder
Posts: 19
Joined: Thu Nov 23, 2017 7:11 am

Re: RFE: Re-UNTRUST TEMP CUSTOM on Reload or browser closure

Post by Bounder »

Cheers for thar barbaz, I have perused since your "heads up" :D
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Bounder
Posts: 19
Joined: Thu Nov 23, 2017 7:11 am

Re: RFE: Re-UNTRUST TEMP CUSTOM on Reload or browser closure

Post by Bounder »

I still think that the ability to do this is worthwhile:
  • It is all about context:
There are many sites/domains/addresses which I prefer to blacklist and have remain as such. Unfortunately there are some 1st party sites who currently require elements from 3rd party domains in a similar "class" to Google Analytics in order to function usefully - especially so for example, in the "Great Southern Land".

Most of the other sites that I may visit will function very well without their suggested elements from the same 3rd party domains - hence the blacklist.

Eventually, although too often after hell freezes over in the "Great Southern Land", some of the sites will change there ways (and heck, may even configure https properly too) and no longer require the afforemention 3rd party domain classes inorder to serve up something useful. In reality, forgetting my earlier geographic sarcastic remarks, this can happen at any time - websites are often in a state of flux after all.

Even though I have now configured "DEFAULT" to allow none of the presets; on the odd occasion where I feel the need to temporarily customise some normally blacklisted presets, it is nice to know that they will remain blacklisted once finished with, and hopefully the next time, the 1st party site administrators will have done the polite thing so that the 3rd party site can remain blacklisted until it ceases to exist.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
barbaz
Senior Member
Posts: 10847
Joined: Sat Aug 03, 2013 5:45 pm

Re: RFE: Re-UNTRUST TEMP CUSTOM on Reload or browser closure

Post by barbaz »

Bounder wrote:
  • It is all about context:
There are many sites/domains/addresses which I prefer to blacklist and have remain as such. Unfortunately there are some 1st party sites who currently require elements from 3rd party domains in a similar "class" to Google Analytics in order to function usefully - especially so for example, in the "Great Southern Land".
And for the reasons noted in the other thread, if you consider these domains Untrusted, you really shouldn't be allowing them outside a sandbox.
*Always* check the changelogs BEFORE updating that important software!
-
Bounder
Posts: 19
Joined: Thu Nov 23, 2017 7:11 am

Re: RFE: Re-UNTRUST TEMP CUSTOM on Reload or browser closure

Post by Bounder »

I agree about sandboxing - it would seem that such should apply to every application which accesses a network anything these days.

Nevertheless, I still believe that my request is well worthwhile ... even if it is not implemented. If there is a major change in my circumstances, then I'll consider submitting a patch myself.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Post Reply