clinton_sf
Joined 13 years ago
Karma
41
Submissions
39
Member since
Aug 21
Recent submissions
Comment · 10 years ago
Yes. And the malware could be polymorphic. Or there could be multiple versions of the same "core" out there. It's not clear to me how sophisticated virus (malware) scanners for OS X are with dealing with that.
Comment · 10 years ago
> Is there any diagnostic tool out there to determine if you've been infected?
From what I can tell, they posted the SHA256 of the offending binary under the IOCs section of that web page. So you should be able to do this in the root of your home directory to detect if such a file exists:
# find . -type f -print0 | xargs -0 shasum -a 256 | grep 664e0a048f61a76145b55d1f1a5714606953d69edccec5228017eb546049dc8c
Comment · 10 years ago
Thought experiment: let's say that Apple doesn't know what the suspect in a law enforcement investigation is suspected of. If the request is between revealing the identity of a user from a particular IP address (which is probably easy for them to determine), or giving away (essentially) a master key to decrypt all iPhones, which would it comply with? I think it would have complied with revealing the identity of a user pretty much every time, even if the suspect was a terrorist, but not necessarily to give away the master key for all iPhones even if the suspect was an intellectual property pirate.
Comment · 10 years ago
Comment · 10 years ago
Maybe it is a coincidence being posted on HN 7 months after the article was written, but the NY Post article is a great commentary on what is in the news these days:
https://en.wikipedia.org/wiki/FBI%E2%80%93Apple_encryption_d...
Comment · 10 years ago
Duplicate of https://news.ycombinator.com/item?id=11275505
Comment · 10 years ago
Take a look at Jocelyn Goldfein's software engineering career ladder chart:
https://medium.com/@jocelyngoldfein/a-very-very-rough-approx...
Comment · 11 years ago
I actually don't see a problem with Apple's MFi program. Back in 2013, a woman in China was electrocuted by her iPhone 4 due to a non-OEM charger:
http://www.scmp.com/news/china/article/1283818/woman-electro...
To quote from the article: “Knockoff chargers sometimes cut corners,” Xiang said. “The quality of the capacitor and circuit protector may not be good, and this may lead to the capacitor breaking down and sending 220 volts of electricity directly into the cell phone battery.”
Apple trying to enforce its quality standards on the charging system seems completely reasonable -- yes, even if it means that the end-user has to pay for the quality. Most Apple customers are actually looking for that quality and willing to pay for it.
There is a great teardown analysis of Apple and knock-off chargers at Ken Shirriff's blog:
http://www.righto.com/2014/05/a-look-inside-ipad-chargers-pr...
http://www.righto.com/2012/05/apple-iphone-charger-teardown-...
Comment · 12 years ago
This approach solves a few problems:
1. Apps in the Mac App Store can't ship their own kernel extensions along with the app. With the framework, it may not be necessary for virtualization products to do that -- enabling them to ship in the Mac App Store.
2. Compatibility breaks between OS version updates. Every time the kernel interface changes, someone shipping a kernel extension will need to ship an update as well. With this approach, it's possible to keep compatibility and let the implementation of the framework do all the heavy lifting.
3. If virtualization products are going to be in the kernel in order to run, it would be better for the host OS vendor to supply official supported interfaces instead.
Just as Intel is making it easier to do virtualization on their chips with VT-x and VT-d, Apple is making it easier to implement virtualization with Mac OS X as a host with this framework.
Comment · 12 years ago
While it may not be covered under FDIC, Federal Regulation E might come into play here, according to this research paper:
Is Everything We Know About Password-Stealing Wrong? http://research.microsoft.com/pubs/161829/EverythingWeKnow.p...
"Federal Reserve Regulation E guarantees that US consumers are made whole when their bank passwords are stolen. The implications lead us to several interesting conclusions. First, emptying accounts is extremely hard: transferring money in a way that is irreversible can generally only be done in a way that cannot later be repudiated. Since password-enabled transfers can always be repudiated this explains the importance of mules, who accept bad transfers and initiate good ones. This suggests that it is the mule accounts rather than those of victims that are pillaged. We argue that passwords are not the bottle-neck, and are but one, and by no means the most important, ingredient in the cybercrime value chain. We show that, in spite of appearances, password-stealing is a bad business proposition."
Comment · 12 years ago
I don't think this is Apple trying to be difficult: SSD TRIM is buggy between all the different vendors (today even Ubuntu enables it only for Samsung and Intel SSDs by default), they want to guarantee that it works by whitelisting what they ship with, and the mandatory driver signing seems like a security improvement. If some third party wants to ship a signed kernel extension that works with their specific SSD (or generic ones, even) and supports TRIM, that should be possible.
FWIW, there is a third party SSD drive that works with Apple's default drivers for TRIM support; I suspect they're doing some sort of identifier spoof to fool the whitelisting code: http://www.angelbird.com/en/prod/ssd-wrk-for-mac-929/