Objective Development (Hacker News):
Third party developers can now bundle their apps with an Internet Access Policy file containing descriptions of all network connections that are possibly triggered by their app. Little Snitch will then display that information to users, helping them in their decision how to handle a particular connection. A description of the policy file format will be provided soon.
[…]
The network filter now performs Deep Packet Inspection instead of the previous IP address based filtering. This results in much more precise filter matching, especially in those cases where one and the same IP address is possibly associated with multiple hostnames (e.g. google.com vs. googleanalytics.com)
[…]
The code signature of the connecting processes is now taken into account. If a rule was created for a process with a valid code signature, that rule will no longer match if the signature changes or becomes invalid. This prevents malicious software from hijacking existing rules.
[…]
To avoid a vast numbers of connection alerts from appearing when using common macOS and iCloud services, Little Snitch now provides preconfigured rulesets for these usage areas.
Sounds awesome. It is compatible with macOS 10.13 if you use the new option in System Preferences to allow the kernel extension to load. Previously, kernel extensions just had to be signed using a special key that you apply for. Going forward, Apple is deprecating kernel extensions, so hopefully they will be adding an extension point so that utilities like Little Snitch can continue to work. If you want to do novel things with the kernel that Apple hasn’t pre-planned for, it sounds like you’ll be out of luck.
Update (2017-06-29): See also: Little Snitch and Possible Deprecation of NKEs.
Kernel Extensions Little Snitch Mac Mac App macOS 10.12 Sierra macOS 10.13 High Sierra Networking Privacy
Henrique de Moraes Holschuh:
This advisory is about a processor/microcode defect recently identified
on Intel Skylake and Intel Kaby Lake processors with hyper-threading
enabled. This defect can, when triggered, cause unpredictable system
behavior: it could cause spurious errors, such as application and system
misbehavior, data corruption, and data loss.
It was brought to the attention of the Debian project that this defect
is known to directly affect some Debian stable users (refer to the end
of this advisory for details), thus this advisory.
Please note that the defect can potentially affect any operating system
(it is not restricted to Debian, and it is not restricted to Linux-based
systems). It can be either avoided (by disabling hyper-threading), or
fixed (by updating the processor microcode).
Due to the difficult detection of potentially affected software, and the
unpredictable nature of the defect, all users of the affected Intel
processors are strongly urged to take action as recommended by this
advisory.
Via Tom Harrington:
Check your Mac CPU with “sysctl machdep.cpu” and compare to this. [Skylake list, Kaby Lake list]
Developers who are concerned can use Instruments to disable hyperthreading until reboot. See Instruments prefs.
Unfortunately, the “Hardware Multi-Threading” setting in Instruments does not persist after the Mac reboots or sleeps, so you have to keep re-applying it. The good news is that Apple should be able to offer a software update that applies Intel’s microcode patch.
Update (2017-07-05): Xavier Leroy (via Hacker News):
Late April 2016, shortly after OCaml 4.03.0 was released, a Serious Industrial OCaml User (SIOU) contacted me privately with bad news: one of their applications, written in OCaml and compiled with OCaml 4.03.0, was crashing randomly. Not at every run, but once in a while it would segfault, at different places within the code. Moreover, the crashes were only observed on their most recent computers, those running Intel Skylake processors.
[…]
SIOU didn’t take my suggestions well, arguing (correctly) that they were running other CPU- and memory-intensive tests on their Skylake machines and only the ones written in OCaml would crash. Clearly, they thought their hardware was perfect and the bug was in my software. Great. I still managed to cajole them into running a memory test, which came back clean, but my suggestion about turning HT off was ignored. (Too bad, because this would have saved us much time.)
Update (2017-12-28): I contacted Apple in early August and was told that the bug would be addressed in High Sierra. However, as of macOS 10.13.2 there is no update for the processors. Mine still shows:
machdep.cpu.brand_string: Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
machdep.cpu.family: 6
machdep.cpu.model: 158
machdep.cpu.extmodel: 9
machdep.cpu.extfamily: 0
machdep.cpu.stepping: 9
machdep.cpu.signature: 591593
machdep.cpu.microcode_version: 88
I spent a couple weeks in December going back and forth with Apple’s support people, trying to get an answer. None of the advisors had even heard of the bug. Eventually, a senior advisor escalated the issue to engineering. The engineer confirmed that Apple is aware of the bug but does not yet have a fix. They will not say when or even if Apple will ship a fix. Apple’s policy is not to comment on unreleased products.
Looking at Intel’s spec sheet, it appears that KBL095/KBW095 were not fixed as of August, so perhaps Apple is waiting on Intel for the Kaby Lake fix. (Intel has had an update for Skylake CPUs since at least June, but it’s not clear to me whether Apple has shipped it.)
For now, Apple recommends keeping hyper-threading turned off to prevent data corruption. This can be done by unchecking the “Preferences ‣ CPU ‣ Hardware Multi-Threading” setting in Instruments. Unfortunately, this setting is not preserved if you sleep or restart your Mac. Apple confirmed that there is no way to make the setting stick. (Years ago, the nvram command could be used.)
My recommendation is to set the Mac not to sleep the CPU and to add Instruments as a login item so that you remember to disable hyper-threading when your Mac starts up.
It’s not clear to me whether the Xeon W processors in the iMac Pro are affected.
See also: ArsTechnica, Hacker News, MacRumors, OCaml Mantis, Reddit, StackExchange.
Bug Compiler iMac iMac Pro Instruments Intel Mac macOS 10.12 Sierra macOS 10.13 High Sierra OCaml Processors
The iOS transition to APFS seems to have gone very smoothly except for some Unicode normalization issues. Apple never really explained to developers how they could make their code work properly, most were not aware that there were issues at all, and the necessary app modifications were difficult to develop and fully test. In my view, pushing this responsibility onto apps was a recipe for endless obscure bugs and poor performance.
At WWDC 2017, Apple essentially admitted that they had made a mistake and told us how they are going to fix it. There is a short-term fix and also a long-term fix that will require another file system conversion. This is not yet documented in the APFS Guide, but here’s a summary of the different cases:
The default for macOS 10.13 will be case-insensitive APFS. It is normalization-preserving (unlike HFS+) but not normalization-sensitive. I expect this to be highly compatible with existing Mac apps. The main difference is that when you read filenames they are no longer necessarily in Form D, but you shouldn’t have been relying on that, anyway.
macOS 10.13 will also support case-sensitive APFS, which will use native normalization. This is new in the developer beta. The filenames are still stored in the same way as prior APFS (not normalized like with HFS+), but APFS now uses normalization-insensitive hashes so that it can quickly and transparently find files without knowing their normalizations. If your code worked with case-sensitive HFS+ and works with case-insensitive APFS, there’s likely nothing new that you have to do for this case.
iOS 10.3 through 10.3.2 use the problematic version of APFS that is case-sensitive, normalization-preserving, and normalization-sensitive. You can write a lot of app code to make everything work, but anyone who hasn’t done this already probably won’t.
iOS 10.3.3 and iOS 11 will also be case-sensitive, normalization-preserving, and normalization-sensitive, but they will add runtime normalization. If you try to read a file but don’t have the right normalization in your path, the file system APIs will transparently look for the file using other normalizations. This should give the correct behavior but at a performance cost.
If you get a new device or erase and restore, iOS 11 will use case-sensitive APFS with native normalization. This is what Apple should have done from the start. It should have basically the same user experience as with HFS+ but with better performance.
An unspecified future update will convert iOS devices using the “bad” APFS to case-sensitive with native normalization, thus completing the fix.
Update (2017-12-14): Despite the native normalization, I’m seeing problems with Git and accented filenames on macOS 10.13.2. If I edit a file with such a name, Git sees it as a new file, and therefore sees two files whose names differ only in normalization. It’s somewhat tricky to then remove the original entry.
Apple File System (APFS) File System Git iOS iOS 10 iOS 11 Mac macOS 10.13 High Sierra Programming Unicode WWDC
Mark Bergen (via John Gruber, tweet, MacRumors):
Google is stopping one of the most controversial advertising formats: ads inside Gmail that scan users’ email contents. The decision didn’t come from Google’s ad team, but from its cloud unit, which is angling to sign up more corporate customers.
[…]
Ads will continue to appear inside the free version of Gmail, as promoted messages. But instead of scanning a user’s email, the ads will now be targeted with other personal information Google already pulls from sources such as search and YouTube. Ads based on scanned email messages drew lawsuits and some of the most strident criticism the company faced in its early years, but offered marketers a much more targeted way to reach consumers.
Advertising E-mail Gmail Privacy Web
