nebulous1

Blackmail to gain what? Speedy update to the site? The OP is going to disclose the vulnerability. The only matter up for debate is the timing.

I read that entire article thinking it said driving instructor. Doesn't really change anything but it makes so much more sense that he's a part time diving instructor.

Their Oura comparison really didn't sit well with me because of that. The device clearly uses a fraction of the power that the Oura is using. If it had a rechargeable battery you would not have to charge it that frequently.

That lifespan is based on the user recording for 12 to 15 hours over those two years. It's a $100 device that can record 12 hours of audio and then you throw it away. You could expend the battery on your first day by holding down the button.

Honestly I can see a niche use but this device strikes me as quite weird and I'm not sure why it isn't a button on their new watch.

How come?

> "ah, you hesitated" no more so than on every single other question.

It was longer. I think almost twice as long. Took about 2 seconds to respond generally, 4 seconds for that one.

The issue with most of what you're saying here is that all of that works the way it does because it can, not because it has to. Code libraries, for example, may essentially prohibit what is being requested by SKG because they can. However, if they couldn't then they wouldn't. The companies selling the libraries aren't going to simply shut up shop.

Which is just to say, if there's money to be made then businesses will do so within the regulatory framework.

I agree, but in this banking apps (around me) use the Integrity API anyway.

> showdead enabled

Thanks, I didn't know this was something we could turn off. Although it does feel like they could just default to collapsed too.

Right. The title seemed to be suggesting that the Nix way of doing things might have detected the backdoor. It's actually intending to suggest ways that Nix could be changed in order to detect the backdoor.

$100 profit on a $150 watch would be crazy. Rest of the post seems made up too. I don't know where these numbers are coming from. I'm genuinely confused.

Thanks!

So, in the situation in the comment OP, with sychronized writes and and unsynchronized reads, what is this "happens before" stipulation prohibiting?

Thanks. So the structure in the OP is an array of uint32s.

> that unsynchronized reads of a uint64 will return some previous valid write, it doesn't guarantee anything about which value is returned

Your the second person saying this, so is my interpretation that this is dissallowed by the part that you quoted incorrect?

> must observe some write w such that r does not happen before w and there is no write w' such that w happens before w' and w' happens before r

edit: somebody is answering this below by the way