Consider avoiding the use of the word "private"

[martinthomson]

I know that local network address space is often referred to as "private" addresses (even in RFC 1918 itself), but this might be misleading. These networks are not private, they just use a locally defined address space. This does not confer any sort of privacy.

Also, this specification provide privacy for network access.

I suggest maybe "local" would be more appropriate, in line with the use in RFC 4291 in "link-local" and "site-local". Though this is probably not entirely correct in that these address spaces are not always local, their address layout is locally defined. "Local" is also an antonym for "global", which is what these addresses are not.

[annevk]

If we change private to local, which makes some sense to me as at least I tend to refer to it as the local network, we need a new term for what is currently local as well.

loopback seems reasonable for that.

That would give us loopback, local, and public.

[mikewest]

Ah, names.

"local" is probably fine, and consistent with messaging in places like iOS ("find and connect to devices on your local network"). The "loopback", "local", "public" categorization sounds fine to me.

That said, it would leave us with (at least?) three "local" concepts in Fetch: local scheme, the local cache state, and this new notion of a "local network". Maybe that's fine? The scheme definition seems like it could be confusing.

[annevk]

I think it works as long as we don't have fetch schemes that do local network thingies. Hopefully those continue to be HTTP(S) schemes.

[letitz]

Local network is fine with me, whatever makes things easier to understand. It's true that PNA could be parsed as private (network access) instead of (private network) access. The english language is not associative...

As for the new name for "local", "loopback" sounds pretty fine.

Now... We could avoid this altogether if we scrap the distinction between "loopback" and "local", and call it all "local".

While conceptually there is a difference in privilege between the two that made the distinction appealing to me, in practice I am much less worried about users getting pwned by websites served from the local network. What's more, we've run into a rather large snag when trying to apply the secure context restriction to (local -> loopback) fetches. Websites served from the local network often have a very difficult time upgrading to HTTPS. Many are accessed without DNS, at e.g. http://192.168.13.37, which makes an upgrade even more difficult than obtaining and deploying certificates already can be.

As a result, Chrome does not apply the secure context restriction to (local -> loopback) fetches. Maybe this is the time to acknowledge that in the spec?

[annevk]

I think we need loopback as a standalone concept if only for https://w3c.github.io/webappsec-secure-contexts/ and the specifications building on that, including this one.

I could see sometimes having to group it with local, perhaps, but that's probably best discussed in a separate issue?

[annevk]

(By the way, I'm not particularly arguing for changing the name of the specification again at this point. If it all ends up being upstreamed eventually that might not be worth the repeated confusion.)

[letitz]

I think we need loopback as a standalone concept if only for https://w3c.github.io/webappsec-secure-contexts/ and the specifications building on that, including this one.

Fair enough, we can keep the definition.

I could see sometimes having to group it with local, perhaps, but that's probably best discussed in a separate issue?

Right, filed #96.

(By the way, I'm not particularly arguing for changing the name of the specification again at this point. If it all ends up being upstreamed eventually that might not be worth the repeated confusion.)

Happy to reword things in the spec text itself, to avoid using the word "private".

I would prefer not the rename the whole spec if we can avoid it, as we have a fair number of references to it scattered across the web now, and we already renamed it once. Even though that was much earlier in the project's lifetime, it was already confusing enough.

That said, if @martinthomson feels like the spec name itself is a blocking issue, then we can do it.

[martinthomson]

Do you mean the repository name or the title? Either way...

¯\(°_o)/¯

[letitz]

Both, as it seems confusing to change one but not the other.

In any case, having discussed this with others, I recognize that a specification entitled Private Network Access that never mentions "private network" would be confusing too.

Let's go for Local Network Access, and talk about local networks in the spec text.

[letitz]

cc @yoavweiss who renamed the repo last time.

[yoavweiss]

Renamed! Please verify everything is in working order..

[letitz]

Thanks! Everything looks fine to me! Now to rename the words inside the repo...

[letitz]

@johnathan79717 is interested in writing his first spec PR, will tackle renaming things.

[letitz]

In the course of writing his PR, @johnathan79717 realized that renaming everything would include renaming the CORS headers: Access-Control-Allow-Private-Network and Access-Control-Request-Private-Network.

Before we realized this, we believed that even though renaming was a tedious affair with a fairly large amount of work involved, the victims were circumscribed to our team in Chrome. We were willing to bear the cost for a better outcome and cross-browser agreement.

Unfortunately, renaming the headers would require a web deprecation. We have already started sending the new headers to servers in warning-only mode for a few milestones in Chrome, and have been badgering developers to support them. Telling them "Actually, you know that work you just did to support our change? Could you do it again?" in the name of spec purity goes squarely against the priority of constituencies.

This is too bad, as I think we all agree Local Network Access would be a better name, and it would be best not to muddy the waters around the word "private". That said, we believe that we should reverse the decision to rename and instead keep the old name. In the future, we would welcome this kind of constructive feedback earlier in the process, when changes are not so hard to make.

[annevk]

1. We can still have good terminology internally even if the web-exposed terminology is bad. E.g., XMLHttpRequest.
2. Chromium deciding to ship a WICG specification shouldn't really make it impossible to change things when they are actually getting standardized. That would be rather bad. We're not here to ratify whatever you happened to ship, but rather jointly work on what we think is best for the web platform over the long term.

[letitz]

1. We can still have good terminology internally even if the web-exposed terminology is bad. E.g., XMLHttpRequest.

This is true. We could rename everything but the headers. That would make it confusing to developers, however, so I'd rather avoid that.

2. Chromium deciding to ship a WICG specification shouldn't really make it impossible to change things when they are actually getting standardized. That would be rather bad. We're not here to ratify whatever you happened to ship, but rather jointly work on what we think is best for the web platform over the long term.

While that's a fair point in general, it has been over a year and a half since this spec's name was set to Private Network Access. There was ample time to jointly work on choosing the perfect name, including by speaking up during the public Blink intent process where the headers were shipped.

[annevk]

I'm sorry, but neither blink-dev nor WICG is a suitable substitute for the standardization process.

I'm personally — not wishing to speak for others here — quite flexible on the header names as I understand the dilemma, but I will forcefully object to this line of reasoning.

[mikewest]

Hey @annevk!

I don't think either experimentation in Blink or WICG drafts substitute for the standardization process. They're instead an integral part of it, ideally leading to more collaboration and shared understanding of a problem space. This particular case is one in which I've been pretty happy with the way we've been working together over the last few years here on this WICG draft, with the TAG (w3ctag/design-reviews#572), various conversations in WebAppSec, standards positions requests (mozilla/standards-positions#143 and webkit-dev), and outreach to developers in various forums. I think we're doing standardization, together, and I hope that continues!

Part of that work, of course, is experimentation and testing in the real world. Chrome has taken an incremental approach, with a couple of stabs at shipping preflights starting in Nov 2021 and eventually sticking the landing in Chrome 104 (August 2022). That took a good deal of conversation with folks about the headers they should expect and the headers they should return. We're still not enforcing them, but entities like SAP and Salesforce have done some work to support this rollout and I think it would be unfortunate to start over again and wait for them to both accept a new spelling and deploy it to various customer sites. I think this creates some reliance interests in the current header naming, which doesn't seem unreasonable to me to respect.

Names are hard. We changed the spec to "Private Network Access" after some discussion with clever folks in Feb 2021, and though we might not have landed on the perfect name, I don't think it's a bad name, nor do I think it's substantially misleading (especially given the RFC's description of the IP ranges we rely upon as "private").

If you feel strongly about referring to these networks as "local" in the specification, I can live with that. At the same time, I agree with Titouan that it would be somewhat confusing for developers to have a concept with one name in one place and another in another. The delta between "local" and "private" doesn't seem broad enough to me to justify that discrepancy, but if it seems broad enough to you, then I'm sure we can work something out.

Thanks!

[othermaciej]

To people who aren't familiar with the IETF terminology for IP address ranges, or do not find it the most salient, it's likely they'd think "Private Network" referred to a VPN or similar technology, rather than to what's colloquially known as the private network. Or in general may suggest some form of privacy protection is involved.

I also agree with Anne that it's inappropriate to suggests standards conversations should be held in a Blink development forum (like the Blink intent process on blink-dev) rather than in a standards or incubation forum (like this repo).

As far as the transition cost of renaming the headers for Chrome, which has shipped these since August 2022: do we have any usage data that would tell us how widespread the reliance is on the current header names? If it's very high, then it may indeed be too late to change. If it's zero or close, then renaming shouldn't be a big deal; the mere fact of having shipped without significant usage doesn't create much of a reliance interest. If it's in between, then supporting both header names for a transition period may be viable. Having this data, if it exists, would help evaluate whether changing the header names is a reasonable option.

Finally, I want to mention that all of the major browser engines have previously renamed or removed features that they were the first to ship, as the standards process progressed. While having shipped is certainly a relevant factor, it hasn't been and can't be a trump card, especially at the incubation stage.

[mikewest]

Hey @othermaciej, thanks for weighing in. I'd like to separate this conversation into two parts: standardization on the one hand, and "local" vs "private" on the other.

Regarding the former, I think we can agree that Blink's launch process is tangential to standardization. I hope we can also agree that this particular specification is an example of productive outreach, good discussion, and general agreement on direction. If there's disagreement on that, I'd honestly love to chat, because it would mean that my internal understanding of collaboration is substantially off. To be clear, I agree with you that blink-dev@ is not a great place for standards discussions, and I think that Titouan et al. have reached out well beyond blink-dev@ for feedback on every aspect of this proposal, pretty consistently over a period of years. This includes being quite responsive to a renaming request almost two years ago that resulted in the current nomenclature.

Regarding the latter: first, I continue to view the distinction between "private network" and "local network" as fairly trivial, but I grant that "local" is marginally less likely to cause confusion in the main. My renaming concerns are practical, not aesthetic. Second, the renaming costs for Chrome are trivial, summed up as s/-Private-Network/-Local-Network/ and then sending a few emails to folks we've been talking to about this for quite some time. The costs to the ecosystem are somewhat less trivial, not because the change is difficult, but because it's change, and change is unfortunately impractical. We're asking developers to take time away from features they'd like to build to revisit their support for our collective desire to raise a new security boundary. It's not unreasonable to see that as friction, as much as we'd like to assume universal acclaim for the protection we'd like to provide.

That said, I think it's reasonable for you to ask for metrics. I'm not sure if we have what you're asking for, but (modulo enterprise environments' reluctance to share telemetry data with Google, which has caused some hiccups in the past) @letitz probably knows whether we track what percentage of preflight requests are currently satisfied by a response, which seems like a proxy for the reliance interests discussed above.

Finally, I really hope that a discussion over names doesn't result in disagreement over principles. The core of the specification we're discussing is, I think, a reasonable direction for us to be moving in together. I hope we remain in agreement on that!

[cwilso]

As one of Chrome's Web standards tech leads, let me underscore Mike's comment: Blink's launch process, and blink-dev as a communication venue, is not considered part of the standardization process. Blink's launch process DOES require simultaneously working in the open standards process, and specifically open standards incubation venues such as WICG; and this spec was been openly incubated in WICG for quite some time before Chrome shipped it. The only reason Blink's launch process (and blink-dev) bear mentioning here is that it provides ongoing indication of how baked we think an incubation is, to the point we are willing to ship it. We are working toward improving these indicators as well, and making sure they're clearly represented in the standards incubation venues too.

As stated above, I don't think it's impossible to change names once they are shipped; there are plenty of examples where that has happened across browsers. If this is "we would support this moving into a WG now, and moving toward REC and implementing in other engines, but this name is unacceptable", then I expect we would work to figure out how to make this happen. If this is an academic point, I'm not sure that there is value in renaming at this point.

[jub0bs]

@letitz

It's true that PNA could be parsed as private (network access) instead of (private network) access. The english language is not associative...

Hyphenation (or lack thereof) lifts the ambiguity: "local-network access".

[jub0bs]

As the author and maintainer of a (very new, still in beta) CORS middleware library, I'm a bit worried by this rename. I want and do support Private Network Access, but if my users know it as Local Network Access, I may have to

• either change the name of the relevant option (which, for established libraries, would trigger the need for a new major version),
• or at least provide some alias for it under the new name (and, as a result, the conceptual surface area of my library's API wouldn't be as small as it can ideally be).

I also suspect that the discrepancy between the name of the spec ("local") and the names of the relevant request and response headers ("private") is likely to cause more confusion than elucidation. CORS itself is already the cause of much misunderstanding by developers; it would be a pity to add to that confusion.

I myself am utterly confused by the rename of this repo despite no rename of the spec itself...

[letitz]

Thanks for chiming in with a web developer's point of view, @jub0bs! I think this illustrates @mikewest's point about reliance interests well.

I myself am utterly confused by the rename of this repo despite no rename of the spec itself...

Yes, sorry about that! We stopped midway through the rename, and the current situation is not tenable. We're working on fixing the discrepancy ASAP.

[jub0bs]

We're working on fixing the discrepancy ASAP.

Any timeline for this? I plan to release the first minor version of my library over the next few days, and it would be nice for its API to use the term ("private" or "local") you settle on.

[letitz]

I was hoping to hear from @annevk and @othermaciej before proceeding. Folks, do you believe we should still go ahead with the renaming?

[annevk]

Colleagues and I would prefer "Local Network Access". I was personally hoping @martinthomson would weigh in (again).

[letitz]

Preliminary data from said UseCounter in Chrome beta seems to confirm that a non-trivial number of pages rely on the header naming. I'm still waiting to see data from stable to confirm.

In the meantime, I am curious to hear other browser vendors' opinions on this bit specifically:

We also think it would be a bad idea to have the specification name its terms differently from the header names, since the original concern is developer confusion, but that issue isn't as critical as keeping the existing developer-visible header names. If it helps the specification go through the standards process to use names that differ from the header names, that would be acceptable.

I'm rather keen to end this whole saga and either finish renaming everything in Chromium, or undo our changes.

[letitz]

Re-opening to track un-renaming the headers, at least.

[letitz]

Headers are back to -Private-Network. I think it makes most sense to go all the way and rename the spec back to PNA. What do others think?

[jub0bs]

@letitz Will there still be a transition period during which -Local-Network headers are supported? If so, is such a transition period really warranted?

[letitz]

Good question! There will be no transition period, because no browser ever shipped support for the -Local-Network headers.

[jub0bs]

@letitz Thanks for clarifying. That's good news for maintainers of CORS middleware libraries.

[danielcompton]

I'm coming to this issue as part of working on nginxinc/nginx-s3-gateway#180 and wasn't quite sure where this issue landed. Is the following summary correct?

• Webkit supports this standard, but may use Access-Control-Allow-Local-Network instead of Access-Control-Allow-Private-Network when they come to implement it: Local Network Access WebKit/standards-positions#163
• Mozilla supports this standard but hasn't started working on it. It is unclear which header name they will use: 1481298
• Chrome has shipped with Access-Control-Allow-Private-Network but is open to also including Access-Control-Allow-Local-Network if another browser ships with it.
• Anyone who is implementing support for this header today only needs to handle Access-Control-Allow-Private-Network, but should consider that they may also need to support a second header Access-Control-Allow-Local-Network in the future.

[annevk]

I think that's correct, modulo calling it a standard.