Cryptographic analysis from ETH Zurich researchers Jonas Hofmann and Kien Tuong Turong revealed issue with Sync, pCloud, Icedrive, Seafile, and Tresorit services, collectively used by more than 22 million people. The analysis was based on the threat model of an attacker controlling a malicious server that can read, modify, and inject data at will, which is realistic for nation-state actors and sophisticated hackers.

Interesting stuff, but it’s worth noting the scope and circumstances.

I think of that like putting multiple things in the same basket, but putting two locks on that basket.

I’m not evaluating whether or not you should do that, but, assuming you trust your partner and their op sec, you could send them the secret via a disappearing message on Signal or some other E2E encrypted communication method.

You set it up on your key, they add it to theirs later, the secret disappears into the ether.

All it takes to sync TOTP is to manually set up the secrets on all keys.

Keeping a second factor in a password manager makes it a single factor, doesn’t it?

[feverishly applauds]

Looks perfect to me!

It’s a very different vibe. I remember my first seg fault in C - kids days are missing out!

The cool thing to do now is to write it in Rust, only using the standard library.

[checks personal website]

Yes, shame on them!

Measure once, cut 38 times.

Chances are, right? At least it’s the first thing I’d check.

I’m pretty happy I never got around to RMAing my Zotac graphics card for its whiny fan.

Steve mentions “server configuration,” but I can’t even imagine what that would be.

Yes! Hahaha, it’s so good.

Number 2 needs to flick the little switch on the SD card.

[flashbacks to the backlog being wiped out because “the client already signed off on the release”]

Wasn’t there a story about people calling curl devs because of car issues?

For what it’s worth, I’m sure the SQLite devs could help somebody clean up their temp files. They just really shouldn’t have to.

I think we’re fully in agreement here: if the API doesn’t specify how to handle null values, that omission means they’re perfectly valid and expected.

Imagine a delivery company’s van exploding if somebody attempts to ship an empty box. That would be a very poorly built van.

That’s the thing though, isn’t it? The devs on either side are entering into a contract (the API) that addresses this issue, even if by omission. Whoever breaks the contract must rightfully be ejected into the stratosphere.

Thanks for the transcription!

Surely Java can tell the difference between a key with a null value and the absence of that key, no?

I mean, you can set up your deserialization to handle nulls in different ways, but a string to object dictionary would capture this, right?

Because they didn’t want to train their JS developers and didn’t want to cause friction for new projects. They get to say they’re using TS, with basically none of the real advantages. (Apart from general rational error checking.)

Yes, but did you get the job?

Also props for the image description.