New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Internet-enabled addon android app (WAS: Support for data requested by apps (e.g. weather)) #302

Open
IzzySoft opened this Issue May 13, 2016 · 56 comments

Comments

10 participants
@IzzySoft

IzzySoft commented May 13, 2016

I'm using a Pebble Time Steel initialized with the latest Gadgetbridge (on an LG P880 running CM11/Android 4.4.4) and just updated to FW 3.11.

It seems that several apps do not work correctly with Gadgetbridge – that is, they start normally but can't get data:

  • Watchfaces loading weather data never show weather data (e.g. Digital and Weather)
  • Apps loading other data either do so eternally (TripAdvisor) or display an error saying "try again, or restart your Pebble app" (Get Me Out)

Is that an error on my end, or is it just impossible to get that working without the official Pebble app? I wanted to avoid using that (got no wish to register and permanently send usage data etc. to some service – which is why I decided for Pebble & Gadgetbridge in the first place :)

@danielegobbetti

This comment has been minimized.

Contributor

danielegobbetti commented May 13, 2016

Gadgetbridge does not have internet access, hence every watchface that requires data from the internet is not going to work.

For the weather, there is an experimental branch (quite outdated, at this point) that is using intents to gather the data from an external app (that is in turn connected to the internet).

Also for watchapps configuration we used a workaround that opens the configuration page using a browser.

Internet access permission is not going to be added, so I'm closing this issue as invalid.

@ashimokawa

This comment has been minimized.

Contributor

ashimokawa commented May 13, 2016

The only way to use pebble apps with internet access are those who use an external android companion app.

We should think about adding internet access and have some internal whitelist for watch apps.

However having no internet access at makes us most trustable - so this is quite a dilemma.

@IzzySoft

This comment has been minimized.

IzzySoft commented May 13, 2016

@danielegobbetti Thanks for pointing out the relationship! I not only respect but even welcome the attitude shown towards the INTERNET permission – and though it may sound like I shoot myself in the foot, I fully agree to keep it that way (privacy first – this is why I decided for Gadgetbridge after all). Still I disagree on closing as "invalid" (read on below for the reason).

@ashimokawa Thanks to you as well pointing to the "work around" with using companion apps. This definitely is a restriction, but at least something one could do straight away without waiting for some updates.

As for the INTERNET permission, I'm with @danielegobbetti here: it should not be added to Gadgetbridge – at least not directly. What I'd suggest here would be an addon, if possible, that could act as the "GadgetNetBridge" (<- name suggestion ;) That way people with a strong focus on privacy and willing to bear with the restrictions implicated simply can leave that off their devices – while others willing to compromise can use it to gain additional functionality.

Why am I that "stubborn"? I guess I'd end up in that second group (compromise). Seeing what's all collected by the official Pebble app, and reading their Privacy policy (plus this Reddit), I really, really hesitate using their app – and by that knowingly have to do without the health and voice functions. But having networking capabilities via a Gadgetbridge addon, I can at least allow controlled access: to have weather details, remote-control my own equipment (with apps like HTTP Push), navigation guides (Get Back in Time, Maptastic) or local transport information (Get Me Out), just to name some examples.

Within the addon there could even be control on which watch-apps are allowed to access the network (either using a white- or a black-listing mode) for additional protection. Being open-source (and the code can be "audited"), such a solution would be fully trustable IMHO.

@danielegobbetti Please let me know if I should file a separate issue on that (requesting such an addon) or if it would be rather misplaced here as, if I guess correctly, "GadgetNetBride" would become a "separate project" (e.g. github.com/Freeyourgadget/GadgetNetbridge)

@danielegobbetti danielegobbetti changed the title from Support for data requested by apps (e.g. weather) to Internet-enabled companion app (WAS: Support for data requested by apps (e.g. weather)) May 13, 2016

@danielegobbetti

This comment has been minimized.

Contributor

danielegobbetti commented May 13, 2016

