It’s part of dumpster fire that is the DMTF ecosystem. Attempting to understand it if you haven’t been exposed to Windows enterprise bullshit is futile. It’s layers upon layers of meta XML to do the most mundane things in the most overcomplicated way without actually succeeding at making any usable standard.
Or, in other words: if you reaction to SOAP was “damn, this is amazing, we need more of this but with even more indirection”, you’ll feel right at home.
This is one reason I stay the hell away from Windows focused software on Linux. There’s a complete impedance mismatch. Also MSFT’s GitHub open source fairy dust project stewardship is a shit show from experience.
> because it's easier to lie and say you already had COVID, and there's a bunch of people who'd probably do so.
It's not actually. They're equivalent. The vaccine proof is PAPER which can be forged. And while evidence of a COVID19 test can be paper too, mine was digital.
It's why I said "at least theoretically" -- the vaccine cards have a date and vaccine lot number on them. I'm making the assumption that this has been recorded somewhere, such that you could at least check that a certain batch was administered on a certain day to a certain person.
Of course, this could all fail under the "medical records in the USA are garbage" issue.
Still, if nothing else, it's better for proving it than "I took a COVID test at home, trust me".
The NY Times [1] just reported that "Apple’s security team has been working around the clock to develop a fix since Tuesday, after researchers at Citizen Lab, a cybersecurity watchdog organization at the University of Toronto, discovered that a Saudi activist’s iPhone had been infected with spyware from NSO Group."
What took so long? Did Apple not know about this in March or was someone sitting on it for 6 months?
“Citizen Lab forwarded the artifacts to Apple on Tuesday September 7.” — from article, no need to jump to unwarranted conclusions about Apple. “In March 2021, we examined the phone of a Saudi activist” - it would be interesting to know the reason why Citizen Lab delayed so long. Hopefully they just wanted time to discover who else was being targeted?
> In March 2021, we examined the phone of a Saudi activist who has chosen to remain anonymous, and determined that they had been hacked with NSO Group’s Pegasus spyware. During the course of the analysis we obtained an iTunes backup of the device.
> Recent re-analysis of the backup yielded several files with the “.gif” extension in Library/SMS/Attachments that we determined were sent to the phone immediately before it was hacked with NSO Group’s Pegasus spyware.
Seems like they originally examined the phone in March, but recently did another analysis, during the course of which they discovered the exploit and reported it to Apple.
I assume it takes time to go from "this person could have potentially been targeted with Pegasus" to "this person's iPhone was exploited by Pegasus, and here is how they did it."
Why did this take so long? The alternate thread pointing at the citizenlab report [1] says that "In March 2021, we examined... and determined that they had been hacked"
It's September. The NYTimes says: "Apple’s security team has been working around the clock to develop a fix since Tuesday, after researchers at Citizen Lab, a cybersecurity watchdog organization at the University of Toronto, discovered that a Saudi activist’s iPhone had been infected with spyware from NSO Group."
So has Apple been sitting on this since March, or has CitizenLab?
As the story clearly indicates, they re-examined backups and recently made a very valuable discovery that everyone should be extremely thankful for. And Apple turned around a worldwide patch for a billion plus devices in less than a week after being notified.
I'd rather the flaw wasn't there in the first place, but a remarkable effort by both parties given that it was there.
Maybe the fearmongers are right, and we've truly reached a post-privacy world. Frankly, I don't know how else you'd describe it: your phone, smartwatch or computer can all be silently hacked without your knowledge (or any easy way to verify that you're infected). You can't visualize or control how your personal data is propagated, and the cherry on top is that it's all a laissez-faire exploit carnival. I don't know if it's fair to call Apple culpable here, but it is fair to say that your phone (and data) is at risk.
The editor is very slick. Where does the 'graph theory' part come into this though? As so far, all I've done is create some vertices and group them by 'bags'. Note that I'm a math theory novice
On the left side there are some tools for running algorithms on the graph. some are not implemented yet. But for example the "play" icons allows you to run djikstra or topological sort algorithm.
I have heard this phrase (daily bread) compared to the story of God providing manna (something flaky, often compared to flour & bread) for food in Exodus 16. In that story, the Israelites were instructed to only collect the manna for each day. If they tried to keep some for the second day, it would become rotten. This meant they were reliant on God's provision each day.
In the same way, this prayer may be about provision of bread enough for today, of sufficient/satisfactory quantity, no more than we need (per Exodus), just what we need right now. You'd obviously then want to pray this each day, and rely on God's provision daily. So daily isn't a transliteral interpretation but more a descriptive one
> I don't know a single engineer that has read the report that disagrees with its findings.
Just want to point out that the document that OP linked claims in the conclusion that the NIST report is invalid, but I have no ability to judge that claim. I have no structural engineering knowledge and have never heard of either of these reports until now.
This was published March 2020 though, and I'd be curious if the analysis was cogent enough to warrant NIST's response in a few years
The only recent commit was for "Enhanced security" a month ago:
https://github.com/microsoft/omi/commit/4ce2cf1cb0aa656b8eb9...