Skip to content

Feature detection #21

Closed
Closed

Description

@phistuck

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.

Activity

  1. letitz commented on Oct 20, 2020

    @letitz
    Collaborator

    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.

  2. letitz commented on Nov 16, 2020

    @letitz
    Collaborator

    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.

  3. letitz commented on Feb 23, 2021

    @letitz
    Collaborator

    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.

  4. jonathanKingston commented on Mar 4, 2021

    @jonathanKingston
    Member

    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?

  5. annevk commented on Mar 4, 2021

    @annevk

    It is, but not having a property as suggested seems even better.

  6. jonathanKingston commented on Mar 4, 2021

    @jonathanKingston
    Member

    It is, but not having a property as suggested seems even better.

    Better? Surely consistency with window.crossOriginIsolated is worthwhile?

    Perhaps there is rationale I'm not understanding though :)

  7. annevk commented on Mar 4, 2021

    @annevk

    As in, my understanding of #21 (comment) is that the plan is to remove this entirely.

  8. letitz commented on Mar 4, 2021

    @letitz
    Collaborator

    Anne's right. I want to remove this from the spec.

  9. letitz commented on May 5, 2021

    @letitz
    Collaborator

    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.

  10. fred-wang commented on May 17, 2021

    @fred-wang
    Contributor

    @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.

  11. fred-wang commented on May 17, 2021

    @fred-wang
    Contributor
  12. letitz commented on May 25, 2021

    @letitz
    Collaborator

    Thanks @fred-wang for catching those omissions. Re-opening to track fixing those references.

  13. reopened this on May 25, 2021
  14. added a commit that references this issue on May 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions