You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 believe the feature detection section exists at least in part because of https://w3ctag.github.io/design-principles/#feature-detect, though that could be remediated with some kind of boolean indicating that private network requests are subject to enhanced scrutiny. @mikewest for historical insight.
I am not sure how this is a privacy breach and I am curious to explore this further. Web servers already know the IP address and interface over which a client contacted them. Even though that information might not be available at the web platform level, it might be reason enough to consider this no worse? Not sure how that interacts with IP blindness and the like.
To your questions:
Will a HOSTS-specified www.google.com that resolves to 10.0.12.12 return "private"?
Yes.
Will "private" have CORS-rfc1918-free access to other "private" hosts?
Yes. See also #1, which raised the idea of subjecting all cross-origin requests targeting local/private IPs to CORS-RFC1918 checks.
After filling in the TAG's security and privacy self-review questionnaire (here) I am inclined to think this aspect of the spec is not pulling its weight.
I think the ordering here is to leave the IDL in the spec until Blink and WPT stop depending on it, then remove it. In the meantime I can add a banner to the HTML integration section explaining that this part is going away.
Activity
letitz commentedon Oct 20, 2020
I believe the feature detection section exists at least in part because of https://w3ctag.github.io/design-principles/#feature-detect, though that could be remediated with some kind of boolean indicating that private network requests are subject to enhanced scrutiny. @mikewest for historical insight.
I am not sure how this is a privacy breach and I am curious to explore this further. Web servers already know the IP address and interface over which a client contacted them. Even though that information might not be available at the web platform level, it might be reason enough to consider this no worse? Not sure how that interacts with IP blindness and the like.
To your questions:
Yes.
Yes. See also #1, which raised the idea of subjecting all cross-origin requests targeting local/private IPs to CORS-RFC1918 checks.
letitz commentedon Nov 16, 2020
After filling in the TAG's security and privacy self-review questionnaire (here) I am inclined to think this aspect of the spec is not pulling its weight.
letitz commentedon Feb 23, 2021
I think the ordering here is to leave the IDL in the spec until Blink and WPT stop depending on it, then remove it. In the meantime I can add a banner to the HTML integration section explaining that this part is going away.
jonathanKingston commentedon Mar 4, 2021
I'm being lazy here but is it common to have a property hang off Document and WorkerGlobalScope?
Isn't the usual extension point navigator if they're shared; why not WindowOrWorkerGlobalScope?
annevk commentedon Mar 4, 2021
It is, but not having a property as suggested seems even better.
jonathanKingston commentedon Mar 4, 2021
Better? Surely consistency with
window.crossOriginIsolatedis worthwhile?Perhaps there is rationale I'm not understanding though :)
annevk commentedon Mar 4, 2021
As in, my understanding of #21 (comment) is that the plan is to remove this entirely.
letitz commentedon Mar 4, 2021
Anne's right. I want to remove this from the spec.
letitz commentedon May 5, 2021
Blink has its own version of the IDL: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/document.idl;l=182;drc=759e84c17afddffd440315069801e280d7ca1d31
I removed the references to the automatically-extracted IDL from WPTs a while ago. I'll go ahead and delete this section.
fred-wang commentedon May 17, 2021
@letitz This attribute is still mentioned on the explainer: https://github.com/WICG/private-network-access/blob/main/explainer.md#integration-with-html ; maybe that should be updated to with similar "A previous version of this specification proposed adding an addressSpace enum property" text.
fred-wang commentedon May 17, 2021
and here too https://github.com/WICG/private-network-access/blob/main/explainer.md#remove-addressspace-idl
fred-wang commentedon May 17, 2021
and at several places of https://github.com/WICG/private-network-access/blob/main/security_privacy_self_review.md
letitz commentedon May 25, 2021
Thanks @fred-wang for catching those omissions. Re-opening to track fixing those references.
Remove `addressSpace` from explainer.
[Private Network Access] Remove `addressSpace` from IDL.
Revert "[Private Network Access] Remove `addressSpace` from IDL."
Reland "[Private Network Access] Remove `addressSpace` from IDL."