(no title)
skuhn | 3 years ago
Some points about how the service operates:
- Fastly does not receive your Chrome browsing history by virtue of running this service, because there is not a 1-1 mapping between URLs browsed and OHTTP requests made. We also cannot view the encapsulated request (which is passed to Google).
- Fastly does not capture access logs for this service, and no logs are sent to Google. There is only access to service-level metrics.
- Google does not have access to modify the configuration of this Fastly service, and does not own the domain or TLS key associated with it.
[1] https://www.fastly.com/blog/enabling-privacy-on-the-internet...
hdevalence|3 years ago
skuhn|3 years ago
I'm not (currently) planning to support customer self-service for this, because I anticipate that most customers may want:
1. Fastly to operate the OHTTP relay service, so that they can clearly state that they can't interfere with its operation to their end users.
2. Customization around business logic. We do plan to re-use the core service implementation across customers, but I've found with the initial implementations that there is an additional layer of business logic that's valuable (things like specifically which headers to strip / pass, using backend API key, verifying a client shared secret, etc.).
However, if it becomes apparent that self-service is desirable here, I'll definitely consider that. There would be a bit more work on the engineering side to enable that.
If you might be interested in that service, I'm happy to discuss: <hn username> @ fastly dot com