@IzzySoft @ashimokawa I changed the title of the issue and reopened it, just to keep track of eventual progress.
I added the wontfix label to make clear that this is not going (or at least it's very very very unlikely :) ) to happen withing gadgetbridge.

@IzzySoft

This comment has been minimized.

IzzySoft commented May 13, 2016

Thanks @danielegobbetti – and as stated before, full ack that it should not be going directly inside Gadgetbridge.Still hoping for the addon solution – as IMHO that would be the perfect way for both sides :)

@IzzySoft

This comment has been minimized.

IzzySoft commented May 13, 2016

tackling things together, #49 would be another candidate requiring internet. So it might be considered putting these 3 (and possible others I didn't catch) into one "internet companion app" – unless modularity calls for separate ones.

@ashimokawa

This comment has been minimized.

Contributor

ashimokawa commented May 14, 2016

@IzzySoft
We should not use the the term "companion app".
When I say "companion app" I mean a pebble companion app for android.

Right now Gadgetbridge works with them. A few good examples are "Ventoo" or "Dialer for Pebble".
You have to turn 3rd party app support on in Gadgetbridge.

But I do not like these for one reason that neven had been made public AFAIK:

Security in PebbleKit is non-existant and in case of "Dialer for Pebble" even destroys security completely for your Phone (Every Android app without any permission at all will be able read your Addressbook and send 1000 premium SMS for 5€ each without you even notice if you have "Dialer for Pebble" installed, even if you do not own a Pebble at all and have neither Gadgetbridge nor the official pebble app installed).

@IzzySoft

This comment has been minimized.

IzzySoft commented May 14, 2016

@ashimokawa The term "companion app" in the title was introduced by and edit @danielegobbetti made. If you "look behind" you will notice that I initially spoke about an "addon to Gadgetbridge" (which I named "GadgetNetbridge").

As for the security issues you've mentioned: those exist even without Gadgetbridge being installed, as you've pointed out. I guess what you wanted to say is if the user installs "GadgetNetbridge" on his device, each and every app would be able to access the network. Which is why I mentioned covering this by a whitelist/blacklist managed in GadgetNetbridge.

Being neither an Android nor a Pebble dev I don't know what's possible in this context, but if possible I'd even wish for an (optional) popup (or log) whenever an unauthorized app tries to get through (which then probably needs another option to simply ignore it for a given app). This way one can identify rogue apps (to get rid of them), manage which other apps should get Internet or which usually want it but shall be used without.

All that of course is based on the assumption that "GadgetNetbridge" can identify where the request comes from.

@IzzySoft

This comment has been minimized.

IzzySoft commented May 14, 2016

PS: One more thing "GadgetNetbridge" could do, thanks to the Internet permission: directly check for firmware updates (e.g. fetching a text file kept in the repo or some other place where the required details are maintained in).

This could of course fire the idea to include access to the Pebble app store as well for app installs and updates – but I'm not sure if that should go here or rather into its own addon, if at all. Though it would be very convenient, of course :)

To not get the wrong idea: I'm not requesting all that here in this issue, but just want to show reasons why such a "GadgetNetbridge" would be a good idea, and to give that idea some weight. If a decision is made in favor of it, "GadgetNetbridge" most likely will get its own project – and all those ideas should then become new "issues" there :)

@danielegobbetti danielegobbetti changed the title from Internet-enabled companion app (WAS: Support for data requested by apps (e.g. weather)) to Internet-enabled addon android app (WAS: Support for data requested by apps (e.g. weather)) May 14, 2016

@danielegobbetti

This comment has been minimized.

Contributor

danielegobbetti commented May 14, 2016

Sorry for the confusion, I renamed the issue.

@ashimokawa

This comment has been minimized.

Contributor

ashimokawa commented May 14, 2016

@IzzySoft
With Android it is not possible to check the source of an "Intent" which is the way most Android apps communicate with each other.
That's also a reason why companion apps written with PebbleKit are such a security hazard.
They can't know if a message was forwarded from a watchapp by the official Pebble Android App or by someone else. So "Dialer for Pebble" would just happy send out these premium SMS in the name of say a "tic-tac-toe" game from android play without any permissions.
Ironically that's also luck for us, so we can also be part of the game and communicate with these companion apps.

