[AGMETEOR]

context

• part of https://github.com/getlantern/engineering/issues/3702
• client half of egress: log every session, with an optional consumer hello unbounded#454 (draft), which adds the hello and a per-session egress log line

summary

• after building the QUIC layer, the unbounded outbound calls SetConsumerHello with:
  • tag: the outbound tag, which for a lantern-cloud config is <type>-out-<track>-<routeID>, so the egress can say which track and route each session served
  • platform: runtime.GOOS
• the hello goes once per QUIC connection on a unidirectional stream inside QUIC, so the donor can't read it and proxied streams are unaffected; an egress that predates it ignores it
• client_version is left empty: the app version reaches lantern-box via tracker/clientcontext, which this outbound can't get at today. Wiring it through is a follow-up, as is a device ID, pending the open questions on egress: log every session, with an optional consumer hello unbounded#454

dependency

go.mod pins getlantern/broflake to the getlantern/unbounded#454 branch commit (d822634). That also brings in the unbounded commits since the previous pin, including #434/#435 (activation counting) and their ttlcache dependency. Re-pin to unbounded main once #454 merges, before merging this.

testing

• go build ./..., go vet ./protocol/unbounded/, go test ./... (20 packages) pass
• the hello itself is tested in egress: log every session, with an optional consumer hello unbounded#454, including a send over a real QUIC connection

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

_{Comment @coderabbitai help to get the list of available commands.}

[myleshorton]

This seems like overkill and also seems brittle. The similar clientinfo approach with our proxies has been a continual source of pain, but it's also a little unclear to me what the goal is here exactly tbh.

[AGMETEOR]

This seems like overkill and also seems brittle. The similar clientinfo approach with our proxies has been a continual source of pain, but it's also a little unclear to me what the goal is here exactly tbh.

@myleshorton if I read getlantern/engineering#3702 right, it came from not being able to tell whether a particular device actually reached the egress. Fleet-wide connectivity is now visible (getlantern/unbounded#460 fixed the URL search, verified in prod), but per device it isn't: the egress only sees the donor, a random CSID and an optional country.

The consumer hello is meant to close that gap. It goes once per QUIC connection on a separate uni stream, so it never touches proxied traffic, and older egresses just ignore it. For now it only sends the track tag and platform. A device ID would be added later, and only once the client can verify it's talking to the real egress (getlantern/unbounded#455 plus a cert rollout). Without that, a malicious donor could impersonate the egress and collect device IDs.

[AGMETEOR]

This seems like overkill and also seems brittle. The similar clientinfo approach with our proxies has been a continual source of pain, but it's also a little unclear to me what the goal is here exactly tbh.

@myleshorton if I read getlantern/engineering#3702 right, it came from not being able to tell whether a particular device actually reached the egress. Fleet-wide connectivity is now visible (getlantern/unbounded#460 fixed the URL search, verified in prod), but per device it isn't: the egress only sees the donor, a random CSID and an optional country.

The consumer hello is meant to close that gap. It goes once per QUIC connection on a separate uni stream, so it never touches proxied traffic, and older egresses just ignore it. For now it only sends the track tag and platform. A device ID would be added later, and only once the client can verify it's talking to the real egress (getlantern/unbounded#455 plus a cert rollout). Without that, a malicious donor could impersonate the egress and collect device IDs.

Hey @myleshorton thoughts?