Jargons of Info Tech industry

Gordon Burditt gordonb.mrv0t at burditt.org
Thu Oct 13 23:39:45 CEST 2005


>> Does the language allow Javascript to open a new window?  Does the
>> language allow Javascript to trigger a function when a window is
>> closed?  I believe the answer to both questions is YES.  Then it
>> is possible to have a page that pops up two windows whenever you
>> close one.
>
>This was a problem, but modern browsers implement Javascript in such a 
>way that it requires permission from the user before it will open a new 
>window.

An infinite loop of asking permission is *ALSO* a denial-of-service
attack.  And I don't believe that the limitation applies in all
circumstances.  This seems to be a feature of the *language*, not
only the implementation.

>> If it can reveal my email address to any web site, it's a bug.  If
>> it can access or alter my personal files or address book, it's a
>> bug.  If it can generate hits on web sites other than that specified
>> in the HTML, it's a bug.  If it can open sockets, it's a bug.
>> If it can look at or set cookies stored on my system, it's a bug.
>> If it can look at or alter the list of previously visited URLs, it's
>> a bug.
>
>All of those things seem like major problems except the bit about 
>cookies. What possible harm can reading and setting cookies do? I had 

Javascript may be able to set cookies even if they are turned off
by the normal mechanism of setting cookies.  Even if that isn't the
case, cookies are supposed to be domain-specific and a cookie from
site A (which might have a session ID for an active login session, or
login credentials for site A) should not be sent to site B.  Javascript
can apparently make its own URLs and send anything it gets its hands
on to any site it wants to.

The existence of a cookie from site A shouldn't be revealed at all
to site B (or to Javascript from site B), regardless of what it
contains.

>always thought they were carefully and successfully designed to be 
>harmless. That's not personal information in your cookies. That 

Some websites *DO* put personal information in cookies.  They don't
all just use randomized session identifiers.  Some of them store
login credentials for a site (not just a currently active session,
but permanent login credentials.  That might not be "personal" the
same way a SSN or credit card number is, but you could still do
damage with it).  A lot of the popularity of Javascript comes from
the ability to steal information from the client computer that
normal HTML does not give access to (e.g.  screen/window size, email
address, IP address as seen by the client (because of NAT and
proxies, might not be the same IP as seen by the server), MAC
address, browsing history, Windows serial number, Pentium CPU serial
number, etc.)

>information is set by websites for the sole purpose of being read by 
>websites. 

*BY THE WEBSITES THAT SET THEM*, not by all websites.  The "domain"
parameter for setting cookies has been in there since the beginning
of the standard for cookies.

If a marketer wants a piece of information, then I don't want him
to have it, even if it's something like "I visited <page X> and
then went to <page Y>" even if there's no identification of who "I"
is.

>Plus, I'm pretty sure that browsers have always allowed us to 
>disable cookies.

I'm not sure that you can disable Javascript from reading cookies
from other sites while allowing Javascript to read cookies from the
site it came from on all browsers.

					Gordon L. Burditt



More information about the Python-list mailing list