Our apps would have to communicate more securely by "content provides" which would be a bit more pain and then I wonder if it would make more sense just to add the internet permission and build two flavors of Gadgetbridge - one with the permission and one without. So users can choose which to install (instead of deciding whether or not to install the addon app)

@IzzySoft

This comment has been minimized.

IzzySoft commented May 14, 2016

@danielegobbetti Thanks :)

@ashimokawa Thanks for those details! Is there some "quotable" documentation/reference on that "security hazard"? I slowly get an idea on its background (while two Android apps would cover that by a permission declared by the one to be accessed and must be requested-by / granted-to the other, that won't work with "watch apps" as they cannot request it). I'd like to write up an article on this (in a way understandable by the end-user), so a "quotable source" would be a good idea :)

As for "addon versus two-flavors": Both would fit the purpose, and I'd accept both solutions. Please consider maintenance etc. as well before making a decision: Which solution would be easier to maintain? Would a "modular approach" (addon) have other advantages maybe needed at a later point? One such advantage would be "small footprint" if more addons were planned: users then could take the "core app" and add only those "modules" they need. As pointed out above, there might be 3 additional candidates already: voice, fitness, app-store. Moreover, having an API for addons might appeal other devs to contribute their own :)

@ashimokawa

This comment has been minimized.

Contributor

ashimokawa commented May 15, 2016

@IzzySoft
Thank you for your suggestions.

Regarding the "security hazard" I cannot name any sources because this is what I found out while creating Gadgetbridge. I originally assumed I would have to write a drop-in replacement for PebbleKit Android to make companion apps (such as "Dialer for Pebble") work with Gadgetbridge. But I found out that would not be necessary because data exchange between the official Pebble app and companion apps are broadcasted throughout the whole system.
Now PebbleKit could have been made to just broadcast to the official Pebble App. And the other way round Pebble could have implemented a mechanism where the target Android app is specified within the watchapps .pbw.
They didn't do that.
And even if they did they would have only solved half of the problem. As I said in Android you can't get the source of the Intents, so everyone could still make companion apps to react to rouge Android Apps trying to exploit i.e. "Pebble Dialer".
A solution for the problem would be (additionally to the "unicast" approach I mentioned above) if the companion apps would generate random tokens and send them to the official Pebble App as soon as the corresponding watch app gets started. After that the companion app would have to ignore all Intents not carrying the token.
If pebble implements such security, we are out of the game.
So I am digging our grave here ;)

@ashimokawa

This comment has been minimized.

Contributor

ashimokawa commented May 15, 2016

I have one quote I like which gives some insights on how Pebble thinks about security:

Pebble-enabled apps are expected to be good citizens and only inspect broadcast containing their UUID

(Source: https://github.com/pebble/pebble-android-sdk/blob/625e63b460bfbc295a768dfa751d2050f8cf540f/PebbleKit/PebbleKit/src/main/java/com/getpebble/android/kit/PebbleKit.java line 539-540)

And how a well-known Pebble 3rd Party developer thinks about us:
https://twitter.com/YGalanter/status/635242691157192704

@IzzySoft

This comment has been minimized.

IzzySoft commented May 15, 2016

Thanks for the detailed description, @ashimokawa – that makes the precaution of "no internet permission" even more understandable. And gives a shiver! Plus rises the question if other systems (e.g. Android Wear) solved it in a better way. But that's beyond this issue. Though it should be pointed out the risk is there – it's there with the official Pebble app as well (and even more).

@ashimokawa

This comment has been minimized.

Contributor

ashimokawa commented May 15, 2016

@IzzySoft
No, adding internet permission in Gadgetbridge would not make security worse.
We only forward incoming pebble messages to watchapps (I assume the official Pebble App does the same), so external rouge apps could send crap to watchapps on the pebble but could not make Gadgetbridge to something like sending an SMS or sending data to some server.

The problem lies in the non-existent security within the PebbleKit Android concept. So the "companion apps" can be persuaded to do evil things by anyone, plus communication can be sniffed by anyone.

"Dialer for Pebble" ist just a very good example because it would send SMS to anyone just by receiving an intent from any unknown origin

So who is to blame? Google because they designed Intents in a way where no one can check the origin of Intents, and Pebble because they didn't bother to find a smart workaround (for example the unicast + token thing as I outlined before).

@IzzySoft

This comment has been minimized.

IzzySoft commented May 15, 2016

@ashimokawa one more reason we should have the possibility of "internet access for watchfaces/watchapps" instead of referring people to use companion apps :)

