ryannielsen

"While [Apple Support] can answer your questions about the account recovery process, we can't verify your identity or expedite the process in any way."

Even if you manage to confuse a support agent, they cannot do anything to speed account recovery or be socially engineered into account compromise.

https://support.apple.com/en-us/HT204921

Not for users who've opted into two-factor authentication: https://support.apple.com/en-us/HT204915

From the page:

Do I still need to remember any security questions?

No. With two-factor authentication, you don't need to choose or remember any security questions. Your identity is verified exclusively using your password and verification codes sent to your devices and trusted phone numbers. When you enroll in two-factor authentication, we will keep your old security questions on file for two weeks in case you need to return your account to its previous security settings. After that, they will be deleted.

Point of clarification: only Apple-signed installers can modify system paths. (c.f. https://support.apple.com/en-us/HT204899) All other installers are subject to SIP restrictions.

And Apple only added a few simple steps for people eager to tinker: reboot and disable SIP. Or reboot into the installer for the other OS with which you prefer to tinker. Or create a VM with an experimental OS. Frankly, most of those steps existed before SIP.

Most users shouldn't care or notice, and will benefit from increased protection. People who want to tinker will (and can and should!) tinker.

It seems the apocalypse came to pass a while back, with the Secure Enclave in Apple's A7 processors.

> Of course, they know how to disable the restrictions or install a jailbreak, so these problems don't apply to the technological priesthood - it's normal people that have to live with the restrictions.

Here's the funny thing: normal people benefit from those restrictions. Without them, their devices – the ones you insist they should own – would quickly become someone else's: the attacker's. It would be awesome if people started thinking about long-term consequences.

Honest question: do you hate root? Should all processes run with equal privileges? Does the kernel have an evil and undesired permissions level?

Very few people should ever need to disable SIP – and that includes almost all developers! Are you building/running unsigned kexts? No? Then you almost certainly don't need to disable SIP.

Most instructions that no longer work with SIP enabled should be modified so they don't conflict with SIP. As a bonus: changes resulting from those instructions are far more likely to be preserved across OS X upgrades.

Malware can only introspect SIP-protected activity by employing kernel exploits. If malware can compromise the kernel, it's game over. You're not going to hide anything, ever.

If anything, it sounds like you want SIP's purview expanded to encompass more of OS X.

Don't forget to weigh those other two factors when judging https adoption. Your goals are understandable and worthwhile. They're also still achievable with appropriate client management software.

Consider this: in a world without https, your children could visit a valid, approved domain and be served malicious or undesirable content because someone modified the content in flight or intercepted the connection. There is literally no way for you to have any guarantee what's served to your children.

In a world with https (and appropriate client management software), you can be confident they really are only receiving approved content because the connection is authenticated and traffic cannot be modified in flight. (And your children are less easily tracked by unknown 3rd parties, to boot.)

Authentication and integrity are often forgotten when discussing https, which is unfortunate because those are two incredibly important benefits that further motivate widespread https deployment.

https://developer.apple.com/library/Mac/qa/qa1176/_index.htm...

  OS 5 added a remote virtual interface (RVI) facility that lets
  you use OS X packet trace programs to capture traces from an
  iOS device. The basic strategy is:
  
  1. Connect your iOS device to your Mac via USB.
  
  2. Set up an RVI for that device. This creates a virtual
  network interface on your Mac that represents the iOS device's
  networking stack.
  
  3. Run your OS X packet trace program, and point it at the RVI
  created in the previous step.

Anything distributed through the App Store is signed by Apple. Developer ID signed binaries can only be distributed outside of the store.

Please, state a cogent argument otherwise.

Potentially nothing, but it is all anecdotal. Where's the widespread or researched evidence of HFS (especially in its HFS+ or HFSX variants) being a slow and easily corruptible file system?

It's not like HFS is a rare and infrequently used file system – it's the primary filesystem for all Macs since System 3, for many iPods, and for all iOS devices.

The scaling limits present in HFS+ will rarely be hit by most users and, while not as resilient as more modern FSs, there are no inherent fatal design flaws with HFS that I'm aware of. Perhaps you've pushed HFS+ beyond its limits, or have usage patterns that trigger a rare fatal bug, but just claiming that something is true is not very productive either.

It's fundamentally not a cache. If it were a cache, Fusion Drive would not increase the total storage space. Anandtech[1] seems to confirm this, noting that Fusion Drive creates a 4GB write buffer on the SSD and all read operations will influence a pinning algorithm which will move, not cache, frequently accessed files from the HDD onto the SSD.

ReadyBoost is exactly a cache, as is ZFS's ARC and L2ARC.

Now then, regarding the statement you question… yes, it is incorrect. ReadyBoost and L2ARC are pre-existing examples of "hybrid models of blending SSD and mechanical disks" that "integrate with the OS" and do so quite intelligently. You are correct to call out that statement. But it really does appear that Fusion Drive is not a cache, but a true unioning of SSDs and HDDs managed by the OS to ensure hot files are on the SSD whenever possible.

[1] http://www.anandtech.com/show/6406/understanding-apples-fusi...

That's an assumption we've yet to see confirmed, and I suspect is incorrect. I doubt every single file that's read will migrate to the SDD. Rather, I expect only files frequently read will migrate to the SDD. Effectively, the SDD will largely be a write cache (but likely only for files written atomically) and a read cache for frequently accessed files.

That behavior would largely sidestep your concerns.

(And, actually, files that are readily streamed, like videos, aren't necessarily files you'd want to store on the SDD. Those can often – though, yes, not always – be read quite quickly from the HDD. Unless you're dealing with truly huge files, or actively editing a video, you don't need SDD throughput.)

Yep. Not dead, not by any stretch of the imagination, but certainly not as ubiquitous as other devices.

http://blog.seattlepi.com/microsoft/2010/06/02/steve-jobs-at...