I will also note that the most recent version did include the suggested update from Fisher:
>> - `should -> SHOULD` in: "If a matching rule contains more than one >> identifier the client SHOULD treat the list as an ordered list." https://github.com/tfpauly/privacy-proxy/pull/326 Thanks! Tommy > On Jan 30, 2026, at 11:53 AM, Yaroslav Rosomakho > <[email protected]> wrote: > > Hello Fisher, > > Thank you for your suggestions! > > From a purely structural point of view, representing transport security via > the URI scheme could work, and that a single connect protocol combined with a > URI template is a viable design. > However, the current document intentionally keeps a distinction between > http-connect and https-connect for several reasons: > Avoiding ambiguity in protocol interpretation. Allowing arbitrary schemes > alongside a generic connect protocol introduces additional ambiguity (e.g., > non-"http"/"https" scheme paired with "connect" protocol). By encoding the > transport expectations directly in the protocol identifier, the configuration > is more self-describing and easier to validate. > Operational and migration considerations. We expect many existing > environments to migrate from PAC-based configurations, where cleartext > CONNECT and TLS-wrapped CONNECT are treated as distinct proxy protocols. > Keeping separate protocol identifiers makes this transition more direct and > reduces the risk of misconfiguration during migration. > Deployment reality and client support. TLS-wrapped CONNECT is not as widely > supported as cleartext CONNECT. Differentiating them at the protocol > definition level allows clients to make an explicit capability decision > without erroneously ignoring a scheme they don't support, attempting a > connection and failing. > > When it comes to order of proxies, the current design is intentional and aims > to separate proxy identity from proxy preference. When multiple proxy > dictionaries share the same identifier, the intent is that they represent > equivalent instances of the same logical proxy service. In that case, > allowing (and expecting) clients to choose among them (using local policy, > randomness, or other heuristics) enables natural load distribution without > requiring the PvD to be dynamically generated or re-ordered per client. > If a deployment requires strict, deterministic ordering (for example, > primary/backup behaviour), the expectation is that those proxies be > represented with distinct identifiers and that ordering be expressed > explicitly in the rules that reference them. > This also enables flexibility to provide a different proxy order for > different proxy-match rules. > Mandating that clients always select the first matching proxy with a given > identifier would reduce flexibility for clients, constrain implementation > choices, and make it harder to support simple load-balancing use cases > without additional server-side complexity (such as dynamically shuffling > proxy lists or issuing client-specific PvDs). > > Hope this helps. > > > Best Regards, > Yaroslav > > On Wed, Jan 7, 2026 at 4:43 PM Fisher Darling > <[email protected] > <mailto:[email protected]>> wrote: >> Hi all! >> >> Apologies for such a late email, but I wanted to chime in with some thoughts >> on the draft. For some context, my team runs various privacy preserving >> proxies, including a second-hop proxy in iCloud Private Relay (a "Proxy B"), >> various single hop CONNECT proxies and finally some Oblivious HTTP relays >> (and gateways). >> >> Overall the draft is great! It nicely defines and condenses some similar >> structures we have in our own control-plane. I can see this being very >> useful for our own tooling and for automatic configuration for our customers. >> >> I have two minor suggestions: >> >> 1. First, consider removing the distinction between `http-connect` and >> `https-connect` and combine the two into one protocol, `connect`. For >> `http-connect` and `https-connect`, transport security is encoded in the >> protocol identifier, whereas for the `connect-*` family of protocols, it's >> encoded in the URI scheme. To me, the capability to provide TLS is a >> question of the transport and not proxying protocol and adding a scheme is >> sufficient to signal that. I suggest using a single protocol `connect` with >> a `URI template` Proxy Location Format. Then with a note specifying that >> only the scheme and host should be present. >> >> For example: >> >> A TLS enabled connect proxy uses `https://`: >> ``` >> { "protocol": "connect", "proxy": "https://proxy.example.org >> <https://proxy.example.org/>" } >> ``` >> And one without TLS would use `http://`: >> ``` >> { "protocol": "connect", "proxy": "http://proxy.example.org >> <http://proxy.example.org/>" } >> ``` >> >> 2. Second, when multiple proxy dictionaries are present, I believe the >> client SHOULD use the first proxy presented to it which satisfies the >> client's requirements and then only move to the next satisfying proxy in the >> event of failure. It is very useful to have a deterministic, >> server-controlled method of determining what actions a client takes. If >> clients always choose the first satisfactory proxy, it's much easier to >> safely deploy breaking changes. >> >> More concretely, I suggest these edits: >> - `should -> SHOULD` in: "If a matching rule contains more than one >> identifier the client SHOULD treat the list as an ordered list." >> - "Multiple proxy dictionaries can contain the same identifier value. In >> this case, the client SHOULD choose the first proxy." >> >> Take for example a blue-green deployment of a proxy. `proxy-blue.example.org >> <http://proxy-blue.example.org/>` and `proxy-green.example.org >> <http://proxy-green.example.org/>` run two different versions of proxying >> code. Both proxies share the same identifier `privacy-proxy`. >> >> The PvD would look something like this: >> ``` >> { >> // other PvD fields omitted >> "proxies": [ >> { >> "identifier": "privacy-proxy", >> "protocol": "https-connect", >> "proxy": "proxy-blue.example.org:443 >> <http://proxy-blue.example.org:443/>" >> }, >> { >> "identifier": "privacy-proxy", >> "protocol": "https-connect", >> "proxy": "proxy-green.example.org:443 >> <http://proxy-green.example.org:443/>" >> }, >> ] >> } >> ``` >> >> With deterministic client selection, we (the proxy provider) can know based >> on this config that all clients should be using `proxy-blue` as their >> primary proxy and only use `proxy-green` as a backup. To deploy, we can drop >> the expiration time and begin sending PvDs with the `proxy-green` proxy as >> the first one in the list. Then we slowly increase the percentage of >> responses which have `proxy-green` be the first in the list while watching >> health metrics. This way once 100% of PvD configs have `proxy-green` as the >> first in the list, we can be fairly confident all of our clients prefer >> `proxy-green` over `proxy-blue`. >> >> This is definitely a contrived example. Moving the traffic using >> DNS/anycast/etc. is usually easier. However, the point is that breaking >> changes in version-less configuration can be difficult to rollout across all >> clients. Knowing that clients will use a certain configuration in a specific >> order makes any breaking or risky changes easier to rollout, especially >> around changes in proprietary keys. >> >> I'm happy to write some GitHub issues or PR if the language changes if >> that's helpful for further review :) >> >> In any case, thanks for reading my email and thank you all for the efforts >> on this draft! >> >> All the best and happy New Year's, >> - Fisher >> _______________________________________________ >> Int-area mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> > > > This communication (including any attachments) is intended for the sole use > of the intended recipient and may contain confidential, non-public, and/or > privileged material. Use, distribution, or reproduction of this communication > by unintended recipients is not authorized. If you received this > communication in error, please immediately notify the sender and then delete > all copies of this communication from your > system._______________________________________________ > Int-area mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
