Capitalism and the environment

Tuesday, July 07, 2009

Sadly, this is not a joke - it's the truth. All large-scale projects see "environmental concerns" just as a nuisance they have to put up with it. Something that will eventually have to yield, because, well, you just can't stop "development", can you?

Why aren't existing trees part of "beautification drives"? Why does beautification always mean pouring massive amounts of concrete on the ground and building railings and felling of trees?

On that note, I would recommend 'Small is Beautiful: Economic as if People Mattered' by E.F. Schumacher as compulsory reading to everyone studying the pseudo-science of economics. And to everyone who thinks growth is good - perpetually.

Labels: ,


Directi Ads on Facebook

Monday, July 06, 2009

Nice :-) This must be resonating with the uber-geeks really well. Check out the careers page as well -- "Open Techie Positions"



Labels: ,


My comments to Ministry of IT about Section 69A of IT Act

Thursday, July 02, 2009

Emailed to grai (at) mit (dot) gov (dot) in as given at http://www.mit.gov.in/default.aspx?id=969

Dear Sir,

With reference to the Draft Rules under section 69A of the Information Technology (Amendment) Act, 2008, available at http://www.mit.gov.in/download/sec69A_Rules.pdf , I would like to bring to your notice the following comments --

(i) Lack of neutral party: There is no provision in the Draft Rules where the request for blocking information is examined by a neutral third-party (say, a court designated for this purpose) before being enforced. This leaves the law open to abuse by persons "in power" who want to curb any criticism (published on the Internet) aimed towards them. In other words this creates a situation where the plaintiff, himself is the judge.

(ii) Lack of representation: There is absolutely no provision in the Act which gives the publisher (against whom the request for blocking has been initiated) a right to a fair hearing in front of a neutral third-party. I realize that on the Internet, which lends itself to anonymity, identifying & notifying the publisher of a particular information resource is difficult. However, there needs to be a process in place using which the Designated Officer first needs to notify the publisher against whom a Request for blocking is pending. This process may include: (a) emailing the contact person mentioned on the website/resource, (b) notifying the ISP on which the website/resource is hosted, (c) general notice on the Minister of Information Technology's website, etc. This is analogous to various "Notices" that any government agency serves before taking drastic action against a person -- like sealing of property, or disconnection of electricity/water supply.

I have worked in the IT industry for 5 years and I understand the need for tighter regulation and stronger cyber-laws. However, these need to be balanced against (a) right to freedom of speech & expression, and (b) right to a fair trial. In my opinion, the Draft Rules completely oversteps these constitutional rights in a bid to provide the governing agencies with more power.

Regards,
Saurabh Nanda.

Labels:


A SIM-card along-with the National ID card?

Taking on from Sanjay Swamy's post at Medianama, I think it's an excellent idea. Sure, there are the rough edges that one needs to smoothen out, but that's the case with any scheme of this magnitude. The kind of opportunities that open if your national ID can be part of your mobile SIM card are amazing. Especially in the mobile banking and m-commerce area.

Picture this: Your bank and telecom provider, both as part of their KYC, will need to know your national ID. Now, if you have the ability to link-up your SIM with your national ID (both smart cards), you can perform a fully authenticated financial transaction through your mobile phone. Just think of the number of services that can be made available to the rural population through such a thing!

The biggest challenge this idea will face is from people getting paranoid about
(a)a telecom operator "owning their identity", and
(b) not everyone having a mobile phone.

The National ID should be a complete in itself even without a SIM or a mobile phone. Something like the new vehicle registration smart cards you get in Maharashtra nowadays. However, it should have a detachable SIM card built right into it. If you want to use the additional features of your National ID, just remove the SIM and plug it in. You can keep your current phone number and even switch operators -- thanks to Number Portability.

The telecom operator (or anyone else on the mobile network) will NOT have access to your identity unless you authorize them during a transaction which requires such an access. It's just that if the SIM and your National ID live on the same hardware (which is, the smart card) you can link them up with ease, as and when required!


Labels: ,


ICICI Bank -- Email shy?

Friday, November 21, 2008

Has anyone ever been able to successfully email ICICI Bank? I've tried twice and failed. Today was my second attempt. After being asked a series of questions (four, I think) I finally get this form.

