Obviously you cant trust the client input on the server. But you can do "warm and fuzzy" validation on the client side. By "warm and fuzzy" I mean providing instant feedback with useful error messages.
When a visitor clicks "submit", the server can be a hard-ass and barf on invalid input in mean, nasty ways instead of trying to do complex interaction with the user. When the server gets pissed off in a webapp that does "warm fuzzy" javascript validation, the server-side validation code doesn't have to remember form values, do complex "IF (error) SHOW THE FORM PRINT THIS MESSAGE" kinds of things. It just can return "hey jackass who turned off javascript, why are you feeding me bullshit?" and be done.
That document.observe is all great until you try to mix Prototype (or any of these libraries) up. Say you needed to use the YUI calandar control on a page that also uses Prototype (for lightbox2). Now the two libraries will "fight" over the browser's onload.
Actually.. that is the biggest problem we have right now. Dozens of javascript libraries and all do pretty much the same thing. All of them "weight" like 20->40k. That "weight" and the potential for them to conflict make life really hard.
What if you based your own code on Prototype and want to integrate a really nice file-upload control that uses MoTools?
What if you are using Prototype and you drop in TinyMCE. Now you've got two runtime libraries that both have their own methods for injecting objects into the DOM. Those two methods are ever so slightly incompatible so if you create a DOM object via Prototype (actually scriptalicious) and try to inject it using the TinyMCE way, things will break in random browsers in very hard to track way.
Enter Silverlight/Flex. Now you can go from dozens of Javascript runtime libraries to only two very stable ones. As the "UI control" scene for these grow, I suspect our dependency on Prototype/jQuery/Whatever will shrink.
After all, it has to be way easier for control vendors to target Silverlight/Flex then it is for them to target javascript. And as a bonus, it is way easier for me to integrate their UI controls into my own Silverlight/Flex application.
I'd go so far as to argue Javascript used to get a bad wrap because only a handful of people bothered to learn it. "back in the day", my javascript experiance consisted of searching google for "Javascript Image Swap" and copy & pasting whatever bit of code I found. I used to comment to colleagues that nobody really knew javascript because I figured 99% of all javascript code was copy & paste garbage.
Once I bothered to learn Javascript and use it ontop of a good cross-browser library like Prototype, I've come to really like Javascript. It is like a cross between my beloved Perl, C# and C.
Javascript is great. The DOM, the tools and web-browsers are what sucks.
The combination of HTML's form controls and Javascript's XMLHttpRequest gives web app designers the power they need to implement 99% of applications as webapps with very little compromise vs. thick-client apps.
Hahaha.. Yeah. Right pal. Sure you could do it all in HTML/DOM/Javascript, but Jesus, I'd like to ship a product on time and on budget.
Do you have *any* idea how much of a pain in the ass any kind of *serious* web development is? The minute you want to do something interesting, like oh, fire an event when the page is done loading, you are in a world of pain.
No, I see the future as Flex & Silverlight. Both are basically really, really, really beefed up versions of Prototype/Scripalicious (or however google spell checks that for me) and jQuery. When properly used, all your javascript code does is act as a shim between the wild wild west of HTML/DOM and your nice, comfy stable runtimes.
I predict within a year, we'll see many of the "rich" UI controls and "rich" interactions be migrated to Flex/Silverlight. Libraries like Prototype/jQuery will be more centered around acting as shims.
"Web 2.0" companies that do not adopt Silverlight/Flex will not be able to remain competitive. Sure they might be able to crank out the same stuff a Silverlight/Flex shop will be able to, but their development costs will be 10x higher.
No. Javascript/DOM is a dinosaur and the faster we can more to a better runtime stack on these great intertubes, the better we all will be.
I don't see what more you might want in javascript
- A real way to include other javascript files.
- A well defined way to say "The page is loaded, all your variables and objects are loaded, Time to execute!" rather then "You can only see the variables and objects that are defined 'above' you and not 'below' you in unloaded portions of the page".
- Ponies.
That was me who mentioned it. Well worth it watching it (it was made in 2006).
I'm not nuts, I just feel that TCP/IP was a great protocol, but we've got new problems to solve that really dont mesh with TCP/IP anymore. Things like NAT, VPN's or MobileIPs are signs that the protocol doesn't fit the task.
Which is a bad, bad thing on mesh networks. TCP/IP really, really, really doesn't like meshes. It doesn't like you hopping around from various "access points" because it doesnt like you changing your address all the time.
Wanna talk hack-job? Think how complex it must be to provide a TCP/IP stack to a cell phone or airplane that hops across access points. Sure they can proxy your web traffic to a central server, but your cell phone isn't getting a "native" TCP/IP connection...
Wouldn't it be nice if the L3 networking stack was smart enough to deal with you hopping around?
What is the point, you say? WiFi could create really nice neighborhood mesh networks that pretty much dont require physical links to operate. Go ahead, you try to do the IP addressing for one of those. Make sure the routing of the TCP/IP hierarchy can address me hopping from node to node or deal with changes in the mesh (i.e. going off line or out of sight).
There are new problems to solve! TCP/IP is a great protocol, but it just doesn't fit the problems we are trying to solve these days.
And to reply to myself, firewalls wouldn't stop most of the attacks you describe either. These kind of attacks dont operate on the network level but the application level. They'd require the firewall to dig really deep into the packet to see what is up. That kind of digging requires what is now expensive hardware (expensive = more than $50)
Besides, we stand as much of a chance filtering them out of our networks as we do trying to block BitTorrent traffic on consumer broadband networks. They'll just invent better ways to hide their traffic.
Stateful routing (i.e. firewalls and NATs) filter out the obvious stuff. Kinda like using SSH doesn't stop people from breaking into your server, but if you "turned of" SSH, people would just sniff your traffic and get your password.
By far the biggest hole on your network is all the software you're running on your computers
Only because I've taken the steps to plug up the obvious stuff like making it almost impossible to route *into* my network. Now the attacks have evolved to work around the firewall/NAT.
probably much of it un-audited and capable of sniffing your "private" network
Audited, yes, but all of my computers are wide open and password free to improve the human factors like, say, the lady getting her pictures off my computer from the laptop (vista does act smart about this, btw, it keeps tract of the network you are connect to and can let you open or shut your "doors" based on your access point).
There are a host of applications where being able to easily and systematically address hosts in a "private" network would be a good thing.
Address translation or not, these are still gonna have to punch holes in my firewall (which would clearly be "default deny") and do it in a user friendly way that doesn't require me to log into my broadband router (which would still exist exactly to provide a firewall)....Speaking of, we'll have to improve our routing protocols to deal with provisioning entire subnets to each customer instead of lumping many customers onto a single subnet. Thats an engineering problem though.
You know what? The telephone company still continues on connecting wires as well. Our concept of "network" will evolve past both "end 2 end" and "connected wires". Sure TCP/IP will be around forever but it won't matter just like ATM, SONET, DSL, T1, OC3, ISDN and POTS are all still around but I dont care which of those I use to connect to the internet.
Those IPv6 innovators will still have my firewall to deal with, and that is about the same set of problems. You still gotta get my firewall to open a port up for your non-trivial protocol and to it in way that doesn't require me to log into my firewalls webpage.
Kidna... I watched again:-) His thesis is that we are at the same kind of transition phase that we were when we moved from circuit switching "connecting wires" to packet switching "making endpoints".
Basically, he is saying "guys, we need to think outside the TCP/IP box. TCP/IP was and is a great wildly successful protocol, but it changed how we do things enough that it created a new set of problems we now have to solve"
I've said it once, I'll paste it again, watch this lecture by Van Jacobson (guy who invented traceroute, Van Jacobson header compression, etc. Come back to me and say I'm not incorrect in saying IPv6 doesn't solve the new problem set we have.
It is a long lecture (especially if you cannot stream it onto your Sage/MythTV like some of us;-P, but it is very eye opening.
See, I agree with you on this. Just like we can bask in garbage collection, gobs of CPU and terabyte disk drives... we'll figure out a way to burn those IP's (assuming IPv6 is adopted and not something else)
Does Sally Sue Downloader know this? I might, but does it assign a non MAC based address *by default*? If it doesn't, lots of people are gonna be awfully surprised when the RIAA shows up and nails them based on their IP address.
Suddenly those flashy "Your IP address is exposed" banner ads wouldn't be so funny, would they.
Unless there is a huge entrenched reason that forces NAT vendors to specifically target them, nobody will use a protocol that doesn't work with a NAT.
Beyond clueless NAT unaware protocols, punching holes in your firewall still breaks the whole "End to End" thing people like to talk about, doesn't it? Epescially given
If you watch any thing on Discovery channel, you'd realize nothing is a "true" measurement until it can stretch across the globe or weight as much as elephants.
Yes, all those can be forged by people in the know. Sally Sue using her bit torrent client on a "stock" IPv6 installation has just given her MAC address to the RIAA. Pretty much all that is required after that is for a slick laywer to make the case she was using the computer with the MAC address in question to download N'Sync and New Kids on the Block.
I'm surprised so many here on slashdot, "Fuck the RIAA" central don't see IPv6's use of your mac address as a huge problem. IP addresses have never given away something like a mac address (and we all would rightly laught at those "Your IP address is exposed" banner ads).
Now a "stock" IPv6t network will give the feds pretty much all the proof they need to tie our internet usage to our specific computer unless we know exactly what we are doing.
Why should they? It will stifle network protocol innovation for decades. Just because they europeans always seem to get their governments to mandate protocols like GSM means we need to as well. In most cases, it was our innovations that lead to their ability to even have a protocol to mandate. If we didn't invent TCP/IP, they wouldn't have anything to mandate (didn't they have some goofy ass government mandated network before?)
If we start mandating protocols, who is gonna invent the replacement for TCP/IP? Hint: not us.
Sorry, it is a "Google Tech Talk" video where Google employees get to listen to lectures by smart people like Van Jacobson, Vint Cerf, the subversion guys, etc. I doubt they have a transcription of it.
It is like 80 minutes long, but if you've got the time, I highly recommend watching it.
Slashdot Mirror
The point of TCP/IP was to keep the military running when the commies nuked our ass to hell. Where does this 'HTTP' fit in with that?
Obviously you cant trust the client input on the server. But you can do "warm and fuzzy" validation on the client side. By "warm and fuzzy" I mean providing instant feedback with useful error messages.
When a visitor clicks "submit", the server can be a hard-ass and barf on invalid input in mean, nasty ways instead of trying to do complex interaction with the user. When the server gets pissed off in a webapp that does "warm fuzzy" javascript validation, the server-side validation code doesn't have to remember form values, do complex "IF (error) SHOW THE FORM PRINT THIS MESSAGE" kinds of things. It just can return "hey jackass who turned off javascript, why are you feeding me bullshit?" and be done.
That document.observe is all great until you try to mix Prototype (or any of these libraries) up. Say you needed to use the YUI calandar control on a page that also uses Prototype (for lightbox2). Now the two libraries will "fight" over the browser's onload.
Actually.. that is the biggest problem we have right now. Dozens of javascript libraries and all do pretty much the same thing. All of them "weight" like 20->40k. That "weight" and the potential for them to conflict make life really hard.
What if you based your own code on Prototype and want to integrate a really nice file-upload control that uses MoTools?
What if you are using Prototype and you drop in TinyMCE. Now you've got two runtime libraries that both have their own methods for injecting objects into the DOM. Those two methods are ever so slightly incompatible so if you create a DOM object via Prototype (actually scriptalicious) and try to inject it using the TinyMCE way, things will break in random browsers in very hard to track way.
Enter Silverlight/Flex. Now you can go from dozens of Javascript runtime libraries to only two very stable ones. As the "UI control" scene for these grow, I suspect our dependency on Prototype/jQuery/Whatever will shrink.
After all, it has to be way easier for control vendors to target Silverlight/Flex then it is for them to target javascript. And as a bonus, it is way easier for me to integrate their UI controls into my own Silverlight/Flex application.
I'd go so far as to argue Javascript used to get a bad wrap because only a handful of people bothered to learn it. "back in the day", my javascript experiance consisted of searching google for "Javascript Image Swap" and copy & pasting whatever bit of code I found. I used to comment to colleagues that nobody really knew javascript because I figured 99% of all javascript code was copy & paste garbage.
Once I bothered to learn Javascript and use it ontop of a good cross-browser library like Prototype, I've come to really like Javascript. It is like a cross between my beloved Perl, C# and C.
Javascript is great. The DOM, the tools and web-browsers are what sucks.
The combination of HTML's form controls and Javascript's XMLHttpRequest gives web app designers the power they need to implement 99% of applications as webapps with very little compromise vs. thick-client apps.
Hahaha.. Yeah. Right pal. Sure you could do it all in HTML/DOM/Javascript, but Jesus, I'd like to ship a product on time and on budget.
Do you have *any* idea how much of a pain in the ass any kind of *serious* web development is? The minute you want to do something interesting, like oh, fire an event when the page is done loading, you are in a world of pain.
No, I see the future as Flex & Silverlight. Both are basically really, really, really beefed up versions of Prototype/Scripalicious (or however google spell checks that for me) and jQuery. When properly used, all your javascript code does is act as a shim between the wild wild west of HTML/DOM and your nice, comfy stable runtimes.
I predict within a year, we'll see many of the "rich" UI controls and "rich" interactions be migrated to Flex/Silverlight. Libraries like Prototype/jQuery will be more centered around acting as shims.
"Web 2.0" companies that do not adopt Silverlight/Flex will not be able to remain competitive. Sure they might be able to crank out the same stuff a Silverlight/Flex shop will be able to, but their development costs will be 10x higher.
No. Javascript/DOM is a dinosaur and the faster we can more to a better runtime stack on these great intertubes, the better we all will be.
I don't see what more you might want in javascript
- A real way to include other javascript files.
- A well defined way to say "The page is loaded, all your variables and objects are loaded, Time to execute!" rather then "You can only see the variables and objects that are defined 'above' you and not 'below' you in unloaded portions of the page".
- Ponies.
That was me who mentioned it. Well worth it watching it (it was made in 2006).
I'm not nuts, I just feel that TCP/IP was a great protocol, but we've got new problems to solve that really dont mesh with TCP/IP anymore. Things like NAT, VPN's or MobileIPs are signs that the protocol doesn't fit the task.
But again... watch the video :-)
found this buried in the video comments:
a kinda-storta transcript
more 'hierarchicalness' in addressing
Which is a bad, bad thing on mesh networks. TCP/IP really, really, really doesn't like meshes. It doesn't like you hopping around from various "access points" because it doesnt like you changing your address all the time.
Wanna talk hack-job? Think how complex it must be to provide a TCP/IP stack to a cell phone or airplane that hops across access points. Sure they can proxy your web traffic to a central server, but your cell phone isn't getting a "native" TCP/IP connection...
Wouldn't it be nice if the L3 networking stack was smart enough to deal with you hopping around?
What is the point, you say? WiFi could create really nice neighborhood mesh networks that pretty much dont require physical links to operate. Go ahead, you try to do the IP addressing for one of those. Make sure the routing of the TCP/IP hierarchy can address me hopping from node to node or deal with changes in the mesh (i.e. going off line or out of sight).
There are new problems to solve! TCP/IP is a great protocol, but it just doesn't fit the problems we are trying to solve these days.
Just by deploying IPv6 we could forget about hacks around hacks around hacks.
Your magic remote access protocol will still have to go across my hard-assed firewall policies. How will it be any different than going over a NAT?
People will still use GotomyPC on IPv6 because it is easier to do over HTTP than it is to punch through a firewall, IPv6 or not.
Ever read mythical man month? IPv6 is a textbook example of the second system effect.
And to reply to myself, firewalls wouldn't stop most of the attacks you describe either. These kind of attacks dont operate on the network level but the application level. They'd require the firewall to dig really deep into the packet to see what is up. That kind of digging requires what is now expensive hardware (expensive = more than $50)
Besides, we stand as much of a chance filtering them out of our networks as we do trying to block BitTorrent traffic on consumer broadband networks. They'll just invent better ways to hide their traffic.
Stateful routing (i.e. firewalls and NATs) filter out the obvious stuff. Kinda like using SSH doesn't stop people from breaking into your server, but if you "turned of" SSH, people would just sniff your traffic and get your password.
By far the biggest hole on your network is all the software you're running on your computers
Only because I've taken the steps to plug up the obvious stuff like making it almost impossible to route *into* my network. Now the attacks have evolved to work around the firewall/NAT.
probably much of it un-audited and capable of sniffing your "private" network
Audited, yes, but all of my computers are wide open and password free to improve the human factors like, say, the lady getting her pictures off my computer from the laptop (vista does act smart about this, btw, it keeps tract of the network you are connect to and can let you open or shut your "doors" based on your access point).
There are a host of applications where being able to easily and systematically address hosts in a "private" network would be a good thing.
Address translation or not, these are still gonna have to punch holes in my firewall (which would clearly be "default deny") and do it in a user friendly way that doesn't require me to log into my broadband router (which would still exist exactly to provide a firewall). ...Speaking of, we'll have to improve our routing protocols to deal with provisioning entire subnets to each customer instead of lumping many customers onto a single subnet. Thats an engineering problem though.
You know what? The telephone company still continues on connecting wires as well. Our concept of "network" will evolve past both "end 2 end" and "connected wires". Sure TCP/IP will be around forever but it won't matter just like ATM, SONET, DSL, T1, OC3, ISDN and POTS are all still around but I dont care which of those I use to connect to the internet.
Might as well mix up all the measurements. Who knows, it might even result in this thing some of you lack known as "humor".
I'm so smart, there wasn't enough IPv6 to map even a quarter of my brain. Your so dumb, they gave your braincells a subnet of 255.255.255.255
Those IPv6 innovators will still have my firewall to deal with, and that is about the same set of problems. You still gotta get my firewall to open a port up for your non-trivial protocol and to it in way that doesn't require me to log into my firewalls webpage.
Kidna... I watched again :-) His thesis is that we are at the same kind of transition phase that we were when we moved from circuit switching "connecting wires" to packet switching "making endpoints".
Basically, he is saying "guys, we need to think outside the TCP/IP box. TCP/IP was and is a great wildly successful protocol, but it changed how we do things enough that it created a new set of problems we now have to solve"
I've said it once, I'll paste it again, watch this lecture by Van Jacobson (guy who invented traceroute, Van Jacobson header compression, etc. Come back to me and say I'm not incorrect in saying IPv6 doesn't solve the new problem set we have.
It is a long lecture (especially if you cannot stream it onto your Sage/MythTV like some of us ;-P, but it is very eye opening.
See, I agree with you on this. Just like we can bask in garbage collection, gobs of CPU and terabyte disk drives... we'll figure out a way to burn those IP's (assuming IPv6 is adopted and not something else)
Does Sally Sue Downloader know this? I might, but does it assign a non MAC based address *by default*? If it doesn't, lots of people are gonna be awfully surprised when the RIAA shows up and nails them based on their IP address.
Suddenly those flashy "Your IP address is exposed" banner ads wouldn't be so funny, would they.
Unless there is a huge entrenched reason that forces NAT vendors to specifically target them, nobody will use a protocol that doesn't work with a NAT.
Beyond clueless NAT unaware protocols, punching holes in your firewall still breaks the whole "End to End" thing people like to talk about, doesn't it? Epescially given
If you watch any thing on Discovery channel, you'd realize nothing is a "true" measurement until it can stretch across the globe or weight as much as elephants.
Yes, all those can be forged by people in the know. Sally Sue using her bit torrent client on a "stock" IPv6 installation has just given her MAC address to the RIAA. Pretty much all that is required after that is for a slick laywer to make the case she was using the computer with the MAC address in question to download N'Sync and New Kids on the Block.
I'm surprised so many here on slashdot, "Fuck the RIAA" central don't see IPv6's use of your mac address as a huge problem. IP addresses have never given away something like a mac address (and we all would rightly laught at those "Your IP address is exposed" banner ads).
Now a "stock" IPv6t network will give the feds pretty much all the proof they need to tie our internet usage to our specific computer unless we know exactly what we are doing.
Why should they? It will stifle network protocol innovation for decades. Just because they europeans always seem to get their governments to mandate protocols like GSM means we need to as well. In most cases, it was our innovations that lead to their ability to even have a protocol to mandate. If we didn't invent TCP/IP, they wouldn't have anything to mandate (didn't they have some goofy ass government mandated network before?)
If we start mandating protocols, who is gonna invent the replacement for TCP/IP? Hint: not us.
Sorry, it is a "Google Tech Talk" video where Google employees get to listen to lectures by smart people like Van Jacobson, Vint Cerf, the subversion guys, etc. I doubt they have a transcription of it.
It is like 80 minutes long, but if you've got the time, I highly recommend watching it.