Javascript and Frames

[Kent Feiler]

One thing I like about frames is that they're a good place to stow
Javascript. Javascript that I'd like to be around while the visible
content of the screen changes goes in the frame declaration HTML file.
It never needs to be reloaded and JS variables can be updated there as
the visible screens progress.

But...if I want to be a good internet samaritan and not use frames,
what's the best way to replace that function?
Regards,
Kent Feiler
www.KentFeiler.com

[Number 11950 - GPEMC! Replace number with 11950]

"Kent Feiler" <zz**@zzzz.comw rote in message
news:qd******** *************** *********@4ax.c om...

One thing I like about frames is that they're a good place to stow
Javascript. Javascript that I'd like to be around while the visible
content of the screen changes goes in the frame declaration HTML file.
It never needs to be reloaded and JS variables can be updated there as
the visible screens progress.

But...if I want to be a good internet samaritan and not use frames,
what's the best way to replace that function?

Have you considered preparing a business plan for your web site? The reason
I ask, is because the attitude that "the web-site shall pay for itself and
then some" leads to some alternative solutions to the usual web-based
problems; problems that seem to be rooted in online conventionality ...

Use of <div>s leaves frames somewhat redundant.
Eg. www.geoceanis.com
PS. For security reasons, I ban all client-side scripting such as Java, on
my browser and even sell a product that makes it easier for others to do
likewise
(www.fieldcraft.biz/software/browser-security)

Client-side scripting is also used for browser hijacking and many "spyware"
worms are installed this way.

You need to establish trust with your visitors before you can reasonably
expect them to benefit from anything you write that will run client-side.
I'd point out that client-side scripting is less user friendly than frames
because while most browsers in use will negotiate frames adequately, many
users such as myself will not allow any code to run on our systems without a
48-96 hour quarantine and subsequently updated anti-virus scan. In the case
of web-launched code, this is impractical and there is no basis for
establishing security boundaries except to disable all scripts.

The trick is to collaborate with your hosting service to run things
server-side. This guarantees that everyone gets the benefit of your
scripting. I know Perl/CGI, VBScript, &.NET can be run server-side. I am not
so sure about Java. By running things server-side, visitors that don't know
you are not being asked to risk virus/spyware/worm infection in return for
accessing the bells and whistles of your page.

If you want to hide your source, then server-side executed scripting source
is much more difficult to access than something tucked away in a frame. For
example, where frames are used to obfuscate the base URL (Eg. SPAM
beneficiaries), it is child's play to trace the base URL through the HTML
source - not a good choice for source protection. On the other hand, some
developers produce an ActiveX.exe file, which is very effective because it
is a pseudo-compiled executable - but I'd wager they'd then wonder why their
site visitors won't stick around...

Anyway, if you don't feel like talking to your hosting service, or they
don't feel like talking to you, find another service. I've had good
technical support from:
http://www.spherecomputers.com.au

At the end of the day, a web site is just a document server and there will
never be a secure implementation of the "applicatio n servers" Microsoft is
so keen on evangelising, without eliminating the two-way nature of internet
communication. If you find yourself writing executable code, it is worth
asking whether or not you would be better off compiling a downloadable
program that you can supply for free if you wish, or alternatively sell for
a profit. This has the added benefit of allowing visitors to establish
coding trust through quarantine and scanning procedures. In the case of your
website, a VB, VC, or VJ application that updates itself from a data file at
your site would be a breeze to write, in addition to being a marketable
commodity.

--
Timothy Casey GPEMC! >11950 is the nu****@fieldcra ft.biz 2email
Terms & conditions apply. See www.fieldcraft.biz/GPEMC
Discover valid interoperable web menus, IE security, TSR Control,
& the most advanced speed reading application @ www.fieldcraft.biz

[Sym]

Number 11950 - GPEMC! Replace number with 11950 wrote:

"Kent Feiler" <zz**@zzzz.comw rote in message
news:qd******** *************** *********@4ax.c om...

Client-side scripting is also used for browser hijacking and many "spyware"
worms are installed this way.

Hmmm - Most traffic deaths occur within 10 miles of home, yet I still
get in the car and drive! In order to get the best out of life some
small risks have to be taken. The browser sandbox and security model
gives very good protection in most instances an dtypically you should
know you are on a "dodgy" site ! You must always have your AV software
running and give regular sweeps for spyware i agree, but sometimes the
beauty of browsing the web means you HAVE to have client scripting
turned on.

rgds
Sym.

[Chris Morris]

"Sym" <sy*****@gmail. comwrites:

Number 11950 - GPEMC! Replace number with 11950 wrote:

Client-side scripting is also used for browser hijacking and many "spyware"
worms are installed this way.

small risks have to be taken. The browser sandbox and security model
gives very good protection in most instances an dtypically you should
know you are on a "dodgy" site ! You must always have your AV software

Most exploits are due to coding or design flaws in the sandbox or
security model (at a guess I'd say a significant proportion of modern
IE or Mozilla flaws are related to this). If you always update your
browser the day a new security release comes out you're probably
safer, but several of these bugs have been exploited in the wild for a
few days before the bug was discovered by anyone who would report it.

