What a coincidence, I went to the Forum to post about browser cookies, and there was a post by someone named "Cookies".<P>Anyway...<P>CD is a very polite website: no pop-unders, pop-overs, blinking stuff. Fast servers. And it only puts one cookie in your browser, which is optional but can make the CD experience a bit easier.<P>Therefore, I was surprised when I clicked onto one thread and my browser was handed a cookie: <A HREF="http://www.criticaldance.com/ubb/Forum4/HTML/000880.html" TARGET=_blank>http://www.criticaldance.com/ubb/Forum4/HTML/000880.html</A> <P>Investigating, I found that the cookie was being placed in my browser because of a linked image from Houston, of the Pied Piper:<BR> <A HREF="http://www.chron.com/content/news/photos/01/09/02/piper.jpg" TARGET=_blank>http://www.chron.com/content/news/photos/01/09/02/piper.jpg</A> <P>I'm not sure if anyone is aware of this.<P>I know how to build a technical solution that would clean cookies out of any external links. Depending on what source code or hooks come with UBB, it might be feasible to implement as well.<BR>

citibob you have the option from your end of disabling cookies in your browser, but you will have to re-enter your username and password each time you post as a result, as I am sure you're aware. We could disable the option to post images in order to avoid cookies from external sites. But speaking for myself, I like pretty pictures. <P>I'm curious, exactly what is your concern with this particular cookie? <P>If you are interested in learning more about UBB you can check out the UBB Developers site - <A HREF="http://www.ubbdev.com" TARGET=_blank>www.ubbdev.com</A> or the Infopop site - <A HREF="http://www.infopop.com" TARGET=_blank>www.infopop.com</A> UBB is written in a perl script, but it's a complicated cgi code, one that I have nightmares about trying to edit. I'm waiting for the people at Infopop, who are getting paid the big bucks, to develop a multi-lingual board, I think I'll be waiting a while.<P>

I use the Konqueror Web Browser, part of the KDE Desktop environment, which comes with RedHat Linux.<P>Konqueror has sophisticated cookie management. As you use it, it configures itself to accept cookies from some domains, reject cookies from others, and ask you about the rest. Whenever it encounters a new kind of cookie, it asks.<P>Since I began using Konqueror, I've been astounded at the sheer number of cookies running around, as well as the insulting names given to some of them. Some sites put 2 or 3 cookies in your browser, from multiple marketing networks. I'm not talking porn sites here, I'm talking about otherwise legit sites.<P>My browser, for example, is currently set to reject cookies from feedroom.com, mediadevil.net, revenue.state.pa, targetnet.com, valueclick.com, webtrendslive.com, addfreestats.com, adlink.de, ads.targetnet.com, advertising.com. Previous incarnations of my Linux system rejected cookies from places like "flycatcher.net" as well.<P>In fact, I only accept cookies from 20 domains, and reject cookies from at least 100 (and growing).<P>I'm sure you can understand that as a matter of policy, I reject cookies from new sites. That includes the Houston paper.<P>I agree, allowing users to post links to pictures is a good feature.<P>The technical solution I referred to would involve building a "pass-through" server at CD. All requests for external resources, such as the picture, would be routed through the CD server. CD would then go out, fetch the picture, reject the cookie, and return the raw data back to the user. It would put a minimally greater load on CD's server. For copyright reasons, it would probably be best not to cache any of those resources.<P>A similar concern involves rogue HTML. Apparently, UBB does not understand how to parse HTML, and just passes through whatever a user writes. For example, use of the UBB URL tag produces a nice link to open a new window, but use of the standard HTML A tag does not.<P>Users could write all sorts of crazy HTML that would mess things up in strange ways: unbalanced begin/end tags and JavaScript are just a couple of things that could come through. In order to prevent that, you have to parse the HTML coming from a post, and accept only a certain carefully designed subset of HTML. Most people don't do this, but I have developed the technology necessary for it.<P>One other UBB concern is searching. Currently, UBB seems to perform a linear search through all the articles. Within the next six months, that will probably no longer be a viable solution. Techniques exist to produce sub-second search times. At some point, CD could greatly benefit from them. Of course, UBB might end up incorporating them.<P>I'm confused about whether UBB is an open-source product or a commercial product. If it's commercial, I would expect the Perl scripts to be obfuscated, and not easily modified. In general, I don't consider Perl to be the best language to build large software products in, but people seem to do it anyway.<P>I hate to reccommend that a working solution be replaced with something else, especially if I don't obviously have the time to do it. But CD might consider using OpenACS ( <A HREF="http://www.openacs.org" TARGET=_blank>www.openacs.org</A> ), a variant of the ArsDigita Community System ( <A HREF="http://www.arsdigita.com" TARGET=_blank>www.arsdigita.com</A> ), at some point. It can certainly do everything I've seen on CD. Moreover, it is an open source solution and should be easier to modify.<BR>

