Such is the story of Google Dart.  Early information about the new programming language was leaked a month ago.  What raised concerns in the IT world, though, was an internal memo stating that Google had the long term goal of using Dart to replace Javascript.  To a programmer, that’s not too far removed from hearing that someone has the long-term goal of replacing English.

Google stepped back a bit and stated that there’s no reason that Javascript has to be headed to the trash bin.  In all fairness, what was posted was likely just optimism about its acceptance as opposed to antagonism against Javascript or anything else.  Given the programming world’s reaction, that’s a good thing.  Not only is Javascript largely considered to be thriving, but some feel that it is more relevant than ever.

The only constant is change

Nevertheless, Google has stated that there are problems with Javascript that are too ingrained in its design to be fixed from within.  Given its age (it was introduced when Bill Clinton was in his first term), it’s reasonable to suppose that a lot about it might not be keeping up with the times, especially given the recent explosion of portable viewing platforms.

Moreover, Google is now about as famous for its alternate services like Google Earth as it is for its search engine.  Even a modest increase in efficiency in the programming back-ends used by these services alone would have a multiplier effect that’s hard to even calculate.  For the rest of the web, Google is helping the transition by releasing a compiler that will translate Dart code into Javascript for any browser or application that is not yet capable of running it.

What are the goals of Dart?

On their technical specifications sheet, Google outlines the following objectives for the Dart programming language:

• Create a programming language that is structured, yet flexible.
• Give Dart a “familiar and natural” feel.  Some have already noted its similarity to Javascript.
• Make Dart appropriate for the full range of web-capable devices.  This might be one of the items that pushed the need for a new language over the tipping point.
• Create a language that launches quickly and efficiently.  This is more important than it seems: as standards and devices continue to splinter, efficiency in compatibility is going to become a high priority.
• Make sure there is a language that can work across all browsers.  This can be considered a sister idea to that of ensuring multiple device compatibility.  The number of browsers right now is higher than it has ever been, and shows no sign of stopping.  Look at Amazon’s inclusion of a new browser in the Kindle Fire, as an example.

Also listed in this document are the specific programming problems Dart attempts to address.  Paraphrased here, they are:

• Dart will attempt to address the problem whereby small programs swell into larger ones that cannot easily be broken back up into smaller components.
• Dart will attempt to address the conflict between static and dynamic languages (though this sheet doesn’t make clear what exactly their remedy is).
• Dart will attempt to address the problem whereby few languages right now are designed to work well both with client and server specifications.
• Dart will attempt to make it easier for programmers to take over each other’s work, by addressing the problem in which interactions with different parts of an application are put more into the code comments than in the code itself.
• Dart will attempt to reduce the cumbersome work associated with context switching.

OK, those seem like good ideas.  What does the audience have to say?

From our surveying, the biggest problem that the IT world has with this new programming language is its mere existence.  The fact that Google has done work to make sure it can be plugged in as many places as possible right from the start doesn’t seem to have mollified them.  This is one more language to learn, and who knows whether or not the time invested in it will be well spent.

The next biggest concern after that was with Google’s approach to its development.  Working with the greater community in developing standards is at this point considered both wise and honorable.  Google says that it is going to, but the initial development sketches and basic coding structures were authored in-house, outside the view of third-party eyes.  Google defended this position, stating that it was necessary to make sure that initial plans didn’t spin too far out into chaos.

A worrisome feelin

This doesn’t dull the feeling that some are getting that Google is becoming another Microsoft, creating “standards” that it single-handedly pushes onto the world.  Given that Google is about as big as Microsoft, it’s hard to see this worry as unwarranted.

Is it fair, though?  That’s a more difficult case to make.  As much as Google has done some things that have not sat well with the internet world, the general consensus is that it has never strayed too far from its “Don’t be evil” motto.  Recall recently, for example, their decision to pull out of China in protest over that government’s information control requirements.

Our verdict: Worth a look

