When the dot.com boom first started, it was driven by investors who saw the potential of the new frontier of the web. As companies started pouring money, other companies quickly followed suit in an attempt to stay even with their competitors. Unfortunately, as we all know, this didn’t work out the way many people envisioned which led to the dot.com crash. However, there were several companies that learned some valuable lessons and would become part of the framework ofweb 2.0

If someone were to analyze most of the successful sites that are on the internet today, there are a few factors that they all have in common. Chief among these factors is the fact that they are user driven; meaning that use of the website is the primary motivation for visitors not shopping. Even large shopping sites include a high amount of user interaction through forums, blogs, and reviews. By providing this usability these sites ensure sticky visitors, which is the holy grail of any successful internet business.

The second common factor that most successful sites have in common is some form of social media. While there are many sites devoted solely to social media, any site that expects to be successful provides some way for their visitors to engage in the social experience such as profiles, messaging systems and other common social media applications. By creating a sense of community and combining it with usability sticky customers almost become a certainty and that is the core of web 2.0.

In the end, the term web 2.0 simply represents a different way of doing business on the internet. However, while the concept is simple, its execution can be quite difficult. Yet if someone is serious about being competitive on the internet, the principles of web 2.0 must be learned and used effectively, or there is little chance of any real success.

Comments

The problem with the world today is that we all try to jump on an online bandwagon without really seeing where it’s going. As the usage numbers stack up, we pile on, determined to hang on for the ride, whereever the destination might be. It remains to be seen if Facebook can avoid the fate of the online community platform. There’s a lot of headstones in this particular cemetary, including Orkut, Friendster and MySpace (sure, MySpace is still breathing, but barely). I’ve been in a few meetings recently where everybody is talking about how to tap into social networking. I think the thing that’s missing is that social networking isn’t a killer app. It’s human behavior, and that comes with some challenges. Humans are unpredictable.

Here’s one way we’re unpredictable. The same group that made Friendster a hot online community, Orkut the next big thing and MySpace the next Google moves from community to community, lighting a fire and then moving on, leaving nothing but a burned out shell. These are the online "nomads" who are always pushing the envelope. Green fields are their motivation, but once main street gets a little civilized (i.e. boring) they pick up stakes and move on. When the dollars chase the next hot online community, this is the gang they’re chasing. Good luck!

Here’s the second way we’re unpredictable. Even if we’re not all online "nomads", we have a tiny little sliver of us that’s curious. We have to check out the new hot online neighbourhood. Think of it as visiting a show home. We want to look at the furniture, oooh and aaah over the decorating, but we have no intention of actually moving there. The online translation would be registering to become a member, visiting once or twice, and then never visiting again. So here, we have a compounding effect. The nomads visit  and start creating buzz (everyone loves the nomads, because they’re just so leading edge). Then the tire kickers (that’s the rest of us poor schmucks) visit for a look. Suddenly you have a hockey stick registration chart that everyone drools over. You’ve got the traffic, now you just have to monetize it! Investment and acquisition offers pour in. Life is good. Two Porsches in every driveway. But then the nomads move on to the next green field (Rule One of Online Communities, There’s always another Green Field), the tire kickers don’t come back (they’re checking out the show home in the new hot community) and the hockey stick breaks in half.

And here’s the third way we’re unpredictable. We like to pick communities that make sense to us, that do something for us, that make us feel at home. We’ll choose the community, the community won’t choose us. This manifests itself in a number of ways. Every brand is trying to create an online community around their brand. I don’t want to belong to a branded community. Most people I know don’t. Certainly not if the brand is something like potato chips or underarm deodorant. Maybe some one some where has enough time in their day to squander some of it on www.nevergetcaughtoffguard.com (I kid you not, a viral game put out by the good folks at Right Guard) but it sure the hell ain’t me. Harley riders frequent an online community, but in true Harley fashion, they took over the joint and basically kicked the landlords out. No, we create communities where it makes sense. Netflix is a community. Amazon is a community. TripAdvisor is a community. eBay is a community. They’re communities because they give us a chance to connect with other that share our interests while we’re doing something that’s important to us. The community aspect just evolves out of our desire to see what other people think about the things we’re interested in.