Even after asking my account number (which will give them instant access to all my contact details -- KYC, remember) they still want me to type out my email address, phone number (along with STD code -- mobile numbers don't work), and complete contact address.

And finally, the damn thing doesn't work!

What's wrong with just giving an email address? Saves them from the development and maintenance cost of developing this stupid tool. Isn't customer support on email cheaper than doing it over the phone?

Update: A friend tell me that the form works on IE and not on Firefox. Irks me even more!

Labels: ,


Email archival without mailing list software?

Thursday, October 30, 2008

I believe that the lack of archives in business communication is a serious enough problem to solve. Especially in these times, when a lot of brainstorming happens on email amongst team members located in different geographies.

I've tried using Basecamp for all business communication and succeeded only partially. Although Basecamp can serve as a good archive for email communication, it just doesn't beat the simplicity of adding any random email address to the CC list when you hit "Reply all". You have to first add a user to a project, then add him to the message, and then reply to the message. This, of course, will work only if the person knows how to use Basecamp. Otherwise, add the additional overhead of evangelizing Basecamp over regular email before getting him to accept this new mode of communication. [1] If something confidential is being discussed, there's also this fear of archiving your trade secrets on someone else's servers.

Probably there's a good use-case to add a new feature in SMTP servers -- an archive header and an email archiving module. If an incoming email has the archive header (X-Archive: true) the SMTP server will archive the email by storing a copy of that email and making it accessible on a web page. All replies to that email (and further replies to those emails) will automatically get archived, regardless of whether they have the archive header or not [2]. The server can also add a footer to each email in the thread to direct the user to the archive. Optionally, the archiving module may also archive email attachments and make them available on the company intranet (or the web).

Various mail clients will also need to be modified to present a user with a checkbox while composing the mail that sets/unsets the archive header.

I think this feature can be easily hacked into postfix (or sendmail) and a couple of open source email clients (like Evolution and Thunderbird).

Alternatively, this can also be achieved by having a record-keeper email ID (something like archive@somecompany.com). Any email CCed to the record-keeper will be archived and available on the company intranet (or the web). The only drawback of this is that the archival chain can break very easily if someone removes the record-keeper from the CC list. This approach can probably be an easier path towards implementation, both from the client's as well as the server's side. (Aren't such archival modules already available?)

If anyone wants to collaborate on this project with me, please drop me an email at saurabhnanda (at) gmail (dot) com. I've been wanting to work on a decent tech project for quite some time now.

[1] Given, recipients of Basecamp messages can now simply reply to messages just like normal email, it's still not perfect. All formatting (even line-breaks) are stripped. And you still have to log on to Basecamp to compose a completely new message.

[2] I think it's reasonable to assume that since the parent wanted the email thread to be archived, it must be archived in its entirety.

Labels: , ,


In Support of "Top Posting"

All over the web, on mailing lists, especially in the open source geek circles [1], top posting is frowned upon. Even while bottom posting, you're not considered cultured if you don't truncate the parent post to the exact specific part(s) your reply pertains to. I, too, used to follow this religiously until recently.

After three years of communicating with non-geeks (you know, the business and marketing types), I realized that a lot of business communication was simply not possible in the typical quote-reply-quote-reply format that is prevelant on mailing lists. This is because of a couple of reasons, which I'll try to enumerate in the following paragraphs.

One of the reasons given for not including the parent post in its entirety is that anyone wanting to refer to the thread can always look up the mailing list archives. Cultured folk should not waste bandwidth and screen real estate by repeating what is available a click away. This is not the case with typical business communication, which starts between two people (with usually their bosses on the CC list -- to be "kept in the loop"). Along the course of a reasonably sized email discussion, the CC list grows exponentially (believe me)! First the bosses' bosses are added -- if the small fry realize that they'll need to save their ass if something goes wrong. Suddenly something is under the purview of a chappy in some other department and him and his boss and boss' boss are added to the list. Later someone realizes that the legal department also needs to be "kept in the loop". Within no time you're having an orgy on email! With each new addition to the CC list you need a place where the latecomers can read-up on the discussion till then. In normal business communication there are no "archives". The latest email, itself, serves as an archive. I've had a tough time catching up on the discussion where each email was regularly truncated by the participants. I had to piece together more than 25 different emails forwarded to me as the "archive" -- believe me, it wasn't an easy task. Therefore it's much better to preserve the entire thread in the body and add your reply to the top of the email.

A side-effect of not having an archive is that you can't really follow the quote-reply-quote-reply pattern ("Comments inline...") very effectively. If five different people are communicating, you suddenly lose track of (a) who said what, (b) in reply to what, and (c) in reply to whom. With an archive, each post can easily be identified on all three parameters. Take away the archives, and within two or three replies you lose track of (a) and (c) very easily. Inline comments, even in business communication, are useful when each paragraph or point in your email can be answered independent of the others. For example, when you're seeking answers to a list of technical questions. However as soon as you want to reply to the reply of your questions you start losing track of (a) and (c). One decent solution I've noticed is prefixing your reply with your name in square brackets. So, a typical email after a couple of back and forth replies looks like:
* Can I pass the customer's shipping address instead of the billing address in the API?
[Alice] It's possible, but why would you want to do it? You already have the billing address in the DB, don't you?
[Bob] Yes, we do -- but we don't want to share it due to privacy concerns.
[Alice] Okay, then you can pass the shipping address.
I've observed a significant side effect of following the quote-reply-quote-reply model of communication -- especially on tech mailing lists. A lot of discussions regularly morph into flame-wars, mudslinging matches, or "preachers preaching the lesser mortals." Don't get me wrong -- the communication style is not the sole reason for discussions going off track. Obviously a lot depends on the attitude of the people involved in the discussion, but I feel the communication style definitely promotes the degeneration of the discussion. When you read a post you generally disagree with, it's very tempting to pick each line, quote it, and try to rebut it individually. It's very easy to get lost in the trees for the woods.

[1] These are the only circles which seem to have a respectable mailing list culture.

Labels: ,


Overestimating users of technology

Wednesday, October 15, 2008

Most software products assume too much about their users. After reading Alan Cooper's "The Inmates Are Running The Asylum" (at Amazon and at IndiaPlaza) I realized how much I used to presume about a user's comfort level with technology while designing products. I now consciously switch off the developer/geek side of my brain while writing product specs or mocking up UI prototypes.

Here's a post by David Pogue on what everyone assumes that everyone else knows but is wrong. I thought I would know every single thing on the list but was surprised to find a keyboard shortcut that was new to me - using shift + space to scroll up in a web page.
You can tap the Space bar to scroll down on a Web page one screenful. Add the Shift key to scroll back up.
Yahoo! recently released their research findings about an OpenID usability report. They were not surprising:
None of the users had heard of OpenID before, and none of them even noticed the OpenID sign-in box displayed below the traditional email/password login form on the site. [...] Observing these tests was more than a bit frustrating for the Yahoo! OpenID team, and the test subjects may have been distracted by the sounds of the groans and head-pounding coming from the other side of the one-way mirror. Certainly there is a lot of work to be done on the OpenID UX (user experience) front.
(At the risk of over-simplification, OpenID is a common username/password using which you can login to multiple websites without creating individual username/passwords for each.)

Labels: ,


Scary: CSRF and REST

Tuesday, September 30, 2008

The latest exploit to hit the web is CSRF. It's nothing fancy, very simple to execute and understand. In a nutshell:
  1. You're signed in to website A

  2. You open a new tab and visit website B. Website B is a malicious website (or is a trusted website which has the potential of being malicious because of allowing user generate content-UGC).

  3. Website B has an image tag (not necessarily, but the simplest to inject via UGC) which points to a predictable URL on website A. For example, <img src="http://www.a.com/account/delete?confirm=yes" /> which basically deletes your account on website A.

  4. Your browser will try to fetch the "image" from website A, merrily sending your session cookie along with the request. And BOOM! On website B you don't get the image ('cuz there is none) but your account has just been deleted from website A.

This is the simplest scenario I've explained. Read the Wikipedia article CSRF to understand how it can be executed in a variety of ways and situations.

Over the past year or so I've been going ga-ga over RESTful architecture and stateless servers. I've tried making URLs predictable and discoverable. Personally, I click on the "keep me signed in" checkbox whenever on browsing the web on my laptop. This just turns my world around!

Does it mean that we now need to make sure we're not signed-in to one site while visiting another? Or that all web applications now have to be stateful and URLs have to be non-predictable? Which means that while generating a page the webserver will have to add a random token to each URL and validate that when the browser requests the URL? The horror!

Any thoughts, anyone? This sounds like impending doom!

Labels: , , ,


This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]