codethief

> Trusted Execution Environments (TEEs) like Intel SGX and AMD SEV-SNP and in general hardware attestation are just f*d. All their keys and roots are not PQ and I heard of no progress in rolling out PQ ones, which at hardware speeds means we are forced to accept they might not make it, and can’t be relied upon.

Slightly off-topic but: Does anyone know what the Signal developers plan on doing there to replace SGX? I mean it's not like outside observers haven't been looking very critically at SGX usage in Signal for years (which the Signal devs have ignored), but this does seem to put additional pressure on them.

I'm not saying it shouldn't follow rules, I said the rules might be different.

A balance sheet becomes pointless if some assets are valued at today's prices, while other assets are valued at their price from 100 years ago.

What I was trying to get at is that there are other ways to update asset valuations besides daily (market-to-market) and once (price paid) – those are just the extreme ends of a spectrum. What makes sense really depends on the asset class and how long you're holding the positions. As for "It's the rules", I'm aware that there are strict accounting rules for companies and regular banks, but do those really apply to the central bank in the exact same way? (A central bank typically operates on a much longer time scales.)

That makes more sense, thank you! Though do gold assets on the books really never get adjusted? I guess that's up the central bank to decide but I would find it surprising.

Call me confused. The comment I was responding to is saying something different:

> The initial limitation to Google/Android is not great, we know that, and we have support for other OSs on our list (like, e.g., GrapheneOS).

First thought: Maybe they bought the gold first? Or the gold price was at a temporary high when they sold it?

Second thought: The numbers don't seem to check out: 129t are 4,147,456.307 troy ounces (1 troy ounce = 31.1034768 g). The total gains of 15e9 USD would thus correspond to gains of $3,616.68 per troy ounce, which seems excessively high, given that today's gold price is at ~$4,712. Even if they sold everything at the current all-time high of $5,589.38 on January 28 (and that's a big if), they would have had to buy for not more than $1,972.70, a price we last had in fall 2023.

They must have had an exceptional crystal ball!

Is anyone here actually reading the article? Yes, they really made a gain of $15B:

> But instead of refining and transporting the gold, it opted to sell the bars and purchase new bullion in Europe. […] Due to rising gold prices, the move helped the bank to generate a capital gain of 13 billion euros ($15 billion),

What a great name :) ("elf" = 11 in German)

But that response is grounded in the training data they've seen, so it's not entirely unreasonable to think their answer might provide actual insights, not just statistical parroting.

Can someone enlighten me what's been going on in the open-source office application space lately? Here we have LibreOffice and Collabora parting ways; meanwhile NextCloud used to integrate OnlyOffice until v18, then started integrating Collabora in v19 (and also in the recently announced stack for openDesk and "Office EU") but then the other day NextCloud announced they'd fork OnlyOffice to create EuroOffice, … which clearly neither Collabora nor OnlyOffice seem to like?![0]

Please just tell me what the canonical stack is that I'm supposed to use these days. I still have scar tissue from the OwnCloud vs. NextCloud situation…

[0]: https://www.theregister.com/2026/04/02/eurooffice_forks_only...

Agreed. "Prefer pure functions, push side effects to the boundary (functional core, imperative)" is at the top of my CLAUDE.md these days.

> The initial limitation to Google/Android is not great, we know that, and we have support for other OSs on our list (like, e.g., GrapheneOS).

GrapheneOS uses standard Android APIs for hardware attestation (as opposed to Google-specific ones), so why don't you just use those from the get-go?

> Smart albums are collections that support rule based additions, as well as one-off additions. So a contributor can add photos directly to the collection, without the owner's clients not having to perform any extra computation.

What I meant was that if the smart album's purpose is allowing contributions to a tag in some other album, then contributed photos will have to be tagged & added to the original album by the owner, won't they, since only the owner holds the collection key.

> For the workflow you've mentioned, we have plans to make albums where collaborators can only view the items they have added

