Hacker News new | past | comments | ask | show | jobs | submit login
Cyanogen Mod: Run in Incognito Mode (plus.google.com)
114 points by gulbrandr on June 16, 2013 | hide | past | favorite | 35 comments



While I think this mode is useful, what I'd really like to see is Cyanogen integrating OpenPDroid [1,2]. OpenPDroid allows for more fine-grained permissions which, I think, is what we need. Because the real problem is not running suspicious programs completely sandboxed from the private data. It's running the otherwise useful apps that request too many permissions that we'd like to keep in check, but still use (which would require allowing them to access some of our data).

[1] http://forum.xda-developers.com/showthread.php?t=2098156

[2] https://github.com/OpenPDroid


I couldn't agree more--OpenPDroid is great, and I would suggest anyone who values privacy and who is technically inclined give it a try.

Unfortunately, we won't be seeing it baked into CyanogenMod. CyanogenMod used to have a feature to disable specific permissions back in the CM7 days. As I understand it, Google insinuated that CyanogenMod would likely be banned from the Android Market if that feature continued; it wasn't ported to CM9. That's why I imagine this new incognito feature isn't configurable and can only be turned fully on or fully off.

Still, this is a step in the right direction. There's a lot of room to stand up to Google about data privacy right now, and I'm glad to see a big player doing it.


This is untrue. Aokp still has a permissions blocking app available with their ROM and I don't know exactly what google would be blocking as far as I know CM doesn't distribute apps on the google market. The issue is it was outright blocking vs seeding so many apps would break/fc.


Here's some backup from ciwrl, a CM dev, from March 2012 [1]:

"I can answer the second part, regarding CM inclusion of such a function. And the answer is a resounding "no". Originally, the functionality for CM mirrored that of PDroid, including 'spoofing' the data calls. It was decided that our footprint in the Android ecosystem was too large to ship such functionality out of the box. A million active users of our own, plus the many derivatives that use our source, would essentially cause a million+ polluted data and statistics for app developers.

Not only was this deemed unacceptable, we received feedback from 'the powers that be' that should such functionality be issued directly, CM could very well be cutoff from all Android Market applications, which again, would ripple to most Custom ROMs.

So, we chose to neuter the functionality."

[1] http://forum.cyanogenmod.com/topic/44589-combining-cyanogen-...


Regarding the original comment of permissions blocking vs seeding fake data(pdroid) are two different issues. Thats why the new incognito mode is not facing a similar backlash.


AOKP is not CyanogenMod. And Google would block CM devices from being able to access the Play market.


so please explain why cm would differ from aokp and why google would even make this distinction. They are both the two most popular roms at this time, that support the most devices. With Paranoid Android very close. Saying that Google would block play market access to CM for doing something another incredibly popular rom is doing is ridiculous.


I'm running CM10 on my phone but I'm not sure where the most recent OpenPDroid installation is or whether it's phone dependent or not...

Mind enlightening me a bit? Thanks!


There's an auto-patcher utility[1] they've developed--you basically give it your ROM file and specify the patch, and it'll generate an update file you can flash to enable it (as well another file you can flash to remove it).

There's also a utility mentioned on that page that provides a GUI for Windows that will automatically download patches and run the auto-patcher[2].

It's definitely not easy yet, but it's not too difficult to get through if you're used to this sort of thing.

[1] http://forum.xda-developers.com/showthread.php?t=1719408

[2] http://forum.xda-developers.com/showpost.php?p=31648393


Thank you for replying (and thanks to the others too but this was more helpful). That certainly sounds within my pea-brain's ability to follow directions.


Well, I'm exploring the process myself. From what I understand, you need to patch the CM source tree for your device with the patches found at [1] (choose the branch that corresponds to the correct Android version; CM 10 is AOSP 4.1.2, CM 10.1 is AOSP 4.2). Then build the source tree and install on your phone, similarly to how you did with the unmodified CM10 firmware. If anyone has more experience with getting OpenPDroid to work with CM, please, correct me if I'm wrong.

