It could also be as simple as "anything tainted by the Claude non-targeting-conditions can't be used in target selection, and we don't want to leak classified information about which components we use in target selection by requiring specific items to be developed without Claude, so we can't allow it anywhere".

If it could be made to work, you could run a fable-grade model in tens of watts.

Once it's established that person A has given _any_ details to person B, the upper bound on "expected cost of an effective defense" is dramatically higher.

A clean room implementation by people who haven’t seen the original work means there can be no discussion of copying, which makes it much cheaper and more reliable to fight an infringement claim.

That's what's referred to as a "clean room implementation" further up the thread.

However, this specific thread is about the scenario where an employee has inside knowledge and is passing that knowledge on to the implementer.

Legally speaking, a clean room implementation has much better defenses from claims of copyright violation.

The NDA doesn't apply to people who haven't signed it, but copyright law does. If you know the material you're receiving is under copyright (eg proprietary source code), and you publish work based on that copyright material, the fact that it's now widely available is not an effective defense against claims of copyright violation.

Person B in this scenario hasn't violated the NDA, but they could be sued for copyright infringement.

Judges, as far as I know, do not generally take kindly to such arguments.

Apps with a config file will often try to read `~/.config/myapp` and also `~/.myapp/config` and maybe one or two other places.

How many permission prompts will users tolerate?

A 1536w / 2048h jpg selfie: 244kb

Progressive JXL at quality=70: 151kb

Loaded 7kb of that file: looked okay up to approx 130px wide.

The first 18kb of that file was a suitable thumbnail up to approx 210px wide.

The first 50kb looked okay up to 300px wide.

The first 75kb looked okay up to 600px wide.

Maybe I need to do a lot more testing, but this seems to work alright?

If browsers extended `srcset` with support for HTTP Range requests, we could use a progressive-encoded jpg (xl or not) file as the source for multiple detail levels.

A device with a small screen would request the first 10kb of the image, while one with a medium screen might fetch 40kb.

The big advantage of that - for sites with many images - is a much better cache hit-rate for a given CDN spend.

Additionally, if you've already fetched a small version of an image and then want to view a bigger version, you've already got partial content downloaded & can fetch only the rest of the file.

“”” After you give up on trying to refactor this code, increment the following line accordingly. HOURS_WASTED_HERE=26 “””