I'm not sure this would cover my use case. 1) I don't like other people's photos getting mixed up with mine for various reasons, which is why I typically set up one subfolder (or in Ente: a separate album) per contributor. 2) I want different people to have write access to their corresponding subfolder, but they should have read access to a larger set of subfolders (e.g. each others' photos, or maybe even the entire "summer vacation" album, though not necessarily).

All in all, the mechanisms you propose seem rather complex to me (and still inferior) compared to simply allowing albums/collections to be nested. And when I say "complex" I mean this not just from a technical point of view, but also from a conceptual & UX one. In the interview on YouTube you mention that a folder hierarchy might seem foreign to younger users but even if I believe that, is the solution really to come up with a solution that's foreign to everyone?

Besides, the entire industry has settled on nested folders as the primary way to organize files & documents as well as access control, from traditional file systems over Dropbox, M365 / SharePoint / One Drive to Confluence. So I'd say whoever is unfamiliar with that will become familiar fast, don't you think?

They, too, offer integrations for LLMs these days, presumably for better OCR and classification.

I've been using News Feed Eradicator[0], a Firefox/Chrome extension, for the same purpose and it's been working really well. For most sites you can configure what should vs. should not be "eradicated".

[0]: https://github.com/jordwest/news-feed-eradicator

Huh, I must have missed that. Thanks!

Ah, you're right. I added the (·)⁻¹ at the very end, when I noticed the units on both sides didn't agree, and forgot about the average.

> The $1 is measured in international dollars. This means it buys the same amount of goods and services in any country as a US dollar does in the United States. It is often used alongside purchasing power parity (PPP) data. The “time” refers to a day of life for anyone, at any age and in any circumstance — not just the hours worked by someone with a job.

So IIUC this "average poverty" (measured in time per international dollar) includes people living off social welfare? Otherwise, if it only included the working population, wouldn't we have

  average poverty ≝ (average yearly income* of the working population / 1yr)⁻¹

and so it should be inversely proportional to the average yearly income* metric mentioned in the article?

*) Adjusted for purchasing power, i.e. measured in international dollars.

Ahhh, now I see! Thanks!

> You can then share[0] this album with recipients who can view / add / auto-add items from their library.

IIUC, when a contributor uploads a photo, the owner of the smart album would need to do some client-side synchronization and 1) add the uploaded photo back to the original album and 2) add the tags ["2020", "Holidays"], so as to control write access to the original album & tag?

Either way, would these smart albums show up next to regular albums, though, or be "hidden"? I'm asking because what I would like to do, e.g., is to have a photo album for all our summer vacation photos and then create a subfolder (tag) for each family member to upload their photos in. If the smart albums all showed up in the top-level (flat) album list, I'd end up with a bunch of albums "2026 Summer vacation", "2026 Summer vacation - Alice's photos", "2026 Summer vacation - Bob's photos" all next to each other, which would kind of defeat the purpose in many ways.

