Linux.com Article DB: JavaScripting And the World Wide Web

<Wintersun> Thank you for coming to our event today, part of the Author Talks Series <dori> Of course, if they want questions answered, that requires the book. <Wintersun> Dori Smith is going to be talking about her book "JavaScript for the World Wide Web" <Wintersun> If you have any questions, please /msg them to Dazman and he will ask them for you. Thanks! <Wintersun> dori, would you like to start by saying something about your book? <dori> First, thanks for coming, everyone! <dori> "JavaScript for the WWW: Visual QuickStart Guide, 4th edition" shipped last month, written by Tom Negrino and myself. <dori> It's chock-full of useful JavaScript tidbits, for both the non-programmer and the geeks. <dori> It doesn't assume that you know anything at all about programming, and walks you through useful scripts slowly, but it's also handy for techies who just want to pick up a book, find out how to do some task, and put it down again without having to deal with tons of theory. <dori> Anyone have a specific question? <Dazman> what console-based web clients support javascript? (i need this to deal with my isp's dsl "dashboard") <Dazman> From lazarus. <dori> Lazarus, I'm not sure what you mean by "console-based"? Almost all the currently shipping browsers support JavaScript, JScript, and/or ECMAScript. <dori> ECMAScript. <Dazman> How much experience do you have in programming with JavaScript? <Dazman> From lazarus: lynx, whatever doesn't require X11 or aGUI <dori> That's what I thought, but I wanted to make sure. I personally don't know of any non-GUI JavaScript clients; sorry. If anyone does, please let me know. <dori> How much experience do I have with JavaScript? I've been working with it since 1996. Our first JavaScript book came out in 1997. Overall programming, though, I've been doing since 1977 (jeez, I feel old all of a sudden). <dori> Next? --- Dazman gives channel operator status to lcModerator <lcModerator> How much have you been involved with Linux? <dori> I actually haven't had a lot of Linux experience; it's one of those projects that I keep planning on getting around to. I've got the box ready to go, but paying gigs keep me too busy to actually load it on there. <lcModerator> What nix experience do you have? <dori> Most of my nix experience is ancient, from back when I worked on workstations back in college. I've been messing around with Mac OS X lately, though, with is UNIX under the hood. <dori> Sorry, folks, not a linux geekette. <g> <lcModerator> The title of your book is "JavaScript for the WWW". Can you tell us a bit about JavaScript not for the WWW? <dori> This is actually one of the coolest areas around, imo. <lcModerator> What's the coolest piece of javascript you've seen. <dori> For instance, JavaScript is the internal scripting language inside Macromedia's Dreamweaver and Fireworks. So someone who'd done a little bit of JavaScript scripting for the web is suddenly able to change DW and FW in major ways to suit their working style. <dori> JavaScript can also replace AppleScript for scripting the Mac, and can also be used inside Windows Scripting Host. All in all, I think that this is the wave of the future--leverage the info you have now, and use it to make your machine work the way you want it to. <dori> The coolest piece of JavaScript? That varies depending on whatever I'm into at the moment. In terms of impact per line of code, I'd have to say bookmarklets. <dori> They've completely changed the way I use the web, and all with just a line or two of code. <dori> You can find out more about them at www.bookmarklets.com (I'm not affiliated with them, just a happy user). <lcModerator> What was the first programming language you used, and what got you away from programming, and using javascript instead? <dori> The first programming language I used, would be BASIC, back in 1977 (hey, don't laugh, it was what my high school had, okay?). <dori> As to the 2nd part of your question, I disagree with the assumption that JavaScript isn't a programming language. Just because it doesn't have a compiler doesn't it mean it isn't "real" programming. <lcModerator> Through your book, do you advocate a particular programming style, having portability in sight, or do you barely present many javascript features letting the programmer choose what appropriate? <dori> Now there's an interestingly phrased question... <dori> Overall, I tried to keep the programming simple enough that it should work anywhere. <dori> I don't like code that checks browser by browser and version by version to see if something can be done; instead, I show how to check by looking to see if objects exist. <dori> Did that answer the question? <lcModerator> Yes :) <dori> It's not really a feature by feature type of book; more of a "Here's a bunch of useful things that you can do" cookbook. <lcModerator> What do you see as the future of javascript? <dori> Before the web came along, tons of research had been done into UI design and human factors and how to make code work *with* users. When the web came along, we threw out all that info. With JavaScript and CSS (aka DHTML), we can start to make web applications that work the way people do, instead of making people work the way someone threw a hack together. <dori> Thankfully, the browser makers have listened to the screaming that happened everytime they shipped a non-standard browser, and have started working on making their browsers more standards compliant. --- Wintersun gives channel operator status to lcModerator --- Wintersun gives channel operator status to [Dazman] <dori> That makes the task of writing JavaScript that works in multiple browsers much, much, simpler. Thank you, Web Standards Project http://www.webstandards.org <lcModerator> How safe do you find javascript to be, and if there are security errors via the web, how dangerous are they? To non-specific os's? <dori> I have, to date, not heard of a single JavaScript security issue that couldn't be recreated more simply using CGI. Most of the screaming I've heard about JavaScript "security issues" have been, imo, from CGI programmers who are worried about losing business due to DHTML and JavaScript taking off. <dori> Bloodline, if you have a question, do it through the moderator. <lcModerator> now with Microsoft .Net and C#, with several features like COM+, IL etc. what is the future of Java and Javascript? <dori> It depends on what you think the future is of non-MS OS's and browsers. If you think that everyone, everywhere, is going to change over to Windows and IE, then .NET is the way to go. If you want your stuff to work cross-browser and cross-platform, though, it's a waste of time. <dori> I'll look at .NET when something real actually ships; until then, it's just more MS FUD (imo). <lcModerator> How viable do you think JavaScript can be in enterprise level applications? JavaScript is interpreted on the client side and not everyone has the same software versions. How do you see high volume applications overcoming the requirement of not turning away any customers? <dori> OTOH, MS has been pretty good about making JScript (their version of JavaScript) work inside Windows--I'm told that a lot of Softies like JScript better than VB & VBScript. <dori> Properly written JavaScript can work in any platform, browser, and version (assuming that it's not completely brain-dead, like Netscape 4). Too many companies who are trying to write web apps focus on the biggest bang for the buck, which is IE/Win 5+. It's all possible to do in other browsers; it just takes more work to make it widely available. Not having it work on certain customer's machines is just due to laziness (again, imo). <lcModerator> What do you think about the future of properitary software in general, do you see Open Source software as the evolution of software in general. And how can a properitary software company compete with open source software that is BETTER, and FREE? <dori> Was there actually a question there, or just a statement? <lcModerator> i think v3 intended it as a question... <dori> I think that many other people have discussed the economics of free software in book length form, and I'm not really going to go into it all. But I do have to ask: when is Mozilla going to ship? <lcModerator> What do you think about the future of properitary software in general? <dori> Proprietary software will do just fine, so long as the alternative is (like Mozilla) late, bloated, and buggy. <lcModerator> Expanding on the enterprise level application question, most browsers have the option to turn off JavaScript. Many paranoid people do just that. What is your opinion on building site functionality around JavaScript when in all reality a good portion of your users will not be able to take advantage of it? <dori> Paranoid people also turn off cookies, and most ecommerce and web apps require them. Paranoid people also remove the radio from their cars so that the Men in Black can't send them hidden messages. Their loss. <lcModerator> going back to the browser question... <lcModerator> as far as non-MS browsers are concerned, they have already failed, with IE controlling more than 80% share of the browsers and netscape 6 already showing signs of failing, and the Mozilla project also has failed to deliver, what do you say about that? <lcModerator> will this affect JavaScript in any way? <dori> OTOH, at any time AOL could ship out 10 gazillion CD's with Netscape, and the stats would change literally overnight. <dori> But in either case, writing simple, straightforward, cross-browser JavaScript is the way to go. <lcModerator> what do you think of Macromedia Flash format with ActionScript, against SVG and Javascript? How do you compare Javascript to VBScript apart from the non-support of VBScript on other platforms? <dori> Flash is what, a $300 product vs. something that's free? Yeah, you can do cool things with Flash and AS, but that's a steep price to have to pay. SVG is a whole 'nother thing, and I'm not holding my breath on that one. <dori> JavaScript vs. VBScript? I haven't spent much time with the latter, as I've been told my MS folks that internally they're starting to prefer JScript. I hate, hate, hate, web pages with VBScript on them, and think that they're all done by people who simply don't know any better. <lcModerator> There are people who turn off JS for other reasons other than paranoia (annoying popups), and it's not "their loss". It's the loss of the site operator. You just said that people who program javascript should try to be as compatible as possible, yet there are many browsers (widely deployed) that don't support javascript at all (along with those who turn it off). Do you recommend in your book that javascript should be auxiliary functionality <lcModerator> pages <lcModerator> er.. <lcModerator> There are people who turn off JS for other reasons other than paranoia (annoying popups), and it's not "their loss". It's the loss of the site operator. You just said that people who program javascript should try to be as compatible as possible, yet there are many browsers (widely deployed) that don't support javascript at all (along with those who turn it off). Do you recommend in your book that javascript should be auxiliary functionality <lcModerator> pages <lcModerator> (rather than mandatory)? * lcModerator apologises for the poor copy and paste :) <dori> I absolutely believe that intelligently written JavaScript should never assume that it's always enabled. There are too many sites written by people who have, for instance, submit buttons that only appear if you have JavaScript turned on. That's just wrong. But putting JavaScript on your site can take huge loads off the server, so it's worth doing. <dori> And if the annoying popups annoy you, stop visiting pron sites. <g> --- muks is now known as muks_away <lcModerator> Most popular sites actually use URL based sessions rather than use cookie based sessions. Their site functionality does not require cookies to work (i.e. amazon). How can you justify to a customer "Hey, it's your customers loss if they cant view the site as you intend to" when dollars might be flying from their pockets <dori> URL-based sessions have their own problems, though. What happens if you're halfway through a shopping visit, have a cart full of stuff, and the phone rings with an important call? You get back an hour later, and your cart has expired and you've lost all that time. A cookie, though, could have saved that info. Every type of functionality has its pros and cons. <lcModerator> Well, that was the last of the questions sent to me... Thank you dori for coming along today. :) I will now unmoderate the channel, to allow anyone else wishing to ask a question to do so. Thanks again :) --- lcModerator sets mode -m <dori> Thanks all! <lazarus> you're ridiculing security-consciousness on the part of a user, in the name of "ecommerce." I don't hear a lot of comments from you about integrating JavaScript with standard "shipping" open source web browsers such as lynx, links, w3m and the like. Please address the place of JavaScript in the security-conscious Linux realm, especially in non-GUI settings. <lazarus> or is security only for the server, not the "ecommerce" client? <nate37> dori: how do you see javascript compared with other languages (python,php,perl,lisp,etc..) from a language standpoint, not machine/browser support of the language? <dori> As I said, there are, to the best of my knowledge, ZERO JavaScript security issues that can't also be accomplished by CGI. I'll believe that there's a group of people who are honestly concerned about JavaScript security (vs. a bias against "scripting languages") when browsers have a way to refuse all pages generated by CGI. <dori> JavaScript will have a place in the open source non-GUI web browser community when the community thinks that it's worth the time to put it in there. <brw> dori: Do you follow BugTraq? <brw> dori: Many of these issues have been documented there. <dori> I look at BugTraq whenever I hear about JavaScript security issues. So far, they've all been accomplishable (is that a word?) via CGI. <brw> I am confused. How are you comparing CGI with Javascript? <dori> Both JavaScript and CGI can look at cookies, for instance. <dori> JavaScript and CGI can redirect pages. <brw> yes, but CGI does not == Javascript. So how can security issues that are javascript be recreated in CGI? CGI is executed on the server while Javascript is executed on the client <dori> Exactly! Case 1: You somehow read someone else's cookie with JavaScript, and then use a CGI to write out that info to a file. Case 2: You somehow read someone else's cookie with CGI and then write out that info via CGI. Yeah, there was a JavaScript bug in case 1. But turning off JavaScript doesn't protect you one bit from case 2, whereas turning off CGI (somehow) would protect you from both case 1 and case 2. <brw> Heh, but with those javascript holes I can read files on the local machine. You cant do that with CGI <dori> Every JavaScript security issue that I've heard of has (1) required CGI to do part of the work and (2) could have been duplicated via CGI without any JavaScript. So what good does turning off JavaScript do? Answer: none, but it makes Perl geeks feel better. <nate37> brw: your script can read it, but how would YOU read it <dori> You can read the files (maybe, in certain circumstances), but you can't write them back out again. So, how is anything compromised? Again, you need CGI to actually do any writing. <brw> You may need CGI to do the writing, but without the aid of Javascripts Security Hole, you would not have access to the info in the first place. <dori> Give me an example. It's easy to say this, but as I said, it can all be done with some clever CGI and no JavaScript. <brw> ok <brw> I read a "secure" system file, say something with respect to a password file or something else. I then redirect to a page which saves that information for me. <brw> Javascript reads teh file <brw> yes <brw> CGI writes the info, yes <brw> but without Javascript, CGI cant read the file. <dori> How does JavaScript read the file? How does JavaScript know what file to read? <brw> you code that in your script <brw> the security hole allows access to it <dori> How do you code that, given that JavaScript has no read or open commands? <dori> You keep saying "the security hole". What security hole? <lazarus> /etc/shadow is a fairly well-known /path/file, and there are many others to check for <dori> Yep, and you can get there just fine by writing a CGI to get there. <nate37> i assume that DOM doesn't have any read or open commands.. not javascript itsself? * brw is looking up on securityfocus hang on <dori> The DOM is just objects. You use JavaScript to actually manipulate the DOM. In my book, I recommend thinking of this as "DOM=nouns, JavaScript=verbs). Read, Open, and Write are verbs, none of which are in JavaScript. <nate37> ah <brw> you know, lets move away from browsers for a moment <brw> I am having problems finding the browser issues I remember <dori> Couldn't find anything, huh? <brw> working on it, dont get so defensive. <nate37> heh <dori> Nah, I'm laughing, I've been through this discussion a few times before. <brw> well I am glad. <brw> lets take a look at this article <brw> http://www.securityfocus.com/vdb/bottom.html?vid=962 <nate37> dori: how does JavaScript "The Language" (not implementation side) compare to.. say... python, perl, or php, in your opinion? * cdlu wants either javascript support in console or the elimination of it. <dori> That's OE, which is another thing altogether. Anyone who uses OE/Win is has a giant target pasted on their forehead (imo). * lazarus agrees with cdlu <Woad> brw: try here http://www.cen.uiuc.edu/~ejk/browser-security.html <Woad> there's a plethora of evil javascript related/browser bugs <brw> heh <brw> there ya go dori: <brw> http://www.cen.uiuc.edu/~ejk/guninski.txt <brw> Now I can find them <brw> you dont need specific commands to read files because file reading is supported in URLs <Woad> Juan Cuartango reported a flaw in MS Internet Explorer JScript that could allow a malicious server operator to read file's with known names from the <Woad> user's hard drive after the user merely visits the malicious page. <Woad> i remember that one <brw> Email clients are subject to javascript vulnerabilities as well. <brw> waod: That is the one I was looking for. :) The Cuartango bug. <Woad> i like javascript, but some of these vendors implementations.. jeez ;) <brw> heh, well because javascript is client side generated, you have to rely on it <Woad> yeah * cdlu thinks javascript shoulb be serverside :) <brw> unless you are going to use it in the same manner applescript is used for, simple shortcuts around your system. <cdlu> should <brw> hah <brw> IMHO, ANYTHING running on the client is subject to problems. Making a blanket assumption that JavaScript is completely safe is foolish. <dori> Oh, I never said JavaScript was completely safe. I just said that I thought the idea that "I have JavaScript turned off, therefore I'm completely safe" is bogus. <brw> noone is putting those words into your mouth <Woad> well if you turned off all client side scripting languages/plugins/etc, I don't think there's any html exploits :) <brw> what we are saying is, Javascript itself is a security risk <Felix> imho, using javascript instead of cgis is like handing the security problems over to your customers... <brw> therefore turning it off can rid you of any problems that originate within javascript <cdlu> nah, <marquee> is a security hazard! :P <brw> I think the funniest javascripts are the ones that "restrict access to your site via password protection" or "Prevent you from right clicking" <nate37> brw: hah yea <dori> Oh, those are just stupid. I give how to do it in the book, along with an entire sidebar on why this is a dumb idea. <nate37> hah <brw> But back to the whole point, JavaScript HAS a history of security problems as does most client side scripting <brw> Unless you are in complete denial, you should agree with this. <brw> granted, javascript has its uses, but server side scripting and shockwave/flash can do everything javascript can do, and much more. <dori> What I'm saying (once again) is that any of those exploits, so far as I can tell, could have been accomplished just fine with just CGI and no JavaScript. <brw> woh woh, back up <jericho> you don't even need server side scripting with flash <brw> Java script opens the door! <brw> That is like saying, Drunk Drivers dont kill anyone without cars. <Woad> dori: you mean CGI + a different client side security issue (besides javascript) <brw> CGI is run on the server and does not mess with the client. <brw> javascript directly interacts with the client <Woad> CGI is just the mechanism, the client side issue is the instigator <brw> exactly <brw> Not sure how many different ways it can be said, but if you still are in some sort of denial, I am sure we might come up with a few :) <dori> I'm saying that, for instance, Cuartango needed (1) you to visit a page of his, and (2) the server side person to already know an exact file & path name. Given those, why couldn't you write something in CGI? Who needs JavaScript to do that? <Assembler> dori: what do u think about the Opera JS implementation? <brw> because you cant execute cgi on the client side <brw> it is as simple as that <brw> do you not know what CGI is or something? <nate37> dori: perhaps there is an exploit where javascript opens up the hole by calling a function right before the malicious code to view a file? (don't know if that is real or not, just an example) <brw> you do understand that CGI is executed on the server right? <brw> that restricts interaction with the client to port 80 communications <dori> Opera? So close, but yet, so far. They tried to implement MS's document.all object, but didn't do it correctly/completely. Now, most of my scripts don't work in Opera because they assume that if document.all exists, it has certain properties. Grr. <Assembler> eheh thxs dori :) <dori> brw: yes, dear, I know what CGI is. And yes, I know that 100% of these exploits require *something* on the server side. While it's handy to have something on the client-side, it's not required, really. <Woad> ashame, opera is an awesome browser <nate37> dori: do you think javascript should be restricted to client side scripting only or expand into other areas? <brw> dori: Heh that statement just demonstrates that you have no idea what CGI is. * Felix agrees with brw <brw> otherwise you would know that it is not possible to do what you are saying without JavaScript or some client side scripting <dori> Nate 37: Expand how? As I said before, I think that what Macromedia's doing with JavaScript has an internal scripting language is way-cool. <nate37> hmm <Felix> brw: this how cuartango works: "set wcover = window.open ("welcome.htm", "Welcome . . . )" as a part of the page -- how would you do such with a cgi but no javascript?? <Felix> s/brew/dori/ <nate37> s/brew/brw/ <Felix> yepp :) <Felix> thx nate <nate37> heh <brw> :) <jericho> you can't. so, so <dori> Open a frameset, and have the page be 99% what they're expecting, and some small part be the file that you're trying to snag. <dori> Or, use an image bug. <dori> Or, or... there's a million and one ways to do this, if you know something about CGI. <lazarus> but doesn't an image bug require cookies? <lazarus> and who allows cookies through these days exceppt winlamers? <Felix> dori: this window just created is meant to actually _hide_ a message box behind it <brw> And most of those require further interaction of the user <dori> Depends on what you're trying to do with an image bug. Yep, cookies is another way to do this. <jericho> lazarus: javascript is not for *nix geeks, see <brw> whereas the curtango bug does not. And is much worse. YOu cannot access files on the local file system via CGI. <brw> simply not possible <lazarus> jericho: apparently, since i don't have a GUI on the box <Felix> dori: a message box generated by windows(tm)... <nate37> brw: its possible.. just would require another exploit in the browser :) <jericho> but that doesn't mean it is useless <dori> brw's problem seems to be a lack of imagination <g> <lazarus> jericho: no, it's worse <brw> dori: Hah, your problem seems to be a lack of knowledge <nate37> brw: such as a backdoor that when give "Location: GIVE ME DAMN PASSWORD FILE" the browser would return /etc/shadow :) <jericho> worse for unix users <lazarus> jericho: its use prevents me from getting onto my isp's lame dsl "dashboard" <Felix> dori: you're SOL, imho <brw> nate: right, but CGI itself is not a culprit. It requires something like JavaScript to help it. <brw> which is exactly my whole point. Javascript creates the vulnerability for other things to use. <nate37> brw: right.. and is javascript the culprit if its an exploit in the browser? <brw> nate: yes, because the javascript is interpreted by the browser. <jericho> javascript helps with the design of the site, not the engine <nate37> brw: and HTML isn't?! <lazarus> jericho: and after all, the context here IS linux.com's #live :) <brw> HTML is a markup language, not a scripting language. <brw> HTML can only format text and images, javascript does more. <nate37> brw: if the browser had the tag: <give_me_damn_password_file to="myevilcgiscript" method=post>... <nate37> brw: or if it would be: <nate37> <form name="myform"> <nate37> <input type="hidden" from_file="/etc/shadow"> (i know from_file doesn't exist.. but lets pretend its an exploit) <nate37> </form> <brw> heh, but that is the entire point. those kinds of things cant happen. <nate37> ermm <form name="myform" method=post action="mycgi.cgi"> <brw> just like you cant get water from a rock, you cant get local user files from HTML. <nate37> brw: then why could they happen with javascript? only threw exploits. <nate37> if html doesn't allow reading from a file <jericho> how about an include("$link"); when link passed throught url = "../../../etc/passwd" ? ;) <brw> because Javascript is EXECUTED on the CLIENT. The Browser, or email program, or whatever EXECUTES CODE. <nate37> and javacsript doesn't allow reading from a file <brw> nate: go read that url above <Woad> nate37: say such a browser exploit existed, cgi is not the instigator, you could format that code with simple html files <brw> jericho: keep in mind that those are server side exploits <nate37> then reading from a file from html and javascript are only possible via an exploit <Woad> all cgi does is run something *server* side, and spit back html, just like any other web page <nate37> Woad: i know what cgi is <jericho> no, mines split back xml, though <nate37> Woad: i'm talking mainly client-side so then i can compare a theoritcal exploit in cgi <brw> but that is my whole point <nate37> brw: which? <lazarus> "spit back text (probably with tags)" <Woad> nate37: point is it's *not* a "cgi exploit" <Woad> that would be a browser exploit using HTML, you would not need server side CGI to do that <brw> without client side scripting like javascript, you cant do anything "exploitive" with cgi <nate37> brw: and back to why i orginally said... <nate37> ermm what i orginally said <dori> nate37: that should be <form><input type="file" name="whatever"></form>. Get them to somehow submit the form, and you're in business. <nate37> what if there was a "GET_FILE: /etc/shadow\nLocation: Mycgi.pl"...an wayy over simplified exploit.. but it could exist somehow. and that would require cgi <lazarus> dori: suggestion: add a Security chapter to version 2, as you can see, it would be popular <nate37> lazarus: heh :) <brw> nate: Those are not client side exploits <brw> nate: You might want to read some of the RFCs that talk about the HTTP protocol and CGI <Woad> nate37: you are thinking about it wrong. what if there was an browser/html exploit that caused /etc/passwd to be POSTed to a new user signup page on my.yahoo.com's cgi? <brw> I understand your argument, but it is not valid because you are talking about things that dont exist. <Woad> that's not yahoo.com's cgi exploit <Woad> that's the browser's issue, cgi has got nothing to do with it <nate37> brw: (1) they are client exploits since the browser IS interpretting the headers... <brw> nate37: they are not exploits because what you are talkiung about is not possible <lazarus> Woad: let's make it more plausible, the next time hotmail.com is cracked, change their new user cgi to ... :) <brw> heh <Woad> that's not a 'cgi exploit' either, that's a hacked server :P <jericho> i discovered one of the most 'dangerous' client side exploit yesterday :) <nate37> brw: its possible, but unlikely.. but ya never know what MS puts in their browsers :) <Woad> they could change the html too, and it wouldn't be an 'html exploit' :P <jericho> only works on ie4+/win32 though <lazarus> Woad: yeah, but you'd have to add some exploit code to the cracked server, not just "kilroy was here" defacement <brw> nate: heh, well while you have a point there, it is still not possible :) <nate37> brw: :p <Woad> lazarus: and the malicious code would have to make the users browser do something it wasn't meant to do. hence, the problem lies in the browser's interpretation of the code. hence, it's a browser exploit <Woad> the mechanism for delivery of the malicious code is irrelevant <jericho> browser exploit, true <Woad> it would not need to be cgi <lazarus> Woad: or be (keeping topical here) malicious javascript code :) <Woad> sure ;) <brw> welp, I am out folx. seeyas <jericho> cya <lazarus> my point is that javascript code or any client-side execution, trusts "someone else's" (namely the server's) code, and that's just-plain-dumb in this hostile internet today <lazarus> running something someone else hands you, that's the problem <Woad> well it's 2 part, you trust the server's code, and you trust your browser vendor to interpret that code correctly <Woad> moreso i think the fault lies in the browser vendor <Assembler> cu all <Assembler> thxs dori <lazarus> what was that *.ini thing that mirc executed? same principle, don't trust other ppl's code, it's asking for trouble <jericho> i'm off <dori> Thanks all--I was supposed to be out of here an hour ago. Bye bye. <nate37> heh <nate37> cya <lazarus> basically the presumption these says should be "assume everything foreign is hostile" <lazarus> s/says/days/ <Felix> lazarus: unfortunately yes <lazarus> felix: gone are the days of .plan <lazarus> okay, this client is no longer behaving, tab completion is dead, for one, and with my typing, i should remedy that <Felix> lazarus: at _that_ point of time, I didn't even own a pocket calculator... *g* <Woad> but by that token, you should never receive data from the 'net. ie. can't even browser web pages cause you might catch malicious html code that your browser vendor has a security problem with :) <Woad> err browse web pages <Felix> woad: pure html doesn't do any harm, does it? <Woad> not that anyone has discovered afaik, but I was just feeding off the examples <Woad> but it's theoretically possible to do weird stuff to browsers with anything it interprets <BB> depends if the renderer has a bug in parse, image display or whatever.. possible though <Woad> buffer overflow an html tag ;) <Felix> woad: use telnet www.somedomain.com 80 and parse the html in your head then... ;) <Woad> well I'm not worried about exploits. this is why you run things as a 'user' :) <Woad> severity of possible exploits is now much less severe to the point I don't worry too much browsing the 'net <Felix> it could still read e.g. your browsers history for that user <Woad> nod. that's also why I keep track of exploits <Woad> but at least I don't have to worry about what the windows users do <Woad> like box rendered inoperable cause i browsed a web page ;) <Felix> MS is great when it somes down to marketing, but the neither do stability nor security... *sigh* <Felix> s/the/they/ <Felix> hallo miro <miro> hi <Woad> MS is getting better.. it's just an extremely slow and painful process

Originally published on Linux.com. Released under the Open Content License unless otherwise stated. Notify Gareth Watts of any errors or copyright violations.

Originally Published: Friday, 8 June 2001	Author: IRC Staff
Published to: interact_articles_irc_recap/IRC Recap	Page: 1/1 - [Std View]
JavaScripting And the World Wide Web Dori Smith, author of JavaScript for the World Wide Web talked to us about writing JavaScript, her book and the future of JavaScript on the World Wide Web. If you missed the event or would just like to read the log of the event, here it is for your reading pleasure.