The bottom line is that, like it or not, Google now maintains a position in which, if they determine that something needs to be changed on the web, and they put the effort into doing it, it’s a good bet that they’ll succeed.  Gmail replaced Hotmail, Google Maps replaced Mapquest, Chrome is replacing Mozilla, and Google+ is making a serious bid to replace the mighty Facebook.

Let’s also remember that no one has actually worked with this language yet.  The devil is in the details.  It may be that when all is said and done, Dart becomes as beloved as, say, Perl.  One thing is for certain, though, and that is that Google is putting a lot of energy into Dart’s development and release.  If they say that Dart has the potential to replace Javascript, it’s ill-advised to not consider that they might be right.

Related posts:

• April 13, 2009 – The Vulnerability of AJAX Applications
• April 9, 2009 – Cross Site Scripting: The Underestimated Website Attack
• April 2, 2009 – Enter the World of Mobile Domains
• December 29, 2008 – Browsers Aiding in Website Attacks

What Makes AJAX So Different?

The purpose AJAX is to enhance speed, interactivity and usability.  The combination of technologies provide a more feature-rich, user-friendly experience.  Instead of loading the requested page at the start of the session, an AJAX engine scripted in Javascript is loaded.  This engine acts a middlemen between the user and the web page, enabling communication between the client and server.  The end result of this interaction is noticed almost instantly.  When making a request to an AJAX page, you may see individual elements of the page update before your eyes (asynchronously) rather than waiting for the page to load completely.

The AJAX Disadvantage

AJAX is a very powerful weapon but one must be aware of the security vulnerabilities that exist.  Some developers have the misconception that AJAX applications offer tighter security because it is believed that the server-side script can’t be accessed without the rendered user interface, which is simply the AJAX-based page.  Unfortunately, this couldn’t be further from the truth.  The mere factor of increased interactivity within the application results in increased text, XML and HMTL network traffic.  This in turn, could lead to the exposure of back-end applications that may have not vulnerable otherwise.  Without adequate server-side protection, it could also give unauthenticated users the ability to manipulate privilege configurations.

Another AJAX vulnerability is associated with the process it utilizes to formulate server requests.  Its engine uses Javascript to capture user commands and convert them into function calls.  These function calls are transmitted to the server in plaintext, making them visible to savvy eavesdroppers.  This could allow an intruder to easily access database fields that contain user login credentials and other critical variables that can be manipulated for malicious gain.  With this information, a hacker can victimize AJAX functions all without directly creating specific HTTP requests to the server.  Coupled with the known vulnerabilities of Javascript, AJAX applications are susceptible to attacks like cross site scripting and similar threats that plague scripts created by other development technologies.

While the evolution of web technologies has enabled applications to enjoy more responsive, interactive, efficient functionality, they also increase the vulnerabilities developers and businesses face on a daily basis.  The growing prevalence of AJAX applications has considerably broadened the threat window, essentially giving hackers a greater opportunity to compromise sensitive data and thieve invaluable assets.  For this reason, developers must stop living under a false sense of security and take every measure possible to ensure that their AJAX applications are completely secure.

Related posts:

• September 23, 2011 – Keep Your Site Safe – Learn What Not to Do
• September 21, 2011 – How To Deal With A Possible Intruder On Your Server
• September 6, 2011 – Performing IP Filtering Through cPanel – A Brief Tutorial
• July 29, 2011 – Is SSL Essential for eCommerce Sites?
• July 22, 2011 – LulzSec’s Hacking Career Slated to End
• March 17, 2009 – Practicing FTP Security
• February 19, 2009 – Fighting Back Against Website Attacks
• January 20, 2012 – Data Backup and Recovery Solutions
• January 3, 2012 – Battle of the Giants: Linux and Windows Compared
• December 14, 2011 – Avira Antivirus Features

Cross site scripting is one of several threats that uses vulnerable applications to exploit a website.  The major difference with XSS is that it does not have the ability to directly steal sensitive information from a back-end database.  Unfortunately, this has led several webmasters to believe that XSS isn’t a high-risk threat.  Ironically, many have gone on to learn the hard way, forced to suffer through public defacement and embarrassment.