I'm not sure I understand yet. If tags (and the photos associated to them) are supposed to be shareable with others, how do you control read/write access to the tag if you don't use separate cryptographic keys? If you re-use/share existing keys (e.g. the parent album's collection keys), how do you ensure the recipients cannot read other photos or tag metadata not shared with them? What am I missing?

Once again thank you for taking the time to discuss this here! I appreciate it!

> While standalone CSS is not yet Turing complete

Looks like it is, though? https://news.ycombinator.com/item?id=47558097

A wall hack is any technique allowing the player to see opponents through walls. Googling for screenshots or videos should give you a good idea of how it looks.

How is that setting supposed to carry over if I don't even have a Google account on my phone?

And even if I disregard that for a moment, what's up with the author being a mouthpiece for Google?

> Google's latest concession makes the sideloading controversy a big nothingburger

> Opting out is going to be even less of a problem than we thought

> This afternoon, Google’s Matthew Forsythe shares some answers to questions he’s gotten about the minutiae of how this process all works — and he’s got some very, *very* good news for us.

(emphasis theirs)

> Doing that once with every new phone already sounded perfectly manageable. But now Google clarifies that even that won’t be necessary, with the opt-out able to be transferred as we upgrade phones. That is maybe just the best news we could have gotten here, and hopefully it’s enough to calm everyone down about the sideloading-sky falling.

> Namely: Salary is taxed lower than dividends.

That very much depends on your tax bracket but at high income levels salaries are usually taxed quite a bit higher (42% vs. ~27%). 42% being the highest tax bracket of course; the first ~69k€ of your salary are taxed at a lower rate.

> If they determine that you paid out dividends as a salary, then you'll be charged with tax fraud.

This might be the case if the company were in Germany, and then it might not even be the taxman that'd complain but social security since you don't pay social security fees on capital gains. However, I doubt German authorities can do much about an Estonian entity paying dividends.

> You can't just keep adjusting your salary up and down every month with a corporation.

Yes, you can. Many companies do that – it's called fixed vs. variable salary (bonuses).

> The problem is that you can only pay dividends the year after you earn the money.

You're right in general (and I assume also in the case of an Estonian entity). Though at least in Germany – surprisingly – this is not correct, look up "Gewinnvorabausschüttung".

Either way, this is not a huge obstacle if you're pursuing this long-term: You only have to make it through the first year without any income. Afterwards you can live off of last year's dividends.

> It's related to commits actually having a parent-child structure (forming a graph) and timestamps (commit/author) being metadata.

Yeah, I think everyone is aware. It's just that the last couple dozen commits, to me, looked like commits had been created in chronological order, so that topological order == chronological order.

> I know GitHub prefers sorting with author over commit date, but don't know how topology is handled.

Commits are usually sorted topologically.

Oops, I should have checked this more carefully. Thanks!

I think such "ludicrous sets of patches" are very common in many jurisdictions. (At least in Germany they are.) I agree, though, git patches would be a lot nicer.

The German parliament even has an official git repository: https://github.com/bundestag/gesetze

Looks like it's been abandoned, though. :(

> how far back (in time) do those 27k commits go

Looking at the commit dates (which seem to be derived from the original publication dates) the history seems quite sparse/incomplete(?) I mean, there have only been 26 commits since 2000.

So if I understand you correctly, users will be able to share tags from a given album but you don't want to make tags separate collections (inside the existing album collection). But what is the alternative here if you want to secure access to the tags cryptographically (which I hope you do)?

A few thoughts:

1. Let's say files inside tags use the collection key of the parent album. Access to a tag (e.g. if I shared it with someone) therefore requires access to the collection key, thereby potentially exposing the entire album. (E.g. if a government agency got hold of a public link I've shared to a single tag inside a bigger album.) Bad.

2. Alternatively, let's say all file keys of files belonging to a tag will also be encrypted with an additional tag key (separately from the encryption with the collection key). This is certainly doable and I assume you already do a similar thing for photos belonging to multiple albums/collections. However, with nested tags this might get annoying fast if a file key needs to be encrypted not only with the tag key of the tag "foo/bar/baz" but also with the tag keys of "foo/bar" and "foo". If you wanted to avoid this, you'd encrypt the tag key of "foo/bar/baz" with the tag key of "foo/bar" and the latter with the tag key of "foo". But then isn't this more or less exactly what you would do if you implemented nested collections?

On top of this, you will need to store an encrypted map of tag -> tagged files somewhere both for performance reasons, for privacy reasons (if you stored the tags inside the files, you'd risk exposing them to people the tags weren't shared with), and to manage write access (contributions) to a tag.

All this, I assume, is also what you do for collections. So then, all in all, how different from collections would tags really be?

--

Irrespective of the encryption questions, wouldn't the addition of tags complicate your domain model quite a bit? You'd likely also need new API endpoints, and separate UIs for viewing photos belonging to a tag (as opposed to an album), sharing a tag, editing/renaming tags, …