View source for Necko: Sandboxing TCP/UDP socket in a separate process

== Objectives ==
Move all the network and socket operations to an isolated process.

== Goals ==
* For security
** Sandboxing network access into a separate process, preventing chrome process from opening socket
** Preventing protocol security hole to be used to control the entire browser
* For stability
** Allow recovering network layer without rebooting firefox, if crash/assertion is detected in the socket process
* For performance
** No major regression found for start-up performance and network throughput

== Requirements ==
=== HTTP Channel ===
* load protocol configuration from Gecko preference
* Alternative Service, uses AlternateServices.txt
* Cookie access need to stay on chrome process
* WebRequest can intercept http request/response
* Download triggered by unknown content type needs to divert back to chrome process
=== FTP Channel ===
=== TCP Socket ===
* permission controlled by chrome process
* prevent system port to be bind
=== UDP Socket ===
* permission controlled by chrome process
* prevent system port to be bind
=== DNS ===
* permission to do system call for DNS query
* thread pool for doing blocking operation in parallel
* allow both chrome process and content process to request DNS query directly to socket process
=== Cache ===
* choice #1: stay in chrome process:
** need a copy of full http response from socket process
** for RCWN, need to delay the construction for ODA IPC endpoint until we know cache win or network win
* choice #2: move to socket process:
**  need access cache data file from socket process
** need to move cache evaluation code from nsHttpChannel to other class on socket process 
=== Proxy ===
* load proxy configuration from Gecko preference
* PAC loading and execution, require JS runtime
* access system proxy setting
* create and connect to name pipe
=== WebSocket ===
=== WebRTC ===
=== PSM ===
* touches the preferences and various txt files in the profile
* Cert store, uses cert*.db and key*.db
* revocation information (i.e. nsICertBlocklist), uses revocations.txt
* certificate error overrides (nsICertOverrideService), uses cert_override.txt.
* HSTS/HPKP information (nsISiteSecurityService, although we've already implemented a way to access this information in non-parent processes), uses SiteSecurityServiceState.txt, SecurityPreloadState.txt
* external PKCS#11 module, require DLL loading from arbitrary file path

=== NSS ===
* uses the cert/key/secmod.db files as well as pkcs11.txt.
* access system file, e.g. /dev/urandom and system policy files under /etc

=== PKI/PKIX ===
doesn't interact with preferences or file directly.

=== Sandboxing ===
* Chrome process is still the only secure zone. Every IPC interface received at Chrome process should be audited
* IPC to content process or socket process should at least do sanity check in the receiver side
* Better not providing interface to create arbitrary TCP/UDP connection

=== DevTool ===
* require TCP/UDP socket
* require JS runtime for devtool protocol

== Design ==
=== Architecture ===
=== IPDL ===
=== Start-up Procedure ===
=== Create HTTP Channel ===
=== Create WebRTC Channel ===
=== Update Preference ===
=== Override Certificate ===
=== NTLM ===

== TODOs ==
* hook ProcessHangMonitor
* hook CrashReporter
* hook MemoryPresure
* hook MemoryReporter
* ensure Telemetry works
* ensure MOZ_LOG works
* remove XPCOM and support only C++ implementation