Btw: Thanks for the clear example. Not blaming the dev, but I definitely won't use "Dialer for Pebble" (or similar apps), knowing that. Speaking of which:

Now I'm additionally worried for other companion apps. I intended to use e.g. Glance for Pebble. But due to its permissions (and the "security concept" you've just explained), wouldn't that mean I'd expose my contacts, calendars and mails to "any app" – in addition to the "send SMS" you've explained with "Dialer for Pebble"? That sounds like a security nightmare to me, as I'd have no control over which app might abuse it. Though of course only using "trusted apps" minimizes the risks one creates by installing such a companion app, it still is an "added risk".

@ashimokawa

This comment has been minimized.

Contributor

ashimokawa commented May 15, 2016

@IzzySoft
You are absolutely right, most probably Glance for Pebble is also a security nightmare as you mention.
There is a slight albeit very unlikely possibility they implemented sending intents themselves and only target the official pebble app, which would not expose any of the data then (and also would make using it with Gadgetbridge impossible). You can check if it works with Gadgetbridge, then its a nightmare, because what we do - everyone can do - without permissions at all.

In any case, if "Glance for Pebble" does anything in the name of the pebble watchapp by receiving a message from it - it is still exploitable to do exactly that when told by everybody else without requiring any permission.

@IzzySoft

This comment has been minimized.

IzzySoft commented May 15, 2016

@ashimokawa

So in short: Whatever a companion app gets granted as permissions can be subject to abuse by any "bad app". Which means to a) take a very close look at the permissions requested before installing it, and b) refuse unwanted/dangerous permissions when installing it (either "on-request" with Android 6+ – or with an app like Xprivacy when rooted).

Though not directly related to Gadgetbridge, it might be useful to point that out in some piece of documentation. Best place would be on explaining the Pebble settings, where one can tick the box to allow access for companion apps. Or maybe a page linked from the Pebble page in the wiki, dedicated to companion apps. Or both, with the config page pointing to the companion page for details. What do you think? Should I start on such a (companion) page when I find some time for it? I'd leave the "linking" out so it can be done when approved :)

@tecufanujacu

This comment has been minimized.

tecufanujacu commented May 20, 2016

In the past I used the great watchface TCW(github) by Alexsum.
TCW uses its great companion app for android(github) and the companion app gives the ability to get weather infos and a lot of other great options for the watchapp for example:

  • the ability to sync the watchapp with a local calendar on android
  • the ability to lock the phone when the watch loses the bluetooth connection with android
  • the ability to choice the weather provider
  • the ability to watch the phone's battery status
  • the ability to watch missed calls, sms and email icon in the watchface

I think that this watchface and its companion app are a great starting point for this project and would be awesome if they could be included in gadgetbridge, would be awesome if gadgetbride cames with an integrated whatface as this.

The watchapp and the companion app still work but unfortunately they aren't more developed and in effect also their site has expired: http://pebblewatch.pw/tcw/

If someone want to test the TCW companion app for android I have a copy of the apk and I can upload it somewhere.

P.S.: I uploaded temporarily the android companion app here.

@IzzySoft

This comment has been minimized.

IzzySoft commented Jun 15, 2016