Also, with XSS attacks (or more directly by cracking the web server
hosting it, which also happens), a site that you believed to be
harmless and trustworthy can be subverted by an attacker to include
harmful scripts. There was a case fairly recently where an attacker
was able to insert a malicious banner ad into a banner ad provider,
which then got added to a number of sites across the internet that
were trusted by their readers, who then got infected. Nasty, but by
having scripting disabled by default even for generally trustworthy
sites I avoided any risk.

--
Chris

[Jack]

Sym wrote:

Number 11950 - GPEMC! Replace number with 11950 wrote:

>"Kent Feiler" <zz**@zzzz.comw rote in message
news:qd******* *************** **********@4ax. com...

>Client-side scripting is also used for browser hijacking and many
"spyware" worms are installed this way.

Hmmm - Most traffic deaths occur within 10 miles of home, yet I still
get in the car and drive!

There's a tale about a person who moved home to nearly 20 miles away,
just because they heard that rumour. I assume it must be true; I read it
somewhere.

And anyway, it makes sense; I keep meeting people that think that way.
--
Jack.
http://www.jackpot.uk.net/

[Kent Feiler]

On Mon, 14 Aug 2006 10:42:47 -0500, Kent Feiler <zz**@zzzz.comw rote:

One thing I like about frames is that they're a good place to stow
Javascript. Javascript that I'd like to be around while the visible
content of the screen changes goes in the frame declaration HTML file.
It never needs to be reloaded and JS variables can be updated there as
the visible screens progress.

But...if I want to be a good internet samaritan and not use frames,
what's the best way to replace that function?
Regards,
Kent Feiler
www.KentFeiler.com
---------------------------------------------------------------------------

My impression is that replacing frames with iframes is a relatively
painless process, but replacing them with divs is something of a
shooting pain in the butt. What I have in mind is loading new html
files to an existing iframe/div.

Based on the emerging HTML principle that anything easy and
straightforward is bad for some reason, is there anything wrong with
iframes that I should know about? I do know that they don't
automatically resize, but that doesn't bother me.

Regards,
Kent Feiler
www.KentFeiler.com

[Number 11950 - GPEMC! Replace number with 11950]

"Kent Feiler" <zz**@zzzz.comw rote in message
news:4p******** *************** *********@4ax.c om...
[SNIP]

My impression is that replacing frames with iframes is a relatively
painless process, but replacing them with divs is something of a
shooting pain in the butt.

This, I can understand completely! Developing the template properly, often
takes longer than writing several dozen pages of content!

What I have in mind is loading new html
files to an existing iframe/div.

Based on the emerging HTML principle that anything easy and
straightforward is bad for some reason, is there anything wrong with
iframes that I should know about? I do know that they don't
automatically resize, but that doesn't bother me.

For what you are planning to do, I don't believe there is anything wrong
with using iFrames, as long as you don't use them to serve up navigation
links. Be sure to specify the correct document type. Keep in mind that the
material in the frames will be lost on the search engines.

We have already covered the issue of client-side scripting, so given the
direction you are taking we can safely assume that you have established the
trust of your visitors and that you are more than just a "good samaritan" if
you intend to make your bridge strategy system available for free...

Good luck...

--
Timothy Casey GPEMC! >11950 is the nu****@fieldcra ft.biz 2email
Terms & conditions apply. See www.fieldcraft.biz/GPEMC
Discover valid interoperable web menus, IE security, TSR Control,
& the most advanced speed reading application @ www.fieldcraft.biz

[Number 11950 - GPEMC! Replace number with 11950]

"Sym" <sy*****@gmail. comwrote in message
news:11******** ************@b2 8g2000cwb.googl egroups.com...

Number 11950 - GPEMC! Replace number with 11950 wrote:

"Kent Feiler" <zz**@zzzz.comw rote in message
news:qd******** *************** *********@4ax.c om...

Client-side scripting is also used for browser hijacking and many

"spyware"

worms are installed this way.

Hmmm - Most traffic deaths occur within 10 miles of home, yet I still
get in the car and drive! In order to get the best out of life some
small risks have to be taken.

The example is irrelevant. When you get in the car, you are still largely in
control. By thinking ahead and driving both strategically and tactically,
treating the traffic situation as a chessboard, you can avoid any accident
regardless of whose fault it would have been. When you click on a link to a
website with your client script turned on, you relinquish control of your
computer. This is more akin to pulling the trigger after a spin of the
barrel in a game of Russian Roulette.

Tell me, do you play Russian Roulette?

The browser sandbox and security model
gives very good protection in most instances an dtypically you should
know you are on a "dodgy" site !

This is like saying that the bad guys wear black hats. Back in Capone's
days, the mafia were actually wearing pearl grey just like regular business
people! As Neighbourhood Watch keep telling us, there is no such thing as a
typical criminal. Besides, "Master Mode" systems have been around much
longer than the PC, and the ability for any system to execute code from a
file that is seen both by the system and the user as other than an
executable program (IE Master Mode in old mainframe-speak) has always posed
an inherent security risk. However, those who don't know their history are
doomed to repeat its mistakes...

