Not Yet Secure

App reviews, usable workflows, and feedback loops

Mon, 23 Dec 2013 00:00:00 -0800

There’s been a lot of discussion lately about iOS apps showing users modal dialogues requesting that they rate the app on the App Store. Like this (from Eff Your Review):

The forces encouraging this behavior are complex, and relate to issues of discoverability and ranking in the App Store. There’s been debate about how to curtail these¹.

My lab likes to think about app markets as a place where feedback loops exist, and part of our research into improving the security and privacy of apps (particularly with permission systems) relies on feedback from a user affecting the marketplace itself. Here’s a flowchart of the entire thing from one of David Wagner’s overview talks:

There’s been work to provide tools to improve apps (to help developers reduce overprivileging their apps², to detect insecure use of APIs³, etc.), or to improve the platform⁴ (making permissions clearer, showing warnings to users at the right time, avoiding habituation). But we make a big assumption:

Not all users need to notice or understand all warnings or notifications for these new systems to be effective — if some fraction of users do notice, and provide feedback back into the marketplace or to the developers when undesirable behavior occurs, then these systems can still have a positive effect on the quality of apps on a platform.

This assumption is primarily based on research that shows that app reviews are one of the most significant factors in a user’s decision to install an app⁵. So if some users notice misbehaviors or warnings, and understand them, then they can write good reviews using them, helping all of the novice users that only look over reviews when considering apps.

But is this actually enough? Can we really say that because some users could write better reviews that our work could actually lead to better app markets?

The recent app rating brouhaha seems particularly relevant. App markets and platforms need to help out enough to make this work:

Users need to be encouraged to write reviews. This is particularly important for apps that user don’t keep installed.
Useful reviews should be easy to write. Platforms probably need to hold users’ hands.
Reviews need to be easy to read, with useful information pulled out for easy access to users skimming applications. App markets need to be more like Amazon than the iOS App Store: ranking reviews on recency and usefulness, pulling out key points common across a lot of reviews, verified reviews, etc.
Fake reviews and ratings need to be curbed. This includes apps begging for reviews.
Rankings and listings in the market should be holistic and well-developed.

We don’t really have any of this on any mobile platform currently, but I think any of them would make for a much better app market.

Footnotes

Can Apple ban them? I’d argue you could get pretty far with static analysis tools, but that’s for another post… ↩
Android Permissions Demystified, by Adrienne Porter Felt et al., developed a tool called Stowaway to detect overprivileged of android apps. ↩
Analyzing Inter-Application Communication in Android, by Erika Chin et al., developed comdroid to detect insecure use of intents. ↩
A lot of work has been done on redesigning permission systems for Android: What’s wrong with permissions, how to ask for permission for different resources, the benefits of automatically granting low risk permissions, etc. This has been a big research area for students of my advisor, David Wagner, and the SCRUB center. ↩
Android permissions: user attention, comprehension, and behavior, by Adrienne Porter Felt et al., SOUPS ‘12. ↩

Breaking Cell Phone Authentication: Vulnerabilities in AKA, IMS and Android

Fri, 30 Aug 2013 22:06:39 -0700

Last year, I worked on reverse engineering Android implementations of IMS, the next generation 4G IP based telephony suite of protocols, with Jethro Beekman at Berkeley.

We released a technical report on our MITM attack against T-Mobile’s WiFi Calling service, which was caused by unvalidated SSL certificates. This was joint work with Jethro Beekman, another EECS grad student at Berkeley. Big takeaway: T-Mobile was great to work with on fixing this vulnerability—their security team is excellent.

In addition to the technical report, we continued to look at IMS systems in general, and how T-Mobile and Android implemented them. We found that, amongst other things, Digest AKAv1, the authentication and key exchange protocol used in IMS, doesn’t correctly require use of the generated secret keys, allowing a variety of attacks. Additionally, generally accessible APIs in both core Android and in T-Mobile’s customized ROMs allow apps with just the READ_PHONE_STATE permission to access the IMS authentication routines in the SIM card, making it possible for low-privilege malware on a phone to let a remote attacker authenticate as that phone.

A simple example of why you might care: An attacker can pretend to be you (your number, your subscriber ID, your phone) and call premium 1-900 numbers or send text premium text messages, costing you real money.

Jethro presented our paper at USENIX WOOT (Workshop On Offensive Technologies) 2013 a couple weeks ago. Thanks to USENIX open access policies, you can view the paper, slides, and video of the talk online.

ignore the code: Opinions vs. Data

Mon, 13 Aug 2012 22:04:28 -0700

Lukas Mathis on the mysterious Gmail checkbox-with-dropdown, and why empirical design is important:

“What Leggett described is exactly how I felt about the widget when I first saw it. I immediately figured out how to use it, but my gut reaction was «most people are not going to get how this works.» It seems I was wrong. This is one of the reasons why I don’t put too much trust into opinion-based usability reviews: There’s a lot of guesswork involved, and guessing how humans behave is an endeavor fraught with peril.”

Norman on Ubiquitous Computing

Wed, 13 Jun 2012 21:58:27 -0700