@noctux you might have missed one point: MAXS can protect its API by permissions as all its components are running on the very same (Android) device – while in our case, the watchapps run on the watch, and thus are not known to the Android system, so they cannot use the permission system (at least that's how I understood it).

IMHO there might be a work-around for that, as GB should be able to tell whether a request comes from the watch (BT MAC of the caller). That "Internet addon" could then be protected by permissions, or by other means only accept calls from the GB main app. I'm not an Android dev though, so I cannot tell for sure.

@noctux

This comment has been minimized.

noctux commented Jun 16, 2016

@IzzySoft: This all sounds a bit strange and like a whole bunch of stuff mixed up together. Pebbles bluetooth-connections (which use Bluetooth v2.1 and upwards, sorry for the a bit dubious reddit reference :/) are both authenticated and encrypted, so the Gadgetbridge-App should most definitely be able to tell which device it is talking to (ok, assuming Androids and Pebbles bluetooth stack have no exploits, which is a bold assumption and that I haven't missed out on fundamental attacks against Bluetooth v2.1+). A very very basic security-assessment I've found on the pebble is here, the referenced Analysis of the Numeric comparison keyexchange is here and general information on bluetooth security is here. So another device should not be able to mascarade as your pebble, and the Device-MAC should be reliable.

SO to me, the situation sounds like, that only installed watch-apps on your manually paired Pebble can use an secure channel to access the GadgetBrideApp, which in return would be able to use a connection secured by the permission system to connect to the Internet-Addon-App, which would execute the apps PebbleKitJS to query the internet, which sounds like desired behaviour. But we might want to filter that access on a per watchapp basis. This is why I asked whether anyone has information on the reliability of the AppUUID-information in pebbles watch->smartphone messages, which would need to be trustworthy to use it for "firewalling" purposes. Or am I missing out on something?

@IzzySoft

This comment has been minimized.

IzzySoft commented Jun 16, 2016

@noctux that's the raw idea I have – but I'm no dev: the watch-app talking to GB – which "authenticates" it as being a watch-app and delegates the request to the "Internet Addon". The latter should be a separate addon as GB itself shall not have the internet permission.

The problem initially described was concerning 3rd-party companion apps, so it might be slightly different. Maybe @ashimokawa can take a look at your suggestion, as he's the one familiar with the topic :)

@danielegobbetti

This comment has been minimized.

Contributor

danielegobbetti commented Jun 17, 2016

@noctux thanks for investigating and mentioning a possible solution. From what I understand by your description and a quick look at the MAXS App, it looks to me that the main app (which exposes the permissions used by the modules) is a "message dispatcher", and the modules are the one performing the operations. MAXS app secures the message exchange from the dispatcher to the actors, but I am not sure if also the opposite direction is secure.

Anyway I believe we need to come up with a concrete implementation idea, then we could reach out to external experts (I hope the MAXS developer will help us) to check its feasibility.

@IzzySoft Honestly I am not so worried by the BT layer security. :)

@IzzySoft

This comment has been minimized.

IzzySoft commented Jun 17, 2016

@danielegobbetti I just tried to sum up what ashimokawa told me :) And as for the MAXS dev: If I'm not hit by Alzheimer's, that would be Flow – who lives not that far away from me :) I had pretty close contact with him on Android.SE (back when he was mod there – now we "switched places" as he got too busy with other things, one of those obviously being MAXS).

Anyway: count me in for testing once you've got that far 😸

@noctux

This comment has been minimized.

noctux commented Jun 20, 2016

@danielegobbetti Yeah, your basic understanding of MAXS seems correct. But the MAXS app is really only the dispatcher, so there are not only actors but also "transports"/input-channels like MAXS Transport XMPP which receive messages and send those to the main app. So you have communications going both ways. But the idea of securing those is the same: There are two additional permissions (for different Access levels, like ACLs) called "org.projectmaxs.permission.USE_MAIN" and "org.projectmaxs.permission.USE_MAIN_AS_TRANSPORT" which are used to secure communications from the addons to the main app. So the idea is just the same: If you can do secure, directional communication via permissions, you can do bidirectional ones as well :)

