jeroenhd

That's also why the approach is fundamentally flawed. The open-ish C2PA protocol has been "defeated" by tricking phones into signing arbitrary data already. The even-more-closed Apple version can be defeated the same way and relies on Apple to be the sole arbiter of truth.

By the time you made your comment, such a system had already been invented, even partially rolled out: https://en.wikipedia.org/wiki/Content_Credentials

Apple's protocol differs in that it requires a timestamping server to sign the file and centralising Apple as the single arbiter of truth. An excellent addition, if you trust Apple and the governments they're friendly with (I don't, especially the latter part).

That's a lot of words to say "we re-invented C2PA but made worse by getting our servers involved somehow".

Like with C2PA, the entire thing hinges on nobody being able to dump keys or trick the TPM into signing arbitrary image data. The timestamping server is a nice idea (though I don't see why they can't just use a normal timestamping server, I guess to keep control over the protocol) but it doesn't solve the fundamental problem that defeated C2PA.

Apple can hold the AI customers hostage by locking this level of AI integration to their app store, taking a 30% cut of AI subscriptions while at the same time having someone else fix the reputation of their devices' voice assistant for them.

There's profit to be made by offering customers choices here, I'm sure Apple will be ready to scoop up all of those delicious slop dollars.

WhatsApp doesn't even have the option to disable e2ee anymore and it's doing just fine, despite their best efforts to screw over their customers.

So was RCS, until Google resurrected its rotting corpse and made it the default messenger for billions.

All we need is for a billion dollar company to build their own implementation and XMPP can be back once more. Exactly the way it gained popularity back in the day.

Based on web browser statistics I've seen, most people use Chrome, some of them use Safari on their phones. There are also people who use Edge sometimes.

But most people seem to use Chrome on every device, no matter how much I wish they didn't.

To be fair, dead birds don't tend to migrate as much (unless they're helped along and stored in a cooler, if you call that migration).

Depending on your needs, XMPP or Matrix are probably your best bet. Both have different clients of varying usability and quality on different platforms, so you have to pick your poison. If E2EE is important, you also need to determine how encrypted you want your messages to be (as both XMPP and Matrix carry quite a bit of identifying metadata in its unencrypted headers).

For most people and use cases, either will probably do, but if you're a human rights activist or journalist in an oppressive country, I'd stick to Signal.

Matrix is a vastly different protocol with vastly different privacy implications. Things like leaking reaction metadata outside of the encrypted envelope (though there finally is an MSC to fix that) should make that obvious. Matrix is cool tech and I use it every day, but comparing Matrix to Signal doesn't make much sense. You can't do what Signal does with Matrix or XMPP, simply because the lack of federation affords privacy and security advantages that federated protocols cannot support.

