skuhn

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.

It's still sold, just not included by default anymore (which is fine with me, since I have tons of them)

https://www.apple.com/shop/product/MK122LL/A/power-adapter-e...

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.

This service with Mozilla utilizes OHTTP, whereas iCloud Private Relay uses MASQUE.

OHTTP is ideally suited for privacy enablement of APIs, whereas MASQUE is more for general purpose traffic.

OHTTP has similarities to MASQUE in that it uses a two hop proxy design where each proxy only knows part of the total requestor / request information. And in both cases these proxies must be operated by separate entities that do not collude.

However, the key difference is that in OHTTP the end destination is known, because there is a 1-1-1 mapping between OHTTP Relay -> OHTTP Gateway -> Target. This could become more generalized in future revisions to OHTTP, but right now it's all hardcoded behavior.

For more about OHTTP at Fastly, I wrote a blog post a while back at [1]. There is also the IETF draft spec at [2].

[1] https://www.fastly.com/blog/enabling-privacy-on-the-internet...

[2] https://datatracker.ietf.org/doc/html/draft-ietf-ohai-ohttp

https://auctions.ipv4.global/prior-sales

$30-35 is the low end per IPv4 address over the last year.

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

There's some similarity to Oblivious DNS over HTTPS (ODoH): https://datatracker.ietf.org/doc/html/rfc9230

Separately from this OHTTP product, we're working on that as well.

OHTTP does require that the parties don't collude, which is why Google has engaged Fastly to run the relay service (which knows end user identifying data) and are themselves running the gateway service (which knows the end user request body).

Part of the contract terms include not delivering log data to Google for this service, among other things that help ensure that this separation of knowledge is upheld.

I can confirm that this is also the spec that we implemented at Fastly for this OHTTP relay service.

More about Oblivious HTTP and what Fastly is doing here is in a blog post that I wrote [1]. I wrote the OHTTP relay service for Fastly and was heavily involved in this deal.

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...

So Yoel posted a link to an article published in Salon titled "Student-teacher sex: When is it OK?" which discusses the broad strokes of a legal case and is in no way advocating on behalf of pedophiles. In fact, the case discussed could not be pedophilic because the student in question was 18.

In your mind this means that Yoel maybe doesn't deserve to be threatened, but still he should have expected this?

So how about for yourself? You posted a link to a link to an innocuous article titled "Student-teacher sex: When is it OK?" What were you thinking?

Boston is also pretty walkable, but I agree that there aren't a lot of options in the US.

Nvidia's datacenter product licensing costs are beyond onerous, but even worse to me is that their license server (both its on-premise and cloud version) is fiddly and sometimes just plain broken. Losing your license lease makes the card go into super low performance hibernation mode, which means that dealing with the licensing server is not just about maintaining compliance -- it's about keeping your service up.

It's a bit of a mystery to me how anyone can run a high availability service that relies on Nvidia datacenter GPUs. Even if you somehow get it all sorted out, if there was ANY other option I would take it.

Perhaps you already know, but initial vaccine trials are not performed against menstruation age (aka likely to become pregnant) women. It is considered medically unethical to do so. That is an obvious double edged sword:

1. It prevents birth defects from occurring with trial participants, because this product has not yet been fully studied and approved.

2. It reduces the initial knowledge of any female-specific issues with the product, and particularly limits knowledge around pregnancy issues.

https://www.path.org/articles/why-are-pregnant-people-left-o...

This study began in April 2021 and the paper was published in July 2022.

Presuming that the amount of time spent was necessary to thoroughly gather, review and document the findings, what would you have wanted done differently?

Besides my comments here, I haven't spoken about it before.

For what it's worth, Apple is hugely siloed and also just plain huge. It's entirely possible that the culture in other orgs was completely different from what I experienced, because it was very hard to interact with anyone outside of your org or the current project scope.

How are they so successful despite this culture? In the case of the project I worked on, I saw a few reasons for success:

1. Management expressed that failure was not an option, so a few people (myself included) out of hundreds pushed ourselves beyond the limit to deliver.

2. Spending a TON of money. I had a different approach to Apple's way of controlling costs (they were very much in the "buying DRAM for iPhones" mindset), and easily shaved millions off of the project. But the inefficiencies inherent to the project's timeline and secrecy and other stakeholders meant the project came in probably 2-3x more expensive than I would have otherwise spent.

3. Leveraging existing institutional resources. Already having a global network and datacenter footprint helped immensely on the time to ship, but it also came with a ton of bureaucratic baggage.

4. Being so large that it ultimately didn't matter. While the project was essential for a key initiative to succeed, and many people (perhaps the entire org) would have been let go if it had failed, ultimately the company would have been fine if it didn't happen. They probably would have just postponed the launch by a year or two and had another org handle the project. It's very hard for a company Apple's size to have anything be an existential threat, so you get a lot of chances.

You're exactly right that companies don't want pure efficiency, and they shouldn't -- there will always be competing priorities to be weighed.

Here's the rub for me, in this particular role at this particular time in this particular company: the workload was extremely heavy, the deadlines were extremely unrealistic, the threat of failure was extreme (up to and including terminating the entire org for failure to meet objectives), and yet it must be done blindfolded and with both hands tied behind our backs.

I'm sure it isn't always like that at Apple, but that was toxic and it contributed to all sorts of toxic behaviors throughout the org. It's no wonder to me that this behavior leads to burnout across the company.

I agree that there is an element of logic in the process, but I also think that it's being done today to a large extent because "this is how we do things at Apple" rather than because it fits the needs of that particular project.

To your example, imagine that the full-time Apple employee responsible for negotiating with that SK factory owner also doesn't know that Apple wants the factory to produce iPhone screens. Just go sign a factory that satisfies our hundreds of requirements, none of which you know, and by the way we need it in a month and everyone else knows what is required but they can't / won't tell you.

There is just no way to get the best results when you operate that way internally.

I worked at Apple relatively briefly, in a lead role on an Important Project that required its own form to be disclosed on it (besides the general agreement you sign to begin employment). A truly toxic work environment that I couldn't get out of fast enough once I shipped the project.

All kinds of projects at Apple have their own disclosure forms, and you are only given one to sign if it's deemed necessary to your work. My responsibilities on this project didn't entitle me to be disclosed on it, which led to all manner of hilariously frustrating guessing games as I tried to deliver on the requirements without actually being told what they were. Conversations regularly went like this: "I can't tell you that that approach won't satisfy the requirements, but I would think twice if I were you." Ultimately I think that I puzzled out what was needed and successfully delivered it, but the method was pure madness.

This wasn't even some new silver gadget launch, it was an infrastructure component to a future product launch down the road. Yet everything and anything can be given the top secret treatment.

Why is that? Running a disclosure-required project is prestigious. Being disclosed on projects is a badge of honor, almost even a high score board, and not being disclosed is used as a weapon in big or small ways.

Anything that Apple manages to ship (in my experience) is in spite of their corporate culture, not because of it.

The other two are to exhaust CO2, fumes and particulates, but I presume that the note about showering is for removing moisture from the interior air and preventing mold growth.

Ideally you want external exhausting vent fans in every kitchen and bathroom, although lots of places have nothing at all or only internal vent fans.

I mostly use regular gaff tape on cables, but if you regularly have problems getting the tape off of the cable there is another kind with a non-adhesive channel in the middle of the tape (Pro calls it Cable Path).

It may be that your theater just hasn't announced showtimes for Thursday and after (beyond whatever the big release is), which is usually when schedule changes are made.