skuhn

There is a very good blu-ray set, now out of print but not crazy expensive, that has five different cuts: US theatrical, international theatrical, workprint, directors and final cut (which is the actual director's cut). That's the best version of the theatrical release that you'll probably ever be able to get.

Only the final cut is available on UHD or an in-print blu-ray (and I would guess streaming as well).

I would immediately shut down and return $114 million to the investors. I'm keeping that extra $1 million as a tip for prompt service.

bash is still shipped on macos 14, the default shell is zsh since 10.15 in 2019.

Unfortunately this will never be fixed. It's not a technical problem. They refuse to ship software licensed under GPL v3, and bash 3.2 is the final GPL v2 version.

I hate it.

This Fastly blog post is really meant to announce the working relationship.

It's not my place to say specifically what this is for (although I imagine Mozilla may announce it themselves), but as of now it's a single use case.

The Relay doesn't know the requested URL or the request body -- but it does know the next-hop destination (the OHTTP Gateway), and by virtue of the way most OHTTP services are currently deployed this tells you the destination service. It does not tell you the specific details of what is being asked for / returned by that service.

These services are implemented in different parts of Fastly's production stack, but they share the same global infrastructure footprint and a lot of the same people/teams are involved with both.

There are other providers of the second hop proxy for iCloud Private Relay, Fastly is one of them.

Yes, that's true. However in practice most deployments that I've worked on are a relay which maps all requests to a gateway which maps all requests to a target. It's not an inherent property of the protocol, and I expect that to evolve over time.

Without going into trust / motivation / etc. of various organizations, OHTTP is not used for general purpose web browsing. This Fastly service is used by Mozilla in conjunction with their own origins, not to random origins on the Internet.

Appreciate your questions and feedback. There's nothing wrong with some healthy skepticism. Ultimately this solution depends on the tech and implementation but it also requires a degree of user trust. I've been happy to see both Fastly and Google being pretty transparent about what's going on and how it works, in order to start establishing that trust.

I can't speak to your points about Google specifically, but I have appreciated in my interactions with the Privacy Sandbox team that they are putting a lot of energy in to delivering these services while also respecting user privacy.

On the Fastly side, I see an opportunity to deliver OHTTP services for a bunch of additional use cases and to other customers. I think this could be a powerful tool to enable privacy for all sorts of things, like metrics and log collection and other kinds of API access. The spec right now needs the client to know various things which requires a tight coupling between client -> relay -> gateway -> target, but I think that there are ways that could be adjusted in future revisions. And not all of the opportunities that I'm exploring are for commercial entities, to your point about NGOs.

I'm also working on some other privacy enablement services, like Fastly Privacy Proxy (which is one of the underlying providers for Apple's iCloud Private Relay) and some un-announced things. Between these various technologies I think that Fastly can help to raise the level across the industry for end user privacy.

Ultimately we are a business and we like making money. I think we can do that in this space by delivering real value to our customers and their end users via these building block services that help them to build privacy enabled products. I'm hopeful that, as we explore more opportunities in this space and OHTTP adoption increases, user trust continues to be built in both the OHTTP technology and Fastly's privacy enablement services.

Yes, I'm working on bringing Fastly's OHTTP Relay to GA, which will allow us to offer it to more customers. That's ultimately more of a pricing and business process thing than any additional technical work. The implementation is feature complete at this point. Planning for that in Q2 (mid-April if all goes well).

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