If you really are doubting what gets used for TLS, open up Console.app, start streaming, run `nscurl https://example.com/` (or load it in Safari, etc.), and you'll see logging like:

    default com.apple.network boringssl 18:11:46.229209-0700 libboringssl.dylib nscurl boringssl_session_apply_protocol_options_for_transport_block_invoke(2360) [C1.1.1.1:2][0x1008cef10] TLS configured [server(0) min_version(0x0303) max_version(0x0304) name(redacted) tickets(false) false_start(false) enforce_ev(false) enforce_ats(false) ats_non_pfs_ciphersuite_allowed(false) cc_mode_enforced(false) ech(false) pqtls(true), pake(false)]

Or comments such as: https://github.com/apple-oss-distributions/Security/blob/rel...

Unsurprisingly, given BoringSSL doesn't have a stable API (yet alone ABI), it isn't exposed as a system library.

My read of everything is that they are using Docker for NVIDIA GPUs for the sake of "how do you compile code to target the GPU"; for AMD they're just compiling their own LLVM with the appropriate target on macOS.

It stands to reason that the same will apply for LLMs.

That’s not to say their privacy story is fantastic, but they very much still have European operations.

The only difficulty justifying this is ICE’s power to stop and question people, and an airport is no different to a random street from that point of view. Do they have probable cause? What suffices as probable cause?

And once you have probable cause, you run into the problem 8 USC 1304(e) creates: someone who doesn’t have documentation proving their legal immigration status falls into one of two categories, they’re either a citizen, or they’re an immigrant violating that section.

(And this is looking at it from a simple legalistic point of view, ignoring any questions about ICE’s behaviour or powers!)

In my experience, it’s the relatively basic questions that have the highest value — both because they’re what you run into programming most often, and because they’re less likely to overwhelm candidates in a high-stress setting.

The goal, at least from my point of view, isn’t to see if they can come up with the perfect algorithm, but about how they construct an algorithm, how they communicate about the decisions they’re making, how they respond to challenges about edge-cases, etc.

I’m also strongly in favour of picking out questions that are reflective of the actual codebase they’re being hired for — find something with some basic algorithmic complexity which has a relatively simple and easy to explain input and output, and use that as the problem.

In general, I think the best problems are those which any competent senior engineer could design a good solution for almost off the top of their head with little difficulty.

If you imagine a world where you have a header, Accepts-Adult-Content, which takes a boolean value: you essentially have three possibilities: ?0, ?1, and absent.

How useful of a tracking signal those three options provide depends on what else is being sent —

For example, if someone is stuffing a huge amount of fingerprinting data into the User-Agent string, then this header probably doesn’t actually change anything of the posture.

As another example, if you’re in a regular browser with much of the UA string frozen, and ignoring all other headers for now, then it depends on how likely the users with that UA string to have each option: if all users of that browser always send ?0 (if they indicate themselves to be a minor) or ?1 (if they indicate themselves to be an adult or decline to indicate anything), then a request with that UA and it absent is significantly more noteworthy — because the browser wouldn’t send it — and more likely to be meaningful fingerprinting surface.

That said, adding any of this as passive fingerprinting surface seems like an idea unlikely to be worthwhile.

If you want even a weak signal, it would be much better to require user interaction for it.

Maybe it’s needing to step back and even ask for design doc before a plan, but even then…

It’s gonna be very interesting to watch exactly how the adoption of WebDriver BiDi goes with Selenium, especially once WebDriver Classic starts to go away, and how API stability is balanced with exposing more and more async capabilities.

And this is no small part of why Java and JS have frequently been pushing VM performance forward — there’s enough code people very much care about continuing to work on performance. (Though the two care about different things mostly: Java cares much more about long-term performance, and JS cares much more about short-term performance.)

It doesn’t hurt they’re both languages which are relatively static compared with e.g. Python, either.