You must always have your AV software
running and give regular sweeps for spyware i agree,

Scanners cannot pick up unlisted threats such as new malware. This is why
you apply a quarantine period to all remotely acquired code.

but sometimes the
beauty of browsing the web means you HAVE to have client scripting
turned on.

Not at all. I've seen lots of sites using client-scripting, and what I've
missed by not running their scripts I could always find elsewhere, usually
within three minutes. The beauty of web browsing is that there are so many
pages serving up the same sort of material, I can just go elsewhere if I
don't like what the site's design says about the webmaster's attitude.

Perl/CGI can do anything server-side that Java can do client-side; and then
some. The beauty of having my client-script turned off is that I can visit
sites like the former: http;//www,spazbox,net/ without any consequences. I
can also open any damn email I like because I don't have to worry about
infected self launching attachments.

This is why you don't turn on your client-scripting:
http://www.spywareguide.com/articles...stall__72.html

And sorry, the only real, non-illusory benefit one can experience via
scripting is internet banking - and even this is wrongly executed because
client-scripting of user authentication actually makes the process more
vulnerable. This is because a large enough algorithm to foil a keylogger is
impractical to serve over a dialup connection, and would even pose
unreasonable bandwidth costs when served over a broadband connection. An
in-house UA written to in-house encryption and authentication standards
would have the potential to be impossible to crack without specialised
hardware located near or onsite - and such strategies make client scripting
obsolete for this purpose.

Having said my piece for the bank, I would point out that my web menus,
which use no client scripting at all, run much faster because mine are not
served up with client scripting. See:
www.fieldcraft.biz for an example.

The web: it's a two way communication system independent of borders and
censorship; not a secure application server for software equivalents of TV
"blockbuste rs".

--
Timothy Casey GPEMC! >11950 is the nu****@fieldcra ft.biz 2email
Terms & conditions apply. See www.fieldcraft.biz/GPEMC
Discover valid interoperable web menus, IE security, TSR Control,
& the most advanced speed reading application @ www.fieldcraft.biz

[David Stone]

In article <44************ ***********@lon-reader.news.tel stra.net>,
"Number 11950 - GPEMC! Replace number with 11950"
<nu****@fieldcr aft.bizwrote:

[huge snip]

>
Having said my piece for the bank, I would point out that my web menus,
which use no client scripting at all, run much faster because mine are not
served up with client scripting. See:
www.fieldcraft.biz for an example.

I visited your site, and there appears to be a small bug in your
web menu code. I've put a screen snap-shot here:

http://www.chem.utoronto.ca/~dstone/webmenu.tiff

- the fubar'd text appears if you mouse-over the first menu, then
move the cursor over the next. If you keep moving the cursor over
succeeding menus, the misplaced text keeps shifting along-side the
revealed drop-down menus.

FF 1.5.0.6 with 17" monitor set at 1152 x 720 (changing
screen resolution is a lot cheaper than getting bifocals!)

[Number 11950 - GPEMC! Replace number with 11950]

"David Stone" <no******@domai n.invalidwrote in message
news:no******** *************** *****@news1.che m.utoronto.ca.. .

In article <44************ ***********@lon-reader.news.tel stra.net>,
"Number 11950 - GPEMC! Replace number with 11950"
<nu****@fieldcr aft.bizwrote:

[huge snip]

Having said my piece for the bank, I would point out that my web menus,
which use no client scripting at all, run much faster because mine are

not

served up with client scripting. See:
www.fieldcraft.biz for an example.

I visited your site, and there appears to be a small bug in your
web menu code. I've put a screen snap-shot here:

http://www.chem.utoronto.ca/~dstone/webmenu.tiff

- the fubar'd text appears if you mouse-over the first menu, then
move the cursor over the next. If you keep moving the cursor over
succeeding menus, the misplaced text keeps shifting along-side the
revealed drop-down menus.

FF 1.5.0.6 with 17" monitor set at 1152 x 720 (changing
screen resolution is a lot cheaper than getting bifocals!)

Thanks for the feedback...

What is happening is that the last menu is word-wrapped to the next line due
to insufficient window width. This allows access to that last menu but the
behaviour is unexpected if not untidy. Suffice it to say that IE is not
quite so lively in interpreting the position of this menu, but in Netscape
(same Gecko engine as Firefox, Mozilla, & a few others) I found myself
chasing the wrapped menu up and down the menu bar as long as I attempted to
mouseover from above. If I fix the width of the menu bar container, this
little laugh will disappear along with the extra menu off the edge of the
window. The fact remains that there are probably one too many menus on the
bar!

This will be dealt with when I facelift the site next month. In the
meantime, I have to figure out how to sidestep a Gecko CSS interpretation
bug, then upgrade a menu maker to a full blown cookie cutter...

Thanks again for letting me know. This little bug was so amusing it
brightened up my night - do you think I should keep it?

--
Timothy Casey GPEMC! >11950 is the nu****@fieldcra ft.biz 2email
Terms & conditions apply. See www.fieldcraft.biz/GPEMC
Discover valid interoperable web menus, IE security, TSR Control,
& the most advanced speed reading application @ www.fieldcraft.biz