Restricting Navigation of Browser For Applications
We plan to use the web browser only for logging in and a new window will be launched for our application.
Our application will provide a more controlled user’s environment that will keep them focused on the task and provide data integrity:
The following changes will be made:
· The new window will not display the standard navigation bar of the browser.
· The right click on the mouse to access that navigation bar will be disabled
· Some keyboard control functions can also be deactivated.
· F5 for refresh of screen will NOT be disabled.
· Control-p for page print will NOT be disabled
· Esc for ‘STOP’ is still being discussed.
Is this a good idea?
Have anyone ran into problems with this idea or
Wednesday, November 21, 2001
It's a terrible idea.
I had to battle with this line of "thinking" from people working on a Web application who thought that they could hide the excessive information their badly designed app sent the browser by these sorts of tricks. They're a pack of dumb asses who don't understand how web browsers work.
If you want to ensure a restricted range of functionality is available to the user of an application, write a boring old client/server app with a Win32 binary that communicates via a proprietary, encyrpted protocol.
If you want to write a web app, accept that you're sending plain text that anyone can read with their client, that you have no control over that client, and that they can trivially evade any measure which relies on features of the client software.
Simple example: rocket scientests who believe leaking sensitive information in hidden form fields can be hidden by disabling view souce in IE. I yelled at them for a while, but they only believed me when I showed them that a Navigator user could still view source.
Wednesday, November 21, 2001
My bank offers it's online banking interface like you suggested, a right pain. Totally user unfriendly.
Why can't a bookmark pages inside the banking application? I could if they designed it properly.
Thursday, November 22, 2001
The only way I found to maintain security risks relatively low was to use a trick similar to session states. What I did was create (server side) a temporary file, and assigned an ID number to it. Then I store any relevant information on it, using a centralized (sp?) "form manager" (believe it or not, I managed to use XML to generate forms, processing inputs and store this data).
The drawback was... the damned thing was AWFULLY complicated, and the architecture somewhat fragile (we had one server to store the XML files, other to process the forms and another one which was running the app), so we had three critical points instead of one.
Maintenance of this spawn was pure hell, but developing applications that use it services was sweeeeet. If I wanted to create a form, I just needed to write a XML file with the description of the data needed, the sender and target URL, some rules of validation and feed the form manager with it... very handy when you are used to write tons of form validation routines.
Besides the maintenance issues, the thing was very nice.
Btw... what was the main topic? Oh, I see... "restricting navigation of browser for applications". Wait, let me remember why I was writing this... ok, I remember. This structure allowed us to maintain a lot of information of the state of the user, based on the unique ID of the session. If the user does something wrong, like messing around with GET parameters, we can tell it. If the user tries to do funny stuff in two separated browser windows, we can tell it; if the user tried to put garbage in the querystring, bum, kick him in the nuts, redirecting him to the "relogin" screen. You can't reload the same submitted form, too, because of the transaction state, and lots of small things like that.
Ok, now I'm boring myself. Adios.
Thursday, November 22, 2001
Richard asks "Is this a good idea?" The answer is as usual "It depends." It depends on who the target users are.
If the target users are employees, and the only thing they're supposed to be doing with the computer is using your app, then maybe you can get away with this. Maybe. Your employees probably won't like it, but if you don't value employee satisfaction, then you can probably do this.
On the other hand, if the target users are customers or other members of the general public, then you're trying to exercise more control of them than you deserve. Most users will hate you for this, and you'll get one of three responses: they'll grumble while using your app, or they'll just go away and do business with someone else, or they'll find a way to defeat your control.
When I encounter apps like this, I'm often in the third category, partly because I enjoy the challenge. I've been known to read sources of pages, ripping them apart to get rid of the useless frames and other nonsense, finding the deep URL that actually does some good. I've been known to build my own small web app that just passes through other people's pages, while removing offensive content (like attempts to open ad windows, or attempts to remove navigation bars from opened windows). I've even been known to patch the binary of my browser to remove its ability to recognize things that I always find offensive (like <blink> and <marquee>.
In short, you don't want to do this unless you're convinced that the upside of partial success exceeds the downside of lost goodwill, lost customers, and customers who work around your stuff.
Friday, November 23, 2001
Fog Creek Home