Yael Grauer:
Sarahah bills itself as a way to “receive honest feedback” from friends and employees. But the app is collecting more than just feedback messages. When launched for the first time, it immediately harvests and uploads all phone numbers and email addresses in your address book. Although Sarahah does in some cases ask for permission to access contacts, it does not disclose that it uploads such data, nor does it seem to make any functional use of the information.
[…]
After this piece was published, the app’s creator, Zain al-Abidin Tawfiq, tweeted that the contacts functionality would be removed in a future release and had been intended for a “‘find your friends’ feature.” He later told The Intercept the feature was stymied by “technical issues” and that a partner, who he has since stopped working with, was supposed to remove it from the app but “missed that.” He claims the functionality was, however, removed from the server and that Sarahah stores no contacts in its databases. This is impossible to verify.
Contacts iOS iOS 10 iOS App Privacy Sarahah
Rich Mogull:
What exactly is the security weakness TLS 1.3 eliminates? – Version 1.3 eliminates support for an older way of setting up encrypted connections using a master key. It could enable someone with a copy of the master key to sniff all encrypted traffic. They could also decrypt any previously recorded traffic protected with that key. The proposed updates to TLS use a different key for every connection, so there is no master key which could allow unrestricted monitoring. We call this Perfect Forward Secrecy, if you want to look it up.
This is a pretty big weakness, which has been used in attacks. Unfortunately it’s also used by legitimate security tools for more efficient monitoring.
[…]
TLS 1.2 is still completely supported and will be for a long time. As online services start adopting TLS 1.3, organizations which rely on passive sniffing of encrypted connections may start losing visibility into those connections. Organizations which want to maintain this visibility will need to update their tools and techniques.
Networking Security SSL/TLS Web
Chris Adamson:
In all these cases, you have to provide the object with its delegate (or target) at initialization time. And that leads to a terrible head-scratcher. What do you do if you want to use one of these objects as a property, but also use self as the delegate?
Swift won’t let you easily do this.
[…]
The point of the lazy variable is that it won’t be assigned until its needed. Which in turn means that it can’t be accessed until self exists, because otherwise there’s no way to access it. Therefore, it’s always OK to reference self when assigning a lazy variable.
I understand the reasoning behind Swift’s rules for two-phase initialization and where you can access self. But in practice they introduce extra work and code ugliness in order to prevent a class of problems that I don’t think I’ve ever had. lazy variables are the best solution I’ve found for the issue that Adamson mentions. In fact, lazy variables are pretty cool in general, although beware that their initialization is not thread-safe.
The other main issue I run into with initialization is that you can’t call helper methods before calling super.init(). This is not an issue in Objective-C because, there, calling [super init] is the first thing you do. But in Swift you have to initialize all of your properties before calling super.init(). Implicitly-unwrapped optionals are the obvious, easy solution. Otherwise, you would need to move helper code from instance methods to static functions or a separate helper object or, in some cases, completely restructure your code if you need to access state or functionality from the superclass.
Update (2017-08-31): One of the issues that neither lazy nor IUOs solve is that you may end up needing to make the property var instead of let, even though you have no intention of modifying it once set. You can partially mitigate this by marking the property private(set). However, that adds yet more verbosity and doesn’t as obviously protect against concurrent access the way let does.
Regarding lazy and concurrency, Heath Borders writes:
I just use another computed property that wraps the lazy var in a Dispatch.sync over a private queue, then I never touch the lazy var.
Update (2017-09-01): Another issue with IUOs is the way they work with type inference. If you assign an IUO to a temporary variable, the inferred type is an optional. This means that you have to either force unwrap when assigning to the temporary or at each use of the temporary. So the IUO has leaked outside of its class. One way around this is to create two properties in the class. The first is a private var of type T!. The second is a computed property of type T that returns the first property (implicitly) unwrapped. Then clients of the class can use the computed property and not have to deal with unwrapping.
Previously:
Concurrency Language Design Programming Swift Programming Language
Mike Ash:
Swift 3 works by essentially automating Objective-C’s NSError convention. The compiler inserts an extra, hidden parameter which is essentially Error *, or NSError **. Throwing an error consists of writing the error object to the pointer passed in that parameter. The caller allocates some stack space and passes its address in that parameter. On return, it checks to see if that space now contains an error. If it does, it jumps to the catch block.
Swift 4 gets a little fancier. The basic idea is the same, but instead of a normal extra parameter, a special register is reserved for the error return.
Joe Groff:
Some more fun trivia: r12 and x21 were specifically chosen because they’re normally callee-saved registers, so a non-throwing function can be “toll-free bridged” as a throwing one, since the non-throwing ABI will always preserve null in the error register.
[…]
One of the arguments against manual propagation of errors has long been the code size and performance cost at each call, but Swift’s ABI does a pretty good job of minimizing the cost without getting too avant-garde—it’s one instruction to zero out the error register at the boundary where you enter a “throws” context, and one instruction (on ARM64 at least, though still one fused uop on Intel) to jump-if-not-zero into the catch block after each call that might throw.
Compiler Language Design NSError Programming Swift Programming Language
Howard Oakley:
In Sierra, the DAS and CTS dispatching system now manages more than seventy activities at most times, one of which is Time Machine’s scheduled backups. However, in Sierra at least, this system has a bug which results in its breakdown: backups suddenly become irregular or stop altogether, and the other activities also become unreliable.
When this happens, it is tempting to revert to scheduling backups using the older launchd mechanism, and that will certainly restore them. But it does nothing for the seventy or so other services which the DAS and CTS dispatching system manages. […]
For anyone needing to run their Mac continuously, particularly as a server, this is a devastating flaw. Although I and others have tried various solutions, the only way currently known to restore normal dispatching services is to restart the Mac. That is literally a showstopper for any server, and is more than inconvenient for many other Mac users.
Previously: Sierra Bluetooth Problems Due to GCD?.
Update (2017-08-31): Thomas Clement:
You can use TimeMachineEditor if you need a third-party Time Machine scheduler.
btw TimeMachineEditor used to be implemented via xpc_activity but eventually had to switch to a custom implementation due to various issues.
Bug launchd Mac macOS 10.12 Sierra Time Machine
