"Apps" is a concept that has been with us for ages. I won't be talking about anything that Apple, Google or Microsoft might mean by "apps", I'll use it as "applications, software" because it's short, precise and gets the point across, as well as the most common usage at this point in time.
ZeroPhone is not my first project of a portable, personal assistant, communicator device. Indeed, the listed qualities are what made smartphones so important in our lives. During all the previous projects I've worked on, I understood one important thing - in the end, it's all about software.
Nowadays, software support makes or breaks a project, I won't get tired of repeating it because it's true and software really is so damn important. This project needs to have above average software coverage quality - I want to outline what "above average" means here, and what I'll be aiming for when planning my priorities for the project.
In general, it's good coverage of what users need - and coverage of what other platforms don't provide. For now, my guidelines are:
- All the typical features that a phone should have. There's no way ZeroPhone can succeed if it hangs on every 10th call, or can't parse a popular (or obscure) type of SMS encoding.
- Some of the advanced features typically found in smartphones (not dumbphones). For example, caller/SMS sender blacklists, WiFi hotspot or simple SMS/phonebook data export functions (had lots of *fun* exporting caller lists from dumbphones at some time).
- Typically unavailable features - whatever is not found in phones at all because not too many people actually use it most of the time. Jamming/rogue cell tower detection, free GPIOs for sensors, a 5V output capable of charging other phones - anything that phone manufacturers won't even think about.
Other than these general focuses, I'll focus on those types of apps:
- Apps for easier tinkering. Makers are an important part of ZeroPhone audience. The ZeroPhone has about 50 different usable connection points you can use to make addons, and I want people to understand just how important it is to have them - because there are lots of amazing things you can do using interfaces that ZeroPhone offers. You can connect modules you could never add to your phone, for the low low prices of Chinese breakouts. The limit is no longer the decisions of those making your phone, it's the one of your imagination and skills, it's the inner beauty of tinkering that people over the world have come to embrace and love.
- Apps for privacy-concerned people. Say, Tor control panel I just wrote for ZeroPhone - it's supposed to give you control on when and how you want to use Tor on the ZeroPhone, and easy control over your tools is an important part of ensuring your privacy. Remember the bomb threat guy who was caught because he was the only one using Tor on the network? You shouldn't make stupid bomb threats like he did, but the threat vector will remain valid no matter how good your intentions on Tor might be - you might be a journalist in a war-torn country and get killed because of government looking on who's streaming through which ports. This is one of numerous reasons we need ZeroPhone apps if we want to counteract the privacy breaches happening everywhere.
- Apps for pentesting. For example, I want to make a simple nmap application - with some very important enhancements. Doing security assessments on networks/tech is something that people rarely do - this fact undermines security. I think the reason is - we're used to the fact that you need an security-oriented Linux distribution to use most of the tools typically necessary. What if you could use most of those on a stock ZeroPhone with a press of a button? For example, nmap - with a simple port-scanning script, bindings to something like metasploit and some simple logic added, you could instantly know of any potentially unsecured devices on your network. Looking at all the problems we encounter, I think easy-to-use one-click pentesting tools are important component of infrastructure in the future, something that could motivate us and help us fix the security mess we're creating.
For the infrastructure to actually be able to survive in the long term, I'll be enforcing limitations.
- Apps should be open-source. This is something A/G/M trio have no interest in enforcing. They want the best user experience, but they are going the "let the market regulate itself" way, with a couple of regulations to avoid breaking laws, as well as usual "we reserve all rights and are not responsible" clause. My opinion is that a single user should be able to fork and change any of the apps if he/she desires, no matter if it goes against what majority might want from the app, and this is exactly what open-source always helped with.
- Is open-source model a panacea? No. It's just damn good at what it does, which happens to be exactly what this project needs.
- No implicit tracking/analytics in apps. Ideally, make it opt-in. This is something an enoumous amount of people are tired of now, and I'll go to the slight extreme of "don't do it unless user explicitly agrees to help you". Open-source components and reviewing code should help with any bad actors on this, too.
- I understand there are ways where analytics and statistics help (such as better user need targeting, bug fixing and feature priority adjustment), so I'll be making sure app authors have a way to remind the user that there's a checkbox they could tick to help the author make better apps - by being better informed on what people need and use. I, for example, will make this feature for ZeroPhone UI framework - a "send error log to help fix bugs" button, a "yes, send telemetry to help development" checkbox (off by default), and a "receive notifications on important updates" mechanism (that'll be asked when ZeroPhone will be first configured).
- There should be a "readable code" expectation from apps. It doesn't matter if an app (external to the core code) is not well-structured as long as it works, honestly - and doesn't interfere with anything else. However, readable code is usually the most modifiable one. To paraphrase - a code that does app-limited localization can have a switch statement with hardcoded things instead of a map, where it'd be shorter to write a map using a dictionary.
- Of course, more elegantly-coded versions are better - but I know I can't expect too much from people that just want to share what they did for their own phones in their free time, and thought others could benefit from that as well. And the usual "no side effects" rules still stand - though more often than not it's easy to fix the side effects (hey, it's open-source!)
There are things I don't yet have a clue about, of course. For example:
- App distribution ways. There are app stores, there are mechanisms for adding GitHub repositories, there are distro-specific repositories and then there are custom package managers for things, all of those ways have its pros and cons, and I'm not yet sure what fits so it's bound I'll have to return to this later, when I'll have my requirements ready.
- If there's anything that has to be done about closed-source apps. While it's a requirement in my book, some people will be overriding it anyway and provide .pyc or .pyo files instead of plain .py apps. I'm going to discourage it, but sometimes people will do their own thing no matter what - and if you look at it, this whole phone is designed to allow people to do things without restrictions, so placing a restriction on it would be as inappropriate as to not allow people to change logos in the UI (a nice example of this is xscreensaver. I understand your reasons, and I disagree - the logo looks goddamn ugly to me).
- Something else that I have stupidly forgotten about? Any ideas, guys?
This guy can't wait to tell me about the extents of this post's suckery in the comments.
This post was hard, but satisfying to write - I know it addresses many important points and questions. As usual, I'd love to hear your feedback - here in the comments, or email me on info at zerophone dot org.