Thank you!
Not really, the controller is not doing dataplane per-say, it only pushes eBPF programs to the kernel for the relevant apps/cgroups so that could be considered control-plane. The full data-plane run in eBPF.
> Is it just the 6 digit code that Apple sends to verify iCloud access?
No. It is unrelated to Apple ID 2FA.
If its what I'm thinking of, it used to be a user-visible thing[1] back in the day.
But now with the need for increased security posture in the modern environment it is now not user visible but held locally and encrypted using the local device secure enclave key. So you would typically now see a prompt for the device password so the enclave can be accessed to access the key to setup/renew iCloud access tokens.
As far as I am aware the only user-visible string still available in the Apple world is (for obvious reasons) the FileVault recovery key on macOS devices. Which is only visible once ... shown to you when you first enable FileVault.
If its what I'm thinking of, it used to be a user-visible thing[1] back in the day.
It used to be user-visible, yes, but I wonder if TFA isn’t a little out-of-date, as the UI flow that used to work in order to see this (settings/icloud/keychain/advanced) isn’t there anymore on Mac or iOS. And random poking around indicates that they didn’t move it.
When one would be prompted to create a new code, the dialog said something about “changes to the servers” or something similar. Now, having read TFA, I wonder if that doesn’t mean an HSM got compromised somehow.
> I wonder if that doesn’t mean an HSM got compromised somehow.
I think the point is there are multiple HSMs in multiple locations under the control of different groups of people and a majority of HSMs have to agree...
First time I enabled iCloud keychain when it was released in iOS 7, it asked for both user defined security code (4-pin at the time) and a verification phone number.
When you switch to a new device and want to pull iCloud keychain to a new device you need to provide your security code (pin) and additionally a verification code that they send to the phone number.
Nowdays I’m not sure what my security code even is, because it stopped asking for it on a new devices, since you can approve pulling iCloud keychain from another device.
> The following steps require the ukbunpack and ukbconv utilities from the UK Biobank website. The file decrypt_all.sh will run through the following steps on one of the on-prem servers.
> Once the data is downloaded, it needs to be "ukbunpacked" which decrypts it, and then converts it to a file format of choice. Both ukbunpack and ukbconv are available from the UK Biobank's website. The decryption has to happen on a linux system if you download the linux tools, e.g. the Broad's on-prem servers. Note that you need plenty of space to decrypt/unpack, and the programs may fail silently if disk space runs out during the middle.
Good catch! The data is everywhere, re-uploaded every week.
I am aware of ~30 repositories that UK Biobank has asked GitHub to delete, and can still be found elsewhere online. They know the site, they have managed to delete data from that site before, and yet the files are still there.
It seems you're correct - the post has been modified.
> This entry was updated on April 21 to correct the incident timeline and scope characterization based on post-publication reporting from Context.ai's security bulletin.
> Key corrections: the initial compromise occurred in February 2026 (not June 2024), the initial access vector was Lumma Stealer malware (not an unknown mechanism), the dwell time was approximately two months (not 22 months),
LMFAO. Brave uses uBO's lists and filters, including trusted filters which have much more capabilities with much more risks to your sites' data and they allow that on all other lists too (even uBO only allows their own lists as trusted by default, other lists need to have permissions from users manually). That's how they can block youtube ads, and no they don't code their own filters for youtube ads either. And be assure that they can't check 100% all commits from uBO and other lists either.
If you want to play "no trust to a 3rd party dev", you should not use Brave's adblocker either. Or at least turn off all the lists inside it, and use your own lists. Your security risk is in those stock lists.
> If you have used Stripe before, Mollie is the closest thing to that experience in the EU.
But Mollie does not even properly support recurring payments, a pretty important feature for SaaS. It does not track subscription state and does not retry failed payments.
This is actually important to understand. What are the dependencies of your dependencies? I.e. if your goal is to be sovereign than knowing how far the turtles go, and who the turtles are, is quite important.
This is helpful, but it is yet to be seen how downstream picks it up. Wikidata[0] has renamed it and marked the Vinyl repo as the preferred one. Gentoo[1] renamed the package and switched to Vinyl. Homebrew[2] is now tracking Varnish Software (downstream of Vinyl). Fedora[3] has switched to Varnish Software as well. At endoflife.date[5], we renamed to vinyl and switched tracking as well. Wikipedia[6] has renamed Varnish (Software) -> Vinyl Cache.
reply