While I've been a bit quiet, a lot of happening for Fursquare... but the bits I am working on now don't really warrant screenshot updates. Right now the underlying framework for the mobile application, a set of libraries and reusable functions, as been mostly fleshed out. In addition, I have written the back-end server REST API and started connecting the screens I posted with static information, so they're truly wired up and retrieving data like a real mobile client app would. This part is slowing down a bit, because as with any API, the security of your mobile app should be at your server level, so ensuring things like rate-limiting chat messages, ensuring someone can't enumerate your friends list on your behalf, and all the other security and business logic is currently being developed and tested.

I wanted to take an opportunity to write a quick journal entry on SECURITY, PRIVACY, and PERMISSIONS. I'm a huge privacy otter, and when I see things like an application update wanting some permission I don't want to grant, like "send text messages on my behalf", I usually just uninstall it. The point of Fursquare is to provide a slick mobile-first solution that connects furs and helps them share thoughts and feelings, and communicate in a social way. But as with all social media-ish apps, concerns about security and privacy are very important, and more so for something like Fursquare than with other sharing platforms like Facebook, which are inherently more about your personal life. Fursquare is about your furry life, and I'm designing it from the ground-up as a pseudonymous and secure way to meet furs and communicate without having to share your personal details, exchange phone numbers, or otherwise put yourself on the hook to be called out just because you're associated with the furry fandom, or want to chat with others in-character.

All that being said, the app does require a lot of permissions on the Android platform, and I want to be very clear and transparent WHY each permission will be listed in the manifest that you will see in the Google Play Store, once it's out of beta. I owe this to each fur who wants to use the app to understand what the app does, might do, and feel comfortable that it's the right solution for all the other more invasive social media apps out there. Here's the permissions it will require:

CAMERA and READ_EXTERNAL_STORAGE - To take a picture to set your profile avatar. Most furs will upload a picture instead, but the camera is a nice option if you want to upload something you draw. While a formal TOS hasn't been written up yet for Fursquare, and won't be until after beta, pictures of real people or irrelevant things won't usually be allowed. Another use of the camera or select-image-from-storage may be for the coming group-chat functionality I'm working on. I have a lot of friends who will build huge Skype or Dolby Axon rooms with lots of friends, and it's fun to share those in a long-running, on-going manner. Of course, taking a picture directly from the app and posting it to a group chat is the kind of functionality that makes it engaging.

ACCESS_WIFI_STATE, ACCESS_NETWORK_STATE , BATTERY_STATS, DEVICE_POWER, PERSISTENT_ACTIVITY - I'm building the app with the battery in mind. No one likes a chatty, bulky app that runs their battery down. In most cases, there's no reason to continuously poll the server for updated information, as I am planning to deploy Google Cloud Messaging API's that push reminders to the app to go check a server, like when you have a new chat message. But sometimes there's data that you want to pull down, but only if it's convenient, such as updating avatar images of your friends -- there's no reason to check that more than once a day, really. The app will wait until the wee morning hours when you're probably sleeping, and it will then check if it has a WiFi connection, and if it is plugged in. If so, you're probably at home, and it will do that once-a-day polling of data to download. If you're at a con, you may forget to charge your phone, and that nightly check won't occur then. If you're out camping (at Oklacon, maybe), then you may not have WiFI, so it won't try to use up your cellular data plan to do that. To know these conditions, these permissions are required to find out if the time is right.

READ_PHONE_STATE and READ_PROFILE - Each mobile device has a unique identifier called an IMEI. Fursquare will read this as part of the authentication to the app. If you log in from a different phone, it will then be able to know this and cause your session on the old phone to go stale. This is a bit better than text-based 2FA, as a fingerprint will be made of the device itself, not a cookie or other characteristic that may be spoofed more easily. Fursquare will NOT use 3rd-party advertising networks, super cookies, or other creepy spyware, and will not ever transmit your IMEI or any derivative thereof to a 3rd party. This is for authentication security only. We will also send a hash of your mobile device's phone number to the Fursquare servers, and we need this permission to get this data. That might sound scary, but skip down to the READ_CONTACTS portion to find out why.

ACCESS_COARSE_LOCATION - Fursquare will be a mobile-first, local-first app. These permissions are usually requested by adware/spyware apps, in combination with your IMEI, to track you and report you to ad networks that may give you relevant advertising based on your location and profile. We don't do that. We only use these permissions to do Fursquare functionality that is coming soon in the Phase 2 badge system, kind of like a similarly-named location-based mobile app. So, we need to know you're at Anthrocon to give you that Anthrocon badge. Or if we ever put in opt-in 'friend nearby' functionality, maybe if you both say you're going to a furmeet so you know someone you want to meet is there, then we'd use this. But that's all.

READ_CONTACTS - A really scary one. Fursquare will debut functionality that will let you OPTIONALLY let it scan your contacts and made a hash (one-way, irreversible representation) of all your e-mail addresses and phone numbers in your contact list. If you allow this in the app settings, will send this jargon to Fursquare servers and we will store it along with your account. Remember from the READ_PHONE_STATE portion above, we also store YOUR hashed phone number. This allows us to find your friends on Fursquare who are already in your contact list, without ever sending their cleartext personal data Fursquare. It also lets us do graph analysis, so, for instance, if you're new to an area, we can tell you who you don't know, but who is a mutual friend of both of you. So yes, the app will see your contact book in the raw, but it will only ever send hashed portions of it to Fursquare. We will never have the real phone or e-mail address of people you know, and since they are useless to us in a hashed form, if you ever delete your Fursquare account, we will delete the hashes too.

READ_CALENDAR, WRITE_CALENDAR, SET_ALARM, WAKE_LOCK, VIBRATE and FLASHLIGHT - While there is no functionality that uses these permissions today, they are requested now so as a more configurable notification system is rolled out in the future and convention 'reminder' alerting features are added, these are options that are available.

INTERNET - ... Sorry, there's no one around this one. ;)

I would love feedback as to anything you feel is inappropriate, missing, or needs further clarification or discussion.