Consider avoiding the use of the word "private"

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.

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.

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.

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.

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?

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?

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

@martinthomson

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.

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

¯\(°_o)/¯

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.

@yoavweiss

cc @yoavweiss who renamed the repo last time.

Renamed! Please verify everything is in working order..

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

@johnathan79717

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

@johnathan79717

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.

We can still have good terminology internally even if the web-exposed terminology is bad. E.g., XMLHttpRequest.
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.

Revert "[Local Network Access] Rename private to local in web_view_br…

Revert "[Local Network Access] Rename content setting from private to…

Revert "[Local Network Access] Rename private to local in request.cc"

Rename private to local in address space overrides (#135)

Bug 1842883 [wpt PR 40968] - Revert "[Local Network Access] Rename pr…

I'm coming to this issue as part of working on nginx/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.

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

Revert "[Local Network Access] Rename net log event from private to l…

Revert "[Local Network Access] Rename net error from private to local"

Revert "[Local Network Access] Rename content browser clients from pr…

Navigation Menu

Repository navigation

Consider avoiding the use of the word "private" #91

71 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Consider avoiding the use of the word "private" #91

Description

Activity

annevk commented on Jan 10, 2023

mikewest commented on Jan 11, 2023

annevk commented on Jan 11, 2023

letitz commented on Jan 11, 2023

annevk commented on Jan 11, 2023

annevk commented on Jan 11, 2023

letitz commented on Jan 11, 2023

martinthomson commented on Jan 12, 2023

letitz commented on Jan 13, 2023

letitz commented on Jan 13, 2023

yoavweiss commented on Jan 16, 2023

letitz commented on Jan 17, 2023

letitz commented on Jan 18, 2023

letitz commented on Jan 25, 2023

annevk commented on Jan 25, 2023

71 remaining items

danielcompton commented on Oct 15, 2023

annevk commented on Oct 16, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions