It’s so we can download all of his downloads from his web server.

Yeah it’s definitely more “logical” and easier to use the way uMatrix does it.

Its functionality is pretty much built into uBlock Origin now, see https://github.com/gorhill/uBlock/wiki/Dynamic-filtering.

I just can’t really resell a disk I’ve drilled through (at the very least it’d lose most of its remaining value). And while I can try to post a sign in front of my door stating that I’d like to physically destroy my disks before they get stolen, I doubt most thieves would respect that.

That’s one of the reasons why I encrypt pretty much all my disks, even those in stationary computers. It protects data from physical theft, but also gives peace of mind when reselling or even when a disk dies in a way that won’t let you overwrite it with zeroes/random data after the fact.

Apple was very late to add AV1 support to their ecosystem in general. As you state, support for hardware decoding was only added with the M3/A17 Pro chips in 2023. There’s still no AV1 hardware encoder on any of Apple’s chips.

I think they were waiting on H.266 and whether it succeeds for too long, they were/are big on H.265 (and all the other HEVC-related stuff like HEIC) so that’d make sense from that perspective.

Pretty much every Secure Boot device trusts Microsoft by default, which is why I think it’s pretty much useless (in its default state anyway).

The user still has to login to their user account. The assumption is that the Windows login is secure so BitLocker can decrypt using TPM and an attacker still won’t have access to the data without being able to log in.

This article obviously shows a method how an attacker can potentially still get access to the data without logging in.

A lot of BitLocker setups unlock using just TPM though, which was my point. No password/PIN needs to be entered at boot time to unlock it, it uses the TPM to unlock. This is the default setup that many companies use. Password/PIN unlock is completely optional.

I’m not misreading that.

It doesn’t already have to be running. BitLocker retrieves its keys from TPM by default, so just booting a device will place the keys in memory.

To minimize downtime, abruptly restart the target system during the Windows boot process, specifically before the login screen appears, as this approach has proven effective in scenarios involving the retrieval of Full Volume Encryption Keys (FVEKs).

By kernel-level debugging with WinDbg, the researcher observed BitLocker operations during the Windows boot process, which revealed that while Microsoft attempts to erase encryption keys using functions like SymCryptSessionDestroy, some keys persist on the heap, potentially due to incomplete key destruction mechanisms.

Is this really a BitLocker issue or more an issue inherent in the hardware design?

EDIT: Okay, looks like Microsoft could do better:

By kernel-level debugging with WinDbg, the researcher observed BitLocker operations during the Windows boot process, which revealed that while Microsoft attempts to erase encryption keys using functions like SymCryptSessionDestroy, some keys persist on the heap, potentially due to incomplete key destruction mechanisms.

But maybe the hardware/UEFI should immediately wipe memory upon restarting anyway…?

Flatpaks also just come with a set of default permissions at install time, so running in a sandbox only really protects against flaws in the software, but not against malicious intentions by its creator. Flatpak doesn’t have an “ask for permission” system afaik, at least not standardized. What you do is you add or subtract from the default the app itself specifies.

Accessing region-specific content doesn’t work as well as it once did with some services actively blocking access from public VPN services nowadays.

Windscribe has a plan where you can pay for an IP address dedicated to you, but this takes away the advantages a shared IP may have.

I think most of VSCode performance improvements just stem from newer CPUs being faster.

At 8 months old it should be well within warranty. Just get it fixed.

I expected something more shocking when I read “working with Russia”.

Kagi uses multiple search backends, and of course it needs to forward search terms to these backends. These backends probably can’t trace the searches back to the individual Kagi user though, but Yandex could still analyze search trends for example.

What’s worse is that - unless they use Yandex’ API for free - customers indirectly (and likely unknowingly) support a Russian company with their paid Kagi subscription.

Kagi should at the very least release a statement about this claim.

This being displayed as “Unknown” is likely just a bug or an app you (very) recently uninstalled. And you probably opened the camera app by accidentally swiping right to left on the lock screen. Even just a slight swipe will launch the app so it’s ready when you’re done swiping.

And I’m not even sure what you’re talking about regarding your QR code.

Android is not de facto superior to iOS, nor is the opposite the case.

If you’re really that paranoid, even GrapheneOS on a Pixel shouldn’t calm you down because it also requires proprietary firmware by Google (and possibly other vendors) to run on these proprietary devices. In this case my advice would be to stop using smartphones altogether and rely on open source computers (couple of RISC-V options out there I think) for your computing needs.

Is the WPA2 specification actually broken? Or just various unpatched implementations of it? I thought many vendors patched against the KRACK attack.

The “Apple TV” is Apple hardware.

Oh I see. According to the article:

The GAZEpolit researchers reported their findings to Apple in April and subsequently sent the company their proof-of-concept code so the attack could be replicated. Apple fixed the flaw in a Vision Pro software update at the end of July, which stops the sharing of a Persona if someone is using the virtual keyboard.

An Apple spokesperson confirmed the company fixed the vulnerability, saying it was addressed in VisionOS 1.3.