Anyway I believe we need to come up with a concrete implementation idea, then we could reach out to external experts (I hope the MAXS developer will help us) to check its feasibility.

Sounds like a plan :) @IzzySoft Yep, that's Flow, and I know that he does at least own a pebble (first generation), so we might be lucky :p

@IzzySoft

This comment has been minimized.

IzzySoft commented Jun 20, 2016

@noctux Sounds cool! Give him regards from me (Izzy – and if he asks "who", the one from Android.SE). Would be great having him aboard, and I'd be happy talking to him again :)

@danielegobbetti

This comment has been minimized.

Contributor

danielegobbetti commented Jun 20, 2016

A further question about MAXS (just putting it here as a reminder, but answers welcome): is impersonation also a threat taken into account? In other words, are these additional permissions bound to the app package name or is it possible for the app com.rogue to declare a permission like org.project-maxs.my-permission?

As far as I understand android would provide also a signature permission check (where two packages must share the same release signing key), but this cannot be used when using fdroid, unfortunately.

@IzzySoft

This comment has been minimized.

IzzySoft commented Jun 20, 2016

@danielegobbetti
That's the drawback of F-Droid compiling all stuff itself (and thus all its apps sharing the same signature). I could of course offer my repo as an alternative: my "updater" automatically grabs compiled .apk files from the releases/ pages on Github (for projects I configure, that is), so your own signature would be used then.

Other than that: AFAIK there was something taking the GID into account. But not being a dev, I'm not familiar with the details at all – so this might well be the same thing going by a different name ;)

@noctux

This comment has been minimized.

noctux commented Jun 21, 2016

A further question about MAXS (just putting it here as a reminder, but answers welcome): is impersonation also a threat taken into account? In other words, are these additional permissions bound to the app package name or is it possible for the app com.rogue to declare a permission like org.project-maxs.my-permission?

(Note: the answer is very opinionated)

Is this really what we want? I mean, that would be an attempt to protect the User from its own stupidity... which will fail most of the time anyways. IMHO, people should read the permissions they grant. If they don't, it's their problem and nothing can save them there? On the other hand, it might be that I discover the one and only way to write gadgetbridge addons or to do better speech recognition in two years time and want to start my own variant, or use my own development version of the addon alongside the Release-version of the main app, etc.pp., a multitude of things that will be made more difficult with signature verification... :) So the permission is exactly what it should say on the tin: "If you grant this permission to app xy, then it can use the following features of Gadgetbridge that are exposed GB-addons: [list here]".

A negativ example for context: Have you tried running Signal without the google play framework using microg for the GCM service? Signature pinning on signals part makes that really hard, without sacrificing a whole lot of security by turning of any kind of signature verification also in system-apks via an Xposed hook... On the other hand, a permission would grant the same level of security but allow for easy replacement....

I mean, there are serveral ways to obtain a credible GB-release-version (last but not least the releases-category of this github-project), or even I decide to trust the fdroid maintainers, etc.pp.. If I start using shady apks from shady sources and grant them any permissions they ask for and as a result my device gets owned, then this is my private user-level problem. This is nothing that can be effectively solved at the technical layer. And lets face it. if I as malware vendor decide to socialengineer people into installing my completely legit software on their device that way, it is easier to ask for the bluetooth/calender/whatever permission and the user described above will simply grant it. Or I use a known exploit against the mass of older android handsets out there.... So I would argue to not fix something that isn't broken.

@IzzySoft

This comment has been minimized.

IzzySoft commented Jun 21, 2016

people should read the permissions they grant