As for Moxie's post: all three points feel completely valid for a service they're offering for free. Moxie does know better than most users (most users don't know the first thing about software, programming, protocol design, or UX design) and it's a companies choices that drive users to their platform in the first place. Users who don't like it can choose from the dozens of other chat apps instead.

As for the second point, Matrix's ever-moving target of a protocol makes selecting a client or server that covers all of your needs a massive pain. Currently, Matrix's primary server software, Synapse (which is also at the base of the matrix.org server many people default to when joining the network), is violating the Matrix protocol, making it impossible to invite users to chat if they are on compliant Matrix servers. On the XMPP side, there are two different methods of achieving E2EE communication, with seemingly no standard mechanism to support the use case "I want to log in to my chat on my laptop and be able to decrypt the messages in the group chat". I can't blame Signal for not wanting to deal with issues like that. One piece of server software, one set of client versions, with fixes ready to deploy when they're called for: Signal's current design saves a lot of time and effort.

As for the third point, that's part of the reason I use Signal in the first place. I like federated networks as much as the next nerd and I like open standards even more, but the decisiveness behind the company, even when I disagree with their decisions sometimes, is what makes it clear what you can and cannot expect.

On the XMPP defence: yes, I believe what they are saying, XMPP could in theory be a good product, just like Matrix could be, and like Signal is. However, currently, it isn't. XMPP is currently losing in terms of public marketshare to Matrix, which I also wouldn't exactly call a great success.

A lot of chess.com information is public (by default) if you know someone's profile. Stuff a couple million email addresses and phone numbers into the "find friend" API and all you need to get profile information is the associated account username.

Chess.com should probably prevent scraping, but as we can read in just about every comment thread about LLMs/Cloudflare/Anubis/Go-away, that's not as easy as it sounds these days.

I would feel the same way if these people weren't installing a permanent surveillance camera.

I don't think it's fair to cry harassment if you're getting filmed setting up the harassment machine.

If anything, Americans are being too nice to Flock. We're watching the villain and setup of a 1980s dystopian scifi horror, except there's no unlikely hero who can save the world by shooting a single weirdo in a suit on top of a skyscraper.

> FortiClient VPN and SmartVPN have 4,134,648 cumulative Google Play installs between them, while Google reports more than 3 billion active Android devices.

A very strange way to reason about killing an API instead of fixing the VPN issue (as someone from Google already suggested they're planning on doing). "Only 4 million people use this, we should kill it" is exactly the kind of reasoning Microsoft in the 2000s would use to kill the ability to install Linux on a PC.

That seems like a good trick to me if you want to prevent people from installing spyware without any obvious signs.

You can almost hide the warnings (there's one small notification in the bottom of the notification tray you can't disable) and on some phones even the VPN icon, but you can't hide the new lock screen code your victim suddenly needs to enter to use their phone.

It used to be that Android showed random popups and notifications about identified security risks, which were awfully annoying if you have a private CA certificate installed. Luckily Google got rid of those.

In my experience, you can also set up biometrics on basically every phone, and Google has a few "don't lock the phone while it's with you in your pocket" like services you can optionally enable as well. Your backup PIN doesn't have to be four numbers, you can put a whole passphrase in there if you want it to be secure.

You could also do facial unlock. Less secure than Apple's implementation but more than good enough if you didn't have any lock screen set before that.

It's technically possible but very unlikely. Running TTS continuously is a big battery drain and slows down the rest of the phone while you're using it. Google has a live TTS service for hearing impaired which I've run for a while to test it, and even with it practically built into the OS it's sucking up battery like you'd expect it to.

It's more likely that this is all due to external forces. Having your device on the same network, in close enough proximity to detect each other, for instance, combined with one of your friends having Googled the stuff you were talking about.

Or just basic data collection. There's the classic story about how supermarkets know you're pregnant before you do, just based on the groceries you buy (no, not pregnancy tests). Ad networks buy and collect a humongous amount of information about everyone and serve ultra specific targeted ads based on nothing more than pattern matching based on what the rest of humanity is doing.

It's impossible to rule out that the thing did run a 24/7 TTS service, but I think the depressing fact that ad networks don't need to listen to our conversations to know what we're talking about is more probable.

Some are friends with politicians

No need for more regulation, is there? A company used its infrastructure to orchestrate a cyber attack. Arrest the people running the company.

If you make money trying to resell Google's free services and data, this is a disaster.

As a regular user, it's a minor annoyance.

These days with cryptenroll and friends, using the TPM is hardly an issue anymore. LVM and swapfiles both work well if you just create one large "everything but EFI" encrypted volume.

You'd need to keep secure boot on, preferably with your own keys loaded, to get all of the benefits, and that's a bit harder to automate.

Windows does all of this and more. It's harder on Linux because of a lack of tooling/interest/business incentives, and because on average Linux users want more control over their hardware than Windows users.

Swapfiles on BTRFS seem to work great if you allocate them early (with the command linked in your article) and put them in a different subvolume than the rest of your system.

BTRFS in general seems more I/O constrained than ext4 or xfs so it's probably still worse to put a swapfile on a BTRFS partition, but so far my systems are doing fine.

Windows also does a neat trick Linux lacks: automatically adding more swap, up to a limit. Systems with loads of RAM barely lose any storage to swap, but once they do get hit, they can get many gigabytes of swap space without user interaction. I believe macOS does it too, of course.

I'm sure there are many reasons why Linux can't do that by default, but it's a real shame.

What reason would your professor have to have you take it down, at least past your due date? One could claim copyright on the project itself if you shared the files, or if you kept the original framework a course might provide, but the work you did is yours.

It's not like heap allocators are hard to come by, there's one right there in the Linux source code.

I've had plenty of courses where professors were afraid of answer sheets leaking out because they intended to use the exact same tests and practicals the year after. Those were always the courses where someone had a copy of last year's answers that was passed around between groups of students. You can't rely on secrecy to save yourself from having to come up with different tests if you hand out a piece of paper to 50 or even 300 people.

There's quite a difference between stealing a loaf of bread and making a career out of fraud to pay your way through college.

Of course, this type of fraud is legal for the one doing the work, so even on that front the comparison doesn't really work.

Beats scamming old people out of their retirement money, I guess, but not exactly a job that people will feel bad about disappearing.

Your link is explaining an addendum on the link OP posted.

My guess is that OP got their account flagged as being a minor and posted the link in either surprise or (understandable) outrage after finding out that Claude has been asking people for ID.

The usual read on cybersecurity determines how bad an issue is using (something akin to) impact on confidentiality, integrity, and availability.

Being able to freeze a computer from the browser is a plain availability risk. It's not exactly a high-priority risk, but still something that should be considered a risk in my opinion.

With operating systems like macOS+Safari reopening a page after reboot, a malware domain can claim to take your computer hostage by te-freezing the PC every time the user moves away from the page until money is paid. People already fall for "we have hacked your computer pay X bitcoin to get it back", this just adds to that.

According to the comments here, this has been a thing for ages, so I kind of doubt that they'll fix it this time. But fingers crossed!

Pixel 9 Pro with Brave, it just sort of freezes for a second or two before I can close the tab using the normal brave button.

Wonder what made the difference. I must've disabled some shady JS attack surface at some point.

You could probably make a pretty believable virus page with this. First you freeze the screen, forcing the user to force reboot. Then, when the system boots again and reopens the website (at least Safari does), you go full-screen and show a "your computer froze because of a virus" screen.

Making the user force-reboot the computer would make the usual fake AV shtick a lot more believable.

"May 18, 2026" is right there next to the title. Nothing changed.

println!() already works, who needs more than that?

Kidding aside, VS Code has excellent debugging support already. Unless you need to share your Rust code base with a legacy C/C++ code base, I don't think VS is the best environment for Rust programming.

There are good use cases for staying within full-fat VS's capability set (drivers, among other things), but I don't think Microsoft needs to add Rust to VS in this much of a hurry.

I don't think "European children will look at the map and feel less significant" is a carefully neutral observation. It's an assumption that European children feel superiority because their country is slightly bigger.

If anything, I expect the accurate sizes set the stage for feeling superiority over their ancestors colonizing huge lands while coming from tiny countries.

If we're talking about kids, they should just get taught this type of geography using a globe. You can get an accurate (enough) inflatable globe for like 3 euros, including shipping.