The issues that were stated about PHP, really apply to ANY language. SQL injection flaws can existing in PHP, Perl, Java, and.NET.
The reason you don't find much about "secure PHP", is that it's not just a PHP issue. You might want to read sites like OWASP (http://www.owasp.org/) and Threats&Countermeasures (http://www.threatsandcountermeasures/). There are plenty of others.
The thing is, it's not as simple to write a "how to" when it comes to security issues. It's a bit more abstract than that, if you try to encompass the whole concept. For example... SQL injection flaws:
Never take anything string of data that came from the user and stick it into the SQL string you are generating, without checking it for a few basic things. Escape ANY special characters that has meaning in SQL (quotes, semi-colons, etc). Quotes are your biggest threat. Quick example:
You are building this string: "SELECT count(*) from users where username = '$username'";
Now imaging $username came directly from user input, and I typed: '; delete from users; --
That results in a query like: SELECT count(*) from users where username = ''; delete from users; --'
Assuming your driver or database doesn't limit single "prepare" or query executes to only one statement, it will run the select, and then delete all users, commenting anything else you would have had after that. Scary, huh?
The best thing is to look for API's that support prepare and execute of a query separately, where you place "?" placeholder in the SQL query string, and then give the data to the execute method. The execute method generally handles all escaping needs to treat it as "data". Clear separation of command and data. Of course, that's not 100%, as you could have a "LIKE" comparisson in your WHERE clause. A "%" in the data is still treated as a wildcard, so you would still have to be sure to escape that in variables you are using with where clause values.
So, there's your simple brief tutorial... but the whole way of thinking is different if you consider all the vulnerabilities. Read OWASP's top 10 list, and think about you are providing information and using information to/from the user. These are your attack surfaces.
Cheers, Your friendly neighborhood Application Security Specialist
I don't know. After 12+ years websites that have learned to use technology effectively have become MUCH better. I don't deny there is a lot of cruft and crap out there as well. But because there are idiots in the world doesn't mean the genius (not necessarily claiming this for myself) that has emerged don't exist.
It seems that almost everyone that argues against me on this keep bringing up simple, static, content pages as their support. But if you people bother reading my postwith the context of THAT POST (as opposed to the bucket your charged up brain has placed it into), you'd see that I am focusing on Web Applications. These are not pages that generally need to be bookmarked. These are not pages that NEED a back button.
I mean, bitch about the limitations of Banking websites all you want. The dynamic content is what allows you to HAVE a banking website. The limitations have little to do with the JavaScript or AJAX. The limitation that you can't go BACK on those pages has to do with general state and flow management. And the "Back button" issue that you mention has nothing to do with the "Back button" issue the article's author mentioned. Your back button issue has existing since the beginning of dynamic web pages/web applications. It is specifically THESE limitations that have driven technologies like AJAX. I mean, if you process a transaction for a transfer, and then try to hit "back", bringing you back to a processing page and the interface just lets you... you're more likely to make a mistake of retransferring money (duplication). The choice your bank made is to not let you go back. Others handle it by just not processing a resubmit on a transaction, but let you back button all you want. Another option would be to use AJAX within the scope of a transfer transaction "application". Hitting the back button would take you to the page you were at before the transfer request. This would actually be idea, since loading into the middle of a completed transaction's form is simply "invalid use".
Hmmm... I think your issue with your bank's "back" button restrictions is actually an argument FOR something like AJAX!
So, once again... your arguments are not with AJAX or similar technologies. Your argument seems to be against poorly implemented applications. The back button issue you descrobe, not allowing simultaneous windows, etc... these are not issues with AJAX or similar technologies. These are issues with the back-end session and transaction management of the application. But since much of that level of backend development isn't inherant to existing frameworks, it becomes a lot more development (and QA/testing) to support. AJAX could actually help alleviate your specific issues, by reducing the client behavior that causes banks like yours to be so restrictive.
HTTP is not a stateful protocol -- sort of, if all you know is RFC 2616. But if you're using any kind of language to create dynamic content on the server, the first thing that happens is almost always to set a session cookie for purposes of maintaining state.
Not to burst your bubble or pick nits here, but once you're talking about maintaining sessions in the application, that by definition is not part of the underlying "protocol" of HTTP. That is a layer above. The HTTP request object (environment, whatever it's called in what you use) is NOT part of the HTTP protocol; it simply uses HTTP, but adds additional abilities.
Of course, I'm not supporting the previous post... just pointing out a flaw.:)
Know what makes those page loads take so long? Javascript, flash, superfluous tables, and all the rest of the crap layered on by the same designers who claim that they need such heavyweight monstrosities to improve responsiveness. Try just putting together simple pages in pure, flexible html some time, and be amazed at just how quickly they load and render.
Actually, as I said, it's perceived time. The blinking and redrawing of the page in an application setting is perceived as taking longer for the user. Whether this is wait time, or time to orient themselves from page to page is irrelevent. Actually, most of the pages of the sites I use are very simple. They do load quite quickly, and they are not overwhelmed with Javascript. One point I agree with the author on is "sparingly".
"Non-ajax browsers" does not mean the same thing as "old browsers." I'm posting this from the currrent version of w3m, which does not and never will support ecmascript in any form.
Which is good, because it saves me the trouble of disabling it. Which is another place at which your "old browsers" assumption falls down: many of us explicitly disable nonsense like ecmascript in any browser we use, however current. I have never yet seen anything done with ecmascript that I wanted to have happen to my browser, so I find that I'm vastly better off without it.
Valid point. I still don't care about them. They're too small a userbase to give up the benefits to the rest of the users who are not so irrationally anti-client-side scripting. Again... I think sites that have an abusive level of scripting are quite annoying. Not once in my arguments have I said to embed JavaScript like mad for every link, image, field, form, and character on the page. But there is much to be gained from a WEB APPLICATION perspective. This is where AJAX really does shine. Pages don't have to reload, even though you're on the same "interface", moving your buttons relative to page location (any scrolling down), causing you to need to reorient yourself on the page.
Oh dear fuck no. "This web page designed for 800x600!" wasn't cool in 1995, and it's not cool now. The whole bloody point of the Web, the whole thing that made it successful in the first place, was the design goal of delivering content in a presentation-flexible manner. If you write markup that breaks in the presence of something so mundane as a window size you didn't expect, then you have failed.
Actually, the "bloody point" of the web was to share information through a more useable interface than existing technologies, such as gopher, specifically for graphical presentation. Images of physics results and statistics were more easily presented in a graphical manner. This notion that the web was first created in a perfect way for all-time, which so many of you seem to cling to, is just stupid. The web was created because the tools available at the time didn't do what some geeks wanted. So they stepped up the game a notch. If you recognize THAT as the foundation of the web, technologies such as AJAX and the like are very much in the tradition of the web, as opposed to the sad view that someone came up with a perfect way to present data for all time, when in fact they came up with a to do things that what existed sucked at doing.
Anyway... reread my post. I focus on appropriate use of AJAX in Web Applications and agree with the original author that simple content and pages do not really benefit all that much, but likely suffer. However in web applications AJAX provides few disadvantages compared to the advantages, within the context and needs of most web applications. Besides... if AJAX doesn't help your application or site, don't use it! If it does, by all means, use away. If your target user base can benefit from it significantly more than they lose, why would you argue that, unless you have some irrational purist sense of "how the world should be".
Well, I'll reply to the anonymous troll on some points.
800x600 is pretty much the minimum of MOST websites. If you're still using 640x480 to support the 3% of people still using that resolution, then you are in the vast minority of websites. Even/. looks like crap at less than 800x600.
KISS depends on how you look at it. I find interfaces that don't cause a page reload, removing the buttons, links, etc. for a moment only to bring them back in a different relative location (as the page sets itself back to the top on a "new page") as more complex. Using several complete page loads to do simple retrieval of informational components to a web application??? Are saying THAT is KISS? If so, you may want to focus less on the "Stupid" part of that acronym.
So, you again missed the point of my post. AJAX isn't being heavily used on basic content pages. It's wider use is in web applications. I stressed that this is where is benefits, and that I agreed with the author on some of the more key points in respect to abuse of AJAX, particularly on basic "pages" of content.
I can only assume you have little real experience in the world of business applications and websites. If a theoretical 5-10% of the market share is requiring me to hold back on usability factors that help me gain a larger portion of the other 90% of users, screw the 10%!!! They're not worth the overall 20% more I could gain by having features and easy of use that competitors don't have.
So, if you think of my statement when you see static content pages being served up with ASP on the end (not that you'd ever see that on my sites, not being a big MS fan), maybe you should re-read my statement. I specifically advise against misuse/abuse of dynamic content technologies for static content. Although if you think that static "content" should be limited to "static flat files" on a file system, then you're truly ignorant of a bigger picture. Flat files have so many limitations it's ridiculous... I'd rather see that someone has a decent content management system in place that uses ASP with a backend database to store the content (more options on content management in an organization bigger than one person to manage it) than see flat HTML files sitting on some file system, requiring direct access to the production server's file system to maintain.
Which leads me to security...
No way most users will. Instead, they will simply stop buying stuff on the web or keeping sensitive stuff on their PC because they know that the black hats are going to exploit them as soon as a hole is found. Most users don't give a rat's ass about security. That is the reality - deal with it. They're not going to "upgrade their browsers" to visit your ineptly coded page when your competetition works fine in any old browser.
Wow. Do you have ANY clue? You act as though the average web user has a clue about what is and is not stored on their computer. They're NOT going to stop buying on the internet, not in significant portions. Yes, you are right, many don't give a rats ass about security... until they realize their machine is so screwed up from trojans, spyware and other things. But I think more and more people are tired of reinstalling Windows, or having to figure out how to use a spyware program, or how to make sense of them... users are already leaning towards trusting auto-updates, and find it to be worth doing to feel assured that the activities they do anyway will be "more safe".
So, if making my websites inaccessible to people who are using insecure, unpatched browsers is one more irritation for them to push them up wise up and upgrade, good. You can argue that you know what you're talking about with user trends and awareness of security, but may I ask you how many software and application security conferences and discussions you've attended? See... I actually WORK as an application security specialist... I'm quite active in the application security community and we'r
First of all, there's no need to make "special pages" when the presentational fluff can be separated in CSS so that the pure HTML still makes sense.
Depends on your definition of a "page". I'm not saying you duplicate backend content. You are making a distinction between implementations, when I'm pointing out specifically presentation. To me, the same content presented with two significantly different layouts are "different pages". You still have to do the work to support/review/debug/test the different formats.
Second, even your average poorly designed page can usually be rearranged to look OK on a small screen. Do View/Small screen in desktop Opera to get an idea of how it can look like. Really? How well does the usability of slashdot discussion threads work on my blackberry? Kinda sucks. How about Yahoo (oh wait, they have a special UI for mobiles). Sure... with SIMPLE content pages. But the point of most of my post was that simple pages with simple presentation is NOT the area that AJAX is focused on.
Mobile devices are actually becoming quite decent as long as there's not excessive amounts of Javascript (though Flash-only sites are even worse). Oh, right... you mean where the more featureful and easy to use sites are headed? Dynamic content exists and is growing. Mobiles haven't kept up. They are getting better than they were... so why not support CURRENT (if you can call a technology that is YEARS old "current") technologies like AJAX?
Oops. clicked "Reply" on the wrong post. Meant to reply on one just a little ways down that pointed out the articles focuses on pages and not addressing web applications.
I am glad that you made this statement. The whole time I'm reading the article, I kept thinking that it was basing the vast majority of its argument on false assumptions that AJAX is predominantly being used on content pages. The best use of AJAX, that I see, is with improving user interactivity with a web application. Web applications are becoming more and more of a need, and I think this is where AJAX is gaining the most ground.
The author talks about how "the page" is the basic idea that was behind the Web. Well, I hate to break it to him, but after 12+ years, things have evolved. The notion of the page has long since been an area of limitation with web applications and usability. This is why we've seen the uprising of many technologies in an effort to have more dynamic content interfaces. Users don't like having to wait for a full page load to make a small request within an application. There is complaint about the time it takes. Granted, this is largely a perception thing, but it is the reality of users.
The type of information being presented on the web has gone beyond thesis papers and simple static articles. The information that users are becoming used to is more complex, as the average user's understanding of relational information grows.
Now, the author does make some good points... but mostly these are when using AJAX in "pages". In this respect, I agree that overzealous, and possibly inexperienced web developers have gone overboard. But a good web developer considers the effects their choices have on a user, and they make the choice to go with one advantage over the loss of another. I am conscious that search engines can't necessarily index my content... so what! If I don't want it to be indexable, so be it... they can index the more "content" oriented parts of my sites, and users can then find the "features" and applications that use better technologies. The complaint about printing... please! A best practice is to take length articles and break them up into multiple pages. Ummm.. this has the same problems with printing. He kind of neglects to point that out.
As was stated previously, many of the arguments are presumptuous that the web is all about "pages". I also question the interpretation of his statistics. 1. Old browsers are likely unpatched browsers. With the vulnerabilities and security issues today, compatibility with AJAX is the least of their problems. Upgrade! 2. Mobile browsers have problems with MOST page content. Websites are designed for a minimum of 800x600 these days, if not 1024 wide. Websites still need to provide special pages to serve up content to mobile devices anyway.
So, I know this is a spoof article by the author about a previous article about Frames back in the 90's... but I think he sticks too much to the premise that existed back then, that the web was all about simple content and "pages", without recognizing that the information complexity has evolved, and that "applications" are becoming more and more necessary for usability of the information. Yes, improvements are needed. Yes, back button support should be support (but not required). Also as was said in an earlier post, many of the problems are not an issue with just AJAX, and many are an issue with the lack of understanding of the effects of the choices made when using ANY new technology.
As also expressed by others, I don't think blogs are going anywhere. They will evolve. What I see is that PodCasts are continuing to grow, and in a way are an extension of blogs. They don't just extend into the written media's domain, but also radio and soon television/video (not yet enough momentum on this yet).
Well, I'm not so sure about that. Almost every Mac user I know (especially the less technical ones) apply the Software Updates to OS X quite regularly (ie. when they pop-up).
However, I actually know far more people skeptical and very hesitant to apply their Windows updates because of fear of it ruining their system. Heck, entire corporations banned SP2 until the last minute. Now MS is actually saying that SP2 needs to be applied. I just had a big meeting on the upgrade to SP2.
So, while I admit their are Mac users that do not apply updates (stupid them), I see it to be far more common (percetage wise) with the Windows users to not apply patches. In each case, the user is at fault... but I wouldn't go using that metric as a comparison of "typical" users, if I were you.
Wow... you need to meet more Linux geeks. MOST that I know have a Mac. They (including myself) still use Linux in some server setups, but for personal use, a Mac is just so much easier while giving me almost everything I want, and then some.
> In this case, although I'd hope that Apple would > realize that they benefit from this type of > interest ('reporting) in the platform, Apple is > fully within thier rights. But I will say, with > such rumor sites to see what's coming down the > pipe, I might have left the Mac platform to the > wind.
While I agree that it may help in some of the hype of the Apple and Mac brands, the primary concern is the stock price. Early release of information allows for competitors to rally against them, market their own products in force, and generally decrease the hype that Apple would have generated in its controlled manner at the time of release. The problem is that the stock of the company (ie. the public value of the company) suffers by leaks of information before they are ready for production and final announcement.
While this helped me in buying up some stock at a slightly lower price than I could have otherwise, it still is wrong. At first, I was kind of against Apple on this, and thought they should just let it go. However, in rethinking it (especially as a share holder), Apple needs to find that leak and plug it. They have a "spy" in their midst and needs to get rid of them. This may be internal, a vendor employee they contract with, whatever... but its a risk to their business to have someone who has no issues with violating their NDA.
Company B is NOT using Company A in its advertisement. It is simply defining "location" by the terms. In your analogy B is putting the trademark within the ad and USING it.
A better analogy would be if B went to an advertising agency that handles ad placements on billboards, and says "put me next to as many Company A locations as possible". The ad agency searches their databases finds Company A's locations (which would be equiv to search terms in this realm) and places Company B's ads there. No trademark infringement.
The knock-offs, as you put it, are not USING the term in their ad. They are simply asking Google to place THEIR ad in a "location" as defined by search terms within the virtual world of search engine web browsing.
The success of almost ANY company will often bring attention to a sector, and cause competitors to ALSO do well. Because you are competing for the same space does not mean that success does not also bring attention to your competition by association of the business sector. That's business!
When someone stumbles on a great idea, look at how many people JUMP on the basic idea and "copy" it within legal limits. The initial company still does well... the market will then dilute. That's business!
Perhaps we should just restrict our kids from watching TV until they're out of the house! That will get the attention of the big TV execs. Hell, the kids might actually get out of the house, or learn how to read a book again.
Don't get me wrong, when I was a kid, I was a TV junky, but it seems that it's getting worse today. Gotta wonder what long term effect this will have on society and/or culture. Someone already mentioned how business is even reflecting short-term gains, and ignoring longer term stability. What's influencing what? Hmmmm.
Right let's just build 10 multi-million dollar landers simply for the purpose of crashing into the earth in an approximation as to what happened 10's of millions of miles away on a planet with entirely different gravity, after traveling long distances bombarded by radiation.
That will tell us exactly what might have happened!
Don't you think they ran test scenarios on earth BEFORE launching? I agree testing on earth is good to work out what you can predict. The point of a black box is to capture real-world data in the event that something occurs that DIDN'T happen in tests and predictions.
But there'd be some information to help ensure that next time the money spent on the project isn't flushed down the crater. The point of such a system isn't for recovery. It's to learn and correct mistakes for the future, based on what happened. The black box in an air plane isn't to bring back what was lost in a crash. It's to understand what went wrong, and make sure corrections are made for the future.
Go with the cross-eyed approach, if you can get it to work for you. I never liked the red/blue glasses method. I tried that too... but the colors just ruin it for me. The cross-eyed method is pretty cool once you get your eyes to focus on it.
I had mine. Came with a DVD I got on Mars. Although, the red/blue 3D method sucks royally! Never liked it. The best 3D glasses I've seen are the polarized ones that I first saw in Captain EO at Disney Land.
The cross-eyed method is the best in this situation, IMHO.
Who knows. One major difference is that many are going with video detection. Minority Report was more complex, with the golves. In stead of simple 2D image detection, it could draw from more, 3D complex gestures.
I played with this game. It was okay. Definitely shows some potential, but I really see user interface limitations. I kept hitting the wrong button when I was reaching for another. It was neat. I guess we'll see if/when games of this nature develop.
Hmmm... Once I have the destination plugged in (which I do before I get in the car), my hand-held (which isn't in my hand at the time), tells me when to turn and gives me warnings as I approach an intersection or offramp.
Many hand-held GPS mapping systems I've used have the ability to tell you direction.
I'm not knocking OnStar, but portable devices can accomplish many of the same features for a flat cost, not a subscription fee.
Look at the original iMacs. I expect they'll go along these lines with certain shades of colors. They'll probably be similar to the colors used in the commercials. I don't think it's brand dilution. A ton of people put colored skins on them anyway. I think they'll push for form and button layout to carry the "branding".
Well, these are still unconfirmed rumors... so time will tell.
Slashdot Mirror
The issues that were stated about PHP, really apply to ANY language. SQL injection flaws can existing in PHP, Perl, Java, and .NET.
The reason you don't find much about "secure PHP", is that it's not just a PHP issue. You might want to read sites like OWASP (http://www.owasp.org/) and Threats&Countermeasures (http://www.threatsandcountermeasures/). There are plenty of others.
The thing is, it's not as simple to write a "how to" when it comes to security issues. It's a bit more abstract than that, if you try to encompass the whole concept. For example... SQL injection flaws:
Never take anything string of data that came from the user and stick it into the SQL string you are generating, without checking it for a few basic things. Escape ANY special characters that has meaning in SQL (quotes, semi-colons, etc). Quotes are your biggest threat. Quick example:
You are building this string:
"SELECT count(*) from users where username = '$username'";
Now imaging $username came directly from user input, and I typed:
'; delete from users; --
That results in a query like:
SELECT count(*) from users where username = ''; delete from users; --'
Assuming your driver or database doesn't limit single "prepare" or query executes to only one statement, it will run the select, and then delete all users, commenting anything else you would have had after that. Scary, huh?
The best thing is to look for API's that support prepare and execute of a query separately, where you place "?" placeholder in the SQL query string, and then give the data to the execute method. The execute method generally handles all escaping needs to treat it as "data". Clear separation of command and data. Of course, that's not 100%, as you could have a "LIKE" comparisson in your WHERE clause. A "%" in the data is still treated as a wildcard, so you would still have to be sure to escape that in variables you are using with where clause values.
So, there's your simple brief tutorial... but the whole way of thinking is different if you consider all the vulnerabilities. Read OWASP's top 10 list, and think about you are providing information and using information to/from the user. These are your attack surfaces.
Cheers,
Your friendly neighborhood Application Security Specialist
I don't know. After 12+ years websites that have learned to use technology effectively have become MUCH better. I don't deny there is a lot of cruft and crap out there as well. But because there are idiots in the world doesn't mean the genius (not necessarily claiming this for myself) that has emerged don't exist.
It seems that almost everyone that argues against me on this keep bringing up simple, static, content pages as their support. But if you people bother reading my postwith the context of THAT POST (as opposed to the bucket your charged up brain has placed it into), you'd see that I am focusing on Web Applications. These are not pages that generally need to be bookmarked. These are not pages that NEED a back button.
I mean, bitch about the limitations of Banking websites all you want. The dynamic content is what allows you to HAVE a banking website. The limitations have little to do with the JavaScript or AJAX. The limitation that you can't go BACK on those pages has to do with general state and flow management. And the "Back button" issue that you mention has nothing to do with the "Back button" issue the article's author mentioned. Your back button issue has existing since the beginning of dynamic web pages/web applications. It is specifically THESE limitations that have driven technologies like AJAX. I mean, if you process a transaction for a transfer, and then try to hit "back", bringing you back to a processing page and the interface just lets you... you're more likely to make a mistake of retransferring money (duplication). The choice your bank made is to not let you go back. Others handle it by just not processing a resubmit on a transaction, but let you back button all you want. Another option would be to use AJAX within the scope of a transfer transaction "application". Hitting the back button would take you to the page you were at before the transfer request. This would actually be idea, since loading into the middle of a completed transaction's form is simply "invalid use".
Hmmm... I think your issue with your bank's "back" button restrictions is actually an argument FOR something like AJAX!
So, once again... your arguments are not with AJAX or similar technologies. Your argument seems to be against poorly implemented applications. The back button issue you descrobe, not allowing simultaneous windows, etc... these are not issues with AJAX or similar technologies. These are issues with the back-end session and transaction management of the application. But since much of that level of backend development isn't inherant to existing frameworks, it becomes a lot more development (and QA/testing) to support. AJAX could actually help alleviate your specific issues, by reducing the client behavior that causes banks like yours to be so restrictive.
-Alex
Not to burst your bubble or pick nits here, but once you're talking about maintaining sessions in the application, that by definition is not part of the underlying "protocol" of HTTP. That is a layer above. The HTTP request object (environment, whatever it's called in what you use) is NOT part of the HTTP protocol; it simply uses HTTP, but adds additional abilities.
Of course, I'm not supporting the previous post... just pointing out a flaw.
Actually, as I said, it's perceived time. The blinking and redrawing of the page in an application setting is perceived as taking longer for the user. Whether this is wait time, or time to orient themselves from page to page is irrelevent. Actually, most of the pages of the sites I use are very simple. They do load quite quickly, and they are not overwhelmed with Javascript. One point I agree with the author on is "sparingly".
Valid point. I still don't care about them. They're too small a userbase to give up the benefits to the rest of the users who are not so irrationally anti-client-side scripting. Again... I think sites that have an abusive level of scripting are quite annoying. Not once in my arguments have I said to embed JavaScript like mad for every link, image, field, form, and character on the page. But there is much to be gained from a WEB APPLICATION perspective. This is where AJAX really does shine. Pages don't have to reload, even though you're on the same "interface", moving your buttons relative to page location (any scrolling down), causing you to need to reorient yourself on the page.
800x600 is pretty much the minimum of MOST websites. If you're still using 640x480 to support the 3% of people still using that resolution, then you are in the vast minority of websites. Even
KISS depends on how you look at it. I find interfaces that don't cause a page reload, removing the buttons, links, etc. for a moment only to bring them back in a different relative location (as the page sets itself back to the top on a "new page") as more complex. Using several complete page loads to do simple retrieval of informational components to a web application??? Are saying THAT is KISS? If so, you may want to focus less on the "Stupid" part of that acronym.
So, you again missed the point of my post. AJAX isn't being heavily used on basic content pages. It's wider use is in web applications. I stressed that this is where is benefits, and that I agreed with the author on some of the more key points in respect to abuse of AJAX, particularly on basic "pages" of content.
I can only assume you have little real experience in the world of business applications and websites. If a theoretical 5-10% of the market share is requiring me to hold back on usability factors that help me gain a larger portion of the other 90% of users, screw the 10%!!! They're not worth the overall 20% more I could gain by having features and easy of use that competitors don't have.
So, if you think of my statement when you see static content pages being served up with ASP on the end (not that you'd ever see that on my sites, not being a big MS fan), maybe you should re-read my statement. I specifically advise against misuse/abuse of dynamic content technologies for static content. Although if you think that static "content" should be limited to "static flat files" on a file system, then you're truly ignorant of a bigger picture. Flat files have so many limitations it's ridiculous... I'd rather see that someone has a decent content management system in place that uses ASP with a backend database to store the content (more options on content management in an organization bigger than one person to manage it) than see flat HTML files sitting on some file system, requiring direct access to the production server's file system to maintain.
Which leads me to security...
Wow. Do you have ANY clue? You act as though the average web user has a clue about what is and is not stored on their computer. They're NOT going to stop buying on the internet, not in significant portions. Yes, you are right, many don't give a rats ass about security... until they realize their machine is so screwed up from trojans, spyware and other things. But I think more and more people are tired of reinstalling Windows, or having to figure out how to use a spyware program, or how to make sense of them... users are already leaning towards trusting auto-updates, and find it to be worth doing to feel assured that the activities they do anyway will be "more safe".
So, if making my websites inaccessible to people who are using insecure, unpatched browsers is one more irritation for them to push them up wise up and upgrade, good. You can argue that you know what you're talking about with user trends and awareness of security, but may I ask you how many software and application security conferences and discussions you've attended? See... I actually WORK as an application security specialist... I'm quite active in the application security community and we'r
Depends on your definition of a "page". I'm not saying you duplicate backend content. You are making a distinction between implementations, when I'm pointing out specifically presentation. To me, the same content presented with two significantly different layouts are "different pages". You still have to do the work to support/review/debug/test the different formats.
Oops. clicked "Reply" on the wrong post. Meant to reply on one just a little ways down that pointed out the articles focuses on pages and not addressing web applications.
I am glad that you made this statement. The whole time I'm reading the article, I kept thinking that it was basing the vast majority of its argument on false assumptions that AJAX is predominantly being used on content pages. The best use of AJAX, that I see, is with improving user interactivity with a web application. Web applications are becoming more and more of a need, and I think this is where AJAX is gaining the most ground.
The author talks about how "the page" is the basic idea that was behind the Web. Well, I hate to break it to him, but after 12+ years, things have evolved. The notion of the page has long since been an area of limitation with web applications and usability. This is why we've seen the uprising of many technologies in an effort to have more dynamic content interfaces. Users don't like having to wait for a full page load to make a small request within an application. There is complaint about the time it takes. Granted, this is largely a perception thing, but it is the reality of users.
The type of information being presented on the web has gone beyond thesis papers and simple static articles. The information that users are becoming used to is more complex, as the average user's understanding of relational information grows.
Now, the author does make some good points... but mostly these are when using AJAX in "pages". In this respect, I agree that overzealous, and possibly inexperienced web developers have gone overboard. But a good web developer considers the effects their choices have on a user, and they make the choice to go with one advantage over the loss of another. I am conscious that search engines can't necessarily index my content... so what! If I don't want it to be indexable, so be it... they can index the more "content" oriented parts of my sites, and users can then find the "features" and applications that use better technologies. The complaint about printing... please! A best practice is to take length articles and break them up into multiple pages. Ummm.. this has the same problems with printing. He kind of neglects to point that out.
As was stated previously, many of the arguments are presumptuous that the web is all about "pages". I also question the interpretation of his statistics. 1. Old browsers are likely unpatched browsers. With the vulnerabilities and security issues today, compatibility with AJAX is the least of their problems. Upgrade! 2. Mobile browsers have problems with MOST page content. Websites are designed for a minimum of 800x600 these days, if not 1024 wide. Websites still need to provide special pages to serve up content to mobile devices anyway.
So, I know this is a spoof article by the author about a previous article about Frames back in the 90's... but I think he sticks too much to the premise that existed back then, that the web was all about simple content and "pages", without recognizing that the information complexity has evolved, and that "applications" are becoming more and more necessary for usability of the information. Yes, improvements are needed. Yes, back button support should be support (but not required). Also as was said in an earlier post, many of the problems are not an issue with just AJAX, and many are an issue with the lack of understanding of the effects of the choices made when using ANY new technology.
-Alex
Amen. Previous poster really needs to expand his definition to one that has existed for a very long time.
As also expressed by others, I don't think blogs are going anywhere. They will evolve. What I see is that PodCasts are continuing to grow, and in a way are an extension of blogs. They don't just extend into the written media's domain, but also radio and soon television/video (not yet enough momentum on this yet).
I seriously doubt they're going anywhere!
-Alex
Well, I'm not so sure about that. Almost every Mac user I know (especially the less technical ones) apply the Software Updates to OS X quite regularly (ie. when they pop-up).
However, I actually know far more people skeptical and very hesitant to apply their Windows updates because of fear of it ruining their system. Heck, entire corporations banned SP2 until the last minute. Now MS is actually saying that SP2 needs to be applied. I just had a big meeting on the upgrade to SP2.
So, while I admit their are Mac users that do not apply updates (stupid them), I see it to be far more common (percetage wise) with the Windows users to not apply patches. In each case, the user is at fault... but I wouldn't go using that metric as a comparison of "typical" users, if I were you.
Wow... you need to meet more Linux geeks. MOST that I know have a Mac. They (including myself) still use Linux in some server setups, but for personal use, a Mac is just so much easier while giving me almost everything I want, and then some.
-Alex
So, then why is slashdot leaving a false claim (despite the small editor's note) on the top of their main page???
While I'm totally NOT an M$ fan, it is kinda lame to have that claim shown to be false on the main page.
-Alex
> In this case, although I'd hope that Apple would
> realize that they benefit from this type of
> interest ('reporting) in the platform, Apple is
> fully within thier rights. But I will say, with
> such rumor sites to see what's coming down the
> pipe, I might have left the Mac platform to the
> wind.
While I agree that it may help in some of the hype of the Apple and Mac brands, the primary concern is the stock price. Early release of information allows for competitors to rally against them, market their own products in force, and generally decrease the hype that Apple would have generated in its controlled manner at the time of release. The problem is that the stock of the company (ie. the public value of the company) suffers by leaks of information before they are ready for production and final announcement.
While this helped me in buying up some stock at a slightly lower price than I could have otherwise, it still is wrong. At first, I was kind of against Apple on this, and thought they should just let it go. However, in rethinking it (especially as a share holder), Apple needs to find that leak and plug it. They have a "spy" in their midst and needs to get rid of them. This may be internal, a vendor employee they contract with, whatever... but its a risk to their business to have someone who has no issues with violating their NDA.
Just my $0.02.
Correct statement, bad analogy.
Company B is NOT using Company A in its advertisement. It is simply defining "location" by the terms. In your analogy B is putting the trademark within the ad and USING it.
A better analogy would be if B went to an advertising agency that handles ad placements on billboards, and says "put me next to as many Company A locations as possible". The ad agency searches their databases finds Company A's locations (which would be equiv to search terms in this realm) and places Company B's ads there. No trademark infringement.
The knock-offs, as you put it, are not USING the term in their ad. They are simply asking Google to place THEIR ad in a "location" as defined by search terms within the virtual world of search engine web browsing.
-Alex
Welcome to the world of business!
The success of almost ANY company will often bring attention to a sector, and cause competitors to ALSO do well. Because you are competing for the same space does not mean that success does not also bring attention to your competition by association of the business sector. That's business!
When someone stumbles on a great idea, look at how many people JUMP on the basic idea and "copy" it within legal limits. The initial company still does well... the market will then dilute. That's business!
-Alex
Perhaps we should just restrict our kids from watching TV until they're out of the house! That will get the attention of the big TV execs. Hell, the kids might actually get out of the house, or learn how to read a book again.
Don't get me wrong, when I was a kid, I was a TV junky, but it seems that it's getting worse today. Gotta wonder what long term effect this will have on society and/or culture. Someone already mentioned how business is even reflecting short-term gains, and ignoring longer term stability. What's influencing what? Hmmmm.
-Alex
Right let's just build 10 multi-million dollar landers simply for the purpose of crashing into the earth in an approximation as to what happened 10's of millions of miles away on a planet with entirely different gravity, after traveling long distances bombarded by radiation.
That will tell us exactly what might have happened!
Don't you think they ran test scenarios on earth BEFORE launching? I agree testing on earth is good to work out what you can predict. The point of a black box is to capture real-world data in the event that something occurs that DIDN'T happen in tests and predictions.
-Alex
But there'd be some information to help ensure that next time the money spent on the project isn't flushed down the crater. The point of such a system isn't for recovery. It's to learn and correct mistakes for the future, based on what happened. The black box in an air plane isn't to bring back what was lost in a crash. It's to understand what went wrong, and make sure corrections are made for the future.
-Alex
Go with the cross-eyed approach, if you can get it to work for you. I never liked the red/blue glasses method. I tried that too... but the colors just ruin it for me. The cross-eyed method is pretty cool once you get your eyes to focus on it.
-Alex
I had mine. Came with a DVD I got on Mars. Although, the red/blue 3D method sucks royally! Never liked it. The best 3D glasses I've seen are the polarized ones that I first saw in Captain EO at Disney Land.
The cross-eyed method is the best in this situation, IMHO.
-Alex
Who knows. One major difference is that many are going with video detection. Minority Report was more complex, with the golves. In stead of simple 2D image detection, it could draw from more, 3D complex gestures.
I played with this game. It was okay. Definitely shows some potential, but I really see user interface limitations. I kept hitting the wrong button when I was reaching for another. It was neat. I guess we'll see if/when games of this nature develop.
-Alex
And not to shoot myself in the foot by bogging down all feed....
:)
Here's a bunch of feeds (mostly RealMedia) for live NasaTV on the web.
-Alex
Hmmm... Once I have the destination plugged in (which I do before I get in the car), my hand-held (which isn't in my hand at the time), tells me when to turn and gives me warnings as I approach an intersection or offramp.
Many hand-held GPS mapping systems I've used have the ability to tell you direction.
I'm not knocking OnStar, but portable devices can accomplish many of the same features for a flat cost, not a subscription fee.
-Alex
Look at the original iMacs. I expect they'll go along these lines with certain shades of colors. They'll probably be similar to the colors used in the commercials. I don't think it's brand dilution. A ton of people put colored skins on them anyway. I think they'll push for form and button layout to carry the "branding".
Well, these are still unconfirmed rumors... so time will tell.
-Alex