And there lies Facebook’s challenge. Being a cool community isn’t enough. Being a hot community isn’t enough. And communities online are rather amorphous. As I said above, communities can form in the click of a mouse online. We don’t need a lot of infrastructure to start connecting. And we don’t tend to stick in one place long. But..and this is a big one…if Facebook can create an open ecosystem where developers create functionality within the community rather than outside it, it has a chance. It won’t be the fact that it’s a community that keeps Facebook alive. It will be that it attracted enough functional critical mass to one place. It’s heading in the right direction, but we’ll see if it gets there soon enough.

Comments

Tag:

DoubleClick neatly covers that vulnerability like a set of thick leather boots. That has the groups concerned. They want the Federal Trade Commission to block or modify the multi-billion dollar proposal Google has on the table to acquire the company.

The three groups submitted a second supplement to the FTC, claiming that without safeguards for consumer information in place, that data could be abused by government or commercial entities.

Google’s current stance on privacy calls for a global standard based on the APEC framework. Melissa Ngo of EPIC blasted that proposal as “feeble” during a conference call.

Amina Fazlullah of US PIRG thinks information collection centralized in this merger, with Google in its dominant position, will affect the consumer’s position in the marketplace. Pricing and item availability could be impacted by what Google would know with its aggregated information.

“Content producers would be stuck with very few choices,” Fazlullah said of advertising opportunities for that blanket group of industries, should the deal go through.

CDD executive director Jeff Chester said the “overwhelming share of control” possible from the deal poses a “profound threat to privacy at home and abroad.”

That seems to be the case for Canada, today, as the Canadian Internet Policy and Public Interest Clinic filed a request for an audit of the merger with the Privacy Commissioner of Canada.

Google has posted an early response to the FTC’s concerns at its Public Policy blog.

Pablo Chavez, Google Policy Counsel, said in the post his company is “glad to see” the FTC readying its town hall meeting about online advertising on November 1 and 2.

“Late last week we sent comments recommending that the Town Hall address two additional topics,” said Chavez. “We did so in response to the FTC’s request for suggested Town Hall topics in addition to the very timely questions it already plans to pursue.”

Google has asked the FTC to consider “the rapidly changing business landscape of online advertising, and the role it plays in providing free, accessible, user-friendly, and high-quality content to consumers,” and “the ways in which online advertising is contributing to a healthy and vibrant small business community.”

First Jikto hits the web, and now this. JavaScript hijacking vulnerabilities in a number of popular web application frameworks, including ones from Google, Microsoft, and Yahoo, could be a threat until their libraries receive fixes.

Fortify Software posted an advisory about the JavaScript issue. Their description of the problem resembles what Jikto can accomplish. Here’s the Fortify summary:

The attack works by using a <script> tag to circumvent the Same Origin Policy enforced by Web browsers.

This is Hoffman’s discussion of Jikto, a JavaScript based web scanner that has the potential to silently install on a web browser and probe websites for cross-site scripting vulnerabilities:

As my Shmoocon presentation slides discuss, Jikto bypasses the "Same Origin Policy" by using a proxy website like the-cloak, proxydrop, Google Translate, etc.

Part of Hoffman’s source code for Jikto has been released on the Internet. Fortify took aim at several frameworks in their analysis of the possibility for a JavaScript threat to exploit them:

We analyzed 12 popular Ajax frameworks, including 4 server-integrated toolkits – Direct Web Remoting (DWR), Microsoft ASP.NET Ajax (a.k.a. Atlas), xajax and Google Web Toolkit (GWT) — and 8 purely client-side libraries — Prototype, Script.aculo.us, Dojo, Moo.fx, jQuery, Yahoo! UI, Rico, and MochiKit. We determined that among them only DWR 2.0 implements mechanisms for preventing JavaScript Hijacking.

JavaScript transports data, making it possible that an unauthorized application could read the data going to a legitimate site. If that data includes confidential information, then a hijack can bring that data to another party.

