Feature Request: block all 3rd party requests to untrusted

[al_9x]

Giorgio,

I asked about this on the old forum but I don't think you responded, what do you think? If a domain is untrusted there is no reason to give them anything or get and parse anything from them. A harsher setting could even block all 3rd party requests that haven't been white listed. I would try that mode, but for untrusted there is no question.

IE8 made some steps towards 3rd party blocking (inprivate filtering), noscript already (I think) has the infrastructure to do it better.

[Giorgio Maone]

Put in my TODO list, thanks for the suggestion.
Actually the only thing missing in document, image and stylesheet blocking, because plugin and frame blocking is automatically applied to untrusted sites independently from the other settings.

[therube]

So would something like this only apply to sites specifically "untrusted" or would it apply to any site not Allowed (i.e., default deny).

If the former, then that may present the case for a "blacklist", but then you are creating, maintaining such a list, which then ends up being a never ending process. (Unless there were a specific, relatively small set of sites you wish to block in that method.)

[Giorgio Maone]

So would something like this only apply to sites specifically "untrusted" or would it apply to any site not Allowed (i.e., default deny).

Only untrusted, obviously. We're talking about blocking the whole document, doing it by default defeats NoScript's purpose.

[al_9x]

So would something like this only apply to sites specifically "untrusted" or would it apply to any site not Allowed (i.e., default deny).

Only untrusted, obviously. We're talking about blocking the whole document, doing it by default defeats NoScript's purpose.

What do you mean by "blocking the whole document?" The whole document would not be blocked if you block 3rd party requests to non white listed domains. It would break many sites that rely on 3rd party content for basic operation, but that can be resolved by white listing. So it obviously shouldn't be the default, but it would be a useful optional enhanced privacy and security feature. When turned on, it would by default (without having to compose and maintain a blacklist), prevent informing 3rd parties about your browsing and prevent the parsing/rendering of 3rd party content, minimizing the attack surface area.

[Giorgio Maone]

@al9_x
Maybe I did not understand your proposal.

Are we talking about blocking

1. any request (including top document requests) toward untrusted (i.e. marked as untrusted, i.e. blacklisted) sites?
2. any subrequest toward untrusted (i.e. marked as untrusted, i.e. blacklisted) sites?
3. any subrequest toward unknown (i.e. non-whitelisted, forbidden by default) sites?
4. something else?

[al_9x]

@al9_x
Maybe I did not understand your proposal.

Are we talking about blocking

1. any request (including top document requests) toward untrusted (i.e. marked as untrusted, i.e. blacklisted) sites?
2. any subrequest toward untrusted (i.e. marked as untrusted, i.e. blacklisted) sites?
3. any subrequest toward unknown (i.e. non-whitelisted, forbidden by default) sites?
4. something else?

I guess I should define the terms for clarity. Any user initiated root (top document) request is "1st party root". Any resulting auto-generated sub-request to the same (optionally 2nd level) domain is "1st party sub". Any resulting auto-generated sub-request to a different (optionally 2nd level) domain is 3rd party. 3rd party implies sub-request.

1st party root requests can be further differentiated, we could call it "explicit 1st party root" when the user knows the destination (urlbar, bookmark, plain link) and "implicit 1st party root" when the destination is obscured by html/css/js

1. explicit 1st party roots to untrusted (and resulting 1st party subs) should not be blocked. implicit 1st party roots to untrusted, maybe, optionally, if they can be differentiated from explicit.
2. yes, this is what I called 3rd party to untrusted, but I suppose because of 2nd level domain matching you can also have a "1st party sub" to an untrusted sub-domain. This case is a no-brainer and should probably be the default.
3. not any, only 3rd party, my previous post was about this case. There is no point in blocking "1st party subs" to non white listed, and if you did, every non white listed site would be broken

[GµårÐïåñ]

Maybe I am misunderstanding this but isn't this function already built into NoScript? Surely it is

[al_9x]

Maybe I am misunderstanding this but isn't this function already built into NoScript? Surely it is

If you are referring to the blocking of ALL 3rd party requests to untrusted or optionally unknown (non white-listed) domains, then no.

[GµårÐïåñ]

I guess I am having trouble understanding it because NS by default blocks all sites until you whitelist it at which time it will allow anything associated with it (although you can continue to apply restrictions to trusted sites too) but anything marked untrusted is permanently/fully blocked and all links to it (again based on the restrictions established by the user). The only thing it doesn't do is block content such as pictures which can easily be supplemented using RequestPolicy or Adblock Plus.

The only thing that I wish was available and we could do is the ability to create mini or specific policies for each site that can mix allow/untrusted contents on a per site basis rather than globally allow or untrusted requiring temporary blocking/allowing. A feature that I believe is in the works already and in the meantime I am able to achieve using NS+RP+AP very effectively, although requires a bit more work.