Living a public life as a privacy advocate

If you’ve known me for a while, you might know me as a privacy conscious individual or perhaps as someone who leads a very public life. The truth is that I lead both these lives; and while that may sound oxymoronic to some, its perfectly clear to me.

I’m a huge privacy advocate. I still remember the day I woke up and read about PRISM first thing in the morning. My reaction was a mix of disbelief, anger, and frustration. In the aftermath of the PRISM reveal, I made a few choices: I would retain ownership of my data, and I’ll do whatever I can to promote tools that help you do this.

I’m still working on both fronts, but the reality of the situation is that we are surrounded by walled gardens. I decided to make the best I could of these gardens. I remember reading a weird suggestion: only post public stuff on facebook; and I was somehow convinced to try it out.

But I took the experiment a step further. If the service is something I can’t control myself (say self-hosted), everything I do with it should be for public-viewing. Since then, I’ve rarely posted anything private on facebook.

Other services where I follow the same advice include:

  • Goodreads - Whatever I read is public information, along with real-time updates of my reading habits.
  • Last.FM - All my music tastes, along with real-time upates on what I’m listening to.
  • Facebook - All of my posts on facebook are public. I do have some private messaging interactions on facebook (I never initiate them) and usually move them to email if they grow important.
  • Twitter - Tiny byte-sized thoughts and observations are again, public. My account is set to public, which doesn’t mean that I trust twitter with my data. It just means that I expect my data to be public.
  • GitHub - One of the few companies I trust to keep my data safe. Barring a few exceptions, everything I do on github is public, ready for anyone to analyze and use as public data. In fact, github makes all of its timeline data available to public as a dataset on bigquery.
  • Bookmarks - Most of my bookmarks are public via xmarks. I haven’t synced it in a while since XMarks and Chrome Sync don’t work well together, but plan to do something about this as well.

Along with all this, most of the writing I do these days is for public consumption, either via my Blog, or some platform like Quora, StackExchange, or Medium.

Why

My reasoning behind keeping all of my online life public is twofold:

  1. This creates a public archive of my life, accessible to everyone.
  2. It doesn’t give me an illusion of privacy when there is none.

In reference to (1) above, I recently setup Google Inactive Accounts, and have to commend Google on the execution of the concept. Be sure to check it out at https://www.google.com/settings/account/inactive.

Disadvantages

This lifestyle choice is not without its comebacks. Stalking me, for example, is very easy. So is probably impersonating me as well. However, these are risks I’m willing to take in order to lead a public life.

Exceptions

By now you might be thinking of me as a pro-facebook share-everything kind of guy. But that’s not completely true. I do have clear limits on what counts as public and what does not. I value my privacy (and that of those close to me) very dearly.

For instance, I count my photographs as something very private. I almost never post public updates anywhere with my picture in it. Perhaps its because I never had any phone with decent camera. Whatever the reason, I try really hard to keep my pictures off the internet.

Another related issue is when the update would involve someone beside me. For example, my sister was recently engaged and I didn’t go on a social update spree telling the whole world about it, because I value her privacy.

My simple rule of thumb is to ask for permission, rather than beg for forgiveness as a person’s privacy is far more important.

What was the first project on GitHub?

Note: This is cross-posted from Quora where I wrote this answer initially.

The first project on GitHub was grit. How do I know this? Just some clever use of the search and API.

Here’s a GitHub search to see the first 10 projects that were created on GitHub. The search uses the created keyword, and searches for projects created before 15 Jan 2008.

They are (in order of creation) (numeric id of repo in brackets):

  1. mojombo/grit (1)

    Grit gives you object oriented read/write access to Git repositories via Ruby. Deprecated in favor of libgit2/rugged

  2. wycats/merb-core (26)

    Merb Core: All you need. None you don’t. Merb was an early ruby framework that was merged to Rails No longer maintained.

  3. rubinius/rubinius (27)

    Rubinius, the Ruby Environment Still under active development

  4. mojombo/god (28)

    God is an easy to configure, easy to extend monitoring framework written in Ruby. Still actively maintained, and use by GitHub internally as well, I think

  5. vanpelt/jsawesome(29)

    JSAwesome provides a powerful JSON based DSL for creating interactive forms. Its last update was in 2008

  6. wycats/jspec (31)

    A JavaScript BDD Testing Library No longer maintained

  7. defunkt/exception_logger (35)

    The Exception Logger logs your Rails exceptions in the database and provides a funky web interface to manage them. No longer maintained>

  8. defunkt/ambition (36)
  9. technoweenie/restful-authentication (42)

    Generates common user authentication code for Rails/Merb, with a full test/unit and rspec suite and optional Acts as State Machine support built-in.Maintained till Aug 2011

  10. technoweenie/attachment_fu (43)

    Treat an ActiveRecord model as a file attachment, storing its patch, size, content type, etc.

I’m sure the id from 2-25 would be taken up by many of the internal GitHub projects, such as github/github. To get the numeric id of a repo, visit https://api.github.com/repos/mojombo/grit and change the URL accordingly.

How does the sdslabs.co.in domain name work?

A very common asked question is about our domain name and how does it work locally. When we launched filepanda, and our preliminary homepage a long time ago, we had been using the easy to remember IP address http://192.168.208.208.

Now, however we are using the domain name sdslabs.co.in for all our services, including DC. To understand how this works, you will have to understand how the name resolution of a domain name takes place.

The Domain Name System (DNS) is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities.

- Wikipedia

DNS is basically a service which resolves domain names to IP addresses. If you own a domain name, you can point it to wherever you want. This is usually done in the administration panel of your hosting services. We have setup multiple domains on our nameserver (mitsu.in as of the moment) to point to the IP address 192.168.208.x.

For instance sdslabs.co.in points to 192.168.208.208, echo.sdslabs.co.in points to 192.168.208.204 and so on. This is done via updating something called A records (this is the part of resolution which transaltes to IPv4 addresses).

The benifits of having such a system in place are enormous:

  • Users don’t have to remember IP addresses, and can easily remember the site address.
  • We can move around services, applications over different machines, and it will only take a single update to change the name resolutions
  • We could add alternative fallback servers easily (by having multiple A record entries) for a domain. We could even use this to point sdslabs.co.in domain to something that is hosted online, for instance.
  • We can have catchy, and simple to remember urls for eg https://sdslabs.co.in/login, and https://sdslabs.co.in/logout

Also, we are running all our services on https, which is not dependent upon the visibility of the website. Even though the site is hosted locally, the process of certificate signing remains exactly the same as any other site. Once we aquire a SSL certificate and attach it to our web-server, the visibility of the domain does not matter to the browser at all.

Note: For the benifit of those not in IIT Roorkee, we are running multiple web-service on the domain sdslabs.co.in, which is only served locally, as it resolves to a local IP address (192.168.208.208)

Caveat: Several DNS servers wil block RFC1913 responses by default (basically any DNS response in the private IP ranges). This is usually disabled in the intranet scenarios, but something to keep in mind if you’re looking to use this solution.