However, I could also do the same thing with URL rewriting and referrers. It is inherent in the internet and the defective
browser client-security model. Nearly all internet security models focus on trying to protect the *server* and the resources
on the *server*. Don't think of this in the traditional model of your PC being the client and the SERVER being the SERVER. Sometimes your PC is the server (think in protocol terms). Most models and protocols don't do much if anything to protect the
client from the server. Not to say "nothing" is there but most stuff assumes that the client is the "untrusted" and the server is "trusted".
Furthermore, fine granularities of trust are needed. Like "when" will I let you see my "session id" and "referrer" at the same time even
after we've estabilished some relationship of trust. Some models (though not widely used) at least prevent server spoofing, but that is
merely authentication and not "authorization" -- Java started to with Applet sandboxing but thats about as far as a real "authorization" system
has gone and even that didn't really cover what you'd let the client send back to a trusted server about your usage.
-Andy
Michael Czeiszperger wrote:
On Mar 16, 2005, at 12:04 PM, [EMAIL PROTECTED] wrote:
Might be, the clients I work with are a self-selecting group. I mostly work with apps concerned about security (financials, millitary,
health care, network management, etc).
Since the session id in the url by its very nature is not/cannot be encrypted really what is the point of doing such a thing?
I believe that the desire to put session tracking information in the URL is part of the anti-cookie movement. Some privacy advocates were upset with online marketers using cookies to gather information and got a lot of press coverage. There is both misinformation and legitimate concern about the ability of the large banner advertising providers to track consumers. The press coverage has largely died down, but the perception of cookies as being somehow unsafe has persisted. Because of this, some companies write their web-apps to work cookie free.
Check out the description of how cookies work at cookiecentral.com:
"Cookies are based on a two-stage process. First the cookie is stored in the user's computer without their consent or knowledge. For example, with customizable Web search engines like My Yahoo!, a user selects categories of interest from the Web page. The Web server then creates a specific cookie, which is essentially a tagged string of text containing the user's preferences, and it transmits this cookie to the user's computer. The user's Web browser, if cookie-savvy, receives the cookie and stores it in a special file called a cookie list. This happens without any notification or user consent. As a result, personal information (in this case the user's category preferences) is formatted by the Web server, transmitted, and saved by the user's computer."
"During the second stage, the cookie is clandestinely and automatically transferred from the user's machine to a Web server. Whenever a user directs her Web browser to display a certain Web page from the server, the browser will, without the user's knowledge, transmit the cookie containing personal information to the Web server."
Note the strange use of language such as "without their consent", "without any notification", "clandestinely and automatically transferred", etc. The whole description is written to make it seem like the invention of cookies is a plot to steal people's privacy.
___________________________________________________________________ michael at czeiszperger dot org | "Kindness knows no shame" Chapel Hill, NC USA | -- S. Wonder
_______________________________________________ Juglist mailing list [email protected] http://trijug.org/mailman/listinfo/juglist_trijug.org
_______________________________________________ Juglist mailing list [email protected] http://trijug.org/mailman/listinfo/juglist_trijug.org