LOL! (sorry, couldn't resist). Do you really think someone who subscribed to Paypal has read the Paypal TOS? Can you name just one? I tried once and gave up after an hour (but with the result I still have no Paypal account). Same with the permissions: As soon as the page pops up, people hit the button. Those few who read them (not to speak from understanding them) are quite a minority.

But yes, I agree: nothing we (or GB) can do something about (and those who don't care can't be helped anyway and need not be protected). But then there's something else to consider: Are those permissions really shown on install? With the changes in the past months, "normal" permissions are often not shown (and what's counted to be "normal" makes ones hair stands on end, which is why I check them beforehand e.g. via AppBrain or F-Droid Web pages). I'm fully with you, a permission-protection should do (and that's also what e.g. Tasker does, so 3rd party developers can write plugins for it). Over-Engineering can't be the way: "If you make an app fool-proof, only fools will use it" :) Also remember: In the competition between developers making their apps more fool-proof and nature producing greater fools, currently the latter is in the lead :)

Apart from that: the question here was not about 3rd party apps communicating with GB – but GB communicating with its "internet companion". This might be a bit different – unless we want 3rd party apps accessing the companion, which originally was thought to be just for watchapps requiring Internet. 3rd party apps can request their own Internet permission.

@noctux

This comment has been minimized.

noctux commented Jun 21, 2016

Same with the permissions: As soon as the page pops up, people hit the button. Those few who read them (not to speak from understanding them) are quite a minority.

I do read the permissions of the android apps I install. And GadgetBridge users are (sorry to say that, because the devs do a marvellous job) a minority.

With the changes in the past months, "normal" permissions are often not shown (and what's counted to be "normal" makes ones hair stands on end, which is why I check them beforehand e.g. via AppBrain or F-Droid Web pages).

At least if you install the app via fdroid without the System-Service plugin, they are shown...

Apart from that: the question here was not about 3rd party apps communicating with GB – but GB communicating with its "internet companion". This might be a bit different – unless we want 3rd party apps accessing the companion, which originally was thought to be just for watchapps requiring Internet. 3rd party apps can request their own Internet permission.

Jupp, you are right. But if we implemented it, I would implement it in a way that fosters the idea of GB-Addons, which might come handy anyways if you think about features like voice input (#189), which is also not necessary for all users in the main app, etc.pp.. In that case the Intends they consume would be the API, and the Permissions control which app may receive the data.

@danielegobbetti

This comment has been minimized.

Contributor

danielegobbetti commented Jun 23, 2016

Just to add it to the list: fdroid itself interacts with the system privileged extension, somehow, hopefully, securely. I checked their manifest files and they do use the signature protection level but I don't have a deep-enough understanding of the implications. I just didn't want to forget about this when we start working on the feature.

@Flowdalic

This comment has been minimized.

Flowdalic commented Jul 8, 2016

Hi @IzzySoft (long time no see!), hi @noctux, hi @danielegobbetti

When using custom Android permissions you just have to ensure that the permission was defined by the correct entity (i.e. your apk), as otherwise a malicious entity could define the permission before you and change its description and/or protection level. Mark Murphy (of CommonsWare fame) has described this behavior, which I also discovered when implementing MAXS, here: https://github.com/commonsguy/cwac-security/blob/master/PERMS.md

Changes of permission handling in Android 5.0 improves the situation IMHO, but since GB targets API 19 (Android 4.4) you have to ensure that the used permission is really the one you defined (and not defined by some other app).

MAXS uses the approach where one application defines all custom permissions used by MAXS. This application is MAXS Main, which also checks for the integrity of the permissions. The relevant code is here.

Hope that helps.

@IzzySoft

This comment has been minimized.

IzzySoft commented Jul 8, 2016

Hi @Flowdalic – indeed, feels like eternity. We often think of you at ASE :)

@danielegobbetti @ashimokawa The "MAXS Main" role of defining all perms should be taken by the current GB – as that's the one everybody will have installed (and none of the discussed "plugins" makes sense without), so it will count as "core" then anyway.

@sjp4

This comment has been minimized.

sjp4 commented Dec 20, 2016

A different flavor of the main app with the Internet permission would be easiest to implement - otherwise if you split out Internet into a separate apk then:

  • What is the interface boundary? If using Webview for JS execution, then either the Webview has to live in the apk which has the permission (Webview will perform its own requests unless you override that), or you have to manually intercept all requests, then forward them through the interface (probably syncronously, given the Webview override interfaces). Although putting the whole JS component in a separate process would also potentially be a complicated interface...
  • What is the interface mechanism and what is the security? Intents can be targeted and permission-based (I'm don't know what the limitation is with certificate-based permissions here, but it sounds like there is one?), I wouldn't recommend ContentProvider for this, or alternatively AIDL could be used - this can also be permission-based IIRC, but importantly the Service can have a whitelist of package names and check each client against them.
@Avamander

This comment has been minimized.

Contributor

Avamander commented Jan 27, 2017

Maybe multiple solutions could be used together?
Something like this:

  • Original insecure API support that can be toggled on-off from settings
  • Similar-to-original more secure API that requires maybe HMACSHA3-256 based authentication, it doesn't have to be intent-based though.
    • App that needs unsafe features will have to first pair with GadgetBridge, then it's given a HMAC it has to keep a secret
    • After that app could request a nonce (if replay attacks are suspected) and then with the secure HMAC a signature for the request can be created, thus the request creator can be validated and the request fulfilled.

This solution would allow old apps to keep working if needed and, depending on the communication method selected for the new API, simple new secure API that allows more dangerous requests fulfilled.

@danielegobbetti

This comment has been minimized.

Contributor

danielegobbetti commented Aug 5, 2017

A proof of concept based on intents and messenger has been tested with a locally modified background-javascript branch and I'm happy to report that it works. As currently it's an open relay to the internet (read: there is no validation of the requests being made) I am not publishing it as is for the time being. The news is that we found a solution and have a working prototype at least for the case of GET requests :-)

