Chrome 142-145 support for local network access features

[chrisdavidmills]

Summary

Between versions 142 and 145, Chrome enables support for various features of the Local Network Access spec. See https://chromestatus.com/feature/5152728072060928 and https://chromestatus.com/feature/5068298146414592.

Specifically, these are:

• The targetAddressSpace Request property, which was previously available behind a flag, and the equivalent RequestInit property. AIUI, the property was finally enabled by default by version 142.
• The local-network-access permission/Permissions-Policy directive, which was added in 142.
• The more granular local-network and loopback-network permissions/Permissions-Policy directives, which were added in 145.

This PR adds/updates data points as appropriate for these features.

Test results and supporting details

Related issues

[github-actions]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[hubertchao]

Summary

Between versions 142 and 145, Chrome enables support for various features of the Local Network Access spec. See https://chromestatus.com/feature/5152728072060928 and https://chromestatus.com/feature/5068298146414592.

Specifically, these are:

• The targetAddressSpace Request property, which was previously available behind a flag, and the equivalent RequestInit property. AIUI, the property was finally enabled by default by version 142.

  • I do wonder whether the loopback property was added later, as the permissions only become granular between local and loopback as of version 145. I'll ask an engineer to comment on this.

loopback property was supported in 142;

• The local-network-access permission/Permissions-Policy directive, which was added in 142.
• The more granular local-network and loopback-network permissions/Permissions-Policy directives, which were added in 145.

Of note: in 145, we only guarantee limited mixing of the local-network-access permission policy directive and the local-network and loopback-network permission policy directive. See https://docs.google.com/document/d/1QQkqehw8umtAgz5z0um7THx-aoU251p705FbIQjDuGs/edit?tab=t.0#heading=h.gfr7vlp7ocj4

Test results and supporting details

Related issues

[chrisdavidmills]

Summary

Between versions 142 and 145, Chrome enables support for various features of the Local Network Access spec. See https://chromestatus.com/feature/5152728072060928 and https://chromestatus.com/feature/5068298146414592.
Specifically, these are:

• The targetAddressSpace Request property, which was previously available behind a flag, and the equivalent RequestInit property. AIUI, the property was finally enabled by default by version 142.

  • I do wonder whether the loopback property was added later, as the permissions only become granular between local and loopback as of version 145. I'll ask an engineer to comment on this.

loopback property was supported in 142;

Thanks! I think we mean "value" rather than "property" (I made this mistake above), but good to know.

I tried adding in previous support data behind a flag, and then a separate data point for 142, detailing that this is both the point where the feature was enabled by default and the point where the loopback value was introduced. But the linter just removes the historic data every time. I wonder if this means we are no longer recording such historic data? Maybe it's good enough like this.

• The local-network-access permission/Permissions-Policy directive, which was added in 142.
• The more granular local-network and loopback-network permissions/Permissions-Policy directives, which were added in 145.

Of note: in 145, we only guarantee limited mixing of the local-network-access permission policy directive and the local-network and loopback-network permission policy directive. See https://docs.google.com/document/d/1QQkqehw8umtAgz5z0um7THx-aoU251p705FbIQjDuGs/edit?tab=t.0#heading=h.gfr7vlp7ocj4

This document is super useful, thanks!

I have improved the notes about the aliasing to be more in line with it. I'm not sure what "only guarantee limited mixing" means, though — this phrase is not mentioned in the document. Can you elaborate?

[hubertchao]

I have improved the notes about the aliasing to be more in line with it. I'm not sure what "only guarantee limited mixing" means, though — this phrase is not mentioned in the document. Can you elaborate?

We don't want people using local-network-access and local-network or loopback-network directives in the same allow attribute for iframes. There's a few reasons for this:

• At some point we do want to remove the local-network-access alias; supporting mixing them would only lead to more usage. (no idea when or if such a removal would ever happen; it'll probably be a long slog)

• Documenting/describing the behaviour of how they combine together is hard to explain and complicated; we decided that it was better to push the combinations as not supported (and force people to use local-network and loopback-network when they want different behaviour between the 2) so that the we didn't have to explain the nuances of what the difference between the following 4 are:

  • allow="local-network-access 'none'; local-network *"
  • allow="local-network-access *; loopback-network 'none'"
  • allow="local-network *; local-network-access 'none'"
  • allow=" loopback-network 'none'; local-network-access *"

(to be clear; I don't think the above 4 examples all do the same thing but I'm not sure, and its not something we're testing or supporting)

The exceptions to the above are for the backwards compatibility cases where they want to make sure the permissions are delegated for all versions of Chrome and also Firefox (who may or may not support the local-network-access alias; I haven't checked). Those are:

• allow="local-network-access; local-network; loopback-network"
• allow="local-network-access *; local-network *; loopback-network *"

which we explicitly test for and guarantee that they work as expected.

(this was also shared in https://crbug.com/487759442#comment2 in case that makes more sense)

[chrisdavidmills]

We don't want people using local-network-access and local-network or loopback-network directives in the same allow attribute for iframes.

@hubertchao OK, makes sense, thanks. I don't think this affects the BCD PR, but it might affect the content PR. Let's revisit this after the content has been reviewed.

[caugner]

If this parameter was behind a flag in 124-137, then we don't capture this:

Suggested change

	},
	{
	"version_added": "124",
	"version_removed": "138"
	}
	}

[caugner]

What does it mean for this permission to be superseeded? Can it still be set and has the same effect as granting both local-network and loopback-network?

[caugner]

Assuming this was only behind a pref:

Suggested change

	},
	{
	"version_added": "124",
	"version_removed": "138"
	}
	}