Pros and Cons

The advantages for users

• As explained earlier, an outgoing SMS i.e. an SMS that is sent deliberately from the user to our system is extremely authentic. Our SMS receiver gets that user's phone-number. We do NOT send the phone-number to anyone. We don't store it ourselves. Instead, we send only a proxy to the merchant. This proxy is stable: That means each number will always get the same proxy. This is explained later. In case of authenticating using the user's email address; our receiving servers only accept those domains who have a valid SPF record in their DNS. We don't trust the "FROM" address present in the email address. Instead we only use the address mentioned in the SPF headers. As it is really tough to spoof the SPF record, one can be quite certain about the user's address so determined.

• SMSes are never pushed to a user. We or our merchants who use our system will NEVER be accused of spreading spam. Why? Because it is the potential user who sent out the SMS to us. Never the other way around. Same is the case with the email route: We can't be accused of spreading spam. NOTE: The merchants who implements our system, may later on ask their users for the users' contact details. That is a separate matter which does not concern us.

• SMS is extremely fast. SMSes are often used in emergency situations. So all phone networks diligently ensure that at least SMSes are sent out properly. In the rare situation, an SMS cannot be sent out from the phone -- Simply Sign In will fail in a safe manner. That means, if the user cannot enter in; at least the user is sure that his/her account has not been compromised.

• SMS does not need an Internet connection at the phone. This can be quite useful many times. It may be possible that you are in a resort and your phone does not have data connectivity but does have SMS. You are browsing at an Internet cafe at the resort; and even though your phone does not have Internet, you can still enter the merchant's website quite easily.

• It is extremely cheap. The cost of SMSes also have drastically fallen -- and are even free. That is because phone companies are making a lot more money from Internet Data. Also, the SMS is used only for the authenticated entry and nothing else. So in comparison with the value that user gets from a merchant who has implemented our system, the cost of the SMS is extremely tiny.

• Since the sign-up process uses your phone's SMS you will be able to know which merchants you had signed-up with and at which date/time. This is super useful to many power users of the Internet who creates accounts on many different websites/SaaS applications/etc. and then forgets about it later.

The disadvantages for users

• The only real disadvantage of such a system (if you can call it that) is that your contact info (phone number or email address) will be known to us (temporarily... we do not store any phone numbers or email address). As explained at great length earlier, we have told you that the origination number of the SMS can never be spoofed and that is key to identifying the user. So once you send out an SMS from your phone, it will be known to us. Now, some people may not like their phone number or email address being known to others. It is a valid privacy concern. Simply Sign In has actually handled this situation too. In the current version, the receiving server we have used actually strips away the actual phone number (or email address, if you used that route); and we use a strong cryptography process called hashing which converts the origination info to a unique alphanumeric code. We NEVER send the phone number/email address received at our end to the merchant the SMS is addressed to. Instead the merchant gets that hashed proxy of the users phone number/email address. Since each different number/email address will have a different hashed code; the merchant will be able to distinguish one user from others as each will have a different proxy. Also, the hashing process on the same origination info (phone number or email address) will produce the same hashed code every time. Which means, when the proxy will always be identified as the same user by the merchant, every time he/she enters the website. Let us repeat what was mentioned earlier: We NEVER store anyone's phone number or email address. They are all used transiently.

• Any other disadvantage? We don't think so. If you can think of some more disadvantages that we need to address; we are all ears. Do write to us. At the end of this documentation, you can read frequently asked questions we have answered till date. BTW, some people may balk at typing a line in SMS. We don't think that is a disadvantage. Our system is not asking you type out a huge message where you may make some typos!

The advantages for merchants

This system is advantageous to merchants too. Some of them are

• There is very little friction for a new user to get an account at a merchant's website. Other systems take a lot more steps (We have given some pain points in other authentication systems at the end). In our case, all the user has to do is to send out an SMS to a specific number as shown on a merchant's page.

• As most users don't have hundreds (or even tens) of phones, the merchant is reasonably assured that the user who enters their website are quite authentic; and most of them have only one account with the merchant. This is quite important for many types of merchant's systems. For e.g. if the merchant has created a profession discussion board; that should not allow multiple accounts from the same user. Why? The discussions happening in that professional discussion board can then get biased. Now one may say; a user may have 2 or 3 phones. True. In such a case the same user may take 3 accounts with the merchant. But that is much less than what would have happened if the merchant was using registrations with email addresses. A user can easily setup 50 email addresses, and then the same user can get 50 accounts into the merchant's website. This is one major reason why people get biased on the Internet.

• A merchant's offerings are very well protected. They can only be used by the registered person only! The merchant is sure that a person (e.g. a son, or wife) CANNOT use an authenticated user's credentials to enter. In short: No sharing of password is possible! *Provided the merchant used ONLY our system for both sign-up as well as sign-in.

• Once Simply Sign In has sent the encrypted data about the proxy, etc. to the merchant's website. the merchant can take all the other decisions as needed. For e.g. some merchants may decide that the Simply Sign In "entry process" is to be used only for initial registration and the forgot-password process. But the rest of the time the user logs in using a username and password that the merchant asks a new account holder to set. In some other cases, the merchants can insist on the user going thru the entry process every time. In some cases, the merchant may be using an open-source SaaS software at his website. In that case, once the authenticated user reaches the merchant's website; a simple code can be used to insert the credentials into that open-source system to register/login the user. In short, we give the maximum flexibility on how the system can be integrated into your website. Write to us, if you have any issues integrating your existing system with Simply Sign In.

• The chances of hacking our website very remote. We do not ask the merchant to share their website user's internal username and/or password (if the password was indeed set) with us. We don't even store anyone's phone number/email address with us either. So nobody can really get anything out of us; by hacking into our servers!

• Hmmm... let me play the devil's advocate here: Let's say that a hacker did get access to our own database. What he will surprisingly find is that there are NO look-up tables. Most other authentication systems at the deepest level, are database based. In those systems, a look-up is conducted where the username (or his/her email address) is matched to a hashed version of a password. So both values have to be present in that database. Our system is algorithm based credential proof and NOT based on database lookups. That means, the hackers will have no choice but to implement the algorithm themselves if the merchants' websites are to be hacked! And also, the hacker will have to con the merchant to use their website instead of ours, for them to replace our system. All that complexity cannot be achieved by any hacker.

• This system brings credibility to the merchant. As we do NOT pass on any user's phone number to the merchant, potential users of that merchant's website would be reassured of the privacy the user would get at the website. So this is especially useful for those merchants who are serious about protecting the user's identity and contacts. Of course, as explained earlier; depending on the merchant's website needs, the merchant is free to ask for additional information from the user; if that particular system needs them. For e.g. there may be genuine reason why the merchant wants to collect the phone number of the user who has come in for the first time. Or the merchant may want an email address, etc.

• There is one major hassle that all merchant's websites have: Which is to write and test the code to let potential users cross a threshold and come into the website. We have done all that hard work for you!

• This is a highly scalable system: As we do not store any information in our servers (not even temporary data) when doing the authentication, our servers work really fast and there is no question of our database getting blown up due to records piling up (there are no entries at all!). Hence, we can serve billions of users.

• We and merchants who implement our system can never be accused of spreading spam. Of course those merchants who implements our system and then separately ask their users' contact information; then the said merchants will have to take up the responsibility of assuring their users about this point.

The disadvantages for merchants

• Frankly, we cannot really think of any! If you have questions please do not hesitate to ask.