The concept was demonstrated quite painfully to Google early in 2006. Jeremiah Grossman detailed a GMail flaw that could reveal someone’s GMail contact information. Google fixed that problem shortly thereafter.

Frameworks will be updated to resist JavaScript hijacking attempts. Ajax developers will want to verify their applications can resist potential break-ins and be aware of the ramifications of the problem:

The loophole in the Same Origin Policy is that it allows JavaScript from any website to be included and executed in the context of any other website. Even though a malicious site cannot directly examine any data loaded from a vulnerable site on the client, it can still take advantage of this loophole by setting up an environment that allows it to witness the execution of the JavaScript and any relevant side effects it may have. Since many Web 2.0 applications use JavaScript as a data transport mechanism, they are often vulnerable while traditional Web applications are not.

The link the file is here, the link to Wisec is here, and it makes for some interesting reading.

The premise of the framework is:

Ajax problems are present both client side and server side and can be classified as follows:

1. System Architecture;

2. Authorization and authentication;

3. Client/Server communication;

4. Management of communication (usually XML);

5. Client and Server are not trusted.

These are all pretty standard issues that when dealing with normal web applications that most web application penetration folks will attempt to subvert. What makes this more interesting is when you can move bits of java code around because the web site owner has made all files read/write or even better read/write/execute (755 or 777 in both UNIX and windows) to make some applications work at all.

While most web applications, or web enabled applications have many common issues, the development of a full Ajax exploitation framework like the Metasploit framework, or purchased web application penetration tools like SpiDynamics Web Inspect is getting to be more and more necessary as information security people do not have the skill sets to properly ascertain the ramifications of some Ajax implementations.

The attack structure called XSS Prototype HiJacking as proposed by Wisec goes like this:

“XSS Prototype Hijacking – It will now be described a new advanced technique to gain total control over an Ajax application. This attack is exclusively based on some of the intrinsic properties of Prototype Languages like Javascript. Prototype based programming is a style of Object Oriented programming where classes are not present; indeed, objects are cloned from already existing objects (native objects) or from scratch (empty objects). Eventually, new methods or attributes belonging to an object could be created or reimplemented by simply defining them.” (Wisec)

Security folks are behind the power curve on issues like this, and more training needs to be done so that security folks are more aware of what is happening in the world of Ajax. As people write better and better descriptions of code exploits, and those exploits are released like the ones on MySpace, Yahoo, and others, security folks should be testing for these kinds of issues. Or at least reading the papers and working with developers to raise the level of awareness for both security and development teams.

For Ajax security and for Ajax developers, this paper just became a must read as understanding the implications of certain implementations are being read by hackers and folks that want to own your web site.

Comments

Tag:

Add to Del.icio.us | Digg | Reddit | Furl

Bookmark WebProNews:

Dan Morrill has been in the information security field for 18 years, both
civilian and military, and is currently working on his Doctor of Management.
Dan shares his insights on the important security issues of today through
his blog, Managing
Intellectual Property & IT Security, and is an active participant in the
ITtoolbox blogging community.

My take on this would be that I don’t really think that the two are even slightly similar in sytanx, semantics or even intended use.

The only thing that I have found in common is the use of the “;” to signify the end of the line.

• The OO implementation is not similar, C# is strictly Object Orientated, whilst I think that Perl was not and is not intended to be OO (I know a lot of people will disagree with me).

  I just don’t think Perl’s OO functionality is that intuative, it is like Javascripts OO: Obtuse!

• C# has a very strict and highly developed Framework that can be used from the start, Perl has lots of modules that you have to install, by default though you would do everything yourself.
• The semantics in C# are stricter, that is you can may tend to do things in one way, other people would tend to do it the same way too.

  In Perl at least it seems to me that you can do everything many many ways, which a lot of people like because one person doesn’t code the same as another; it is not forced on you.

• Perl has Regex’s built in to the language, in C# Regex’s are an object that you construct etc.

I use perl because I can do a lot of work quickly in it, and my site is based on a Linux server.

I use C# because I like the langague and it is my job.

There are many more reasons that the languages are completly different. This was my take.

Comments

