Go Unfloc Yourself Bundle Laravel Package

Technical Evaluation

Architecture fit. loophp/go-unfloc-yourself-bundle is packaged as a bundle — the naming and loophp convention point to a Symfony Bundle (DI extension + Bundle subclass), not a Laravel package with a ServiceProvider. That is a meaningful mismatch for our stack: Laravel will not auto-discover or boot it, and its configuration surface (Symfony Configuration tree, service definitions) does not map onto Laravel's config/*.php + container bindings without an adapter layer we would own. More importantly, the value proposition is narrow: opting out of FLoC is expressed as a response header (Permissions-Policy: interest-cohort=()) and/or a set of hosts to block. In Laravel that is a one-file middleware or a single header() call in a base controller — roughly five lines of first-party code. The package therefore does not reduce our surface area; it adds a third-party dependency, a Go binary, and a framework bridge to replace trivial code.

Integration feasibility. Composer installation is plausible, but the useful artifact is the underlying Go executable (go-unfloc-yourself), not the PHP wrapper. Adopting it means our build and deploy pipeline must produce or fetch a correctly targeted static binary. We have no evidence in the release of CI matrices, test coverage, static analysis, or a published artifact list — the 1.0.0 tag is a single import commit (b1916e4), which is an "initial set of files" drop rather than a hardened release. Semver 1.0.0 here signals intent, not stability.

Technical risk.

• Relevance risk (highest). FLoC was retired by Google in favour of the Topics API. A package whose sole purpose is emitting an interest-cohort opt-out may be solving a problem that no longer exists in current browsers, which caps its long-term value regardless of code quality.
• Maturity risk. One commit, no changelog history, no visible test suite, no documented API. There is no track record to reason about for breaking changes, because nothing has changed yet.
• Supply-chain risk. Executing or shipping an opaque third-party binary in our runtime or image is a privileged action; we would need source review, reproducible builds, and checksum pinning before it touches production.
• Framework risk. A Symfony-shaped package inside Laravel creates a permanent adapter shim that we maintain across Laravel majors.

Key questions for the maintainer / our spike.

1. Is this intended for Symfony only, or is there a framework-agnostic core we can consume directly?
2. Does it shell out to a Go binary at request time, at container build time, or is the binary embedded?
3. Which platforms/architectures are published (linux/amd64, linux/arm64, musl/Alpine)?
4. What is the maintenance commitment and release cadence? Is there a CI pipeline and test suite?
5. Given FLoC's deprecation, what is the roadmap — does it extend to Topics API, or is this effectively feature-frozen?
6. License and provenance of the embedded binary?

Integration Approach

Stack fit. Poor-to-adequate. The header-level behaviour fits Laravel cleanly; the delivered packaging does not. Treat the package as reference material for which headers/hosts to emit, and implement the behaviour natively rather than adopting the bundle.

Migration path. If we do adopt it, isolate it behind our own abstraction:

1. Build a FlocOptOutMiddleware (or a response macro) in our codebase that unconditionally sets the header from config.
2. Make the header value a config key (privacy.floc_opt_out) so it can be toggled per environment.
3. Only if the package offers functionality beyond the header — e.g. host blocking or a maintained list — wire the package in as the implementation behind that config flag, so removal is a one-line change.
4. Register the Symfony bundle manually if required (add to bootstrap/providers.php via a thin ServiceProvider wrapper) and publish its config through mergeConfigFrom.

Compatibility. Verify before any code: PHP constraint (^8.x?), Laravel support policy (we are on 10/11), presence of symfony/http-kernel version conflicts against our existing Symfony components (Laravel pulls several), and whether the binary artefacts cover our container base image (likely Debian-slim or Alpine). Alpine/musl and arm64 are the usual gaps.

Sequencing.

1. Spike (½ day): read source, confirm what the binary actually does, confirm whether the header is the whole story.
2. Baseline: ship the native middleware without the package; this is independently valuable and reversible.
3. Evaluation (only if step 1 finds non-trivial functionality): add the package behind the config flag in a single non-critical service, run in staging for one release cycle.
4. Decision gate: adopt, or drop and keep the ~10-line native implementation.

Given the evidence, step 2 is the likely terminal state.

Operational Impact

Maintenance. High relative to value. A single-commit, single-maintainer package with no release history means we cannot distinguish "stable" from "abandoned." We would own the Symfony-to-Laravel adapter indefinitely, and would need to re-validate on every Laravel major and every PHP minor. The native alternative has zero external maintenance cost.

Support. No documentation, no issue history, no upgrade guide. Internal onboarding would consist of reading source. Expect all support burden to land on the adopting team.

Scaling. The header itself is free — set it once, ideally at the web-server or middleware layer, and the per-request cost is a string copy. The danger is the execution model: if the integration invokes the Go binary per request, that is a process spawn per response and will dominate latency under load. Any adoption must confirm the binary runs at build/boot time or, better, that only static configuration is emitted. Confirm also that the header survives our CDN and reverse proxy — several providers strip or rewrite Permissions-Policy.

Failure modes.

• Binary absent or wrong architecture in a rebuilt image → runtime errors; must fail closed with a guarded no-op, never a 500.
• Silent header stripping by CDN/proxy → we believe the opt-out is active when it is not; needs an external assertion test in CI.
• Composer constraint conflict with symfony/* on a Laravel upgrade → blocks framework upgrades.
• Upstream abandonment → we inherit a frozen dependency with a confusingly stable 1.0.0 version.
• Relevance drift → we operate a control for a deprecated browser mechanism, creating false assurance in privacy documentation.

Ramp-up. Low for the header behaviour (hours for any Laravel developer). Moderate-to-high for the package route: Go toolchain familiarity, cross-compilation, container image variants, and Symfony DI semantics for whoever owns the adapter. Budget roughly one engineer-day for the spike and bridge, versus under an hour for the native middleware.

Recommendation. Do not adopt loophp/go-unfloc-yourself-bundle into the Laravel stack at 1.0.0. Implement the response header natively behind a config flag, document the FLoC/Topics API deprecation caveat with our privacy stakeholders, and revisit only if the project demonstrates a maintained, framework-agnostic core with published binaries and CI.