I am not sure why the feature detection section exists.
Do you envision websites not showing links that would be blocked by this feature (due to non-cooperating local/private websites)?
If you still think it is needed, then I think it should be a boolean or something similar - isLocalMixedContentProtectionSupported (the name is not important).
I feel like this local/private/public distinction, is a privacy breach. While it does not tell the client side the exact IP of the website it is currently running in, it does distinguish itself between the local network/Intranet, private network and the Internet, which could be made useful for (attacks? spoofs? or) blocking features for, say, users that cloned public pages into their private/local networks.
Will a HOSTS-specified www.google.com that resolves to 10.0.12.12 return "private"?
Will "private" have CORS-rfc1918-free access to other "private" hosts?
This is not something I would want to expose to the client. I feel like it is none of its business.
I am not sure why the feature detection section exists.
Do you envision websites not showing links that would be blocked by this feature (due to non-cooperating local/private websites)?
If you still think it is needed, then I think it should be a boolean or something similar -
isLocalMixedContentProtectionSupported(the name is not important).I feel like this local/private/public distinction, is a privacy breach. While it does not tell the client side the exact IP of the website it is currently running in, it does distinguish itself between the local network/Intranet, private network and the Internet, which could be made useful for (attacks? spoofs? or) blocking features for, say, users that cloned public pages into their private/local networks.
Will a HOSTS-specified www.google.com that resolves to 10.0.12.12 return "private"?
Will "private" have CORS-rfc1918-free access to other "private" hosts?
This is not something I would want to expose to the client. I feel like it is none of its business.