Add to Del.icio.us | Digg | Reddit | Furl

Bookmark WebProNews:

Paul Kinlan is the author of the popular C#, .Net Framework blog. Paul is an Analyst Developer working in Southport, England. Paul has several years experience developing and designing massively scalable enterprise systems on UNIX and Windows based architectures.

From this preview you could see an endpoint and a parameter, so Niall tried and it worked for everyone. That inspired me to make this fast PHP implementation of it, using the Zend framework JSON library. If you’re interested, have a look at the code.

Comments

Bookmark WebProNews:

Joost de Valk is an SEO from Nijmegen, the Netherlands, who works for Onetomarket, an online marketing company. He has experience as a sales manager for several IT companies, is involved in open source projects like WebKit and Mozilla, and is the creator of the biggest online resource on CSS3. Joost blogs about web design and SEO, and writes all sorts of scripts for webmasters.

The slow slog of writing all my code from scratch is not for me – surely we have moved beyond that now in web development?

The big question was – which framework to use? Since the advent of Ruby on Rails, development frameworks have become quite the flavour d’jour and there are now, well, maybe not thousands of them, but quite a few! The last time I heard there are about 80 development frameworks out there. I am not 100% user of this number, it could be a bit higher, it could be a bit more conservative (on this site you can find about 40 PHP frameworks listed – www.phpwact.org/php/mvc_frameworks). The point is, the web developer is now really spoilt for choice. Which is a problem in itself, since having too much choice can leave you dithering between different options.

This article is therefore about how I made my choice, which was CakePHP, and which factors I took into consideration.

Obviously and certainly I will get bombarded with “Why don’t you try X framework, it is really much simpler to use…” type responses. That is quite OK, to each his own! But this is the choice I made and I am sticking to it. Frankly, the idea of going through another learning curve gives me the heeby-jeeby’s….

I found that the selection criteria were not independent. In other words, once I’ve ruled out some frameworks due to some specific criteria, other factors came into play. It was therefore more a process of elimination than judging all the frameworks off a predefined set of criteria.

The first major selection point was: Ruby on Rails or not.

Obviously there is the attraction of using a brand new, hip, buzz-word hyped framework. You can’t go wrong with something that is getting so much attention… or can you?

Let’s look at some of the selection criteria that filtered out Ruby on Rails”

1. Ease of installation and ability to run on shared hosting

The problem is that most of my clients make use of a shared hosting environment. Can Ruby on Rails run on common-or garden variety type shared hosting? The answer was, I soon discovered – no. One needs to either have access your own private servers or run on a shared hosting environment that has Ruby on Rails pre-installed. Admittedly, there are a couple of them now starting up. A comprehensive list of hosting providers that offer Ruby On Rails hosting can be found on the RoR Wiki – wiki.rubyonrails.org/rails/pages/RailsWebHosts

2. Minimize the learning curve

Even though I knew that any new framework will involve a steep learning curve, I really didn’t have the guts to go through TWO learning curves – one for the language itself and one for the framework. I might still have been prepared to go through the learning curve though if it wasn’t for the fact that RoR requires special hosting.

So basically the decision was: Not RoR. And based on criterion 2, I decided to stick to a PHP framework, and not go for something else based on Perl or something else since I’ve been developing in PHP for the past two, almost three years. Having said this, it is all very well to say that CakePHP allows you to use your PHP skills – because it is an object oriented framework/MVC based framework it has its own rich language infrastructure. You still need to learn the CakePHP terminology and the learning curve is pretty steep!

3. Ability to run on PHP 4

Although PHP 5 offers more object oriented features, once again, not all shared hosts offer PHP 5 out of the box. I decided that I wanted to stick to a framework that will offer backwards compatibility and enable me to run on most of the servers that I, as well as my clients, host on.

My further criteria came down to:

4. Must have good documentation

Under good documentation I count the following:

- User manual

- Examples and code snippets

- Screen casts and videos – although I do not see these as essential

5. Good support by the user community

