hackademix
Changing the working principle of "Temporarily set top-level sites to TRUSTED"
Now, in my opinion, temp trusted works quite strangely. Let's consider as an example the site lifehacker.ru, which has quite a lot of third-party scripts.
By default, the noscript settings were changed to set temporary permissions for the top-level domain.
In the list of domains we see at least mail.ru and yandex.ru Let's try to open them in neighboring tabs.
Mail.ru also has a dependency on yandex.ru. Yandex.ru redirects us to dzen.ru.
As we can see in these images, domains are set to temporarily trusted in accordance with the settings. If we return to the first site, we see that by visiting these sites, we have opened access to these sites for it.
In my opinion, it's not safe. And not rational. Moreover, temporary permits not only work on all sites at once without restrictions, they also work until the browser is closed or all temporary permissions are manually revoked.
What is proposed to do
There are several proposals for changing the work of temporary permits.
- Temporary trust should be valid only on the site (page) where they were issued. That is, if I have issued temporary permits on one site, they should not apply to other sites.
- If the option to issue temporary trust to a top-level site is enabled, these permissions will only work on the sites of the specified top domain, the permission should not apply to other domains on which scripts from the specified domain are placed.
- Temporary permissions must be cancelled when the tab is closed.
Thus, the temporary trust that will be issued will affect only the site on which we operate and will not affect the work of other sites or contributions. This will allow you to correctly test the changes without affecting neighbouring tabs. Or view the site without affecting the work of other sites. Temporary permits should be issued very limited and, after verification, should be transferred to the category of permanent ones.
If this change contradicts the main idea of the extension, I suggest changing the behaviour of only the "temporary trust for top-level domains" settings. This is where it has the main impact.
I suggest changing the behaviour of only the "temporary trust for top-level domains" settings.
This may be a bit of a 'sticky' issue since having to track what's going on in every tab could add a massive overhead, especially to the significant minority of weirdos like me who often have hundreds of tabs open (with or without a tab management addon) - and that may simply be impractical for the scope of NoScript.
I understand completely your concern though, and perhaps one way to implement this without a major performance hit, would be a low-priority check of all open tabs when a tab/window is closed, to identify if the top domain for any open tab matches the 'temporarily trusted' domains of the just-closed tab. If it does, maintain the temporary trust; if none match then discard the temp trust for that domain in this session. This seems like a practical improvement that should be only a small amount of development work, both to implement and to debug later with regards to the dozen or so top tab-management addons. 👍️
That wouldn't resolve the other main issue you raised though, which is temporary trust of a top-level domain in one tab, being 'used' by that same site as a secondary domain in another tab. Particularly for things like Facebook and Google, I would love to be able to limit their 'permissions' to only when I'm on THEIR domains, and block it everywhere else, to minimise profiling and tracking.
It's concerning that you haven't received any response to this in 3 months. 😕️
My understanding is that the problem reported by the OP is a real one, but one that it's specific to the "Temporarily set top-level sites to TRUSTED" feature.
Indeed you can already use Contextual Policies in order to restrict permissions (either temporary or permanent) to a specific top level domain, and "Remove restrictions for this tab" as a quick temporary "fix" which operates on the current tab only and goes away as soon as it's closed.
Therefore I'm inclined to implement the last suggestion,
changing the behaviour of only the "temporary trust for top-level domains" settings
by re-implementing it as an automatic contextual policy restricting the permissions to the subresources matching the top domain itself.
I checked version 12.5.903.
I checked the same site lifehacker.ru. The behavior remains the same.
Opening the site and checking permissions:
Opening it yandex.ru, which redirects us to dzen.ru:
We update the first tab and see that yandex.ru missing from the list:
We can see that permissions are issued for all sites, and they will remain valid until the browser is closed or time restrictions are removed:
Contextual Policies is an interesting option, but it requires a lot of settings for each individual site. It is not suitable for permanent work with each random site.
We can see that permissions are issued for all sites, and they will remain valid until the browser is closed or time restrictions are removed:
Yes, but the issued permissions are not blanked TRUSTED: they're CUSTOM contextual policies matching the same permissions of the TRUSTED preset, but working only if the top document is the same: i.e. yandex.ru will work only if you're on the yandex.ru page.
What's the difference with "of the option to issue temporary trust to a top-level site is enabled, these permissions will only work on the sites of the specified top domain, the permission should not apply to other domains on which scripts from the specified domain are placed"?
Oh, I'm sorry, didn't pay attention at the moment. Yes, that's much better.
But one more point, why do we need to remember these temporary settings at all?
I open a tab, if I have the issue temporary permissions for a top-level site option enabled, let these permissions be applied for this tab. You don't need to save these permissions in the settings.
If I close the tab, I don't need these permissions anymore. If I open a new tab with the same page, the temporary permissions that are set in the extension settings will be applied again.
This way there will be less potential for error and with the current changes it will be safer.
One more thing, I decided to check what Custom permissions are issued for top-level domains:
It turned out that they apply to all domains, not just this one. Thus, it has little effect on security.
If I close the tab, I don't need these permissions anymore. If I open a new tab with the same page, the temporary permissions that are set in the extension settings will be applied again.
Oh, now I understand what you mean. Again it makes sense, in the context of "Temporarily set top-level sites to TRUSTED", thanks.
It turned out that they apply to all domains, not just this one. Thus, it has little effect on security.
What do you mean here exactly? These are the DEFAULT permissions (those which are applied to any site which is not known/listed) and indeed have no security implications. In other words, no special permissions are automatically granted to the top level domain, unless in a top level document or a subresource of a tab where the top level document is same origin.
What do you mean here exactly? These are the DEFAULT permissions (those which are applied to any site which is not known/listed) and indeed have no security implications. In other words, no special permissions are automatically granted to the top level domain, unless in a top level document or a subresource of a tab where the top level document is same origin.
If these are the default values, why create a new configuration item separately for this domain?
If these are the default values, why create a new configuration item separately for this domain?
Because otherwise you wouldn't have an entry point to manage the permissions when the top document is "any site" vs a specific site, if you wish to change anything (e.g. allow unrestricted CSS or fonts).
It's a bit strange, but since I don't understand extension development, I can't say anything. At the very least, what has been done is already much better than it was before. Thanks!
Ahh, so this is why that behavior changed in the add-on.
I appreciate what it's trying to do, but I think it has a little further to go.
Since it's using CUSTOM to create a temporary TRUSTED, site-specific restriction, there a few new issues.
- The option text is now confusing.
- The per-site temporary option now uses DEFAULT settings, which defeats the purpose of the temporary TRUSTED option. (Interestingly, when looking at the permissions from the browser button tool, it shows the default "TRUSTED" permissions applied. However, checking permissions in the add-on settings shows the "DEFAULT" settings applied. So... which is it? I assume it's DEFAULT, because my pages load bare-bones at first. So, why is the UI misreporting?)
- Seems like there's other issues which are already reported in #441.
My suggestions:
- Add a tooltip or explanation next to the "Temporarily set top-level sites to TRUSTED" option that explains it will create a "CUSTOM" entry using <some pre-defined set of options, such as whatever is currently set in "TRUSTED" or "DEFAULT">.
- Add a fourth configuration (giving us DEFAULT, TRUSTED, UNTRUSTED, "TEMP TOP TRUST"), and this TEMPTOPTRUST permission will have its own settings. Out-of-box installation of plugin can default to the same permissions as TRUSTED, but can be adjusted as user desires which affects any new TEMPTOPTRUST permissions granted. This permits flexible adjustment. If the "applied" permission is still "CUSTOM", then at least it becomes more clear what's happening. (However, ideally this would become it's own category?!)
- Regardless, it needs for the CUSTOM entry to at least mimc TRUSTED instead. It's frustrating when the page loads like it's blocked and requires more clicks from me.
(Names and even behaviors can be workshopped, but I wanted to offer this as a starting point.)
Thank you for your time! I hope this is the correct place to add to the conversation, and I hope you find these thoughts helpful.
