Internet-enabled addon android app (WAS: Support for data requested by apps (e.g. weather)) #302
Closed
opened 6 years ago by izzy
·
57 comments
No Milestone
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
This issue currently doesn't have any dependencies.
Loading…
Reference in new issue
There is no content yet.
Delete Branch '%!s(MISSING)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
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:
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 :)
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.
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.
@danielegobbetti Thanks for pointing out the relationship! I not only respect but even welcome the attitude shown towards the
INTERNETpermission – 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
INTERNETpermission, 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)@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.
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 :)
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.
@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).
@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.
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 :)
Sorry for the confusion, I renamed the issue.
@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)
@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 :)
@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 ;)
I have one quote I like which gives some insights on how Pebble thinks about security:
(Source:
625e63b460/PebbleKit/PebbleKit/src/main/java/com/getpebble/android/kit/PebbleKit.javaline 539-540)And how a well-known Pebble 3rd Party developer thinks about us:
https://twitter.com/YGalanter/status/635242691157192704
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).
@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).
@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".
@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.
@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 :)
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:
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.
Looks like both the pebble and the android apps are open source software: https://github.com/alexsum
Sorry links were provided already... I didn't notice (from mobile)
Yes, they are both open source softwares and for this i proposed them.
I can ensure that TCW with its companion app is the best watchface that i have ever used on my pebble, I think that after Gadgetbridge it is the best open source software for pebble.
I'd like to see the TCW features integrated in Gadgetbridge, I hope this is possible.
@tecufanujacu unfortunately, the Android app just crashes right at start on my device (LG P880 with CM11/Android 4.4.4), so I cannot really test it. Watchface looks nice, though.
I/ActivityManager( 532): Displayed nodomain.freeyourgadget.gadgetbridge/.activities.AppManagerActivity: +301ms I/Timeline( 1197): Timeline: Activity_idle id: android.os.BinderProxy@42027ce0 time:44771458 I/Timeline( 532): Timeline: Activity_windows_visible id: ActivityRecord{4203d4e0 u0 nodomain.freeyourgadget.gadgetbridge/.activities.AppManagerActivity t4} time:44771624 I/Timeline( 1197): Timeline: Activity_launch_request id:nodomain.freeyourgadget.gadgetbridge time:44793846 I/ActivityManager( 532): START u0 {cmp=nodomain.freeyourgadget.gadgetbridge/.activities.ExternalPebbleJSActivity (has extras)} from pid 1197 D/nodomain.freeyourgadget.gadgetbridge.service.DeviceCommunicationService( 1197): Service startcommand: nodomain.freeyourgadget.gadgetbridge.devices.action.startapp V/WebViewChromiumFactoryProvider( 1197): Binding Chromium to main looper Looper (main, tid 1) {41f96c78} I/LibraryLoader( 1197): Expected native library version number "",actual native library version number "" I/chromium( 1197): [INFO:library_loader_hooks.cc(116)] Chromium logging enabled: level = 0, default verbosity = 0 I/nodomain.freeyourgadget.gadgetbridge.service.devices.pebble.PebbleProtocol( 1197): got APPLICATIONMESSAGE PUSH from UUID 52d59234-a54b-4da1-b048-5c5ec121f54d I/nodomain.freeyourgadget.gadgetbridge.service.devices.pebble.PebbleIoThread( 1197): Got AppMessage event I/nodomain.freeyourgadget.gadgetbridge.service.devices.pebble.PebbleIoThread( 1197): broadcasting to uuid 52d59234-a54b-4da1-b048-5c5ec121f54d transaction id: 1 JSON: [{"value":1,"type":"uint","length":1,"key":0},{"value":0,"type":"uint","length":1,"key":1},{"value":0,"type":"uint","length":1,"key":2}] W/chromium( 1197): [WARNING:proxy_service.cc(890)] PAC support disabled because there is no system implementation I/chromium( 1197): [INFO:simple_index_file.cc(437)] Simple Cache Index is being restored from disk. I/nodomain.freeyourgadget.gadgetbridge.service.devices.pebble.PebbleProtocol( 1197): APPRUNSTATE: stopped 17e9e8a6-c57d-46c5-a8da-2c7211de0b73 I/nodomain.freeyourgadget.gadgetbridge.service.devices.pebble.PebbleIoThread( 1197): unhandled message to endpoint 52 (17 bytes) I/nodomain.freeyourgadget.gadgetbridge.service.devices.pebble.PebbleProtocol( 1197): APPRUNSTATE: started 52d59234-a54b-4da1-b048-5c5ec121f54d I/nodomain.freeyourgadget.gadgetbridge.service.devices.pebble.PebbleIoThread( 1197): unhandled message to endpoint 52 (17 bytes) I/ActivityManager( 532): Displayed nodomain.freeyourgadget.gadgetbridge/.activities.ExternalPebbleJSActivity: +822ms W/AwContents( 1197): nativeOnDraw failed; clearing to background color. I/Timeline( 1197): Timeline: Activity_idle id: android.os.BinderProxy@42248b40 time:44794933 I/Timeline( 532): Timeline: Activity_windows_visible id: ActivityRecord{42074d00 u0 nodomain.freeyourgadget.gadgetbridge/.activities.ExternalPebbleJSActivity t4} time:44795125 D/dalvikvm( 1197): JIT code cache reset in 5 ms (633700 bytes 9/0)Is this an issue of GB or of TWC? "Allow access" is checked of course.
@IzzySoft, that's strange but doesn't depend from Gadgetbridge.
I used TCW with cm11 and with cm12, now I just tested it with cm13 and everything works without problems with or without Gadgetbridge installed(I just tested TCW on two different phones).
To be more accurate, using Gadgetbridge TCW isn't able to communicate with the pebble smartwatch, if you want test it unfortunately you have to use the official pebble app, is for this motive that I haven't more used TCW.
I hope that the great work behind TCW can be used in or with Gadgetbridge.
I will look into that, but right now priority is #296 and #251
I really love GadgetBridge (with MicroG they are my preferred Android apps), for now I'm busy with the university but during the august month I'll start studing android to help in gadgetbridge development and if I'll be able I'll try to integrate TCW.
BTW: Seen my praise: Smartwatches and privacy – contradiction in terms? (article in EN & DE with free Gadgetbridge promo :)
Great article! Thanks for the kind words. I had no idea that pebble employees were mentioning gadgetbridge as a viable alternative to their app for privacy conscious users. According to my sources we were tolerated but not loved by them. Good if things have changed.
If someone at pebble is reading this, we would like very much to get our hands on one of the new devices (or at the very least on firmware 4.0 preview) before they hit the market to properly support them. 😏
Glad you like it! If I cannot help coding, that's the least I can do to support the project :)
I was very much surprised as well. I hadn't considered a Pebble otherwise, to tell the truth. I cannot say whether that's the general behavior nowadays, or maybe was "a slip" or just one specific employee. Still, I valued it high and gave a thumbs-up to their support for that. So let's hope it's really a "things have changed" :)
But truth to be told: What do they have to lose? The majority of their customers will stick with their app anyway (especially those who "don't care" and "have nothing to hide"). Those who care wouldn't buy a device if there's no privacy-choice. So they can only win if they point to GB. Maybe they realized that.
You have my vote for that :)
PS: I originally offered them an article (plus maybe a chapter in one of my Android books) in return for a device to test. Now I just sent them the link to the article, asking them to send the device (or FW 4.0) to you instead. I'll keep you updated (as this issue might not be the best place for it, find my contact data in the imprint of the site with above article ;)
@IzzySoft
Thanks for the article, I liked it (read the German version) 👍
But I don't think they will send us anything, they even didn't want to send us beta firmwares (which watchface developers already had).
If the Bluetooth LE only rumous are true, then it will be a hell of a task to support these new devices.
Actually it was hard to get where we are now, some very small things were trial and error for days.
Ok we are getting offtopic ;)
@ashimokawa
Glad to read! As you saw in the verdict (Fazit), I plan for another article. Maybe after the redesign would be a better time than "ASAP"?
Well, let's say I don't expect it. But we may "wish for a star". I might be able to say more within the next 48h. Chances are IMHO 50:50.
Yeah, a bit :) If there's a better channel, just name it. You know where to find my contact details :)
First off, sorry if I've missed out something above, but my perception of the original problem is as follows:
Is this correct?
So if it is, there might be a solution. I happened to come across an android App that has an quite similar, security-focused philosophy called MAXS. The concept is that there is an Main app similar to Gadgetbridge in your usecase and then a bundle of plugable "agents", that themselves require the permissions for e.g. reading SMS, using Bluetooth or you name it.
As it also enables Shell Access and this a hell lot worse than what you/gadgetbridge want to do, so I asked the developer how he secures the intents. Turns out one can restrict the senders of an intent to apps holding a certain permission via the "android:permission" receiver property which is enforced by the Android Operating System automatically. Example for the shell module would be here.
Only small drawback of this approach seems to be a slightly more complex Installation (source):
So the user has to be forced to start the app after installation and before the installation of the modules - a fair tradeoff in my opinion and a situation that might improve with the dynamic permissions introduced in recent Android Versions.
Is this what you originally wanted? It would at least get us around having two builds and one could always add or remove the internet-access-capability (via the dedicated app) as desired.
As a Sidenote: Do you know whether the UUID is enforced on the watch-side when messages are sent? If so, we could even "firewall" individual apps/their javascript in a more or less secure manner, which would be nice :)
@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.
@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?
@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 :)
@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. :)
@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 😸
@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 :)
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
@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 :)
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.
@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
.apkfiles from thereleases/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 ;)
(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.
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.
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.
At least if you install the app via fdroid without the System-Service plugin, they are shown...
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.
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.
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.
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.
A different flavor of the main app with the
Internetpermission would be easiest to implement - otherwise if you split outInternetinto a separate apk then:Webviewfor JS execution, then either theWebviewhas to live in the apk which has the permission (Webviewwill 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 theWebviewoverride interfaces). Although putting the whole JS component in a separate process would also potentially be a complicated interface...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 recommendContentProviderfor this, or alternatively AIDL could be used - this can also be permission-based IIRC, but importantly theServicecan have a whitelist of package names and check each client against them.Maybe multiple solutions could be used together?
Something like this:
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.
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 :-)
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)
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?
Yes of course there is, at multiple levels :) Open projects are:
Is the repo for the internet addon somewhere?
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.
That would be great. I'm not really experience with GUI stuff, but I'd be happy to give it a try.
The idea of another app providing network access where/if required has been floating around, but having no
network accessfor Gadgetbridge itself has been quite effective and we will for sure keep it this way, that is why the Wont fix label has been applied. As for the other app, it will need developers, design and another repo... that is also where it need to be tracked and reported.