IE 7 not sharing cookies between browser windows

I have run into a show stopper issue with IE7 and I need help working around it. I am building a new website called http://InternetSAR.org, which purpose is to allow people to review and report on aerial imagery from search and rescue efforts via the Internet using Google Earth. This is an effort being built off of what was learned from the Amazon MTurk search for Steve Fossett.

My problem is that even when IE users have logged into InternetSAR.org, when they request new overlays via Google Earth (which hands the requests off to the default browser) IE will spawn a new browser window and not pass the user session cookie to the new request thus the script can not associate the user back to their session. I need to find a work around so that when overlays are requested via links in Google Earth overlays that IE will pass the cookie properly.

Again this is not a problem in Firefox and I do not yet know about IE6.

After much beating my head against my keyboard in penance to the Microsoft gods for using Firefox I figured out what the problem was.

I was passing session cookies that expired at the end of the session (e.g. browser is closed). IE was considering the new browser windows spawned by Google Earth to be new sessions. As soon as I started specifying cookies to expire at an explicit point into the future (e.g. 2 hours) IE would share the session cookie with other windows.

That is just plain nuts.

Slightly off topic, but is the Google Earth imagery too out of date for this sort of thing? How often is the satelite imagary updated?

Unless there is a more up to date paid version... our house, street, estate is still not on there and we have been living here for a year - neither is my friends, and he's been living there for 3.5 years

The imagery in Google Earth itself is always going to be old imagery taken before a plane or vessel went missing, however, what we will be doing (and have done in the Steve Fossett search) is acquiring new aerial and/or satellite imagery that was taken AFTER a plane or vessel went missing. Using a special XML file called a KML overlay, we can instruct Google Earth on how to download and position specific image files from the new imagery we are working with and overlay them on top of the old Google Earth imagery. What this allows one to do is compare the new imagery against the old default imagery provided by Google Earth and look for any changes (e.g. a crash site).

It is actually really cool and Google Earth is much more powerful than most people realize. The default imagery is pulled from Google's servers and the updated imagery is pulled from our servers. Being able to compare old and new imagery on top of each other and almost perfectly lined up is really a very powerful search aid.

Once people sign into InternetSAR.org, which will be the home for the volunteer organization I'm founding with others to conduct these Internet based imagery analysis efforts, they can then go to the section of the website that is set up for a specific search effort and request an imagery overlay assignment. Using a grid search pattern, the website will systematically assign small groups of images for the individual to review. If they find something of interest, they click on a link within the info box for the overlay and fill out a report about what they find. These reports will then be reviewed by a team of evaluators who will help narrow down the list of reported imagery to a small list of really promising leads, which will be then passed on to the search team, which requested us to help them with their search.

Right now the only real expensive part of this is the cost of acquiring up to date imagery. In the case of the Steve Fossett search, Google paid/arranged for the imagery we are using to be taken about a week or so after he went missing. Some of the imagery is being hosted on Amazon S3 servers and are left overs from Amazon's Mechanical Turk search effort. Other imagery, which is being made available for the first time on the Internet is being hosted on servers we have secured for this purpose. To conduct a typical search effort we expect to need around 200gb of disk space to host imagery and expect to consume at least 2 terabytes of bandwidth per month to serve up the imagery for a given search effort. In addition to there being lots of images for any given set of imagery we are working with, we can not use JPG type compression for image files so they have very large file sizes. Using JPG compression would introduce artifacts into the images, which would cause problems with reviewing the imagery, in addition the JPG format does not support transparent alpha channels, so we have to save the image files as 24bit PNG files.

In the case of the Fossett search we are currently hosting 200 image sets (just a small fraction of the total Imagery taken for the search) with each image set having 350-400 512x512 pixel images at around 400-500 kb each. This means we are currently hosting around 70,000-80,000 images for a total disk space usage of 27-38 gb. As part of our normal assignment process, each image will be assigned to three different people. Images of particular interest will get looked at many times more by others.

Our goal is to eventually be able to organize thousands of people to participate in any given search effort. Often times those participating in a search effort will have a special connection to the given search, or be drawn into participating in a specific search effort by local media efforts. We are also hoping to cultivate a large pool of volunteers from withing the search and rescue, aviation and boating communities that will contribute their time and effort to searches to help out fellow members of their respective communities. The original Mechanical Turk search effort for Steve Fossett for instance reportedly had around 50,000 people who participated in it.

The scale of what I have been working on is well beyond anything I have ever done before. A particularly high profile search effort could make a SlashDot or Digg traffic surge seem like a small trickle. I have to really evaluate every single database connection my scripts make and determine if it is absolutely necessary or not. When database connections are made I have to do everything possible to ensure that SQL calls are released just as quickly as possible. InternetSAR.org will in all likelihood become a non-profit organization and keeping hosting costs down will be critical. This means my scripts must be as nice to web and database servers as is possible.

Wow, just amazing.

You deserve a lot of luck with this, and if it helps finds just one person then that has to be worth while.

Quote:

---

Originally Posted by Blue Cat Buxton

Wow, just amazing.

You deserve a lot of luck with this, and if it helps finds just one person then that has to be worth while.

---

Thanks, yes if this can prove effective at locating missing aircraft and/or watercraft it could radically change search and rescue operations forever. The amount of work this has taken is far beyond any project I have ever undertaken. The website coding alone is all consuming, but I'm also working to organize the organization and bring other people in to help get things going.

One thing that I have not yet accomplished is to find someone who is willing to donate some time to create a title graphic and logo for the site. I'm working with absolutely no budget so I can't exactly run a design contest. The best I can offer is a "byline" on the site on the "credits and special thanks" page that will be created to acknowledge everyone who contributes to getting the organization and website up and running.