IMO, this is an <u>end-user issue</u>, not a CD issue. Why don’t you just run a firewall if you're worried about your system being compromised? You must spend a lot of your time rejecting cookies when you’re on the Net, doesn’t that get tiresome?<P>My take on cookies:<BR> <BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Before you panic over cookies, it's worth remembering that the vast majority of cookies are benign attempts to improve your Web browsing experience, not intrusions on your privacy.<HR></BLOCKQUOTE>source: W3C -The World Wide Web Security FAQ<P>You may like to "manage" cookies but I refuse to get paranoid about them. We live in an age where information can be accessed no matter how 'careful' you are. Am I taking a risk? Maybe, but walking across the street is a risk. Also, I don't offend easily, what someone else names a cookie means little to me. <P>The 'pass-through' server idea is good in theory--but there have been problems with connectivity for the UK dial-up users since moving to the new server, I don't think they could take another hoop right now, they're already timing out in peak hours. <P>UBB is open source, but you have to pay a licence fee. It’s just perl script so anyone can modify it (provided they can write perl).<P>Re: "rogue HTML," If you know HTML then you know that you simply add a "_blank" or "_top" etc., target tag to a referrer to open a new browser window. And the UBB script just converts the UBB tags to HTML anyway, so it does "understand" HTML, but if you use HTML it expects you to know what you’re doing. Some UBB administrators don't allow the HTML option on their boards, maybe to avoid those who don't understand it from trying to post with it. UBB code is just "HTML for dummies," it was created to look simple from the users perspective and so they don't have to understand HTML code.<P>UBB is not perfect, but I've looked at a lot of message boards and from what I've seen, UBB is the most flexible. CD doesn't run the current version, I don’t know if the search function has improved. And as I mentioned, since we have two languages going on this board, and Infopop developed scripts to run other languages, staying with a company working towards multilingual solutions is of interest. <P>Stability should never be taken for granted; a "new solution" would have to be tested extensively before it could be enacted. I don't think anyone currently volunteering his or her time could undertake that, and aren't you writing a thesis or something? <P><BR><p>[This message has been edited by Marie (edited February 20, 2002).]

As I said, I am VERY hesitant to recommend replacing something that works with something new. I am extremely appreciative of the work you and others at CD have put in to get the system running and keep it running. I agree that UBB is one of the best bulletin board systems I've seen.<P>At the same time, I think it's important to understand the strengths and weaknesses of the system being used, even if there is no practical way to ameliorate the weaknesses.<P>I am always looking to learn more about web software such as UBB. Thank you for replying on this thread, your comments have been educational.<P>My research is in the area of web security and privacy. I'm not blindly paranoid about cookies; however, I'm also appalled at what some of the sites out there do. I believe they only get away with it because most users aren't aware of what they're doing.<P>Our software should enhance our privacy, not erode it. Even for novice end users. Unfortunately, most of the browsers out there aid and abet the erosion of end-user privacy.<P>Turning off cookies is impractical because they are necessary for certain sites. I spend minimal time rejecting cookies; once Konqueror has been told to reject a cookie once, it will do so automatically forever after. I think all browsers should work this way.<P>Rejecting cookies from new sites has thus become one more minor annoyance of modern life, like deleting telemarketer phone calls from our answering machines.<BR>

In theory, I agree with you about cookies, but I find using a firewall to be a more practical security solution. And I hope you're not relying on your email software to be secure and are encrypting your mail with PGP or something like that. <P>I had a look at the <A HREF="http://www.openacs.org" TARGET=_blank>www.openacs.org</A> software, hmmm, it runs on an AOL server--now that's a company that makes me paranoid about privacy! <A HREF="http://www.zope.org" TARGET=_blank>Zope</A> and <A HREF="http://www.python.org" TARGET=_blank>Python</A>, which are also open source, are better, IMO. Python is the same as the AOL server, but both are principally used as a development systems, and not really recommended for business-type or commercial use. That's why Apache and Perl have been proven to be the most reliable in this kind of environment. Zope would be better than OpenACS in the sense that there are a lot more people working on it.<P>One thing about "free" open source software, you get what you pay for--all the bugs and no support or liability from the developer's end...

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>One thing about "free" open source software, you get what you pay for--all the bugs and no support or liability from the developer's end...<HR></BLOCKQUOTE><P>You can say that again. However, I do recall an exception. When Apple contracted the man himself, Niklaus Wirth, to reinvent Pascal as Object Pascal, a tool to teach the concepts of OOP, they gave it away free, with tech support and manuals! Now let's see that kind of generosity coming from Redmond...<P>Cookies are so essential in so many ways. I don't think I could live without them. Imagine having to type in your username each time. Urgh!<P>However, I do avoid Microsoft sites like the plague...

