An Immigration Officer may search you until they are satisfied you are a citizen. As long as you have a passport (or emergency travel document) listing you a citizen, this should be straightforward and they're unlikely to have grounds for any further search. At that point, you have been let into the country.
Customs Officers are much more likely to have grounds for a search — if they believe you are bringing prohibited material on the electronic device into the country (and "reasonable grounds" is low, as it typically is for customs — "you're acting kinda sus" is a reasonable ground), they can search your device. It is an offence to refuse a search, so while you've been admitted to the UK, you could be arrested for that offence.
This is all broadly comparable to most other countries immigration and customs laws; the UK is not an outlier here.
The problems with the UK are primarily things that apply to everyone, not just at the border — for example the Terrorism Act 2000 and Regulation of Investigatory Powers Act 2000. But again, in the border case — that's basically all going to be _after_ you are admitted to the UK.
> a new "Adminless" account model with linux-like just-in-time escalation
This was the promise of User Account Control, was it not? Or does that just prompt for confirmation for various actions, without actually enforcing a security boundary?
The way I read it, the difference between existing UAC and "Adminless" is that the user is always in the Administrators group and UAC just unlocks an Administrator token/ACL temporarily to bestow the actual powers of the Administrators group. In "Adminless" the user is only a less privileged/low privilege user, a new system-managed Admin User is created, and the new security boundary prompts instead of unlocking a temporary token/ACL are more "runas" the system-managed Admin User. It's similar to Linux sudo sending commands to the root account, where Linux doesn't have a token/ACL model that allows temporarily upgrading the existing user "in place". It's also similar to how Windows Admin security was managed pre-UAC in places that separated standard accounts and Admin accounts, and similar to how many corporations still manage security, with the difference being that the new "Adminless" admin account is system owned (like the various internal service accounts), supposedly does not allow interactive login, has no password only a hardware security key (hence why the new security boundary requires Windows Hello unlocks every time, versus UAC can be as subtle as Yes/No, depending on configuration/group policy).
"Adminless" is a funny name given that there's still an admin account involved, it's just an admin account that is much more than before not a user account but more like a service account.
UAC provides just-in-time elevation. The user belongs to the 'admin' group (aka wheel) and only receives an admin token when performing a task that requires elevation. Once the task is complete, the token is destroyed.
> Once the task is complete, the token is destroyed.
It's less granular than a task though, it's an execution context. If you're running Notepad++ and it wants to update, it requires an elevation. The installer is now running in an admin context and can do whatever it wants, once it's finished installing it usually asks if you want to launch Notepad++ again. At that point the installer running in the admin context can launch Notepad++ within that admin context.
Thus there's a potential for the admin context to persist indefinitely.
In my mind, tasked based elevation is more granular. Something like "I need to write to the program files directory" and not a carte blanche "gimmie admin access to do whatever the hell I want".
Sorry, I'm confused. I can't figure out from your explanation how the new adminless just-in-time elevation is supposed to be different from UAC's just-in-time elevation?
UAC is per-process and monotonic. Once elevated, the entire process stays elevated.
The new model is per-operation. Even if the same process has been allowed to elevate before, it must ask to do it again. I don't know how granular this is, and whether there's a grace period like sudo.
However, the biggest problem with UAC was that it was considered too noisy for the end user, leading to people just blindly accepting every dialog and Microsoft turning down the default level to the much less secure "don't always prompt". I don't know how this new model will address that problem; naively, it seems to be worse on this front.
Huh. In that case, the upthread commenter likening the new model to being more "linux-like" seems confusing.
Given that they didn't mention which Linux security model the new system was like, I presumed they meant the most commonly referenced model for performing administrative tasks: sudo/doas - which elevates a process for its entire runtime.
But if it's a per-operation model, I guess they might have been comparing it to the "desktop portal"/"policykit-dbus" model instead? Which does kind of fit, but I don't think is the security model that most people think of when someone says "linux-like just-in-time escalation"?
> Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many applications. As a result, this specification does not mandate a particular maximum number of connections but, instead, encourages clients to be conservative when opening multiple connections.
If there is capacity, they are obliged to provide it on a non-discriminatory basis. If there isn't capacity, then it gets into questions of allocation (which still needs to be done in a fair and documented basis).
To reply mostly with my WPT Core Team hat off, mostly summarising the history of how we've ended up here:
A build script used by significant swaths of the test suite is almost certainly out; it turns out people like being able to edit the tests they're actually running. (We _do_ have some build scripts — but they're mostly just mechanically generating lots of similar tests.
A lot of the goal of WPT (and the HTML Test Suite, which it effectively grew out of) has been to have a test suite that browsers are actually running in CI: historically, most standards test suites haven't been particularly amenable to automation (often a lot of, or exclusively, manual tests, little concern for flakiness, etc.), and with a lot of policy choices that effectively made browser vendors choose to write tests for themselves and not add new tests to the shared test suite: if you make it notably harder to write tests for the shared test suite, most engineers at a given vendor are simply going to not bother.
As such, there's a lot of hesitancy towards anything that regresses the developer experience for browser engineers (and realistically, browser engineers, by virtue of sheer number, are the ones who are writing the most tests for web technologies).
One could definitely imagine a world in which these are a test type of their own, and the test logic (in check-layout-th.js) can be rewritten in a custom test harness to do the same comparisons in an implementation without any JS support.
The other challenge for things like Taffy only targeting flexbox and grid is we're unlikely to add any easy way to distinguish tests which are testing interactions with other layout features (`position: absolute` comes to mind!).
Note the Eurostar is perhaps an especially bad example in terms of affordability, versus most HSR in Europe:
* the Channel Tunnel has very high access charges (because construction was very expensive, and as a private entity it took on a lot of debt and wants to pay that off!), and
* the terminals in both London and Paris are too small for the time taken by border control now the UK is no longer in the EU (which has led to Eurostar running fewer trains—but the demand has hardly decreased).
22-24 March, Copenhagen to Berlin and back, one adult:
€210 by train.
€170 by plane (no luggage added).
The plane is much faster, but I can get work done on the train. Both cities have cheap public transport connections between the centre and the airport.
Yes — because the move to 16k pages happened at the same time as the move to arm64.