Would you like a pocket-size device that reminded you of each appointment and daily event? I would. I am waiting for the day when portable computers become small enough that I can keep one with me at all times. I will definitely put all my reminding burdens upon it. It has to be small. It has to be convenient to use. And it has to be relatively powerful, at least by today’s standards. It has to have a full, standard typewriter keyboard and a reasonably large display. It needs good graphics, because that makes a tremendous difference in usability, and a lot of memory—a huge amount, actually. And it should be easy to hook up to the telephone; I need to connect it to my home and laboratory computers. Of course, it should be relatively inexpensive.

What I ask for is not unreasonable. The technology I need is available today. It’s just that the full package has never been put together, partly because the cost in today’s world would be prohibitive. But it will exist in imperfect form in five years, possibly in perfect form in ten.”

– Donald Norman, “Design of Everyday Things”

Ant colony optimization

Tue, 19 Apr 2011 21:53:40 -0700

Image Source: Wikipedia

I’ve been looking at ant-algorithms for pathfinding lately. They’re interesting because they are very simple multi-agent search, but some of the benefits that I originally thought it might have (dealing with imperfect last-known-information, dynamic environment, etc.) seem to be negated by the fact that it isn’t terribly great when you don’t have a ton of agents.

I’ll have a more concrete idea of how feasible ant-algorithms are once my implementations are done and I can run simulations. Never hurts to separate the hype from the substance, though.

Update (2011-12-31): We ended up implementing some various pathfinding mechanisms for many-agent movement in a semi-unknown environment. Turns out that ant colony optimization is actually not so great… at least in the classic “pathfinding” sense. Convergence is slow, the actual amount of shared information is weak, etc. The test program is at least pretty, thanks to wxPython. The settings are all at the top of the Python script, and a little arcane, but you can run it with

python sim.py

You can download the program here: sim.py

Charting and Design

Thu, 29 Apr 2010 21:50:42 -0700

From mrgan.tumblr.com:

Another much-linked chart, this one deemed beautiful enough to grace the cover of a book. An appealing image, certainly. I’m not sure how it relates to flowers, but ok.

Now let’s try using the actual chart. Find what the cultural significance of red is in the Muslim culture. No? Ok, it doesn’t work that way - let’s instead find what color symbolizes peace in Eastern European cultures. Find it yet? Need a compass, perhaps, to trace from the in-chart legend to the desired slice?

Please stop the madness. The purpose of a chart is to illuminate; if it’s harder to read than a raw-data table or a paragraph of text saying the same, then don’t use a chart. And if your goal is simply to create a pretty graphic, then don’t try beefing up your science cred with this “information” stuff.

Arranging data in an aesthetically pleasing way with no regard for how the arrangement affects the viewer’s understanding is simply dishonest. It’s only popular because no one really cares to use these charts for any real purpose. (Color significance in cultures - I mean, does it get any fluffier?) Imagine someone with no database experience “visualizing” a SQL query in this way and trying to sell a database administrator on it.

Information can be beautiful. Information can also be ugly. It can be helpful or misleading, educational or confusing. Information doesn’t care; the designer has to.

The chart is question is definitely good looking. I’ve made good looking figures (not with as much art to them).

The point I get out of this: the chart isn’t designed.

It’s simply made to look good.

But can this chart be designed? The post on Neven Mrgan’s Tumblr argues that the data doesn’t work in a chart.

Too often school assignments I’ve had require figures/charts, and looking back, these really often were unnecessary, redundant, etc. Almost all of them fell under the “harder to read than a raw-data table or a paragraph of text saying the same”. The issue was that there was no freedom in the assignment to make design choices. And there certainly wasn’t design thought going into the construction of most of the assignments, either.

GCC Undefined Behavior

Mon, 29 Mar 2010 21:46:45 -0700

From feross.org:

Check out this little GCC gem that I just discovered read about.

...

When GCC identified bad C++ code, it tried to start NetHack, Rogue, or Towers of Hanoi. Failing all three, GCC printed out a cryptic error message. Wow.

This just goes to show you that when the official C++ specification talks about undefined behavior, they mean business:

[Undefined behavior is] behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which the Standard imposes no requirements

No requirements indeed.

I found this immensely entertaining. "Undefined Behavior" indeed. Also, not surprising that those who have to use C++ could stand have some humor injected into their otherwise painful lives (I kid... kind of).

Using Head-Related Transfer Functions (HRTFs)

Sun, 21 Mar 2010 21:41:03 -0700

First, HRTFs are adorable:

(ASCII from the MIT KEMAR FAQ, circa 1997, on how to apply HRTF impulse responses.)

My time spent playing around with cSound was delightful and a little sad. There’s so much more I could learn, and a lot of that is fundamental to really understanding signal processing, digital instrumentation, and computer music. But, I have learned a lot about actually using HRTFs, as one of the things I toyed with while building a little game called sound_fall. While they didn’t work out for that project, I still wanted to dig around a little more, and share some of what I found (since real discussion of HRTFs is lacking).

If you’re interested in cSound, the online manual is very useful, if a bit dense. Looking through the examples included in the pages for the HRTF opcodes was more immediately enlightening, at least from getting immediate use. The relevant opcodes here are hrtfer, hrtfmove, hrtfmove2, and hrtfstat.