[1] https://github.com/OpenPDroid/PdroidBuildPatches/tree/4.2.0


From what I understand, you have to install it into the ROM and reflash, and then install an app that will manage permissions. Installing it into the ROM is the hard part, but I've heard that there are tools to do it.


Frankly I think that level of privacy control has little appeal to the mainstream. You could of course argue that modded Android ROMs also have little appeal to the mainstream, and so adding non-mainstream features to modded ROMs is cool. (And I'd totally agree with you.)

But I suspect that Kondik might aspire to get privacy features like this into AOSP. Something like an all-or-nothing incognito mode has precedent in places like Chrome and Firefox, so I feel like something like this would have a reasonable chance of making it in. A fine-grained permissions system likely wouldn't.

However, I personally would like a little more fine-grained control. I might trust a location-centric app with my GPS (or at least recognize that the app is useless without it), but not want to give it access to my contacts.

Note that CM7 did have a fine-grained permissions system. It wasn't as extensive as OpenPDroid, but you could flat-out reject individual permissions given to apps on CM7. Unfortunately it often caused crashes, as the apps weren't built to be denied so harshly. The fake-/no-data approach of incognito (also one of the options that OpenPDroid offers) probably won't cause any compat headaches.


Thanks for an insightful reply.

> Frankly I think that level of privacy control has little appeal to the mainstream.

One might argue that the whole idea of privacy is of little appeal to the mainstream.

> The fake-/no-data approach of incognito (also one of the options that OpenPDroid offers) probably won't cause any compat headaches.

The idea of OpenPDroid is to provide fine-grained permissions together with the fake-data/no-data approach to enforcing them, which prevents apps from crashing when access is denied. And that also enables using the apps even when they might have potential violations of your own privacy policy.


> Frankly I think that level of privacy control has little appeal to the mainstream

Those that unlock their bootloader, root their device/flash third party firmware are not mainstream users though. However, many of them do share the same sort of apathy to privacy as mainstream users from my observations. Although there are some reputable third party ROM projects for Android, it's quite amazing how so many are willing to blindly flash nearly anything posted on a forum with little regard to what it might do to their device.

Regarding OpenPDroid, anyone can submit any sort of additions to Cyanogenmod that they wish and are then reviewed on their gerrit[1]. First step to getting something like OpenPDroid in Cyanogen is for someone to integrate it without messing up the source tree and submitting it for review. They might deny it still, but one won't know until trying.

[1] http://review.cyanogenmod.org/


OpenPDroid style fine-grained app permission control has already been explicitly rejected by Steve Kondik. See https://jira.cyanogenmod.org/browse/CYAN-28

He expanded on his reasons in a Google+ post: https://plus.google.com/100275307499530023476/posts/iLrvqH8t...

I'd love to see a privacy focused fork of CyanogenMod personally. Time to person-up† and do it myself perhaps :)

† Is there a non-gendered equivalent to man-up?


> Is there a non-gendered equivalent to man-up?

Yes, it's "man-up". "Man" is, like it or not, a reference to the species there.


In that context it is literally a reference to traditional male behavior (that could be expanded as expected male behavior in response to adversity).


? no it isn't, and even if it was that would still be sexist


> The API provides a simple isIncognito() call which will tell you if incognito is enabled for the process (or the calling process). Third party applications can honor the feature using this API, or they can choose to display pictures of cats instead of running normally.

Does anybody know what the logic behind this is? I assume "incognito" modes in browsers don't expose something similar. Is the idea that if this is provided, then application programmers will be less inclined to attempt to subvert the system?


From what I've read: It always disables access to contacts, location data, and the like. Apps, however, have their own saved state (say, your score in a game). The idea is they can selectively choose to run in Guest mode when incognito is enabled.

It'd be cool if they forced apps to run in a temporary directory like how incognito mode saves cookies in the browser. Apps would appear as if you wiped their data. CyanogenMod's implementation seems like something you'd leave on, though, and constantly losing your data would be no fun (no server to backup all changes you make, unlike the web).


It's meant for content providers. Like, you have an app which the users can use to take pictures with and then another app chimes in "Hey bro can I take a look at all this delish data you have there", and the content provider is like "Whoa dude, lemme check if you incognito... Oh, yeah, have some kittens instead."


I gladly welcome this. While it's not nearly as powerful as OpenPDroid or similiar, it's a good option designed for the "average user".

I know that the average user isn't going to flash a new rom, but that's exactly the feel that I get from CyanogenMod: a polished additional experience over AOSP, that even the average user could use and enjoy.

Other custom rom, like AOKP, already include a more featureful permission manager. It gives all the control you'll ever need, but it's not as easy to use and it might cause some applications to crash. And the "advanced" user can always flash OpenPDroid over CyanogenMod, thanks to the auto-patcher it only takes few minutes.

Keep also in mind that this is designed pretty much for Facebook, the most hated application on Android.


I'm not an Android user, so I'm curious: what's so bad about the Facebook app?


If you do a quick search of the Android Forums, a general complaint is just the performance of it while Facebook runs in the background as a service (impacting the currently used app) . Also tends to be a battery hog from all the syncing it does. I don't want to get into the whole privacy debate on it, so I'll let someone else field that part.

However, Android Permissions are "all or nothing" when you install an app. Combined with apps being able to potentially access much more than other platforms based on the permissions an app requires (as well as any app can read your sdcard without permission prior to Android 4.1 [though it's still disabled by default on 4.1 so apps not accounting for that permission don't crash]) and the need of some people to install certain apps, they must choose what is more important--potentially giving into whatever permissions this app wants or doing without.

I don't personally use it because I don't want Facebook on my rooted Android device (though I'm like that for most apps), but I have seen those reoccurring complaints over the last few years.


Can I get away with uninstalling the main Facebook app but keeping Messenger to save battery, or will I have to opt for an IM client that doesn't work with Facebook chat groups?


I never used the Facebook app on Android personally, so I do not know. Was not even aware they were two separate apps. Perhaps someone else can chime in.


This looks like it would be an excellent addition to CyanogenMod. Also, for any CM users that might be lurking: Have any of you been able to get SEforAndroid (http://selinuxproject.org/page/SEAndroid) running? I haven't spent too much effort researching this, but would be very interested to hear some anecdotes/experiences.


It's on my list of things to integrate into my own Android Builds, but have not had time to do much AOSP modding lately.


Another option I've found is xprivacy using the xposed framework

http://forum.xda-developers.com/showthread.php?t=2320783


Note that Cyanogen Mod has previously rejected features that would cost Google ad revenue because they don't want to anger Google.


Without a citation its complete bs. If you're speaking of cornerstone it was not because of Google its because of stability and apps. If cornerstone was useful some ROM would have integrated it and its not found anywhere.


He probably talks about this rejected 2011 patch: http://review.cyanogenmod.org/#/c/5677/ The first comment reads: "I am not sure that this is the direction I want to see CM go. This will piss off developers, carriers, and probably Google."


If you continue reading the thread its primarily because its unfriendly to developers. Seeding dummy data and interfering with developer source of revenue is not something they wanted at the time. Even with this incognito mode, they are attempting to do it in a developer friendly way.


Yep, they want to retain the API's semantic as much as possible. BTW, OpenPdroid and similar are even more invasive and unfriendly to developers and revenue (randomize IMEI on each call,etc.). Regarding the pleas to merge this: That patch will definitely not make it into CM. That's also the reason why the original PDroid has been delivered as both a normal patch for the source and as .smali patch for use with apktool to enable easy integration the way autopatcher does.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: