##Bringing this to development mailing list >> ----- Original Message ----- >> From: d3fault <d3faultdot...@gmail.com> >> To: bog_dan...@yahoo.com >> Cc: >> Sent: Wednesday, January 16, 2013 7:53 AM >> Subject: Full Ministro in Ministro-Redirection stub >> >> Hi, sorry to bother you as I'm sure you're busy working on Android Qt, >> but I'm wondering if maybe you didn't see my post here: >> http://lists.qt-project.org/pipermail/development/2013-January/009249.html >> on the topic of "[Development] Android port - Why do we need >> Ministro?". I understand the technical problem of "no common shared >> folder" that Ministro solves and I'm wondering if there's a problem >> with the design in my link (solves the same problem) that I'm just >> failing to see? I like what Ministro does but I think making the >> experience as seamless as possible (aka, they don't ever see or >> explicitly install Ministro) would be the best solution for the end >> users. >> >> Also be sure to click to the next email in the thread for the "DUH" >> solution to the bandwidth problem. >> >> I am aware of the 2 new cons introduced by my design: each/every Qt >> Android application now requires access to the SD-Card and the Network >> (security risks), but I think they're worth it in the end because >> Android is not a secure OS to begin with, as it includes proprietary >> and closed source binaries (I'm willing to bet our views on security >> differ). >> >> >> Thank you for all of your contributions to Necessitas/Ministro/Qt, >> d3fault >> > >On Wed, Jan 16, 2013 at 10:52 AM, BogDan <bog_dan...@yahoo.com> wrote: > Hi, > > Your solution sound similar with this > https://groups.google.com/group/android-qt/browse_thread/thread/708d0be52dd4af92 > one. > > Please check that thread for my answer. > > Cheers, > BogDan. >
Hmm, you're right, the design is flawed. I've been letting the problem soak in my subconscious for the past week or so and came up with a solution that I'm not sure you'll like. Basically it's a compromise between: a) Not trusting other applications to supply and/or not change the libraries (because as you pointed out, md5 summing for integrity and loading of libraries is not an atomic process) b) Not caring about security because Android is already insecure (proprietary binaries): as long as it is *FUNCTIONAL*, security can be assumed to already be compromised so who really cares as long as it works Here's a solution that implements the compromise: tl;dr: 2 Activities in the manifest. One for 'idgaf'/insecure/FUNCTIONAL usage, and one for forced-loading-of-local/verified-and-non-outside-writeable-libraries/safer usage In Launcher: 1-ActivityRegular: Checks local dir for libs, broadcasts for libs path (uses them if found), downloads libs if necessary, caches them on SD card, md5sums local copy that is actually loaded 2-ActivityForcedSafer: Checks local dir for libs, DOES NOT BROADCAST FOR LIBS PATH, downloads libs if necessary (or pulls from SD card cache), caches them on SD card if relevant, md5sums local copy that is actually loaded Pros: Completely transparent/seamless to end users (the biggest pro of them all), still provides 'moderate' security for those who actually trust proprietary binaries (ROFLMFAO) Cons: A pretty hefty amount of wasted disk space for every app that is run even once in 'safer' mode (it would be possible/easy to run out of space by running them all in Safer mode), cluttering of Launcher menu (two entries for every one activity), all Qt-Android apps would need Internet and SD Card Permissions Even though the first con is a pretty big one, I think it's worth it in order to provide a seamless Qt-Android user experience. I myself will launch every app in 1-ActivityRegular mode, so the first con will be invisible to me. I think most users will too because Android is not a secure OS to begin with. Be that as it may, we should still provide an "as secure as Ministro [currently]" mode of operation for those who want it. Additionally, knowledge of the underlying system/design allows you to choose which Qt-Android application will be the one in charge ('trusted', just as Ministro needs to be trusted) of supplying the libs: whichever one you install first. d3fault _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development