To get a feel for this, I’ve made a simple .csd file—the file that contains the instrument and score information for cSound. It plays a fractal phased sine wave that I made in Audacity.

<CsoundSynthesizer>
<CsOptions>
; non-realtime output
  -o hrtf.wav
</CsOptions>
<CsInstruments>
  sr = 44100  ; standard sample rates
  kr = 4410
  ksmps = 10
  nchnls = 2  ; final output is stereo

instr 10
  kaz line 0, p3, 180          ; move azimuth from front around right to back
  kelev line 50, p3, -30       ; move elevation in arc from 50 to -30 deg
                               ; (above you to below you)
  ain soundin "fast_tone.wav"  ; input sound

  ; set left and right channels to results of the hrtfmove2 opcode
  ; this has less clicking, especially when used for real-time synthesis
  ; this processes ain, with azimuth 0, the predefined elevation arc,
  ; and the two HRTF data files (that contain the impule responses)
  ;aleft,aright hrtfmove2 ain, 0, kelev, "hrtf-44100-left.dat","hrtf-44100-right.dat"

  ; This does the same, but with the predefined azimuth arc and an
  ; elevation of zero.
  aleft,aright hrtfmove2 ain, kaz, 0, "hrtf-44100-left.dat","hrtf-44100-right.dat"

  outs    aleft, aright

endin
</CsInstruments>
<CsScore>
i10 0 20  ; play for 20 seconds
e
</CsScore>
</CsoundSynthesizer>

I tried to comment the file enough to make it readable, even if you don’t really know what’s going on. To use it, you’ll need to have cSound installed, and grab this pack I made with the .csd, fast_tone.wav, and the HRTF data files.

Then, from a terminal, invoke csound: $ csound simple_hrtf.csd

This will output a file named hrtf.wav. Try listening to it with decent headphones:

Your browser does not support HTML5 audio.

You may notice that you need to pay a bit of attention to where the sound is coming from to really get the effect. The sound I used has enough edge and variation that the motion in space is more noticeable than a more solid tone might be under the same transformations. You can pass the hrtfmove2 opcode any mono input, so experimentation is easy.

The actual math for using the HRTF datafiles involves FFTs and discrete-time convolutions—since I skipped out of being an electrical engineer, I’ve avoided needing to learn about things like that, but I can’t help being curious. If I was a little more competent, I might try to build an extension for OpenAL (which is woefully neglected these days, from the looks of it) to add this functionality. That would make it a little easier to integrate into applications that aren’t music synthesis oriented. Oh well.

Moving on from here, I’d really like to find a good system for real-time synthesis. cSound seems like a possibility, but it isn’t really designed for it from the ground up—the HRTF example here is outputted to a wavefile to avoid buffer and clicking issues.

SOUND _ FALL : build with sound

Thu, 18 Mar 2010 21:36:49 -0700

A friend and I had the idea of building games (defined loosely) that didn’t use sight as the primary medium. On a standard PC, this generally limits you to only sound.

This project is available on GitHub.

Place blocks of sounds without using your eyes.

Download, start it, and then close your eyes. See what you can build using only your ears.

This game/vignette was created using Python (tested in version 2.6) and PyGame.

This was a surprisingly long haul for only four days of working on it on and off. I’ve learned more than I think I’ll want to know in a long time about 3D positional audio.

Some of the good things I’ve learned:

PyGame is actually well-built and stable. They know how to handle sampe buffers.
Pyglet is definitely a possibility for future endeavors. It’s basically an extension of PyGame for better 3D support.
Python is, as always for me, a great prototyping language.
HRTFs are awesome.

But some things I had to learn the hard way:

OpenAL is a behemoth that I wish worked better. The fact that all of the Python bindings are terribly old and poorly documented doesn’t help.
Keep things as simple as possible, even if the overall idea is really complicated. OpenAL was way more than this project needed. I ended up building a custom panning system (since PyGame’s mixer only supports Left/Right channel volumes) that was far simpler, and it did everything I needed it to.
Humans don’t have high enough resolution for audiospatial recognition: we really distribute sounds within eight regions of the sphere (from my experience). The rest of what we think we might be sensing is due to other cues.

The fact that humans can’t pinpoint sounds in 3D space solely based on the sound was my primary sticking point.

I had originally wanted to implement this only using 3D positional audio with HRTFs—Head-Relational Transfer Functions. I thought this would let me cue the position of blocks around the player, but it just didn’t end up cutting it. But that doesn’t stop HRTFs from being really awesome.

If you aren’t familiar with HRTFs and care about audio production in any capacity, you should check them out. Head-Relational Transfer Functions (HRTFs) are signals that you can convolute a mono input against to get the actual signals that a human would hear in each ear. MIT made a database of them, called KEMAR, back in the ’90s using a dummy head and special microphones. I’m still not comfortable trying to use them by hand, but cSound has HRTF support for static and moving positional sounds, which is really cool. I wanted to try to hack together using the command-line interface to cSound through Python to build this system, but HRTFs just weren’t enough. Darn.