[tor-talk] Orbot and firewall?

[Number Six]

On Wed, Mar 21, 2012, at 09:41 AM, tor at lists.grepular.com wrote:
> On 21/03/12 05:11, Number Six wrote:
> > I'm actually curious if the implementation in LBE is better tolerant
> > to app failure than what Cyanogenmod has. The Cyanogenmod
> > implementation causes apps to get exceptions thrown at them when the
> > code that needs the permission tries to execute. Some apps catch
> > these exceptions and move on. Some simply die.
> >
> > It is possible that what Mike means by "not nearly is good" is that
> > LBE's "state of the art hooking techniques" actually have a more
> > elegant solution to the exception problem (such as causing all APIs
> > that require the permission to silently fail without throwing
> > exceptions).
>
> As I understand it, the LBE implementation supplies fake data, instead
> of causing exceptions to be thrown. Eg, it will return a fake IMEI, or
> an empty contact list etc. I've not had it crash any apps for me.

Interesting. While this is quite awesome, it does seem like a situation
where it would be really be useful to have the source code available...

Who knows if this "fake data" has been properly generated.. For all we
know, it could just transmit a randomly generated yet persistent GUID
for your IMEI... Or, more subtly, it could seed its PRNG with a constant
value (say your "Phone Identity"?) to ensure the same result...

> The reasons are mainly down to usability. When you install an app
> through normal channels, LBE Privacy Guard sets sane defaults. Eg, it
> will set access to location to be "Ask", so the first time the app
> attempts to access my location a message will be popped up giving me
> the option of allowing/blocking and remembering (or not) that
> decision.

Word. Having a permissions umask applied upon install does sound
very nice...

> It also lets you block access to the network per app, and it lets you
> set permissions depending on wifi or 3g per app. This is important as
> it is a lot easier for end services which are regularly polled to
> track your location and behaviour if you're constantly popping on and
> off different wifi networks (work/home/coffee shop etc). If you only
> connect via 3g, then they're able to determine much less about you. Of
> course, if you're using Orbot, that's even better.

These sorts of permissions are available via DroidWall.. However, at
some point between initial install and my permissions enable/disable
audit (after discovering the Cyanogenmod feature the other day), I've
realized that DroidWall now also requests the "Phone State and Identity"
permission. Damnit all to hell...

> The user interface is extremely well polished for an app like this
> too. It is easy to see all of the apps that have permission to send
> SMS for example at a quick glance, and whether or not LBE is blocking
> them. It even displays how much bandwidth each individual app has used
> over wifi and over 3g separately, with graphs. I can see how many
> times each app has attempted to access some data, eg my call logs, and
> how many times it has been blocked from doing so.

Yeah, querying my installed app list by permission is also something
I've always wanted...

> I completely understand why some people may not feel comfortable
> using it though. Thoughts about the software being evil *have*
> crossed my mind. I would be much happier if the source code was
> available. Even happier if stock Android or Cyanogenmod had these
> capabilities built in.

Can one of us agree to file a bug in the Cyanogenmod ticket tracker
asking for a better implementation of the permissions handling to more
closely match LBE's features?

I would volunteer, but I'm still afraid to actually run LBE...

I see 4 main advantages of LBE so far.

1. Don't throw exceptions. Return fake data and/or fail silently.
2. Apply some sort of permissions umask to freshly installed apps.
3. Provide the ability to view your installed apps by permissions.
4. Ship with a DroidWall that doesn't need "Phone Identity" perms.

Anything else?

-- 
http://www.fastmail.fm - Same, same, but different...