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

[tfpauly]

Having worked a lot on system-wide local network access policy and restrictions, and how to expose them in API and to users, using “local” is going to be far clearer in the long run than using “private”. If this is something that’s intended to be standardized, we should have the care to get the naming right now. I certainly sympathize with the hassle of changing things in the midst of early deployments, but I’d urge us to continue with the rename.

[martinthomson]

I tend to agree with @annevk and @tfpauly. Though a name change might cost some people, those who are affected knew the risks of early adoption. A clearer name will help with future adoption.

[letitz]

Thanks for your replies, folks. Let's go ahead with renaming the spec and the terms within. #97 can be re-opened and merged.

The header will also be renamed in the spec. Chrome will support both headers for some time (send both, accept either), with a goal to deprecate the old one eventually.

those who are affected knew the risks of early adoption

I think this applies to new features, not to deprecations. This rename punishes the folks who put in the work to avoid being broken by a change in the platform and help us to improve the security of the platform as a whole. Unfortunately, this rename rewards the kind of inaction that makes deprecations difficult.

[jub0bs]

@letitz I'm glad that a consensus emerged. You mention that

Chrome will support both headers for some time (send both, accept either), with a goal to deprecate the old one eventually.

Is there a Chromium issue associated to these planned changes? If there is, I cannot find it.

[letitz]

I just filed https://crbug.com/1418287 to track all the renaming work. The header change will likely be its own issue, but more than that it will have a chromestatus entry and go through the Blink intent process.

[annevk]

Thanks @letitz and @johnathan79717, much appreciated!

[azanatta]

Just to be clear, for almost 1 year you prepare the general public to a fairly big change in the headers that must be present server side in order for a specific request to work, then weeks before the feature gets shipped, you take it off the roadmap and start renaming it, including the headers because "those who are affected knew the risks of early adoption. A clearer name will help with future adoption"?

The early adoption wasn't for fun, we had to adapt to the security changes Chrome is implementing if we want Internet to work as we know it, so OF COURSE we have to early adopt this, which means having big players to be informed, waiting for patches, repacking and distributing affected software, FORCING customers to upgrade theirs.

I am starting to worry about the way Chrome is handling big changes like this one, multiple times we had to communicate Customers about an imminent change which required upgrades, which never occurred and got postponed. Then when the shipping date seems to be fixed, it gets taken off the roadmap (113) just a few weeks before. Then someone starts discussing about renaming the WHOLE thing, and it even get approved: specs are updated but the actual feature is not at this point, since it's not even anymore in the roadmap.

You understand that this is getting totally confusing and this goes against the enforcement of well needed security features like this one. As a Customer, after repeated false alarms, I would simply adopt the easiest solution which allows a safe continuation of my work, which is the deactivation of the security feature.

I hope you all will reconsider the renaming, since this would generate so much headaches and loss of trust towards the Chromium project.

I have of course filed a bug about this, which nobody has yet checked: https://bugs.chromium.org/p/chromium/issues/detail?id=1424387#c1

[tfpauly]

This is about defining standards across the web, not just Chromium. As explained in comments earlier on this issue, if an implementation chooses to implement a feature before it is standardized, it is always subject to change. The right outcome is to not roll back these changes, but to ensure that in future cases, the consequence of early adoption is made clear.

[letitz]

Hi @azanatta, and apologies for the confusion. I strongly regret how this has played out for web developers.

Chromium (see above) actually proposed that due to situations like yours, the best course of action would be to not rename anything - the existing name being "good enough". Other browsers recently pushed back hard against the PNA name, arguing as @tfpauly does that Chromium shipped too early, leading to the current situation.

I do want to stress that the work you have done is not in vain. Chromium is still planning to ship this specification, even if not next month in 113. We will support both the old and new header names for the foreseeable future. Deprecating web APIs takes a while, as we cannot break the web willy nilly, hence the recent setback. Note that other browsers have indicated that they are willing to ship this too, though there are no timelines yet.

[azanatta]

Thank you @letitz for your message,

@tfpauly I'm fighting for standards since we had to deal with internet explorer in the early years, I get what you are saying. When Chromium announces a breaking changes and defines a deadline in the roadmap, we (developers) have to adapt our code and systems to make sure that everything will keep working after the deadline is met, I hope you understand this. What you call "early adopters" are the ones that put a lot of work to prevent that from one day to an other large systems stop working for an announced breaking change in the most used browser in the world. Pointing fingers to the early adopters of an officially announced breaking change, therefore, from my point of view, is totally wrong.

@letitz my only concern here is, as you and other people already stated, Chromium decided to announce these breaking changes a long time ago setting deadlines that kept changing over and over, finally being withdrawn until further notice due to a feature renaming. I really hope this will serve as the example of how changes like these should be widely discussed including end-users, before they get to the roadmap.

[jub0bs]

I'm only the author of a lowly CORS library, but I'd like to weigh in again and, this time, in favour of this rename.

Terminology matters. Choosing the wrong terms may induce misunderstanding, which may in turn have security ramifications. For example, I don't think that the (now very technical) term site, as used in the context of the SameSite cookie attribute, was particularly judicious; but that ship has sailed. If the W3C folks believe that "local" is less ambiguous than "private", I'm more than willing to go to the effort of amending my library's implementation accordingly.

Besides, it's not like this rename induces an immediate breaking change. @letitz has announced plans for a transition period during which both variations of the relevant headers will be supported. This is just one data point, but for my library, the effort required to accommodate this change is little more than one copy & paste.

The only downside I perceive, as a library author, manifests itself if the term "private" is being used in the public API of the library. In that case, the relevant functions/methods might need to get renamed (if only for consistency), and that would require a breaking change.

[jyasskin]

TL;DR: We (the Chrome security team and web standards team) have changed our minds about renaming these headers.

We've started collecting data on how much adoption the existing header names have, and while we don't have full answers yet, the early indications are that there's more adoption than we'd want to break. @letitz and his team worked directly with about a dozen developers to help them migrate to this system, and we also see ~500 uses + ~50 issues about one of the header names on Github. @letitz has added a UseCounter, for which we expect to see non-trivial usage. Given that we don't want to discourage developers from adopting security improvements, we believe that it's in users' and developers' best interest to keep the existing header names, Access-Control-Allow-Private-Network and Access-Control-Request-Private-Network, and we have decided to do so in our implementation. We'll undo https://github.com/WICG/local-network-access/pull/97 to match that reality.

We recognize that this might delay progress through the standards process, but it's important to note that the current names aren't a result of Chrome designing something in isolation. @letitz' team has been designing this feature in public discussions in the WebAppSec WG over the course of 7 years. We asked Mozilla and Webkit for opinions ~2 years ago. @annevk even picked the current name 2 years ago, although that wasn't on WebKit's behalf.

Despite all that, if another browser ships this feature with the ...-Local-... names, then in order to improve interoperability, we'll add support for those names in addition to the ...-Private-... names. We'd be looking for others to do the outreach to convince developers to change their code and explain why it was worth asking them to go through this extra pain, and we'd expect to deprecate and remove whichever names have less adoption after a reasonable amount of time.

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.

We apologize to the developers who've been impacted by all the churn. We’ll try to avoid it in the future.

[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 https://github.com/nginxinc/nginx-s3-gateway/issues/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: https://github.com/WebKit/standards-positions/issues/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.