As Android users, we are given the curse of knowledge. Each application we buy in the marketplace (now Google Play) tells us in exactly which ways the app will be snooping on us. Unfortunately there is neither a justification for these violations nor usually any more granular information about the intrusion than "Monitor All Phone Calls" or something equally opaque.
I think that other mobile OSes might not be as explicit about what permissions an application has, likely because the apps are screened as opposed to the wild west Android market. Perhaps most users ignore these permissions and blithely accept that they have no privacy anyway and thus aren't that concerned about what further damage is being done. I thought it might be useful to go over a standard application from the more suspicious perspective so that developers can understand what they are up against when they request these permissions and maybe why I have stopped updating at least half of my apps.
So I'll pick the Facebook application which is admittedly a bit more permissive than a run of the mill application simply because of the amount of coordination and communication it does. I'll list the different permissions, then my paranoid mind's worst misuse case for them, and finally what they might actually be doing with my information.
- Your location - fine GPS location
Your personal information - read contact data, write contact data
- Paranoid: Where to begin? I'm allowing Facebook to know where I am at all times. Not just when I'm posting something to provide a search context, but all the time, even when I'm not using the app. Facebook can know whether I visited the STD clinic, a political rally, when I'm usually away from home, and how much I like to eat Taco Bell. They could assemble that data into traffic maps and sell that data to the highest bidder or really just all the bidders.
- Reality: The only location aware thing the app does that I am aware of is their version of check-in.
Network communication - Allows the application to accept cloud to device messages from application's service, full Internet access
- Paranoid: So Facebook has an extensive social graph of me already, but now they have access to data I haven't specifically given them. Is my old girlfriend in my contacts list? Is some old work contact of mine going to see me suddenly show up in their suggested friends list? Really, should Facebook be seeing that at all?
- Reality: So I really don't know why Facebook needs access to my contacts. It doesn't seem to link them up in the contacts view, and I don't see any integration with the app. I assume this is to enable the initial scan if you choose to do it?
Your accounts - act as an account authenicator, manage the accounts list
- Paranoid: Facebook can do anything related to the internet (which I assume in this case means just any TCP/IP traffic). Anything. Facebook could be downloading additional content, using a keylogger, anything that it has access to could be pumped back to their servers wholesale. This would be a particularly thorny one to try to restrict, but it's also pretty insidious.
- Reality: Probably mostly just sending you status updates so you can see when your friend posted a funny picture of cat, right?
Storage - modify/delete SD card contents
- Paranoid: The description on this is poor. It could mean that Facebook is logging you into your other apps. It could be proxying your access and doing all sorts of malicious things. Heck it could even be removing your Google+ account.
- Reality: Probably logs you into Facebook app based on your android credentials
Phone calls - read phone state and identity
- Paranoid: Yes, please read everything on my phone. Would you use the Facebook website if you had to allow it to read the hard drive on your PC? Your Quicken files? Your website cookies and browsing history? Your passwords? Are there any limits to this file system access?
- Reality: Probably runs a cache of images and video on your SD card, or maybe it needs it to upload photos you took? I actually have no idea why it would need this access if the app is running on the system storage.
System tools - prevent phone from sleeping, write sync settings
- Paranoid: Facebook doesn't make phone calls and doesn't log phone calls. What is this all about? Must be spying on your phone calls to add more payload to your social graph. All the more information to sell to third parties.
- Reality: Probably just doesn't want to send you a notification while you are on the phone? Needs to not update if the phone is asleep?
- Paranoid: If I've set the phone to go to sleep on inactivity, Facebook should comply with my settings, why are they trying to second guess me?
- Reality: Stop the screen from blanking out when you are playing a video maybe?
So there you have it: a peek into the mind of a paranoid user. Now would these permissions be a lot easier to accept if they said something more akin to what is in the "Reality" statement? I think so. You really have to give far too much trust to an application when you run it on your smartphone. Other operating systems might hide this from you, but in reality your rights are probably far more compromised than you think they are.
Now mutliply this problem times the 40-100 apps you want to run and you have the difficulty involved with being an Android user. And multiply that times another 30% of the apps that seem to want to "upgrade" their permissions by requesting more access when they release a new version. It's really pretty scary and a real waste of my time to try to sort out what is legit and what is not. We need a better system.
Last weekend, I participated in Twin Cities Startup Weekend and wanted to capture a few thoughts about the process. I went with Trent and we offered up our services as developers. For those unfamiliar, the process basically goes like this:
- People pitch ideas for startup companies. These can be all over the board, from ideas that people have been kicking around forever to spur of the moment.
- The ideas are voted on to pick the best by popular opinion (and coercion and cronyism in some cases).
- Teams form organically around skillsets and interest.
- Work like mad for 30+ hours getting an initial product going.
- Demo the product to a panel of judges and maybe win a nominal prize.
We picked a startup idea based around aggregating clearance items from local retailers so that people can bargain hunt. It sounded fun, unique and well suited to our abilities. I'm really happy with our choice and proud of what we are able to accomplish in such a short amount of time. The site ended up being called Froogify but we took it back to stealth mode after the demo. You can sign up to find out about it at www.froogify.com
Some thoughts about the weekend:
Startup pitch versus product - The tone of the event was different than I had imagined it would be. I came prepared to make something that could be used, but most of the focus seemed to be on making something that could be pitched to VCs. It didn't matter if it worked or how deep the feature set worked. In short, it was not a maker's event which I should really not have expected it to be, but it did get me wondering if there was a venue for something more about building and less about selling. Would anyone else be interested in more of a code jam type of event? Keep an eye out for more from me on this topic in the future.
I need to pitch something - I've been kicking around a lot of ideas for a long time. It would really be fun to see one of them come to fruition through this event. If you want to pitch something at one of these, let me know and I'd be happy to talk about it and give some strategy in advance.
With drive accomplishment explodes - Our team was energized and enthusiastic and we accomplished more in 36 hours of development and business work than some businesses do in a month. Sure, we cut a lot of corners and really focused on a minimally viable product, but still it was crazy fun to be a part of. Clearly working that amount of time in 2 days is not a sustainable rate, but if you could keep a team really jazzed about what they were doing you could harness some of that magic. Figuring out how to motivate people to that level of intensity is a real trick though.
This is a different skillset
- Most of my programming in the last 15 years has been in environments that valued correctness and stability over speed. I don't have enough tools in my toolbox for these types of situations. It was humbling to work with the amazing Eric Brandes
who kept pulling quick tools out of his bag of tricks. I really need to expand my repertoire and pull in more of these quick tools that make building things fast a lot easier.
Prebuild - There was some talk that the eventual winner of the competition had built most of his software beforehand. At first, I found that a bit offensive, but then I accepted the nature of the event and the fact that creating a working product wasn't exactly the focus. The take away is that I will come into the next event with more prework done. I don't know what I will be building, but having a database, source control and maybe a few project templates set up beforehand wouldn't be too hard and would have saved an hour or two.
Overall - This was an exhausting, all consuming weekend that was an absolute blast. I'm super excited that our business owners for the startup seem interested in carrying it forward and making it a real product. We didn't win the competition, but these guys seem to have the drive to succeed that could make this thing work. That would make me immensely satisfied. Regardless though, I will be back next year to see if I can help launch someone else's dream (or maybe my own).
I've been thinking a lot lately about web pages that do too much in a single page or what I call the "everything page" and what it really costs to develop and maintain one. It's a topic that Trent and I have also been talking about in terms of web development being developing sites as a collection of pages (e.g. your typical shop cart checkout process) versus web applications that function more like a traditional application where a main window is represented by a single page (e.g. the Gmail interface).
It seems that in the majority of web applications I have worked on the paradigm is usually several pages that are smaller in complexity and then one or two pages that are real doozies. Often times the complex pages don't start out that way but as features get added, things have a tendency to compound. Whether they start out that way or end up that way, I'd argue that getting a handle on that complexity and finding a way to reduce or manage it is critical to keeping down the cost of development and future support.
So how do we deal with these monster everything pages to make sure they don't cost us an arm and a leg?
The other approach I would mention is related but one that is often a harder sell. You should consider how you can break that page apart into multiple pages. A product owner or business stakeholder might make an assumption that having everything happen on a single page is just as easy as having a multiple step process (with all that "annoying clicking" to navigate). What is the real cost of cramming a ton of functionality into an everything page versus spreading it out into smaller pieces and do the stakeholders know? For example, if you have 4 pages that each take 5 hours done separately, would you consider putting them into a single page if it instead took 40 hours and all future maintenance took twice as long? Depending on the UX demand, the answer might be yes, but I don't think this cost gets factored into the decision often enough.
The most important thing you can do though is to recognize right away when you have an everything page in the works so that you can start to think about ways to manage the complexity and keep the true cost of the page under control.
Q: What did the Zen Buddhist say to the hot dog vendor?
A: Make me one with everything.
I was talking with my friend Andre Taddeini recently about the state of the industry and he made an interesting observation that the amount of bad code being written might be increasing in proportion to the demand for programmers. I thought it was interesting enough to talk about here.
The reasoning is that, as the demand for programmers goes up, the aggregate quality of developers goes down because the supply of capable programmers is somewhat upwardly inflexible due to the amount of effort that goes into being expert. Since the supply of expert developers can't keep up with a rapid increase in demand, the expected quality of a hire is necessarily lowered. As the overall quality of programmers is lowered in this fashion, the corresponding code that is written should lower in quality as well.
There is an implied relation between experience and quality, but it could be equally true that the acceptable quality of inexperienced developers would also lower simply through demand. Either way, I accept that experience doesn't necessitate skill, I'm only talking in the aggregate. The other assumption present is that we are holding the quality of code constant over time. This might not be true if constant improvement in frameworks and tools lessen the need for programming skill. There is certainly some truth to that assertion, but, by observation, the rate of tooling and framework support increases only offsets the increased expectations of application complexity. Another assumption present is that the demand for developers overall is roughly equivalent to the demand for expert developers.
So Taddeini's Law is
Q = E / D
Where Q is the quality of code produced, E is the population of experienced developers and D is the demand for experienced developers.
It's really a pretty trivial observation and I'm probably aggrandizing it by calling it a law, but I think it has some interesting implications for the state of our industry. If it's accepted as true, the implication is that the current increase in demand for developers is creating an influx of bad code for our industry to grapple with in years to come. Did the same thing happen during the dotcom boom? As inexpertly written code rots, will organizations be paying an increased "maintenance tax" in the future? Should larger organizations plan for this in some way? And finally, is there something we can do lessen the impact of under-qualified people in the industry overall?
Okay, just a quick note about the name.
At the risk of sounding more sophisticated than I really am, it comes from Plato's Theory of Forms as it relates to virtue ethics. Now I don't really prescribe to it in its truest sense, but it's the idea that all things have a perfect form including us. A circle can be perfectly described mathematically, but no circle in existence is truly perfect - every single representation deviates from that perfect idea in some way. In this same way, we all deviate from the perfect person that could be. Now depending on your ideas on metaphysics and religion, you may or may not believe there really is some perfect you, but there is always a more perfect you in your imagination (unless you are a hopeless narcissist I guess).
So virtue ethics tells us to move towards that more perfect us by getting better at everything we do. The same concept can be expressed as Continuous Improvement, or Kaizen, or sharpening the saw, but it's really all just about making ourselves better at what we do. So with this blog, I'm hoping to capture the ways that I try to improve myself and the things I learn along the way.
Plus, I couldn't call it Perfect Circle or I'd get traffic from people looking for the band :). Well that and it sounds really pompous.
There was a time when it felt like everyone was starting a blog. A virtually infinite sea of voices shouting into the ether; each individual too focused on what they had to say to notice that nobody was listening. There are a lot of reasons not to start a blog, but I think I’m going to do it anyway and here are my counterpoints to the doubting voices that tell me not to:
1. Nobody is going to read it anyway
Okay, yeah, so I don’t care about that one too much. In many ways, I’m writing this for my own benefit. It will help me organize my thoughts on a subject and also to serve the dual purpose of reminding me of a solution when I find it. Oh, did I mention this was going to be a tech blog? Mostly about my life as a software developer. Writing down my learning will help me remember it in the future and give me a place to look it up if I don’t.
2. You don’t have anything to add
Given the multitude of voices out there, it’s almost impossible to have a unique thought or experience, but every so often it happens and when it does I hope that I can put it down in a cohesive way. If my thoughts are unoriginal, at least I can make them entertaining or reinforce the wisdom of others.
3. You’ll just abandon it like everyone else does
There is a good chance of that really, but maybe it will stick. And if it doesn’t, it will be a lasting (in internet years) piece of evidence that I am just as half-arsed as everyone else. :)
So, in short, strap in for a possibly short, possibly meaningless ride that nobody else is going to take. Here we go!