BBEdit 11 is a great update with lots of good changes. Some of my favorites:
- There’s now a single window for Find Differences instead of three, and it’s easier to see which files have changed.
- “Highlight instances of selected text” sounds kind of odd but ends up being incredibly useful.
- Text colors are more configurable, and you no longer have to retype the name of a color scheme after editing it.
- Different languages can now have different default fonts.
- Documents now have a Super Get Info–style popover.
- There are new search commands: “Extract” and “Replace All in Selection.”
- Clippings are more orthogonal to languages. The new Clippings system is much more flexible.
- You can now create text filters with custom, xib-specified user interfaces.
- There’s now an easy way to add keywords to the built-in languages.
- The application is transitioning to Cocoa, but—unlike in Xcode and some other Cocoa apps—unsmoothed text still looks good.
BBEdit Font Smoothing Mac Mac App Text Editor
The fix macosx folks have a Git repository showing all the data that Yosemite sends to Apple, with different preferences settings:
When the user selects ‘About this Mac’ from the Apple menu, Yosemite phones home and s_vi, a unique analytics identifier, is included in the request. (s_vi is used by Adobe/Omniture’s analytics software).
Speculation is that it is looking up the marketing name of the Mac model. The cookie was first set when visiting Apple’s Web site.
The logs show that a copy of your Safari searches are still sent to Apple, even when selecting DuckDuckGo as your search provider, and ‘Spotlight Suggestions’ are disabled in System Preferences > Spotlight.
This is because Safari has a separate preference (under Search, not Privacy) to turn off Spotlight Suggestions.
When setting up a new Mail.app account for the address admin@fix-macosx.com, which is hosted locally, searching the
logs for “fix-macosx.com” shows that Mail quietly sends the domain entered by the user to Apple, too.
My guess is that Apple has a database of mail server configuration information to help make the setup process smoother for users.
I don’t think Apple is doing any nefarious here, but it is a good exercise to make this sort of list. I hope that Apple is doing so internally and that one day they will be more transparent about it the way they are about iOS security. The current privacy policy is a good start.
An open question is the extent to which Tim Cook’s vision is possible:
A few years ago, users of Internet services began to realize that when an online service is free, you’re not the customer. You’re the product. But at Apple, we believe a great customer experience shouldn’t come at the expense of your privacy.
Cook frames it as Apple not needing your information because it isn’t monetizing it, but there are definitely cases where having more information would help Apple improve the user experience—at the expense of privacy. It is not always possible to maximize both.
Apple Apple Mail E-mail Mac Mac OS X 10.10 Yosemite Privacy Safari Spotlight
John Gruber:
There’s no doubt in my mind it’s good short-term business sense to go with a 16/64/128 lineup instead of 32/64/128. But Apple is not a short-term business. They’re a long-term business, built on a relationship of trust with repeat customers. 16 GB iPads work against the foundation of Apple’s brand, which is that they only make good products.
Apple has long used three-tier pricing structures within individual product categories. They often used to label them “Good”, “Better”, and “Best”. Now, with these 16 GB entry-level devices, it’s more like “Are you sure?”, “Better”, and “Best”. Fine, keep the 16 GB models around for expert business and education buyers who know that they really don’t need more storage space. But don’t put devices on the tables in Apple retail stores that you wouldn’t recommend as a good product and good value to typical customers.
Apple Business iPad iPad Air iPad mini iPhone iPhone 6 iPhone 6 Plus Storage
Pierre Lebeaupin:
Nested block comments do not work. They cannot be made to work (for those who care, I filed this as rdar://problem/18138958/, visible on Open Radar; it was closed with status “Behaves correctly”). That is why the inside of an #if 0 / #endif pair in C must still be composed of valid preprocessing tokens.
[…]
Little did I know that not only Swift method calls are not more dynamic than Objective-C method calls, but in fact don’t use objc_msgSend() at all by default! Look, objc_msgSend() (and friends) is the whole point of the Objective-C runtime. Period. Everything else is bookkeeping in support of objc_msgSend(). […] Apple is trying to convince us of the Objective-C-minus-the-C-part lineage of Swift, but the truth is that Swift has very little to do with that, and much more to do, semantically, with C++. This would never have happened had Avie Tevanian still been alive working at Apple.
[…]
I find it very odd that there is no description or documentation of threading in Swift. And yes, I know you can spawn threads using the Objective-C APIs and then try and run Swift code inside that thread; that’s not the point. The point is: as soon as I share any object between two threads running Swift code, what happens?
[…]
I don’t like: the lacks of a narrative, or at least of a progression, in the book. Where is the rationale for some of the less obvious features? Where is the equivalent of Object-Oriented Programming with Objective-C (formerly the first half of “Object-Oriented Programming and the Objective-C Programming Language”)? This matters, we can’t just expect to give developers a bunch of tools and expect them to figure out which tool is for which purpose, or at least not in a consistent way. Providing a rationale for the features is part of a programming language as well.
[…]
Swift seems to go counter to all historical programming language trends: it is statically typed when most of the language work seems to trend towards more loosely typed semantics and even duck typing, it compiles down to machine code and has a design optimized for that purpose when most new languages these days run in virtual machines, it goes for total safety when most new languages have abandoned it. I wonder if Swift won’t end up in the wrong side of history eventually.
[…]
Swift, with its type safety, safe semantics and the possibility to tie variables as part of control flow constructs (if let, etc.), promises to capture programmer intent better than any language that I know of, which ought to ease maintenance and merge operations; this should also help observability, at least in principle (I haven’t investigated Swift’s support for DTrace), and might eventually lead to an old dream of mine: formally defined semantics for the language, which would allow writing proofs (that the compiler could verify) that for instance the code I just wrote could not possibly crash.
Concurrency Language Design Message Passing Objective-C Programming Swift Programming Language
John Siracusa:
CloudKit isn’t just the network data storage API that developers have always wanted from Apple; apparently it’s also the API that Apple has always wanted for itself. Both iCloud Drive and Apple’s new iCloud photo library service (upon which the upcoming replacement for iPhoto is being built) were written from scratch on top of CloudKit. Looking at it another way, if CloudKit doesn’t work well, third-party developers won’t be the only ones suffering.
Apple’s ability to make sure its servers are always available and that they answer requests in a timely manner is still an open question. As anyone who’s ever gotten an inscrutable error or interminable spinner from an Apple TV while trying to watch a video from the iTunes Store knows, Apple’s use of a network service does not necessarily ensure its reliability or speed.
The most reassuring thing about CloudKit is its design. It looks a lot more like a well-executed client library for a traditional Web service than a Cocoa API that just happens to have a network component. It’s still far from the cross-platform, multi-language ideal presented by Microsoft’s Azure Mobile Services, but Azure can’t hope to compete with the platform integration of CloudKit on OS X and iOS.
Roustem Karimov:
We don’t have to guess when something goes wrong anymore, and we no longer have to tell our users to perform a set of magic steps hoping that some of them would trigger iCloud to work. CloudKit solved the problems we had with the old iCloud.
It’s a great sign that Apple is eating its own dog food and no longer trying to abstract away the network. I think it’s a mistake to only make CloudKit available to App Store apps.
1Password App Store CloudKit iCloud iOS iOS App Mac Mac App Mac App Store
Tom Harrington:
For whatever it’s worth, I’ve been developing iOS apps since early 2008 and I regard the code signing process as conceptually straightforward. In practice though, it’s flaky and unreliable. More than six years in and I still routinely lose a day to trying to get code signing working again.
[…]
Code signing works or doesn’t work for incomprehensible reasons. Getting signing working again does not result in learning any useful skills that can be applied to future attempts.
The bug’s original title was more colorful.
Bug Code Signing iOS Mac
Neustar (via Landon Fuller):
In my previous post, Differential Privacy: The Basics, I provided an introduction to differential privacy by exploring its definition and discussing its relevance in the broader context of public data release. In this post, I shall demonstrate how easily privacy can be breached and then counter this by showing how differential privacy can protect against this attack. I will also present a few other examples of differentially private queries.
There has been a lot of online comment recently about a dataset released by the New York City Taxi and Limousine Commission. It contains details about every taxi ride (yellow cabs) in New York in 2013, including the pickup and drop off times, locations, fare and tip amounts, as well as anonymized (hashed) versions of the taxi’s license and medallion numbers. It was obtained via a FOIL (Freedom of Information Law) request earlier this year and has been making waves in the hacker community ever since.
The release of this data in this unalloyed format raises several privacy concerns. The most well-documented of these deals with the hash function used to “anonymize” the license and medallion numbers. A bit of lateral thinking from one civic hacker and the data was completely de-anonymized. This data can now be used to calculate, for example, any driver’s annual income. More disquieting, though, in my opinion, is the privacy risk to passengers. With only a small amount of auxiliary knowledge, using this dataset an attacker could identify where an individual went, how much they paid, weekly habits, etc. I will demonstrate how easy this is to do in the following section.
cjbprime:
Amazing. If you said to someone “Hey, I wanted to know where you went after the cab picked you up last year, so I called up the cab company and asked them where they dropped you off and they told me”, they would be outraged at (your behavior and) the breach of privacy shown by the cab company. But the city released a dataset that allows exactly this query. What were they thinking?
Something else that could be mentioned in the linked article: if someone you were with got in a cab in 2013, and they told you where they were going, and you remember the approximate time and location, you can tell whether it was their true destination regardless of how many other people were being picked up at the time, because you don’t have to find the exact ride they took, you only have to see whether any rides went to the place they told you.
This search is even extremely resistant to the differential privacy suggested by the post’s authors. I’d be much happier simply stating that location data is not de-identifiable, and no-one should use a cab in a city that logs location data if they aren’t happy with an adversary knowing where they went.
Privacy
