Right now networking.onc is a sibset of networkingPrivate, so that would need to be addressed first.

I thought we also did additional permission checking for networking.onc?

At some point (but probably not until Q1 or Q2) I hope to replace the use of networkingPrivate in Chrome UI with a mojo API so it might just make sense to wait for that.

The code in the background would not really have to change (except for a rename).
The main thing would be moving private parts of networking_private.idl to networking_onc.idl, and nodocing it.

(networkingPrivate permission would still need to stay around, though).

But yeah, moving settings to mojo API would enable us to remove parts of networking_private :)

What type of things would we need to move from networkingPrivate to networking.onc?  IIRC, we deliberately kept some of the functionality in networkingPrivate that we didn't want to expose more broadly.  If we successfully migrate callers to networking.onc for the shared state, could we just fork the APIs and then have networkingPrivate and networking.onc with separate functionality?  And then, once settings uses mojo, we can just delete networkingPrivate entirely.

Well, I do not plan to expose any new functionality to the networking.onc API, the private parts of the networking API will still be protected by networkingPrivate permission.

But yeah, once settings switch to mojo, we should be able to get rid of the most of the private parts (i.e. pieces that cannot be used without networkingPrivate permission) of the networking API.

> Well, I do not plan to expose any new functionality to the networking.onc API, the private parts of the networking API will still be protected by networkingPrivate permission.

Ideally, I'd prefer these just stay in a separate API (networkingPrivate).  It makes the distinction clear, prevents us from needing nodocs or having confusing documentation, and makes ripping them out when replaced by mojo easy.  Is there any reason to have them in networking.onc?  Right now, the networking.onc API is aliased, but once we migrate callers to the networking.onc functions we want to expose, we could unalias and fork the APIs.

Yes, I think that given the plans to move settings code to mojo, it would make sense to keep his separate for a little bit more (as the most, if not all, of the diff between the APIs stem from the usage in settings).