To some extent, that’s just the nature of the incentive structure — you pay money for exploits with no penalty for false reports? Just rely on monkeys typing reports till one happens to be correct.
The other thing is to remember is that when it comes to complex targets, attacks still are found by using a different fuzzer and/or targeting a different entry point.
It stands to reason that the same will apply for LLMs.
Last I knew Opera still had a decent amount of engineering staff in Poland, and still had some in Sweden, both in the EU, plus still has some amount of staff in Norway, not in the EU but definitely in Europe.
That’s not to say their privacy story is fantastic, but they very much still have European operations.
ICE’s scope isn’t who is coming into the country — that’s CBP’s scope. ICE’s scope is supposed to be those committing immigration offences who have already entered the country (either because the CBP failed to catch them, or because they were admitted but never left).
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!)
> 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.
So hopefully if you are tourist from abroad, CBP will give you stamp into your passport, otherwise you have entered "illegally". They are not always stamping passports.
CBP is doing it electronically for quite some time, as they can see your date of entry in the system and they are not controlling your date of leave against passport when you are leaving USA (you won't even meet CBP at that stage), but it is all checked electronically.
Last time I got stamped. But it seems like an exception than a rule.
A lot of countries don’t stamp passports — if you can guarantee the entry is immediately recorded in your central database, and you can reliably look up the latest entry for a given passport, a stamp doesn’t really gain much.
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.
It’s common enough for groups to not consider the spec done until there is a decent bit of implementation experience (both because actual implementers tend to find interesting bugs in specs, and because many things are hard to measure without any implementation).
Beyond the economic arguments, there’s a lot in JS that actually makes it a lot easier: almost all of the operators can only return a subset of the types and cannot be overridden (e.g., the binary + operator in JS can only return a string or a number primitive), the existence of like string and number primitives dramatically reduce the amount of dynamic behaviour they can have, only proxy objects can exhibit the same amount of dynamism as arbitrary Python ones (and thus only they pay the performance cost)…
From when I was working on optimizing one or two things with Cython years ago, it wasn’t per-se the branch cost that hurt: it was impeding the compiler from various loop optimisations, potentially being the impediment from going all the way to auto-vectorisation.
If you send a flag ever, then absence of a flag is also fingerprinting surface.
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.
reply