"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.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
What framework(s) are you using for your apps, and how does that affect your security model if users can write around it? In Android this was controlled with an API and permissions to provide building blocks for apps, are you planning something similar?
Are you sure? yes | no
As for now, it's a self-designed framework made in Python, and it hardly exposes any API that could be limited =) I'll be looking at FSO API (http://www.freesmartphone.org/), it seems promising - after writing some wrappers around DBus, it could be made into something really simple and user-friendly, too =D Having said that, I don't yet know how it handles permissions, TBH - it's all still to be researched.
Are you sure? yes | no
I like the idea of freesmartphone.org to provide the structure, I didnt know something like that existed. Looking forward to getting my hands dirty ;-)
Are you sure? yes | no
maybe for an app store just have a website where you can go, to download and see the source code of the apps as well as the github repo that dillon suggested
Are you sure? yes | no
Yep, those are going to be likely features - granted, I now know I can't promise anything on the timing, but I do hope somebody could pick them up before I do =)
Are you sure? yes | no
how about the arduino ide?
Are you sure? yes | no
Writing sketches on this screen? Possible but unlikely. Compiling and flashing them? Did that last week, actually, worked as good as it does on Linux - which's "perfect" =)
Are you sure? yes | no
We believe the future of ... our way of life will be determined by how well we prepare our children for success in the 21st century. Today we see great potential for the application of technology to enrich and transform education for all learners. http://www.ycombinator.com/edtech/
Are you sure? yes | no
Apps for learning and teaching are vital as we look at next generation and just those who eager to know how ZeroPhone works (in order to hack it=make it the most sutable device))) as on a target audience too
Are you sure? yes | no
Agree! Forgot about this as a priority - but then, it's kinda included in "tinkering apps". I'll think of what apps we'll need for this and include it in one of the updates further down he road =)
Are you sure? yes | no
After reading this, I thought of an interesting method of distributing apps. What if you make a git repo in the style of https://github.com/sindresorhus/awesome ? Then app developers can create pull requests that link to the github where their application resides. You can make some app store-type program that parses the list and gives information/ability to install all of the apps. Each app would need a specific format, preferably hosted on github - maybe an /app/ directory with a readme for a description and images and an install script or something.
Point of contention is that you control what apps make the list. You may see this as a good thing because you can keep spam out, but also bad because you're in control and hold the same power as the big 3 companies. Just something to consider.
Are you sure? yes | no
App format is something absolutely necessary, indeed, at least something like "app.manifest" document. Currently, pyLCI uses "has __init__.py and main.py, main.py has menu_name variable (optional) and init_app function in it" criteria. I like it because it's quite minimalistic but I'm sure it won't be enough at some point =)
RE: all kinds of "awesome" lists out there - it wouldn't have to be hard-coded, I still need to give people a way to share their apps without some kind of approval (like Ubuntu PPAs).
Problems I see with "awesome" kind of lists:
1) Depends on GitHub (though can be self-hosted on zerophone.com/app-list, for example)
2) Depends on maintainers (more of a good thing, and if I give a self-hosted option, even a better way to)
3) Scalability? Though apt IIRC uses a similar way with its Packages.gz file, and this can and should be gzipped
4) Updates? There'd need to be a mechanism to provide people with new releases, and yet not have to update apps with each new commit (also, trusting apps to not become malicious as they are upgraded - this is very important!)
5) I'll think about it some more, too.
Are you sure? yes | no
There's a ton of options for the app format. Just have to find the one you like or roll out your own.
Good point on the updates. That's something I didn't think of. In that case, it might work out well to use a system similar to apt. You'll have to think of a clever way of entering the PPAs. Perhaps an app ID that you automatically issue (so there's no duplicates) (which an user that wants to install can just type in)? Maybe the site that generates the app ID can also generate the app format file?
There's lots of options when you have a blank slate.
Are you sure? yes | no
I think that in the end rolling your own is always preferrable - provided you have seen enough other formats, of course =)
Hmm, I for some reason would rather go the Linux package management way and use human-readable app names, whatever the author picks that isn't taken =) Names that make sense are also usually more readable, and I don't think using a Markov chain generator is the way to go =) App format file could be generated with a command-line tool. Now, if we were to talk about app verification, that's another story.
The reason I'm basically using whatever Internet now uses for websites is that this allows the most flexibility and the most decentralization possibilities. My aim is so that you could deploy a ZeroPhone app repo at your home and it'd be nobody's business except yours - and that's what we currently have with websites and webservers, I like it. The only thing I don't like are SSL certificates which cost and are centralized - but open systems allow you to do whatever the heck you want with certificates anyway =)
Lost of options, indeed. And they all become irrelevant when you roll out your first release including a choice you made - once you do that, you typically have to support it for the rest of your life =D
Are you sure? yes | no
The software plans sound amazing!
It's going to be great seeing the app development take shape, and also see what users can come with too. The app repository could be phenomenal! :-)
Are you sure? yes | no