The Consequences of Cross Site Scripting

The damaged inflicted by XSS exploits is widely documented.  There have been cases where large corporate websites were hacked by this attack with the results almost always being catastrophic.  Cross site scripting is used to achieve a wide variety of malicious goals and below are some of the most common:

DoS (Denial of Service) Attacks

Accessing sensitive, unauthorized information

Modifying browser and security settings

Spying on victims’ computing activities

Website defacement

Identity theft

The consequences of a successful XSS attack can be crippling for businesses of any size.  Security vulnerabilities in some of the most popular websites have led to the theft of credit card numbers and other identifying customer information.  Consumers have been duped into clicking links that direct them to a rogue site purporting as a legitimate business.  Unaware of the malicious ploy, the customer enters their details into the application, handing them right over to the hacker.  If you are the cause of your customers being compromised, they will rightfully lose trust in your site’s security, a situation that could lead to liability issues and ultimately the loss of your business.

Educate Yourself About Cross Site Scripting

The increasing number of successful attacks is proving that large enterprises are just as vulnerable as organizations working on a smaller budget.  What this really shows is that there is not necessarily a lack of resources, yet a lack of awareness within businesses at all levels.  Numerous security reports reveal that a great number of applications on the web are vulnerable to XSS.  Sadly, is not uncommon to find website owners putting their customers and business at risk by not practicing sound security.

On the surface, cross site scripting may not seem as severe as other threats but that is what makes it so dangerous.  This is one exploit far too many webmasters are not prepared for.  Until more become aware, the problem will only escalate and continuously claim new victims.  Unless you want a disaster on your hands, take every measure you can to ensure that your web applications are secure.

Related posts:

• December 29, 2008 – Browsers Aiding in Website Attacks
• October 20, 2011 – Google Dart – Ready or not, a new Language Arrives
• October 5, 2011 – When Markup Languages Attack
• September 10, 2011 – Control Panels – What are Their Limits?
• May 30, 2011 – Google Chrome Browser Cracked
• October 27, 2010 – Static HTML Pages vs CMS Generated Sites
• June 16, 2010 – Protecting Your Site from DDoS Attacks
• May 5, 2010 – Healthy Website Security Practices
• November 6, 2009 – Use Captcha To Keep Spammers At Bay
• September 14, 2009 – VPS Web Hosting – Do Your Really Need a Control Panel?

What are Mobile Domains?

The mobile domain is a fairly new concept on the domain name market.  As wireless technology becomes more tightly integrated with the internet, webmasters are increasingly trying to target a new audience – mobile web surfers.  If you are looking for innovative ways to increase your visibility, you may want to consider a domain name strategy centered around the fast growing traffic surfing the mobile web.

In 2004, a case was made for adopting DotMobi as a new Top Level Domain.  In 2006 .mobi became a reality, now standing alongside TLDs like .com and .net.  The major difference is that this extension is exclusive to delivering the internet to mobile devices.  This is not to say that .coms and other popular extensions can’t be viewed over a mobile device.  The advancements in web technology essentially means that any website can be developed for mobile browsing.

Interoperability and Usability Problems

While any given domain can be optimized to provide the internet experience via a PC or mobile phone, integrating the technologies isn’t as easy one may think.  Despite all the advancements, most mobile devices do not support key web elements such as Javascript or cookies.  And because 3G is still only present in a small number of devices, the mobile internet as a whole lacks the speed needed to surf the web effectively.  For this reason, the development of mobile websites must be handled on a separate scale for now.

The Bright Side

The issues of incompatibility does not mean that the technologies will never work in perfect harmony.  For now, you may want to consider leaving your existing website as is and then optimizing another for mobile internet traffic, giving yourself the opportunity to embrace audiences on two separate webs.  Now is probably the best time since using the mobile internet to increase visibility is a new strategy altogether.