Firewall to eliminate some cookies but not others. Hmm.... I was not aware of such software. Actually, I can't believe a site would be so audacious as to pass cookies with a PICTURE, it's not even a full HTML page. Easiest thing would be to build browsers to only accept cookies when they come from original HTTP request, not any secondary requests spawned from it (such as included pictures, etc).<P>Before today, I was not aware that there WAS open source software that you had to pay a license fee to use. I find only mild correllation between how much one pays for software and how few bugs it has. Of course, the $200 license fee for UBB is nominal compared to the other costs involved in running a board such as CD. The real issue is whether it's possible to add functionality if needed (apparently it is with UBB), and whether that functionality could be expected to be incorporated in futures releases (apparently this is also the case).<P>I will investigate Zope and Python some more, it might come in handy some day. Thanks for the tip. BTW, I thought Python was a language, not a web server. Is it both?<P>AOL server runs TCL, which my gut feeling says is even a less appropriate language than Perl in which to write large applications. Philip Greenspun (originator of ACS) felt differently, but I think my hunch is validated: when AOL (based near DC) bought MapQuest (based in the Midwest), AOL naturally wanted to move MapQuest over to AOLServer. MapQuest couldn't find even ONE TCL developer locally, so they ended up relocating a friend of mine, who was formerly chief developer on AIM. OK, I've just talked myself out of ever using a TCL-based version of ACS.<BR>

OK, just for fun, a list of some of the better "free" open source software, and what you do/do not get. This list is not comprehensive. Please do not flame me.<P>Emacs: no support, but also no bugs (it's never crashed on me in over a decade of use). Emacs is high on features, but not the types of features typically demanded by users these days.<P>PostgreSQL: no support, but also a database pedigree going back to the origins of the relational database. Innovative design. Bug-wise, seems to work as well as any other DB I've used, which is to say it just works. RedHat now supports PostgreSQL: they have re-packaged the system as "RedHat Database" and sold it for about $3000. The graphical DB control clients available for PostgreSQL are significantly better than those available for Oracle (Toad), which cost $1K.<P>Java: supported by Sun but not individual support. Very well-engineered software. Clean, clean clean. I've never found a bug or had my JVM crash.<P>StarOffice: Lots of bugs. But if you don't run MS Windows, it's still your best way to read/write MS Office documents. And at least it will write your documents in an open format that you have some chance of reading 30 years from now.<P>Apache: relies on a wide base of experience for support. So many people know how it works. Unfortunately, it has had enough bugs in the past, such as buffer overflow problems, that I'm scared to install it on my computer. Commercial web servers have also been plagued by buffer overflow bugs, which can allow hackers to gain root privileges on your computer.<P>Mozilla, also supported by AOL/Netscape as Netscape 6: project plagued by unforseen difficulties, major time/cost overruns, oodles of bugs, and in general a bloated, uninspired design. The design is a copy of Netscape 4, which was built the way it was built not for ultimate useability, but to win the now-unimportant browser wars. The resulting program is slow and buggy. The bugs might be worked out someday, but I don't ever expect Netscape 6 to be anything but a hog. When I click on a mail message in Mozilla Mail, it takes almost 1 second for the message to appear! Compare to Netscape 4, which is much faster (but contains utterly incomprehensible code, which had to be thrown out). Mozilla is truly a disaster.<P>Some commercial software:<P>Bluestone SapphireWeb, a web app server (I used to work for Bluestone): Full of idiosynchrocies, bugs and lack of documentation. I realized at one point that people would be MUCH better off using more standard systems, such as Java Servlets, JSP, etc. Many open-source implementations are available for these, and even the closed-source implementations cost vastly less than Bluestone's $30K-and-up pricing model. Bluestone eventually figured that out too, after I left.<P>MS: Disclaims liability for the use of its products. So does just about every other major software vendor.<P>Over the long term, I think open source software will come to dominate. The reason why is that once software is built, it kind of kicks around the world forever. Later on, it can only be improved. I use some open source software originally developed in the 1970's, for example.<P>Closed software can be developed faster in the initial stages, but it seems to have a shofter lifetime. When the software no longer suits the business needs of the company that produced it, the project is dropped and the source code never released.<P>Software, like dance, seems to need to be contiuously "produced" in order to stay alive. Even if a company releases its source code, that code will only go somewhere if a community is built up around it to continue development.<BR>

Oy Vay! Why did I try and read to the end of this thread? It gave me a headache! hee hee hee. All I have to say is thank you to Marie and the other computer types who take care of this website

Isn't Zope another free Open Source software? I'm researching it as an alternate to manual HTML-editing/publishing of reviews.

I'm running out the door, but just to be clear I'm not suggesting a firewall would filter cookies, I just prefer it in terms of security. <P>I don't think I would get too indignant about a cookie in an image that has been effictively "hijacked" by this website. The Houston paper could ask us to not link to their site and then we wouldn't be able to use their image. We could ask the company to provide us with the image but the amount of time it would take to request it and then post it here would mean it probably wouldn't happen. If you were surfing the Houston paper's site and were concerned about cookies that would be a different story... <P>

Marie, I agree with you in general. I'm not indignant about the cookies, I just never realized it was a possbility before this week. <P>Thanks again.<BR>

I only get indignant about cookies that don't have chocolate chips in them.