@danielegobbetti danielegobbetti moved this from Whishlist to Being worked on in Pebble support Oct 17, 2017

@gudenau

This comment has been minimized.

gudenau commented Nov 1, 2017

I read this super quick, so forgive me if I missed something.

Here are my thoughts on this:

The dictation should be a separate application so you can have different providers, online and offline for example.

The internet plugin could be setup to only allow certain URLs, limiting the impact of misuse.

Gadget bridge could manage permissions of watch apps, it should know what app is requesting what correct?

Like with the MAXXS thing you could setup permissions, I'd recommend that to be honest. Only problem is with F-Droid you can't trust signatures if that one point was correct. (Could a custom repo fix that?)

Intents are inherently insecure, they are hard to secure. Who's to say there isn't a roge app with a trusted package?

Also the biggest problem with using signatures for security, users wouldn't be able to create custom providers. App specific dev mode until reboot or something?

(I did in fact read PayPal's TOS)

@SolidTux

This comment has been minimized.

Contributor

SolidTux commented Jun 29, 2018

I think the URL filter is a really good option. Maybe block all by default and have an option to log and display all accessed URLs. From there you could select those URLs or domains you like to activate.

Is there any help needed/possible here?

@danielegobbetti

This comment has been minimized.

Contributor

danielegobbetti commented Jun 30, 2018

Is there any help needed/possible here?

Yes of course there is, at multiple levels :) Open projects are:

  • the internet enabled addon itself (which is unreleased because it's basically an open proxy for every app even without internet permission) needs
    • GUI for logging, authorization of apps, etc.
    • securing the communication with other apps (to avoid it being an open proxy)
    • ...
  • integration between Gadgetbridge and the internet addon
  • decide where the URLs are whitelisted (who does what)
  • ...
@SolidTux

This comment has been minimized.

Contributor

SolidTux commented Jun 30, 2018

Is the repo for the internet addon somewhere?

@danielegobbetti

This comment has been minimized.

Contributor

danielegobbetti commented Jun 30, 2018

No, but it's literally a 10-row service that does the opposite of the messagehandler in Gadgetbridge.

It has no GUI and no check, as mentioned above. If you want to help we can create a repo for it.

@SolidTux

This comment has been minimized.

Contributor

SolidTux commented Jun 30, 2018

That would be great. I'm not really experience with GUI stuff, but I'd be happy to give it a try.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment