To increase adoption, Apple should expand the current list of entitlements until it covers every reasonable behavior that users expect from Mac apps. A good test for this is any app that is currently available in the Mac App Store. Having been approved by Apple’s own reviewers, and purchased by Apple’s own customers, the merit of these apps should be considered implicit. If a Mac App Store app’s reasonable behavior cannot be achieved in the confines of the sandbox, it should be considered a sandboxing bug, and a new entitlement should be added.
The current list of sandboxing entitlements is pretty short, but Apple’s about to start requiring every app in the Mac App Store to fit within their constraints.
The App Store’s prior rules already kept out a lot of useful apps that need complete filesystem access, such as the excellent SuperDuper! backup tool. The sandboxing requirement will further restrict what can be in the Store.
Sandboxing is a great idea. But if too few developers can use it, most users will never be able to run a sandboxed-apps-only setup, removing much of the purpose of sandboxing in the first place.
And if Mac users perpetually remain accustomed to looking outside the App Store for robust software, it hinders everyone in the App Store ecosystem, including Apple.
Apple announced that a future version of iOS will require user permission for Contacts access.1 I had previously suggested a dialog box similar to the permission dialog for location access, but a lot of people resisted that idea, saying that there are too many iOS permission dialogs already:
Location
Push notifications
Twitter account (new in iOS 5)
If an app wants access to all of these, it usually barrages users with a stack of dialogs on its first launch. The barrage-of-dialogs approach, like Windows Vista’s security warnings, isn’t great: users get overwhelmed or annoyed and just start carelessly dismissing all of them without reading them.
The Android approach is different: apps display a list of the permissions they need on their Market pages, and then don’t prompt upon access. The idea is to allow people to decide whether they’re OK with an app’s access before installing it. This also has downsides:
People may not see or understand the permissions in the Market listings. Or they may just ignore them, since they’re too fine-grained and mostly irrelevant.
People may forget what permissions an app uses after they install it, so they may not realize what the app is accessing while it’s in use.
People may refuse to install an app because of a permission it lists, even if that permission is for an optional feature and the app would work perfectly well without it.
That last one would definitely hit me. If all permissions were listed in the App Store, Instapaper’s customers would be wondering why it “needs” location (optional automatic dark mode based on sunset times) or contacts access (optional email-in contact addition, optional find-friends feature). They might refuse to buy the app because they think it needs these features to work, when in reality they’re minor features that most customers will never use. Already, “Top In-App Purchases” has probably cost me some potential customers since they think the app is constantly going to be asking for more money (optional subscription, which I had to offer via IAP to get server-side search in the app).2
Neither iOS’ barrage of dialogs nor Android’s huge list of permissions in the Marketplace is a great solution.
Dialogs can be done well in many cases, avoiding the barrage. They’re only shown when the app requests access to the protected resources, and only the first time. Conscientious developers can usually avoid showing multiple dialogs in a row by only showing them when the data is needed — for instance, I don’t ask for location access unless (and until) a customer selects the automatic-dark-mode setting.3
Careful users can also make better decisions about whether to allow access when they’re prompted on demand. If I asked most careful people if Instapaper could have their location, they’d refuse, because there’s no obvious good reason. But if the app asks right when they enable a location-based setting from a screen that shows why it’s asking for their location, they can make a more educated decision. Similarly, if an app doesn’t seem to have a good reason when it asks for Contacts, a skeptical person can decline.
I like Rene Ritchie’s mockup of an app permissions sheet, which would consolidate these permissions into one panel in Settings for each app. (I believe Android already does this.) But since most people won’t know about it, I don’t think such a sheet can replace the dialogs — it can simply make the after-the-fact settings nicer.
Ultimately, I think Apple’s current implementation of dialogs on first access, then settings to revoke later, is the better, more understandable, less annoying solution with fewer negative side effects for users and developers. They just need to add another dialog and setting for Contacts access, and that’s probably exactly what they’ll do in iOS 6.
Some other local data, such as Calendar entries and your synced media library, is also available to apps today without asking the user for permission. I’d be fine if those required a dialog, too. But I’d argue that Contacts are more important to be kept secure, and as we’ve seen, more likely to be abused by unscrupulous or careless developers. ↩
At least Apple stopped requiring all apps that could access web pages to be rated 17+ for mature themes, profanity, nudity, sex, and drug use. I got a lot of emails from concerned customers about that. ↩
I also stop requesting location data once the device has given me the fastest, largest, least granular location (with an accuracy of within approximately 3 kilometers) because, since this is only used to calculate sunset times, I don’t need it to be any more accurate. ↩
Jesse Thorn thinks a lot more highly of the Grado SR-60 headphones than I do:
They’re comfortable, and feature open construction, which means that you’ll be able to hear what’s going on around you in addition to your music. This is how your ears and brain were designed to process sound, and will improve your listening experience, not hinder it. Trust me.
Before I switched to closed Sennheisers for my primary headphones,1 I had a pair of SR-60s for so long that the earpads disintegrated, and I’d never call them “comfortable”. It’s not just me, either: this is a very common criticism of the SR-60 and SR-80. And their open-backed design renders them impractical or unusable in many situations.
The SR-60s always come up in entry-level awesome-sounding headphone recommendations because they do indeed sound amazing for the price. But they come with two huge practical caveats that should prevent reviewers from giving them a general-purpose, unqualified recommendation.
On Sennheiser, Jesse says: “Unlike Sennheiser, [Grado hasn’t] mass-marketed their once-quality products into extinction.” What does that mean? ↩
The recurring theme: Apple is fighting against cruft — inconsistencies and oddities that have accumulated over the years, which made sense at one point but no longer — like managing to-dos in iCal (because CalDAV was being used to sync them to a server) or notes in Mail (because IMAP was the syncing back-end). The changes and additions in Mountain Lion are in a consistent vein: making things simpler and more obvious, closer to how things should be rather than simply how they always have been.
Reminders in iCal (or BusyCal) are clunky at best, and Notes in Mail via IMAP are absolutely horrible. I’d love Mountain Lion even if the dedicated Notes and Reminders apps were the only new features.
(And if they’d fix the embarrassing reliability of Lion’s Preview.app.)
I feel like no one else is saying this, and since I’ve not ever been one to hold back what’s on my mind I absolutely will — enough is enough. I’ve had it with incremental updates to Android smartphones every two weeks, I’ve had it with the super-sized ridiculousness, and I’ve had it with all of these marketing gimmicks. Just focus on a quality product, and you won’t have to release eight “flagship” models a year.
If even a BGR writer is saying this, I think we’ll look back on the last few months as the period when a trend even bigger than the Galaxy Note jumped the shark.
Thanks to InVision for sponsoring the Marco.org RSS feed this week:
The UI prototyping phase of the design process is crucial to get right. It’s about figuring out how your product will work and ensuring everyone is aligned before moving into building.
InVision is a web-based prototyping tool that lets you paint an accurate and realistic picture that anyone can understand.
InVision is beautiful on mobile as well. Simply navigate to your project from your iOS or mobile device and experience a realistic picture of how the app will feel. “Save to Home Screen” on iOS for a full-screen experience.
InVision is offering a 30 day free trial along with a special discount for the first six months.
From John Gruber’s review of Isaacson’s authorized biography of Steve Jobs:
Isaacson’s book may well be the defining resource for Jobs’s personal life — his childhood, his youth, his eccentricities, cruelty, temper, and emotional outbursts. But as regards Jobs’s work, Isaacson leaves the reader profoundly and tragically misinformed.
I mostly enjoyed the book, despite its flaws.
Like many people reading this, I was already familiar with most of Jobs’ recent work and some of his past highlights. What I expected from the book was a biography of Steve Jobs, the person. On that, it delivered reasonably well.
But the reason we care so much about this person is because of his work, so it’s a shame that the representation of his work in his biography has so many flaws.
There’s certainly a set of people willing to spend $10,000 on a proposal. It’s likely there’s also a set of people who would propose with chain restaurant pizza. Still, it’s disheartening to think that the intersection of those two sets may not simply be zero.
There are “only 10 packages available”. I wonder how many they’ll sell.
MG Siegler on the awful world of most online reporting:
Most are stories written with little or no research done. They’re written as quickly as possible. The faster the better. Most are just rehashing information that spread by some other means. But that’s great, it means stories can be written without any burden beyond the writer having to read a little bit and type words fast. Many are written without the writer even having to think.
Have you ever been interviewed by a reporter or blogger for a story? How accurately did the final story represent the truth, or what you said?
I’ve learned that talking to the press is like talking to the police — ideally, don’t, since your interests conflict and there’s little to no potential upside for you — but I regularly forget or ignore this wisdom.
Like MG says, most reporters are under a lot of pressures that work against the quality and accuracy of their stories. I’ve found that reporters have usually already written the story, at least mentally, before they ask me for a quote, and they’ll bend, twist, and edit what I say to support their narrative. I’m simply a puppet to tell their story, whatever it is.
Usually, I can sniff out a bad story by the interview request, and I’ll just decline to comment. But sometimes I mistakenly accept a bad interview and give quotes that get distorted, and the resulting story can be pretty far from the truth.
I try to remember that whenever I read anything in the press about a subject for which I don’t have first-hand knowledge.
For instance, one of the chips inside the Lytro is a Marvell Avastar 88W8787, which has Bluetooth and Wi-Fi capabilities. The Lytro doesn’t currently offer any sort of wireless syncing abilities, so perhaps a future software update will enable those features, allowing for wireless photo transfer or perhaps remote control of the device via Bluetooth.
Wireless photo transfers would certainly help the Lytro’s appeal. Now that I’m accustomed to the iPhone with Photo Stream, having to transfer photos from a cutting-edge new consumer camera by plugging it in via USB seems clunky.
A lot of people have asked if I’ve ordered a Lytro camera to review here. It’s tempting, but I haven’t. There are a few red flags for me in their sample pictures (Flash is required to zoom or change focus).
They all feature roughly the same composition to show off the dynamic focusing: an object very close to the camera, and a background scene further away. But while the close-up subjects seem to have moderately acceptable sharpness, the further-away parts of the scene appear to have very poor sharpness and detail, even when focused. There also appears to be a lot more noise and chromatic abberation (purple edge fringing) than even a modern smartphone camera.
So it’s a cool new technology with a killer feature (and maybe more later with software updates), but is that enough to tolerate optics that look noticeably worse than the iPhone that you already have in your pocket?
It’s hard enough for many of us to justify anything between a smartphone and a DSLR today, but with a high-end compact, you could at least say that the photos are better quality than the phone’s. If the Lytro can’t produce better photos than the phone, it won’t matter that you can refocus them later.
Dan Benjamin, my podcast co-host, asked me to record a special episode in John Siracusa’s Hypercritical time slot, since John couldn’t record this week. Those are big shoes to fill, so I said I’d only do it if Merlin joined us.
Why would VEVO pirate content? Because it was easier than getting it legally. This is the actual root cause of piracy online. It’s not shady, masked individuals at swanky events commandeering computers to pirate for the hell of it. It’s VEVO employees. It’s everyone.
Nate Anderson thoroughly disassembles RIAA CEO Cary Sherman’s New York Times op-ed, a blabbering, rage-filled diversion-fest so badly conceived and written that it makes me question the editorial standards of The New York Times.
I’ve probably kept up with Dan’s Data for longer than any other website. That AeroPress that everyone discovered last year? I remember reading his review in 2006. That’s nothing — I read his review of the Pine D’music MP3-CD player before buying one in 2000. And if you think I review headphones acceptably, Dan puts me to shame.
His posts were the inspiration for Instapaper’s automatic Wikipedia popovers when you tap a Wikipedia link, since he copiously links to Wikipedia and I just had to know what he was talking about without leaving the page.1
And his new Psycho Science series on the blog is fantastic. This article (remember, this is a link post) got me reading about borosilicate versus tempered glass and inspecting our Pyrex all evening.
If you’re my kind of geek and have been reading on the internet for a long time, you should definitely be reading his site and blog (which aren’t the same, probably for legacy reasons).
Note to Instapaper competitors: Do not start reading Dan’s writing. ↩
The world is full of ideas that can be executed with 10 to 20 hours per week, let alone 40. The number of projects that are truly impossible unless you put in 80 or 120 hours per week are vanishingly small by comparison.
This is of course nothing new. We’ve been playing this bongo drum for years. But every time I see people crumble and quit from the crunch-mode pressure cooker, I think what a shame, it didn’t have to be like that.
It’s easy to set Path on fire for this, but accessing the iOS Address Book is essential to most “Find my friends on this service” features. Indeed, I use the Address Book for a similar feature in Instapaper as well. But there’s a big implementation difference between my method and Path’s.
The two Instapaper features that access the Address Book
Instapaper accesses the Address Book for two features:
The “Add ‘Read Later’ by Email” option in Settings, which creates a new Address Book contact with the customer’s special email-in address. This feature operates only on the device and does not send any information to the Instapaper servers. And the only reason it even reads the Address Book at all, rather than just writing to it, is to check for an existing copy of the “Read Later” contact so it doesn’t make a duplicate.
When searching for new friends in the Friends section, I offer a “Search Contacts” option. This sends (over SSL) a list of email addresses to an Instapaper server, which issues a single SELECT statement on the user database to find any matches. That’s it. The list of email addresses isn’t stored (the query isn’t even logged), and only email addresses are sent, not anybody’s name, phone number, address, or other information.
When implementing these features, I felt like iOS had given me far too much access to Address Book without forcing a user prompt. It felt a bit dirty. Even though I was only accessing the data when a customer explicitly asked me to, I wanted to look at only what I needed to and get out of there as quickly as possible. I never even considered storing the data server-side or looking at more than I needed to.
This, apparently, is not a common implementation courtesy.
We can’t prevent services with poor judgment or low ethical standards from doing creepy things with the data once it’s sent to them. We can’t even realistically use App Review to only permit access to the Address Book fields (email, name, phone, etc.) that are justifiable for any given app to access, because there are too many gray areas.
But Apple can, and should, assure users that no app can read their contact data without their knowledge and explicit permission. I don’t know why this hasn’t always been required, but it probably isn’t a good enough reason to justify the erosion of user trust in iOS apps that this could cause.
Apple needs to change the Address Book API to require user permission first, like Core Location and Push Notifications do. I don’t care how many applications break as a result. Not requiring user permission to date should be treated as a security hole and patched promptly.
Thanks to kooaba for sponsoring the Marco.org RSS feed this week:
kooaba Shortcut is a shortcut between real life and the Internet. Take a picture of what you are reading in a newspaper or magazine and instantly get connected to the digital version.
Using image-recognition technology, Shortcut recognizes what you’re reading. Once recognized, you can share the digital version of the pages via Facebook, Twitter, SMS, and email, or store them in Evernote. This works with over 1,000 newspapers and magazines worldwide. (See a list of publications.)
Shortcut also works with advertisements in newspapers and magazines, and billboards with the Shortcut icon. After taking a picture of such an ad, you gain access to extras such as coupons, sweepstakes, or store locators.
With Shortcut, you no longer need to type links into your phone, search Google for information, or cut out articles. Just take a picture instead!