One should keep in mind that mobile domains and the mobile internet are both such new concepts that they will require some fine tuning in order to catch up to the much more mature internet.   So, even though mobile technology has come a long way, there is still a while to go before we truly enjoy a seamless browsing experience like we do on a PC.

Mobile domains represent an exciting period for the internet world.  Technology has taken us so far yet we have barely even scratched the surface.  When it comes to mobile web surfing, the possibilities are endless.

Related posts:

• December 14, 2011 – Avira Antivirus Features
• October 20, 2011 – Google Dart – Ready or not, a new Language Arrives
• September 5, 2011 – Premium Domain Names: What Are They?
• July 18, 2011 – Domain Name Expansion Expected to Create Major Problems
• April 22, 2011 – Becoming a Domain Speculator with No Experience
• March 21, 2011 – A Review of Social Commerce Trends
• January 19, 2011 – How to Find the Cheapest Domain Names
• September 18, 2010 – .CO Domains – Frequently Asked Questions
• September 7, 2010 – How to Pick the Right Domain Name Extension
• August 5, 2010 – .CO Domains Gaining Momentum and Google Support

Despite the fact that several improvements have been made, none of the top web browsers are completely secure.  Because of this, many web security experts are projecting that website attacks will continue to be an issue.  The combination of enhanced functionality and the lack of adequate security implementations have left a number of browsers vulnerable to sophisticated attacks.  Some researchers are saying that the increasing number of exploits is the direct result of Web 2.0 technologies and advanced web hosting features.

Evolution in Technology Opens Doors to Further Threats

Things were fairly innocent in the early days of the internet when static pages were prevalent, before technologies such as JavaScript and Active X came into play.  Today’s World Wide Web is dominated by dynamic web-based applications and complex server-side scripting languages, factors that enable browsers to be used in various ways to exploit websites.  Gary McGraw of Cigital, a software security company, agrees that these feature-rich designs have made browsers far less secure, stating that they are structured more like complete operating systems.

This past September Google released Chrome, its new web browser which was immediately faced with stiff competition in the form of Microsoft Internet Explorer, Mozilla Firefox, Apple Safari and Opera.  While internet users have a wide variety of browsers to choose from, the options are still limited in terms of security, including Chrome.  Experts contend that the browser war of who can out do one another in the feature department is what ultimately leads to these security vulnerabilities.

Though quite serious, the security issues associated with today’s popular web browsers are not attributed to a lack of effort.  Some say that developers are doing all they can but when considering the fact that website attacks such as cross site scripting and cross site request forgery are typically the result of design, these flaws tend to be much harder to fix than bugs found in software code.  Observers suggest that the vulnerabilities are not going to disappear entirely but do stress that browser developers can do more to enhance security.

In general, development teams only have a little time to address browser vulnerabilities before the hacker community is able to discover them.  Developers are being encouraged to practice browser security just like those who make other software products.  This is extremely important as the major web browsers literally have hundred of millions of users.  One solid approach towards website security is standardized authentication, something that would need to be addressed by system administrators.  Another recommendation is for browser developers to design products that alert users when they are being directed to intranet zones such as localhost or RFC1918 as attackers are increasingly targeting internal devices.  Security firms have also predicted that the manner in which data is handled when requests are made between a browser and website should play a critical part in future designs.

Related posts:

• November 26, 2009 – Authentication Hacking: Is Your Site Vulnerable?
• December 6, 2011 – Comparing The Best Web Browsers
• May 30, 2011 – Google Chrome Browser Cracked
• October 16, 2009 – Major Threats to Business Website Security
• April 9, 2009 – Cross Site Scripting: The Underestimated Website Attack
• January 13, 2009 – How to Find Secure Shared Hosting
• October 20, 2011 – Google Dart – Ready or not, a new Language Arrives
• June 28, 2010 – Shared Hosting and Site Downtime
• February 1, 2010 – False User Authentication: A Common Hacking Tactic
• December 30, 2009 – Five Simple Website Safety Tips