Question: I am creating a SaaS that will be delivered through a Vertical Information Portal (VIP).

In my research I have found that by developing a custom lean web browser and installing it on the clients platform, I can better restrict access to the portal on the web by only allowing this custom browser to access it.

I realize there is a threat of duplicating the the client browser. but I feel it is better option instead of any browser being able to access the portal to receive the payed services, and much easier to flag for piracy.

However, in regards to security of a custom browser, I have not been able to find any useful information. I would elaborate on this point, but unless I am missing something (which is probably the case), I have nothing to go on.

Can you point me in the right direction to make a thorough threat assessment on a custom browser build for a VIP delivered SaaS?

**EDIT**

By looking at the possibilities of a customized connection from server to client, I am not trying to re-invent the wheel, but looking at innovative options to make improvements to the wheel.

I do not make the assumption that any system is totally secure, and I fully believe the practice of IT Security is a constant work in progress that must be improved on (hence, the purpose of this question).

Answer: 
It sounds to me like you want your Web based SaaS application to be accessed only by browser/client/hosts that have some system integrity properties that are usually lacking in a typical web client host -- e.g. absence of malware, resistance to malware. If that is so, then you should consider developing a client that is a hardened dedicated browser appliance:
a) delivered to users as a liveCD image to be booted on typical PC HW from RO media;
b) built using SE Linux and bootstrap to restrict the executable application software to consist of a web browser;
c) local packet filter configured to permit communication only with the host(s) of the server side of the application;
d) browser configured to trust only the server certificate of the server side of your application;
e) several other supporting characteristics, but that's the gist. 

An worked example of hardened dedicated browser appliance is available at:
 <https://github.com/trustthevote/BrowserAppliance>
In addition, you will probably want to build into the client image a key pair and PK certificate that the server requires as a pre-req for service. As you point out, it is certainly possible for the cert and key pair to be extracted and used by a different client host; but it is a strong measure to prevent casual or accidental use of "normal" client hosts such that the server would interact with these risky clients. If your application uses strong user authentication, then you de-scope your risk further by limiting the pool of people who would benefit from something as weird as cracking keys out of a perfectly usable hardened dedicated browser appliance, in order to rig up their existing PC as a client, without having to boot from RO media as a pre-req for using your application.

Hope this helps!
John Sebes
<http://osdv.org>
This is [(in)security though obscurity](http://en.wikipedia.org/wiki/Security_through_obscurity), I don't see how this improves the security of any system. Probably the reason why you can't find any information on this topic is because its not a good idea. I suspect you would also implement your own HTTP protocol, and then forbid clients from sniffing the wire with wireshark/tcpdump. Oah and you will have to forbid the client from opening their own socekts, and access to telnet...

But all that aside, I can still find and leverage xss/csrf/sql injection/whatever using just a web browser... What is keeping the attacker from putting sql statements into an html form or the address bar. So by reimplementing the wheal you are already giving the attacker a perfect tool to compromise your system. 

Whats the point?