What's the Difference Between the Green and Red Lock Icons?

[Skeezix]

I just searched the NoScript FAQ for the phrase "green" and only found one entry, and that didn't help me, so...

When looking at my trusted sites, some have a green Locked icon and others have a red Unlocked icon. When can I turn on the green icon? I guess I don't really understand the ramifications of the green and red icons, so where can I look for an explanation?

[Pansa]

The mouseover for the green lock says "Match Https content only".
Sadly the red lock doesn't say "matches http and https", partly because it wouldn't be fully true.

For general rules (rules that start with ...page ) green means https , and red means both. (hence if you make a green locked rule for ...google.com it only matches httpS://*google.com, if you make a red locked one it also matches http://*google.com)

For specific rules (those that already start with https or http), red means http, green means https (thus the lock being redundant with the URL written in the rule, thus a rule for http://www.google.com has a red lock, and one for https://www.google.com a green one)

[barbaz]

where can I look for an explanation?

Taking this question literally, the answer is https://forums.informaction.com/viewtop ... =7&t=23974

[lancelot]

The mouseover for the green lock says "Match Https content only".
Sadly the red lock doesn't say "matches http and https", partly because it wouldn't be fully true.

For general rules (rules that start with ...page ) green means https , and red means both. (hence if you make a green locked rule for ...google.com it only matches httpS://*google.com, if you make a red locked one it also matches http://*google.com)

For specific rules (those that already start with https or http), red means http, green means https (thus the lock being redundant with the URL written in the rule, thus a rule for http://www.google.com has a red lock, and one for https://www.google.com a green one)

Strange. The red lock meaning "Both" is I think reasonable. With old NoScript there were cases like Steam working over http but the authorization page requiring https, and that became a bit of a mess (temporarily allowing https and then revoking the permission blew away the permanent rule for http). Now it's not an issue.

But what is the justification for the rule being different for full addresses (as in, the red lock meaning http://www.google.com but not https://www.google.com)?

[barbaz]

But what is the justification for the rule being different for full addresses (as in, the red lock meaning http://www.google.com but not https://www.google.com)?

It should only be that way if your whitelist rule is for "http://www.google.com" instead of "...google.com"

[lancelot]

But what is the justification for the rule being different for full addresses (as in, the red lock meaning http://www.google.com but not https://www.google.com)?

It should only be that way if your whitelist rule is for "http://www.google.com" instead of "...google.com"

I understand that, that's what I'm asking: why red "...google.com" means http and https, but red "http://www.google.com" means http only?

Is it only because "http://www.google.com" explicitly says "http://"? I guess I don't see how it can be useful. http+https is useful, like in the situation with Steam. But when is "http only" useful?

[barbaz]

Is it only because "http://www.google.com" explicitly says "http://"?

Bingo.

I guess I don't see how it can be useful. http+https is useful, like in the situation with Steam. But when is "http only" useful?

Did you not just give an example of how http-only can be useful?

It sounds like you want Steam's http site always Allowed, but you don't want their https Allowed except for one specific function. So you could permanently whitelist the http version, and only Temporarily allow the https version when you need it.

Am I misunderstanding you?

[lancelot]

Well, that was just an example of how the old NoScript didn't always cleanly distinguish between the two.

In practice I don't see why I would want to block https if I'm allowing http. For Steam I just allow the red dot-dot-dot 2nd level domains, and that's it. If it wants to transfer something over https as well, it can be my guest, everything just works.

If I went with fully specified http:// and https:// addresses, I would have to allow two separate things, like you describe. It's more fine-grained, but I'm still not convinced that this distinction is needed for fully specified addresses but not for dot-dot-dot rules.

[Pansa]

Well, that was just an example of how the old NoScript didn't always cleanly distinguish between the two.

In practice I don't see why I would want to block https if I'm allowing http. For Steam I just allow the red dot-dot-dot 2nd level domains, and that's it. If it wants to transfer something over https as well, it can be my guest, everything just works.

If I went with fully specified http:// and https:// addresses, I would have to allow two separate things, like you describe. It's more fine-grained, but I'm still not convinced that this distinction is needed for fully specified addresses but not for dot-dot-dot rules.

Well technically if you really wanted to, you could achieve the same for the ...page rules, too.
If you put the greenlock on an untrusted rule, it will ask you again if the same domain delivers http content, too.
In the end when you specify the SPECIFIC url, it would create a bit of an issue visualizing it properly, and you never know, someone may find the one domain where he really wants to have the http scripts but not the https scripts.
Sure, generally one might think that they serve the same scripts just either over http or https, but what when the content each delivers are different.

So in the end, when you make general rules it asks you "https or both", and when you are making really specific rules, it makes them really specific, at the cost of maybe having to have more than one.

[lancelot]

Well technically if you really wanted to, you could achieve the same for the ...page rules, too.
If you put the greenlock on an untrusted rule, it will ask you again if the same domain delivers http content, too.

Do you mean making black ...page.com untrusted and making red ...page.com trusted to allow http but not https? That would be cool (in a bizarre way), but it doesn't seem to work: untrusted black ...page.com entry doesn't have any lock icon and if I add a temporary trusted red ...page.com, I can access the content coming from https. So apparently trusted red ...page.com overrides untrusted black ...page.com, and the result is still http+https.

[Pansa]

Well technically if you really wanted to, you could achieve the same for the ...page rules, too.
If you put the greenlock on an untrusted rule, it will ask you again if the same domain delivers http content, too.

Do you mean making black ...page.com untrusted and making red ...page.com trusted to allow http but not https? That would be cool (in a bizarre way), but it doesn't seem to work: untrusted black ...page.com entry doesn't have any lock icon and if I add a temporary trusted red ...page.com, I can access the content coming from https. So apparently trusted red ...page.com overrides untrusted black ...page.com, and the result is still http+https.

Yeah you are right, I did it from memory completely forgetting that there is no lock to choose from to begin with
But you can still make fullpath rules for http if you made a black untrusted rule. (black and red text corresponds to greenlock /redlock respectively anyway)

[lancelot]

But you can still make fullpath rules for http if you made a black untrusted rule. (black and red text corresponds to greenlock /redlock respectively anyway)

I don't follow. If I make a (trusted) fullpath http rule, it'll allow content coming over http but not over https for that page. How can a black untrusted rule make a difference here? I think it's the same case of the untrusted rule just being overridden, not of one rule "minus" the other.

[Pansa]

But you can still make fullpath rules for http if you made a black untrusted rule. (black and red text corresponds to greenlock /redlock respectively anyway)

I don't follow. If I make a (trusted) fullpath http rule, it'll allow content coming over http but not over https for that page.

Yes, which was the point.
The black https untrusted rule only makes a difference in so far as default and untrusted not having the exact same restrictions in terms of factory settings. (they do for me, but that's because I don't really run a black list at all).

Be that as it may:
I think we have pretty much cleared up what the locks are, and with the fact in mind that "https" doesn't mean "completely secure and thus wanted" and http not "calamity waiting to happen" (the difference being interception and alteration by third parties, rather than just "content" being wanted in the first place), you can be pretty specific with what you want from some of the big JS providers, provided they are nice enough to properly create subdomains for the different things.

[Skeezix]

@Barbaz

Thank you for sending me the link. I took a look at it and Jeez!! That's a lot of info that will take my feeble mind a few days to digest and comprehend. Thanks again!