In this presentation I provided undergraduates an introduction to the wildes of cross platform development in the mobile domain. In the end, we explored a few solutions and talked about the strengths/weaknesses of those third party providers. The second half of the talk involved the Android security model and how it WAS important to application developers.

1. Cross-Platform UI Development
600.250 User Interfaces and Mobile Applications
Michael Rushanan

2. Problems
● Providing a consistent UI across multiple platforms.
– Most common/inefficient solution: implement UI individually for each platform.
● Number of platforms, at least in mobile, is increasing:
– Ubuntu Touch
– Android
– IOS
– Tizen
– Moblin
– MeeGo
– Symbian
– Windows 8 Phone
– BlackBerry

3. Trivia Time!
● How many of you have heard of Tizen, Bada,
Moblin, or MeeGo?
●
Can anyone share an experience developing
something event-driven (another mobile app
maybe) while contrasting it with Android
development so far?
● How do you mock up UI designs?

4. More Problems
● Providing a consistent UI across multiple
platforms.... desktop vs. mobile.
– What problems would you run into when
transitioning from Desktop-to-Mobile, or
Mobile-to-Desktop?

5. Welcome to UI Hell

6. Alternative Solutions
● Manufacturers have not been forthcoming with solutions
in which to handle the inefficient approach to
multi-platform support. The best you have is:
– Xcode SDK supports streamlined development for both OS X
and IOS development. It's at least in the same language.
– Ubuntu and other Linux Mobile variants are leaning more heavily
toward HTML5 for UI development (with an exposed API for
gesture support).
● Third-party providers have been busy trying to solve the
above and provide an intuitive UI development
environment for not-well-versed programmers.

7. Trivia Time!
● Has anyone used a third-party UI development
tool/SDK?
● How do you feel about HTML5, CSS,
JavaScript... C#?

8. Third-Party Calling...
●
MoSync SDK: Cross-platform SDK and HTML5 tools for mobile app development.
– The Good: Free and open source. A free commercial license that removes support. Supports
more than a handful of devices.
– The Bad: Windows and OS X Only.
● PhoneGap: Unified UI development via one language: HTML, CSS, JavaScript.
– The Good: I've used this to mock up applications before. It exposes device features via an API.
Examples: Accelerometer, Camera, Compass, Geolocation, File, Notification, Storage. I can get
this to work on Linux!
– The Bad: Eh, it's all web based. Maybe this is ok? It also allows you to do some pretty
non-standard things that blow off Android/IOS standardization.
● Mono: Cross platform, open source .NET development framework.
– The Good: If you ever wanted to do .NET dev on a machine other than Windows, this was your
calling. Mono offers MonoTouch (now Xamarin.iOS) for iOS and Mono (now Xamarin.Android) for
Android.
– The Bad: There are two separate SDKs for supporting iOS and Android. You have to purchase
licenses to use these. You really have to <3 C# to make this transition However, the added perk
of native code is speed and efficiency.

9. Transition
UI consistency is hard to achieve, but a warranted task.
Perhaps more painful, is achieving UI consistency while
maintaining appropriate security design. Note: this is just
an introduction to Android security.

10. Android Security Model
600.250 User Interfaces and Mobile Applications
Michael Rushanan

11. Why Talk Security?
This is a UI and Mobile Development class, right? Why do
we care about security?
– Whether it's event driven, or a simple deterministic shell script –
you should always include security in your design!
– When introducing principles of security into any application,
there is often a trade-off between security and usability? Why
do you think that is?
– Can you think of some Android specific security considerations
when implementing your application?
● Hint: Storage (external/internal), Content Providers, Networking, Input
Validation, WebView, Interprocess Communication.

12. Core Security Features
The, “things you don't have to worry about because it's already
handled.”
– Android Application Sandbox.
● Isolates data and code from other apps.
– Encrypted Filesystem.
– Application framework that provides secure functionality.
●
Cryptography (never ever invent your own).
●
Application Specific Permissions.
●
Secure Interprocess Communication (IPC).
– Granular Multi-layered Permissions.
●
Application-defined.
●
User-granted (don't rely on the user).

13. Storage
● Is the data I store on the device accessible to
other applications?
– Context.MODE_WORLD_READABLE/WRITEABLE
● No, and for good reason. Should Fruit Ninja have
access to your ToDo list? Why?
● What about physical theft?

14. External Storage
● When and why would you use External
Storage?

15. External Storage
● Music/ - Media scanner classifies all media found here as user music.
●
Podcasts/ - Media scanner classifies all media found here as a podcast.
● Ringtones/ - Media scanner classifies all media found here as a ringtone.
● Alarms/ - Media scanner classifies all media found here as an alarm sound.
● Notifications/ - Media scanner classifies all media found here as a
notification sound.
● Pictures/ - All photos (excluding those taken with the camera).
●
Movies/ - All movies (excluding those taken with the camcorder).
●
Download/ - Miscellaneous downloads.
Oh... and caching too!
Shamelessly stolen from: http://developer.android.com/guide/topics/data/data-storage.html#filesInternal

16. Content Providers
● Content providers are useful for offering a
storage mechanism that can be limited to your
application, or exported to allow access to
some set of applications.
● Input validation. Why should we validate input
from an untrusted application?
● What about an untrusted user? ;)

