Apple (via Vivian):
Setting a firmware password in OS X prevents your Mac from starting up from any device other than the built in hard drive. Locking your Mac from Find My Mac also sets a firmware password that you’ll then need to enter in order to use your Mac.
If you don’t set a firmware password, someone can boot the Mac into Recovery Mode and reset the password on your main partition. This would allow access to all unencrypted (i.e. non-Keychain) data. However, the firmware password isn’t that secure because Apple can bypass it. Plus, the drive could be physically removed from your Mac and attached to a different Mac. So, if you want to prevent access to your data, it’s better to use FileVault. The firmware password only prevents your Mac from being booted without access to your data, which probably doesn’t matter much.
FileVault Mac macOS Recovery Passwords Privacy Security
Graham Lee:
OK, if everything succeeds you can use the Maybe result (which will be Just the value) as if it is the value itself.
[…]
The other case is that your operation failed, so we need to represent that. We need to know what type of object you don’t have(!), which will be useful because we can then treat the lack of value as if it is an instance of the value. How will this work? In None, the no-value version of a Maybe, we’ll just absorb every message you send.
[…]
The NSError-star-star convention lets you compose possibly-failing messages and find out either that it succeeded, or where it went wrong. But it doesn’t encapsulate what would have happened had it gone right, so you can’t just rewind time to where things failed and try again. It is possible to do so, simply by encapsulating the idea that something might work…maybe.
Message Passing NSError Objective-C Programming
Natasha Murashev:
Here is a scenario – you need to do something in your code based on whether an optional value exists or not, but the thing you need to do does not need to actually use the optional value.
[…]
This immediately stood out as “wrong” to me. By now, I’m very well trained to unwrap optionals all the time, so having a != nil just feels wrong in Swift. Also, I don’t like the != here – I had to do a double take to realize that this code executes if something is actually there, so to me, it’s also not as readable. Of course, this code works and is completely “correct” for the situation, if that’s what you prefer.
David Owens II:
It just doesn’t feel semantically correct. The optional is not nil, it specifically
has a value of None. I’ve never liked this syntax; I’ve talked about it before - thankfully the bool
comparison has been lost, but the nil check still sits wrong with me.
Language Design Programming Swift Programming Language
Lorenzo Franceschi-Bicchierai (via Nick Heer):
Apple has long maintained that conversations over iMessage and FaceTime use end-to-end encryption, meaning “no one but the sender and receiver can see or read them,” as the company said after the PRISM revelations. That claim has turned out to be partly true: normally, Apple can’t read your iMessages, but they can if they really want to.
[…]
We asked Google to clarify, or elaborate, on Monday, and a spokesperson confirmed that Hangouts doesn’t use end-to-end encryption. That makes it technically possible for Google to wiretap conversations at the request of law enforcement agents, even when you turn on the “off the record” feature, which actually only prevents the chat conversations from appearing in your history—it doesn’t provide extra encryption or security.
FaceTime Google Google Hangouts iMessage iOS Mac Privacy Security Web