This, in combination with formal documentation is absolutely essential. All of these frameworks are pretty young and the documentation is also constantly evolving. Some documentation might be patchy in details. This is where the user support in terms of the community comes in. How active are the forums? Is there a bug tracker? Any other informal tutorials, write-ups, comments, blogs and other support?

6. Regular upgrades and bug fixes

..but not so close to each other that the software becomes unstable and unusable. Backward compatibility is also important. Version number of the software can be used to indicate maturity.

Working off the following list (www.phpit.net/article/ten-different-php-frameworks/) one can see that the list has narrowed down to the following frameworks:

- CakePHP

- Seagull Framework

- WACT – ‘disqualified’ since the latest version now requires PHP 5

- Zoop

- CodeIgniter

The next step was a bit less scientific – but still fitted in with point 5 – how well is this Framework regarded? How much support does it generate in the ‘community’.

I scouted through forums and followed links and surfed the net and tried to get a general feel – and overall, CakePHP did seem to come out tops. A similar check that one can do is the following – do a Google search for each of the frameworks and see how many results are returned. This will give you a good idea of the general support, number of tutorials, number of forum posts and general ‘talked about’ factor for the specific framework. The results for this exercise can be seen here: http://www.tm4y.co.za/cakephp/ruby-on-rails-popularity-for-web-development.html

In summary therefore, the support for Ruby on Rails and the amount of information available for it is astounding and you will probably not go wrong if you decide to go this route. But if you want to stick with a PHP framework – CakePHP seems to be the route to go!

Tag:

Add to Del.icio.us | Digg | Reddit | Furl

Bookmark WebProNews:

Christine Anderssen is the owner of Tailormade4you. After 20 years in the corporate world of IT management she decided to brave the new frontiers of Internet Entrepreneurship. Tailormade4you helps small and medium businesses with Web Services in the form of Web Hosting and Web Development

I really like the policy mechanism in the WSE, it affords me a kind of AOP (aspect orientated programming) that I am really starting to get into.

For instance I have made a lot of SoapFilters recently, some handy, some just for tests, but each of them allow me to add an aspect of functionality into the webservice that I am creating in a configuration and not a design time.

If I want security, just add a policy line in the XML config, if I want auditing another line, if I want exception shielding another line.

All of these aspects of the system I am creating can be added at deployment time thus leaving my web service code clean and simple.

An example, pseudo code:

And a policy file (not an actual file that would work in this example) would say:

This service code and policy file model is so much cleaner and simpler than what you would have to write if you didn’t have an AOP style policy system:

Now tell me which code you would like to maintain!

Tags: asp.net, WSE, WSE3, c#, .net, webservice

Technorati:

Add to Del.icio.us | Digg | Reddit | Furl

Bookmark WebProNews:

Paul Kinlan is the author of the popular C#, .Net Framework blog. Paul is an Analyst Developer working in Southport, England. Paul has several years experience developing and designing massively scalable enterprise systems on UNIX and Windows based architectures.

It’s actually a tool primarily intended for photo sharing:

[] Max lets you make beautiful photo slideshows to share with your family and friends. You can also use the newsreader to keep up with the latest news updates from around the world.

The pics in the screenshot gallery show a very nice-looking application indeed.

Will I try it? Probably not, or at least not until a final release comes out. This is a beta and it requires .NET Framework 3.0 RC1 (ie, pre release) installed. I have some apps on my PC that need .NET Framework version 2 which I have installed and I don’t know if 3 RC1 will mess up how those apps work. Erring on the side of caution, therefore.

Plus I’m happy with using tools like Flickr for photo sharing and FeedDemon for my RSS reader. So this isn’t compelling enough for me for either use.

Good review at TechCrunch. And check out the 75+ comments and trackbacks there.

Max’ full name is Microsoft Codename Max, a name that does not trip off the tongue lightly. What is it with Microsoft and poor product naming choices? Don’t even think about Bob.

Yahoo! My Web | Furl

Bookmark WebProNews:

Neville Hobson is the author of the popular NevilleHobson.com blog which focuses on business communication and technology.

Neville is currentlly the VP of New Marketing at Crayon. Visit Neville Hobson’s blog: NevilleHobson.com.