17. Final Note on Input Validation
● Android already has query methods that
manage input validation for you... hence doing
RAW QUERIES is bad. No, doing you own
input validation does not make it better.
– query()
– update()
– delete()
Come on, what could go wrong? SQL Injection (we're interested in
this), buffer overflows, use after free, and off-by-one errors (these
last few are native code implementation errors that have bad
consequences).

18. Permissions

19. ToDo Permissions
● What permissions should your ToDo app
have?
String String String
READ_SMS NFC CAMERA
Allows an application to read SMS messages. Allows applications to perform I/O operations over NFC Required to be able to access the camera device.
String String String
CALL_PHONE BRICK BLUETOOTH
Allows an application to initiate a phone call Required to be able to disable the device (very Allows applications to connect to paired bluetooth
without going through the Dialer user dangerous!). devices
interface for the user to confirm the call
being placed.
String String
String
SET_ALARM VIBRATE
SEND_SMS
Allows an application to broadcast an Intent to set an Allows access to the vibrator
Allows an application to send SMS messages. alarm for the user.
String String String
FORCE_BACK READ_CALL_LOG WRITE_SMS
Allows an application to force a BACK Allows an application to read the user's call log. Allows an application to write SMS messages.
operation on whatever is the top activity.

20. Networking
● IP Networking – you're data is only as secure
as the protocol that you use.
● Encrypted socket-level communication can be easily
implemented using the SSLSocket class. In a game
app, why would you want to use the SSLSocket class?

21. Networking
● SMS is not secure. There has been work in
academia to encrypt the contents of SMS, but
the constraint on such implementations is the
allowable size of SMS.
● Google recommends the use of Google Cloud
Messaging (GCM) and IP networking for
sending data messages.

22. WebView
● WebView consumes web content, that includes malformed
JavaScript. Thus, common web security issues such as
cross-site scripting can occur.
● We can turn JS off by not calling setJavaScriptEnabled().
● Android provides addJavaScriptInterface() such that JS can
directly interface with some set of your android methods. If
you allow a general WebView to enable such functionality, a
malicious JS could do what it pleases with your methods.

23. Cryptography
● We've already seen an example with SSLSocket and
HTTPSUrlConnect.
● The take-away here is always the same, “Don't invent your
own cryptographic methods/ciphers/whatever.”
● There is a Cipher class in Android that provides the
appropriate methods for symmetric and asymmetric
encryption.
● There is a secure random number generator in Android,
SecureRandom. Please don't use a seeded random
method instead.

24. Interprocess Communication
● Intents are the preferred mechanisms for asynchronous IPC in Android.
– sendBroadcast()
– sendOrderedBroadcast()
● You can apply access permissions to broadcasted intents so only certain applications
can register to see the intents. If you're doing this, you might just consider invoking the
receiver directly.
– android:exported
● Allow use of IPC by other apps.
– android:protectionLevel
● Characterizes the potential risk implied in the permission and indicates the procedure the system should follow
when determining whether or not to grant permission to requester.
– “normal” = default low risk, requests isolated application features.
– “dangerous” = high-risk, requests private user data or control.
– “signature” = granted only if the requesting application is signed with the same certificate as the application that declared the
permission.
– “signatureOrSystem” = system grants only to applications that are in the Android system image or as above.
– android:permission
● Applications will need to declare a corresponding <uses-permission> element in their manifest to start, stop, or
bind service.

25. Everything Else
●
Dynamically Loading Code.
– Discouraged to load code outside of APK. That's why libraries get bundled in the
APK.
● Security in a Virtual Machine.
– Dalvik is Andriod's runtime virtual machine.
– This provides an application sandbox in which to run applications. If you're interested
in more about sandboxes, ask me – I have links to some relevant papers (all in the
Android world if you like).
●
Security in Native Code.
– Google encourages development with the SDK. However, you can use the NDK to
write more complex code for runtime efficiency and performance.
– Native code tends to be problematic because bugs lead to root level compromises
(buffer overflows).
– Native code written for an application is SANDBOXED. Just because it's native,
doesn't mean that it escapes the model. However, it also makes it easier to escape
the sandbox with buggy/insecure native code.