7 ms·
My own muses and solution: http://williamedwardscoder.tumblr.com/post/13316924653/better-permissions-in-android http://williamedwardscoder.tumblr.com/post/13316
by willvarfar 10y ago
My own muses and solution: http://williamedwardscoder.tumblr.com/post/13316924653/better-permissions-in-android http://williamedwardscoder.tumblr.com/post/13316924653/bette...
Basically, back in the Symbian/UIQ days, we worked on this and came up with a way to embed apps within another visually even though they were separate apps with separate permissions.
So an app wouldn't need all the internet access stuff just because it embeds ads; instead, an ad-service running on the phone would embed ads in the space given to it by the app.
We primarily wanted to show contacts and online status etc inline without each app needing to be able to read your contacts or find out their online statuses.
The host app would basically use a UI widget that took a 'url' to what was going to be shown, and apps registered as providers of various url schemes e.g. uiq_contact:phonenumber_goes_here?display_options=whatever
- unicornporn 10y agoSpeaking of security... Did you know you can turn on SSL (for free) for your Tumblr blog these days?
- willvarfar 10y agoHad no idea. Enabled it now.
- pjmlp 10y agoSymbian/UIQ, already had quite a good security model specially since S60 3rd Edition, pity Android devs not followed up on it.
- digi_owl 10y agoFrankly i will eternally be puzzled why Symbian was dropped like a hot potato when iPhone and Android entered the scene. It was almost as if the American tech press was completely unfamiliar with the mobile world outside USA (never mind being stupefyingly in love with Apple), and thus they praised iPhone like something unique in the mobile world when it launched. The real puzzler though is that the rest of the world's tech press parroted that message like they believed it, when they should have known better.
- willvarfar 10y agoI was an insider so I was jaded and biased. But ... :) S60 was a horrid codebase and very hard to wrangle into modern things. UIQ was a cleaner smaller codebase where the main big apps (e.g. messaging) didn't actually use the latest greatest parts of the framework. UIQ was always being dragged in opposing directions by its two big owners - Sony Ericsson and Motorola. Sony Ericsson had some success with their early P800 and just wanted to keep on iterating that with the P900 etc, whereas Motorola wanted smarter feature phones and features like keypad navigation. Neither wanted capacitive touch, despite UIQ suggesting it umpteen times. The Symbian codebase was an antiquated C++ dialect. I happened to have liked it, and found it very expressive and powerful and simple, but there was definitely a learning curve. When the iphone came along it was so simple and beautiful and had a capacitive screen and basically everything else was obsolete immediately. Android was unreleased and actually had an extensional crisis at that point, but they quickly revamped it to be more iphone-like and launched. At that point everyone else thought "android will be cheaper to develop!" and dropped Symbian just as quick as they could. And I don't blame them.
- digi_owl 10y agoThat all sounds oddly similar to a bunch of reasoning going on in the FOSS world right now.
- pjmlp 10y agoYes Symbian C++ was a pain and the Codewarrior replaced by Eclipse with CDT (attempt 1), replaced by Carbide (Eclipse CDT attempt 2), augmented with PIPS, extended with Qt, on top of Perl and BASH scripts wasn't very fun to use, if at all. Recall that Nokia blog post that was quickly removed, about only devs that get paid would develop for Symbian? When version 3 came out I was expecting Symbian C++ would be replaced by proper C++, given the overhaul the system got for security support. Yet, the OS itself with its mikro-kernel architecture, C++ instead of C, task based architecture and security model was quite interesting from OS architecture point of view. The updated Belle version was quite a joy to use on my Nokia C6-01.
- pjc50 10y ago
- masklinn 10y ago> Basically, back in the Symbian/UIQ days, we worked on this and came up with a way to embed apps within another visually even though they were separate apps with separate permissions. iOS added that in v6 with "remote view controllers", it's used to embed a JIT-ed Safari view inside arbitrary applications (without having to disable w^x for them)
- willvarfar 10y agoI got the initial idea from X's XEmbed. Its an old idea. Android also has remote views. Nobody is using it to avoid giving everybody permissions / capabilities, though :(
- masklinn 10y ago> Nobody is using it to avoid giving everybody permissions / capabilities, though :( I believe MacOS uses it to provide file access to sandboxed applications: the "Open" dialog is a remote invocation so that sandboxed applications can access files outside the sandbox without having blanket filesystem access.
- iainmerrick 10y agoThat would be great! Both Android and iOS partly implement it, but in each case it's underused. On Android, an app can send an email just by posting an intent. That will open your favourite email app and create a new message, but crucially, you can check the contents yourself and decide whether or not to hit "send" or not. The app can't interfere and can't even tell whether it was sent (modulo underhand stuff like tracking pixels). Unfortunately, the intents for "post a message to twitter/facebook/whatever" are badly designed and don't work well with most apps. So many apps just request direct access to your social media. On iOS, you can deny Facebook and Twitter access to your photo library, yet still post photos: you just do it in the Photos app itself. Photos gets access to your social media, rather than vice-versa, and that's (probably) OK because Photos is built into the platform, not a third-party app. Unfortunately people don't seem to know about that, and just use the (admittedly easier) workflow of sharing photos from within the Facebook or Twitter app. And sharing multiple photos from Photos didn't work properly the last time I tried: it creates multiple posts rather than a single post with multiple photos. So in each case the platforms offer the functionality you're looking for, but apps and/or users are too lazy to use it properly. I don't know what the solution is. Apple or Google could make it harder for apps to do the wrong thing, but that would probably just annoy users ("I upgraded my phone and now I can't share photos any more!")
- fjrieiekd 10y agoAnd even on Android this functionality has a lot of holes. As an example, just try to find a robust way of sending an email with multiple attachments that only shows email apps and doesn't crash some of those apps.