Getting a bit creepy
blog.gingerlime.com
blog.gingerlime.com
On my Android phone:
* With standard Android, I have to whitelist an application when installing it. I cannot pick which permissions I give it, I cannot control when it can use those permissions, and I cannot remove permissions. Ever.
* With Cyanogenmod, I can restrict permissions fine grained both for permissions and applications. This would be really great if it were usable, but when I try to use it the applications behave very badly (often crashing) if they don't get unfettered permission to use my data.
I would love it if (a) applications behaved well in the absence of permissions (I fault Google for setting expectations of availability that don't require this) and (b) I had a UAC style permission granting mechanism[1] so that I control an application's access to my data and can monitor what it is asking for and when. While it could still "steal" my data (cache it, send it to the borg) any time I gave it permissions, it would at least give me a clue that the application was not trustworthy if (when) it popped up unexpected permission requests.
[1] I cannot believe I said I like Windows UAC dialogs. That will cost me another year in purgatory. :-/
That said, there are some alternatives to Cyanogenmod's Incognito mode, which should work better.
One is XPrivacy [2], which relies on the XPosed Framework [3]. This is what I'm currently using on my Android phone. You can allow/restrict some permissions by default, and then have a whitelist for certain applications.
Another one is OpenPDroid [4], which requires you to patch your rom (there are some preset for the biggest roms, so usually it's just a matter of a few clicks). I haven't used it, but it should work just like XPrivacy.
XPrivacy and OpenPDroid send blank/fake data instead of blocking applications from using certain APIs, so they cause way less crashes. They even allow you to choose the fake data to provide, so that you can fake, for example, your location.
[1] http://www.androidpolice.com/2013/07/25/app-ops-android-4-3s...
[2] https://github.com/M66B/XPrivacy
[3] http://forum.xda-developers.com/showthread.php?t=1574401
[4] http://forum.xda-developers.com/showthread.php?t=2098156
AppOps has been removed [1] in Android 4.4. Maybe it'll come back in a later version, but it's disappointing that it's no longer just hidden.
[1] https://android.googlesource.com/platform/packages/apps/Sett...
Fixed in Android 4.3. Now you can approve any permission at install and turn it off anytime later.
http://www.androidpolice.com/2013/07/25/app-ops-android-4-3s...
What you describe may exist in a future version of Android but does not in 4.3.
You have a valid point that it could be easier, but I wanted to clarify that.
As an app maker, I'd like it if I could declare mandatory permissions and optional ones, as well as the iOS model of asking for permissions on demand. There are features I'd like to add, but I can't easily do so because (a) it would prevent auto-updates - all existing users would have to explicitly okay it, so many will naturally leave it at current version for months or years and never receive any update; (b) more permissions naturally makes users more cautious. So I'd rather be able to just ask to do something when the user has expressed they need it, but there's no such option.
Interestingly, ios has added more and more permission toggles over time.
They're not very fine-grained[0], but they do allow toggling per-application access.
[0] which is kind-of a shame but avoids getting overwhelmed
Some of these are just new features, but others like microphone access have been added to old APIs.
As an app developer, I sympathize, but if you've got a reasonably complex app that requires 8 permissions, that's 255 permutations of code paths that you need to test (that you don't need to test right now) to make sure your app performs correctly. And that's not a reasonable request to make of an app developer.
Aside from that, some apps rely on, e.g., INTERNET permission to do their monetization. Aside: It's majorly not cool to "block ads" just because you don't like ads; pay for the ad-free version if you don't want to see ads. It's cheap in almost all cases. It's HARD to make money as an app developer; it may not be technically stealing to block ads, but it's ethically indistinguishable.
That said, as an app developer I would love to have the ability to request OPTIONAL permissions, or even better, request them at runtime (basically, let the OS bring up a "Do you want to let this app have PERMISSION_A, PERMISSION_B, and PERMISSION_C, to enable the following feature: FEATURE DESCRIPTION"). Again, though, I'd want to request a SUITE of permissions at once, so I don't have to worry about testing with random user-configured permutations of permissions.
There are some features I'd love to add, but they wouldn't be needed by everyone -- and I wouldn't want to scare people away from downloading my app, so I don't add them at all.
But I absolutely would still want guaranteed permissions: If my app needs Internet to make money, then I don't want someone to be able to use it if they're blocking Internet for the app, or otherwise blocking ads on the phone. You don't want the ads? You're free to use another app, or pay to turn the ads off.
Not really; this depends on how the OS developer implements denying various permissions. For example, your app already has to handle empty address books, location services reporting valid, fixed locations, and SMS messages not arriving; it also can't assume network and messaging services are available, even in the absence of permission problems.
But I absolutely would still want guaranteed permissions: If my app needs Internet to make money, then I don't want someone to be able to use it if they're blocking Internet for the app
How do you currently handle limited, filtered, or no Internet access for reasons other than lack of permission grants? Why can't you handle permission-based Internet blocking in the same way?
If the OS handles it transparently, then sure, it could work. But as I understand things, that's why the CyanogenMod "feature" of selective permission disabling fails: If I ask whether the Internet has a valid signal, and it unexpectedly throws an error, then my app will either crash or behave in an untested way (depending on whether I'm catching top-level errors and continuing to run anyway). I don't know how the 4.3 feature handles it.
I don't want users to have the ability to disable Internet, though; not if I'm writing an ad-supported app. I don't want to kill the app on devices that simply never connect to the Internet either, so I'd prefer if the OS guaranteed that, IF there's an Internet connection, it will give me full access to it.
Perhaps that's the hardest part to test about the Cyanogen-style permissions disabling: that there's no uniform way Android handles a missing permission. Sometimes the API will throw an exception, while other times it returns a null Object.
Your average app already has significantly more than 255 permutations of code paths. While testing every permutation with e.g. automated tests is a great way to try and ensure full coverage, simply handling each once will often be sufficient: a significant number of these permissions, properly handled, will be orthogonal to the others.
Many disabled permissions aren't adding fundamental complexity: What's the functional difference to your code when it reads 0 contacts from my address book because I don't have any, vs when it reads 0 contacts from my address book because I disabled the permission? You already need to handle the former.
You're right in that it would be possible to have the OS report "0 contacts" instead of throwing an error, and THAT case should be handled.
In fact, I'd love to have the ability to block reading of contacts from all apps except ones I explicitly allow. It's the more basic "INTERNET" permission that is core to monetizing apps that I take umbrage with blocking; if someone is using my contacts somehow to monetize their app, that's not cool, and I absolutely wouldn't want to use an app that did that.
...or to write your own wrapper which does the same by handling the exception, and to then exclusively use that wrapper in your client code.
Catching the error isn't even half the battle, either. If you want the app to "work," you need to explicitly test the full set of permissions any particular block of code might need prior to enabling aspects of your UI that require them, or your app is going to behave badly.
At best, your proposed solution would prevent the app from crashing, though it could still get into a bad state -- a non-modal dialog waiting for a particular result could never be closed, for example, because of an unexpected throw that skipped over the proper cleanup code. Yes, that code SHOULD be in a finally{} clause, but what if you missed something? I'm an awesome developer in a lot of ways, probably even a 10x+ developer, but I don't consider myself perfect. Do you?
Have you developed apps for Android as an indie developer? Or for iOS? How much extra time would you want to spend to cover corner cases like this, instead of adding features that might actually improve your revenues or ratings?
How likely is it that you'd successfully handle all 255 extra permutations with no real testing? And don't think unit tests would solve the problem: You'd really need full functional and UI tests, probably with a human to really be sure that you're covered. Some apps really don't work without certain permissions (say an Internet chat app with no INTERNET permission), so be sure you have reasonable error messages that explain to the user that the app can't work if you don't give it the right permission. And word the message so that your average non-techie will understand it, or be prepared for lots of negative ratings with "app doesn't work! uninstalled!" comments.
No, making it easy for people to kill permissions on an app is the wrong answer. Giving developers the ability to optionally query sets of permissions reduces the complexity from exponential to constant, and allows for optional features to exist in an app.
I don't consider myself a 10x developer, nevermind a perfect developer. But I still think you're continuing to overstate the difficulty of minimizing the combinatorial effects and general difficulty of handling missing permissions. You can certainly make a herculean task out of it if you want to, however.
> Have you developed apps for Android as an indie developer? Or for iOS?
Depends on how you're defining both "developed apps" and "indie".
> How much extra time would you want to spend to cover corner cases like this, instead of adding features that might actually improve your revenues or ratings?
While I certainly wouldn't relish platform mandated "busywork" as a developer, I've seen much worse and much more pointless work than such.
> How likely is it that you'd successfully handle all 255 extra permutations with no real testing?
How likely is it that you'd successfully handle all execution of your app even with real testing? For anything sufficiently complex, statistics will eventually catch up with you, and your chance will, when rounded, come to a nice and magical number... nil. Zero.
Mistakes will happen, complexity will happen, and removing features in an attempt to prevent the inevitable from eventually striking is the wrong answer. Don't get me wrong, permissions sets are a fine way to help reduce that complexity without necessarily harming the other goals. And it'd be nice to have it done for you. And it'd be nice to have it done as atomic sets. But I remain unconvinced it's unreasonable to manage without those niceties.
( although as a matter of personal taste, if I want to kill INTERNET and just read my chat app's logs or settings I'd like to be able to do that -- and can at the OS level by turning off both mobile data and wifi, your monetization strategy be damned.)
Spent time (and money) on your own initiative to develop an app that's been published in the Android and iOS stores.
I spent my own time developing a game that's in the Android and iOS app stores.
> How likely is it that you'd successfully handle all execution of your app even with real testing?
My point wasn't about bugs. My point was about execution path coverage: If code has never been hit, then it may contain hidden bugs.
And if I'm doing things right, 100% of the code would be executed in testing. There are techniques to specifically track code coverage, so you don't need to wonder whether a code path has been triggered, but in general I don't write code and then never execute it.
> But I still think you're continuing to overstate the difficulty of minimizing the combinatorial effects and general difficulty of handling missing permissions.
It's your right to believe as you will.
Then no.
> My point wasn't about bugs. My point was about execution path coverage: If code has never been hit, then it may contain hidden bugs.
"it may contain hidden bugs" sounds like, at the end of the day, your point was about bugs. Any distinction you're trying to make is too subtle for me to pick up on without spelling it out more.
> And if I'm doing things right, 100% of the code would be executed in testing.
There's a big difference between executing all code, and executing all permutable paths into said code on a micro level (e.g. function by function), and executing all permutable paths into said code on a macro level.
I've been in the unfortunate position of having even the first option being literally impossible for parts of a codebase. Lack of complete test environments for your mandatory 3rd party APIs suck! You can write your own mocks, but that's not exactly the same thing -- especially when you don't know what kind of quirks to expect. And as you might expect, it did lead to a bug! Fortunately, patching on both Android and iOS is significantly easier, and equally fortunately, the bug was later found, patched, and the patch shipped successfully.
And while I think "complete" test coverage of every possible permutation is a nice thing to strive for on a micro level, at a sufficiently macro level it becomes effectively impossible. Techniques like fuzzing let you test that a significant majority of combinations works out in your favor, but there will always be the 0.0001% corner case. Well before "impossible" comes "overkill".
I suspect we have a fundamental disagreement of opinion as to what constitutes "overkill".
Of course it was. It's always about bugs.
But code that has never been executed can have orders of magnitude more categories of bug than code that works at least once. And I'm good enough that 99% of the time I don't miss the corner cases -- it's the more blatant problems that tend to bite me, and those are eliminated by making sure all the code gets executed at least once. Once my code is wired up right, it tends to work. But I won't know if it's wired up right until it's been executed once.
>Lack of complete test environments for your mandatory 3rd party APIs suck!
Try writing code for systems without the ability to debug. Or where something is going wrong and there's no way to figure out why based on logging or debugging. Or without complete (or correct!) documentation. Or for projects where, once you ship, there is no option to patch your app, so it needs to be as close as possible to bug free. Thankfully modern platforms (mostly!) avoid the last pitfall, but I've been there, along with the other situations. And I win these battles.
>I suspect we have a fundamental disagreement of opinion as to what constitutes "overkill".
No, I'm just not communicating effectively. And it's no longer worth it for me to try any harder.
FWIW, I'm not talking about complete test coverage. The apps I usually write (games) are almost entirely pointless to write tests for. Ever. Sure you can for some specific libraries you're using, but for the actual game itself? Hardly ever worth it.
I've shipped games with zero chance for patching, some pretty popular -- and I didn't hear of any bugs worth mentioning after release. And there were no tests involved in the development process (other than the kind where QA tests the game and tells me what doesn't work). I know that concept is a bit alien on HN, but it's rare to find a game (or even a game engine) with a nontrivial test suite.
Most game bugs wouldn't be prevented with unit tests anyway -- probably only one in a hundred at best. They almost always result from emergent complexity, not from a single function returning a bad value.
Maybe I'm taking your repeated reference to testing all 256 permutations too literally.
> Try writing code for systems without the ability to debug. Or where something is going wrong and there's no way to figure out why based on logging or debugging. Or without complete (or correct!) documentation. Or for projects where, once you ship, there is no option to patch your app, so it needs to be as close as possible to bug free. Thankfully modern platforms (mostly!) avoid the last pitfall, but I've been there, along with the other situations. And I win these battles.
At least I've dodged one of those bullets: I haven't worked on anything outright unpatchable just yet :).
> No, I'm just not communicating effectively. And it's no longer worth it for me to try any harder.
I appreciate the effort you've made.
The app is a happiness tracker that tries to correlate things with your happiness level. Right now, it's just location and some text/values you input. But what happens if some users want to correlate their texts with happiness? Or their pictures?
I don't want to have to ask everyone to grant my app access to major phone functions when only a small subset of users would want that functionality. Unfortunately, I have to because of the way the OS is setup.
Now, considering only 1% of customers (I assume less) will be glad to have this feature, it will not be worth for developers to add extra complexity handling the permissions issues.
Ideally though, I would love having the same thing as you described. In reality, most customers are feeling OK even if the app requires root access.
In 1998 I worked at a large publicly traded insurance company. We provided quotes online and sent a follow-up email to the person with their written quote in it. I was asked to figure out a way to determine when the person read their email. Our infrastructure was Classic ASP so I:
1. Created a new web site in IIS
2. Changed IIS' processing of .jpg to run through the ASP processor
3. Created a .jpg program in the site that would update a quote's record as having read the email
4. Put an img tag in the HTML email that loaded the "jpg" file with the unique identifier on a querystring
Our business people used this to automatically initiate an outbound call to the person the second they read the email. A lot of people were creeped out, "OMG I just sat down to read your email, what a weird coincidence" but by god those people bought insurance from us.
Of course today, that is the reason why images don't automatically load in emails. But there are plenty of people finding new creepy things to do every day.
Beyond that, 1998 wasn't exactly the dark ages. I knew plenty of people that had cable modems in 1996. I had an ISDN line myself in 1996 and a DSL line in either 1998 or 1999. There were plenty of options for people back then that didn't live in the middle of nowhere. And call waiting took care of letting calls through unless the person explicitly disabled it. Heck, any time I had dialup I had two or more phone lines and I had a cell phone since 1994.
But you're right - like all solutions it wasn't 100% perfect but it sure helped tremendously.
BTW, great conversion technique. Certainly something to do nowadays too, if you can get them to load an image or click a link. I wonder, do average people load images in emails or click the links "if this email does not render correctly"?
Unfortunately, I'm not sure other operating systems are much better.
You're right, though, that I'm being a bit overdramatic, the options are definitely there.
At least that is getting rectified, little by little. Apparently 4.3 introduced a tool called "Apps Ops", which brings some of the fine-grained permission control seen in Symbian (where it was actually possible to select which permissions to grant) to Android. [1]
Once the power users learn to make most of this tool, the app developers will have no choice but to learn to cope with their apps getting too onerous permissions yanked from under their feet. Which, to me, is a very good thing indeed. It gives the developers one more avenue to compete in - make your app too nosy and you risk getting sidelined by an upstart clone that behaves better with user privacy.
[1]: http://www.phonearena.com/news/A-hidden-Android-4.3-feature-...
I think the funny part in all of this is that iOS does give you more fine-grain controls over app permissions.
1. Don't ever email me unless it's in response to a specific request initiated by me.
That's why companies run A/B tests rather than trust word of mouth.
Perhaps what turns me off are the desperate "Please come back to $SERVICE, you've been gone for more than 35 seconds! Please come back!!" from the free services. I don't mind the weekly specials from the local computer retailer, for example.
> To me this is crossing some invisible but very clear line. I haven’t used the product yet, and it’s already trawling through my personal stuff?
I'm confused by this example. Isn't this exactly the purpose of MightyText, the app he installed? It's routing your text messages through you server. Obviously their system knows what texts you are sending, otherwise how would it function? Also, the product has been used if you give it permission to access your contacts.
Blog post author here. The purpose of MightyText (as far as I understand it anyway) is to allow me to use SMS through my computer at greater ease. I accept that in order to do that, technically I need to allow the app to access my Android SMS, contacts etc and "act on my behalf" to deliver messages.
I trust the program not to abuse this access I give it. I do not expect it to use this information to spy on me, even if this spying is merely for marketing purposes or to encourage me to use their program more. I think that's the creepy part.
EDIT: I've updated the original blog post to make this clear.
In other words:
"Yes, I know it's wrong and they should not know these things about me, but I want to use their product anyway, so can we please just pretend nobody knows what's going on in our society?"
Because the most likely alternative is they have the exact same information but the consumer isn't fully aware. Which is actually more creepy.
I went to Rackspace.com based on a HackerNews article a couple months ago and I'm still bombarded with ads for them on every site I go to.
Why do you think this? The company that I work for uses remarketing, and it actually works really well. I don't know the details behind it, but I know that it's a good source of leads (at least for my company).
Keep in mind that it might not work very well with you, but HN readers don't exactly represent the majority of web users.
The web felt less creepy now.
https://chrome.google.com/webstore/detail/notscripts/odjhifo...
Why? If you have a Facebook feed, then haven't you already signed up to be spied on?
I suggest that if someone doesn't like this business model, then purchase your programs; don't get ad-supported programs.
From my understanding, it sounds like MightyText scrapes in your SMS messages and allows you to read/respond to them from their client. Looks like it just picked up old messages and accidentally thought they were unread.
Otherwise, this isn't just run-of-the-mill tech company creepiness, it's fraud like the dating websites advertising "3 messages waiting for you."
(TL;DR: Twitter displays a different behavior with the user profile of my ex-girlfriend than with any user name, including people I've interacted with much more in the last 1.5 years)
I would like many people to do the experiment.
Yes, we can! :-)
This is just another reason to curate the things we let into our lives.