× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: HTTP Server's jobs for CGI applications
  • From: "Stone, Brad V (TC)" <bvstone@xxxxxxxxxxxxxx>
  • Date: Mon, 17 Jul 2000 08:47:24 -0500

> Brad wrote:
> >Hans,
> >Only you disable cookies and Javascript.  ;)
> >Paranoia of javascript and cookies is unfounded.
> 
> No, you're wrong.  Paranoia regarding these two is quite well
> justified.  Use of the two by web sites can result in the
> gathering of quite detailed information about your web
> surfing habits.  

--snip--

>  The banner ad company knows
> which web page requested the banner ad (using the HTTP_REFERER
> variable). 

You can get this CGI.  Don't need Javascript.

> Even if you only visit sites that promise not to well their
> customer lists, you may still have your privacy compromised.
> Consider toysmart, a web start-up that went belly-up.
> Although they promised not to sell their customer list, it is
> one of the things put up for sale by their creditors!

Selling customer lists has nothing to do with cookies or javascript.  That
data is stored on their server.

> 
> (You can read more about the security holes involved with
> cookies at <http://www.cookiecentral.com/>.)

Oh gosh.  Not this site again.  One rougue site who's idea was "stretch the
truth about cookies" to get people to come to their site.  

Here's a great quote from their site:
"Most cookies are not executable, and I have not come across one. In general
Cookies are stored as text files and cannot be of danger or pass on viruses.
Even if a cookie is executable it cannot automatically spread on a virus
unless you execute it. But of course with recent bugs in Internet Explorer
3.0, it will let a site run a application. In theory, if a executable cookie
was set with malicious contents, then it is possible that IE3.0 could
execute it, then it could affect your computer with a virus."

Starts off saying most are not executable, but if they are, they can be
viruses and spread if executed.

Ya, most cars don't fly, but if even if they could, it will crash into the
ocean, but only if you do take it into the air and if it's a 1974 Volkswagon
Beetle Wolfsburg edition.

> JavaScript is a whole other can of worms.  Personally, I tend
> to keep it disabled for my home browsing for several reasons:
> 1) My browser never crashes with JavaScript disabled.  2) Too
> many web sites do nonsense with it.  Just look at the nonsense
> foisted on us by Geocities!  3) Some web developers use
> Javascript coding that is specific to a particular browser and
> you end up with lots of error messages popping up.

I agree with most of these points.  It does suck when you get javascript
errors, but most sites want to know about these problems because, as with
any software, there is bugs.  I am guessing you're not referring to your 10
year old cousin's home page, but more like business sites.  They want to
know about bugs.  If you don't report them, things don't get better.

 The bottom line is this - I know I'm not alone in my
> concerns.  If you code a dependency on cookies and JavaScript,
> you'll end up pissing off at least a few people.

Why would they be pissed... just turn on Javascript.  It's like people that
put movies out on DVD and not VHS.  Buy a freakin DVD player and enjoy real
entertainment.  :)

> 
> Heck, it's not like it's that difficult to avoid using these
> things.  There are other ways to maintain session state (easy
> using Java Servlets in fact).  Also, it's not difficult to
> limit JavaScript to things that only affect appearance and
> don't affect navigation through your site.

Exactly.  But sometimes it's a whole lot easier to use Javascript to
navigate through, espeicially with CGI.  I won't touch the Java Servlets
statement, because that's CGI, not client side scripting.

Brad
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.