On Mon, 15 Sep 2014 04:29:30 +0200 Olivier Nyssen <nysse...@gmail.com> said:
> Hi everyone, > > "A global survey of more than 1,200 mobile apps has discovered that the > vast majority (85 per cent) fail to provide basic privacy information. > > The global survey faulted apps for accessing large amounts of personal > information without adequately explaining how they were collecting, using > and disclosing personal information. Almost one in three apps appeared to > request an excessive number of permissions to access additional personal > information. > > More than half (59 per cent) of the apps left users struggling to find > basic privacy information. Many (43 per cent) of the apps either providing > information in a too small print, or also hide the information in lengthy > privacy policies that required scrolling or clicking through multiple > pages." http://www.theregister.co.uk/2014/09/11/mobile_app_privacy_survey/ > > Any ideas how we could solve this on the OS level ? the way i'd do things is this way: 1. have 3 defined app groups: "native", "trusted", "untrusted" 2. be able to add more groups like "work" later 3. on installation of an app the user needs to select which group it goes into (perhaps with apps of some categories in an appstore able to indicate their default desired group that is selected by default, though still changeable by the user). 4. each group has set of things it can access/do without any further user interaction. 5. what each group can do is configurable by the user, and the user themselves can create groups too. 6. groups can have blacklists of accesses (these things can never be done by an app in this group no matter how much it tries) 7. any access to something not granted by the group permissions the app lives in and not blacklisted involves a dialog being put up by the security system asking the user to permit this action by this app yes (for N secs/mins), no (for as long as this app runs), always, never and this is remembered for that app if always or never are selected. dialogs would require an explanation in the dialog of a minimum length - perhaps with user feedback options in some combobox or whatever in the dialog to report the permission request as spammy/poor/suspicious (feedback going into appstore then for more detailed review if enough user feedback indicates an issue) 8. these groups would be set up in a downward permission manner - eg something in native can read/write stuff in trusted, but not the other way around. something in trusted can read/write something in untrusted, but not the other way around. at least by default set up this way. 9. any resource that can be sandboxed should be - eg contacts can have a different db for different groups - so give the app aaccess to contacts, but it's a different contacts db to the "native" or "trusted" groups. this fixes the all-or-nothing approach in other os's - where it's grant all the app wants, or don't install it at all. you can install and just get some things banned from app access. this would appeal to corporate entities as they could customize their own "work" group to have precisely the access needed. the ability to sandbox different data stores eg of contacts would also help here. really the best i see is a mechanism to allow the more technical users to do just what they want (that includes corporate IT departments), and be fine-tuned over time. the defaults are what would matter here and define at least out-of-the-box privacy for most people, so we'd really just argue on what the defaults should be. the rest honestly is watching carefully what apps do - the dialog mechanism clearly exposes what apps are and are not doing to their data and where/when they are doing it. -- Carsten Haitzler (The Rasterman) <ti...@rasterman.com> _______________________________________________ General mailing list General@lists.tizen.org https://lists.tizen.org/listinfo/general
