site banner

Culture War Roundup for the week of January 6, 2025

This weekly roundup thread is intended for all culture war posts. 'Culture war' is vaguely defined, but it basically means controversial issues that fall along set tribal lines. Arguments over culture war issues generate a lot of heat and little light, and few deeply entrenched people ever change their minds. This thread is for voicing opinions and analyzing the state of the discussion while trying to optimize for light over heat.

Optimistically, we think that engaging with people you disagree with is worth your time, and so is being nice! Pessimistically, there are many dynamics that can lead discussions on Culture War topics to become unproductive. There's a human tendency to divide along tribal lines, praising your ingroup and vilifying your outgroup - and if you think you find it easy to criticize your ingroup, then it may be that your outgroup is not who you think it is. Extremists with opposing positions can feed off each other, highlighting each other's worst points to justify their own angry rhetoric, which becomes in turn a new example of bad behavior for the other side to highlight.

We would like to avoid these negative dynamics. Accordingly, we ask that you do not use this thread for waging the Culture War. Examples of waging the Culture War:

  • Shaming.

  • Attempting to 'build consensus' or enforce ideological conformity.

  • Making sweeping generalizations to vilify a group you dislike.

  • Recruiting for a cause.

  • Posting links that could be summarized as 'Boo outgroup!' Basically, if your content is 'Can you believe what Those People did this week?' then you should either refrain from posting, or do some very patient work to contextualize and/or steel-man the relevant viewpoint.

In general, you should argue to understand, not to win. This thread is not territory to be claimed by one group or another; indeed, the aim is to have many different viewpoints represented here. Thus, we also ask that you follow some guidelines:

  • Speak plainly. Avoid sarcasm and mockery. When disagreeing with someone, state your objections explicitly.

  • Be as precise and charitable as you can. Don't paraphrase unflatteringly.

  • Don't imply that someone said something they did not say, even if you think it follows from what they said.

  • Write like everyone is reading and you want them to be included in the discussion.

On an ad hoc basis, the mods will try to compile a list of the best posts/comments from the previous week, posted in Quality Contribution threads and archived at /r/TheThread. You may nominate a comment for this list by clicking on 'report' at the bottom of the post and typing 'Actually a quality contribution' as the report reason.

10
Jump in the discussion.

No email address required.

Thanks. I suppose publishing a white paper at least opens them up to more serious scrutiny (which I've seen in serious-ish forums like HN). But my initial response is rather skeptical still, though. The encryption methods seem like they should be far more expensive than Apple is letting on [1], and they say they're using this for querying remote databases with encrypted queries. They're less clear on how these databases (for photographic landmarks, URLs, and such) are encrypted in a manner that actually hides the query from Apple. Are the encryption keys different per-device? If so, how do they avoid needing a separate database per device? And if not, it seems there's a lot of trust that they would be unable to figure out which rows matched.

I know Google's approach to similar issues has been focused more on device side ML models. Pixel phones support offline song recognition (I've noticed it's fairly limited to popular songs), and Google Translate can work (in a limited fashion) offline. Why does Apple need to do cloud-based POI recognition in photos? The whitepaper only shows 6 very well known landmarks, but it seems like it'd be easy enough (and secure!) to do this on-device. Given the known computational costs of FHE, it might even be better for battery life.

  1. Quoting the linked FV paper: "As to whether any of these [previous] proposals is really practical, the answer is simply “no”.... The most recent paper manages to execute one AES encryption homomorphically in eight days using a massive amount (tens of GBs) of RAM memory." That's before their proposed algorithm, but they don't directly seem to claim many-orders-of-magnitude improved tractability.

The encryption methods seem like they should be far more expensive than Apple is letting on

Oh, I would read it differently. I think they're letting on that it's pretty expensive, which is why they're doing all the mess with sharding and DP.

Are the encryption keys different per-device? If so, how do they avoid needing a separate database per device?

My understanding of BFV is that when the device does its keygen (unique for each query, I assume), it produces and then passes an "evaluation key" as part of the public key. One has to design the scheme so that there is sufficient expressivity in the set of evaluation functions that can take in the evaluation key and perform the desired operations on the encrypted message. I don't believe this involves completely encrypting the entire database from scratch using the public key every time; it just requires running the same operations on the same underlying database, but with the evaluation key in the operations. They call out that it's important that the BFV scheme has many of the operations they want, expressible in, shall we say "evaluation key parameterized form".

I think a lot of the work in library building is essentially building up a set of these "evaluation key parameterized" operations. You have to start with extremely simple operations and then build your way up to more usable tools that are composed of those simple operations.