Web Design and Graphics

“Fast flux” is an evasion technique that cyber-criminals and Internet miscreants use to evade identification and to frustrate law enforcement and anticrime efforts aimed at locating and shutting down web sites used for illegal purposes. Fast flux hosting supports a wide variety of cyber-crime activities (fraud, identity theft, online scams) and is considered one of the most serious threats to online activities today. One variant of fast flux website hosting, “double flux”, exploits the domain name registration and name resolution services.

you might need more informations for the technical aspects of fast flux hosting and fast flux service networks, how the DNS is exploited to abet criminal activities that employ fast flux web hosting, identifying the impacts of fast flux hosting, and calling particular attention to the way such attacks extend the malicious or profitable lifetime of the illegal activities conducted using these fast flux techniques. also about current and possible methods of mitigating fast flux webhosting at various points in the Internet. we need to discuss the pros and cons of these mitigation methods, identifies those methods considers practical and sensible, and recommends that appropriate bodies consider policies that would make the practical mitigation methods universally available to registrants, ISPs, registrars and registries.

Standard free instant messaging/live chat applications offer functions like file transfer, contact lists, the ability to have simultaneous conversations etc. These may be all the functions that a small business needs but larger organizations will require more sophisticated applications and live support those can work together. The solution to finding applications capable of this is to use enterprise versions of instant messaging applications and live chat software. These include titles like XMPP, Lotus Sametime, Microsoft Office Communicator, etc., which are often integrated with other enterprise applications such as workflow systems. These enterprise applications, or Enterprise Application Integration (EAI), are built to certain constraints, namely storing data in a common format.

There are two ways to combine the many disparate protocols:

1. One way is to combine the many disparate protocols inside the IM client application.

2. The other way is to combine the many disparate protocols inside the IM server application. This approach moves the task of communicating to the other services to the server. Clients need not know or care about other IM protocols. For example, LCS 2005 Public IM Connectivity. This approach is popular in XMPP servers; however, the so-called transport projects suffer the same reverse engineering difficulties as any other project involved with closed protocols or formats.

Some approaches allow organizations to create their own private instant messaging network by enabling them to limit access to the server (often with the IM network entirely behind their firewall) and administer user permissions. Other corporate messaging systems allow registered users to also connect from outside the corporation LAN, by using a secure firewall-friendly HTTPS-based protocol. Typically, a dedicated corporate IM server has several advantages such as pre-populated contact lists, integrated authentication, and better security and privacy.

Some networks have made changes to prevent them from being utilized by such multi-network IM clients. For example, Trillian had to release several revisions and patches to allow its users to access the MSN, AOL, and Yahoo! networks, after changes were made to these networks. The major IM providers typically cite the need for formal agreements as well as security concerns as reasons for making these changes.

Choose a Great Domain Name

As you build the mobile version of your site, you’ll need to decide upon the domain by which users will access it, and work out how to advertise the fact that it exists. There are several options for choosing a mobile domain. Let’s explore each of them.

1. Use a separate domain altogether (e.g. www.example-mobile.com).

Creating a separate domain has never been necessary for any of the sites I’ve worked on. A separate domain name can hurt your site’s overall branding and can confuse users — how many people will actually remember both the URL for your traditional web site and your mobile version? And which site should you promote in your advertising? Such an approach can end up being a hassle, and is therefore not recommended.

Use a subdomain (e.g. m.example.com).

Creating a subdomain is probably the most popular option. Using a subdomain (such as mobile, or just m to keep it short) keeps your mobile site part of your brand without creating confusion. Obviously, if it suits your customers, you might want to localize the term ‘mobile’. And if adding ‘m’ to the start of your domain name spells something horrible, you might consider placing the mobile element at the end of your URL (e.g.http://example.com/mobile/).

Either way, you should assume that people will get the address of your mobile site wrong. Anticipate this eventuality by setting up several different common subdomains — m, mobile and others — and redirecting them all to a single mobile site, just as you should redirect typos like ww and wwww for your traditional web site to www.

Use a .mobi top level domain (e.g. example.mobi).

The question of registering a .mobi TLD has been the cause of heated debate among web developers ever since the availability of .mobi domains was announced. Personally, I’ve never used a .mobi domain for any of the projects I’ve worked on, but this decision may come down to a personal preference. If you have a few hours to kill, a quick search will provide you with plenty of information about the pros and cons of using a .mobi domain.

Do nothing, and let the server send the best page based on the user agent.

Performing user agent detection is perhaps the most interesting option from a developer’s point of view. It’s also the most elegant from a user’s point of view, but unfortunately it’s the approach that’s most prone to issues.

Here’s how it works: when a user visits the site example.com, the server looks at the visitor’s user agent and tries to detect if the visitor’s using a mobile device or a desktop browser. Given that information, the server will send the most appropriate page for that user agent. The beauty of this approach is that it allows you to use a single URL, which anyone can use with any device. Whether they’re on computers or mobile devices, all users will magically view the version of the site that is best optimized for them. When it’s done well, this can be great solution. But when it’s done poorly, it can be a disaster.

The second option that we discussed (using a subdomain) has one other advantage: a user browsing with a high-end device might first visit the mobile site, then realize that this site doesn’t contain the information he or she wants. The user then has the option of navigating the traditional web site to locate the information. The user experience might not be optimized, but the user should still be able to find the desired information.

With user agent detection, however, there’s only one URL, and therefore only one version of the site that can be returned to that device. The customer can’t choose the version to view — even if he or she is capable of viewing the site. If you plan on performing user agent detection, you’ll need to allow for exceptions so that devices can override the detection process in order to view a specific version of the site. As you can see, if you head down this road, things can get very messy, very quickly.

When you’re deciding on a domain name for a mobile site, the colleagues and companies I’ve worked with have always chosen option #2. Creating a subdomain is the easiest of the options to set up (you already own the domain), it’s the cheapest option (there’s no need to register the .mobi), and it means that you avoid having to spend hours tweaking the server (and potentially messing up normal traffic). The end result is a sandboxed subdomain built specifically for mobile devices. And if traffic numbers are not what you expect (for better or worse), a subdomain gives you the flexibility to grow or scale back the mobile site without impacting on the traditional web site

Validate Your Markup

Desktop browsers can be quite forgiving. A few misplaced HTML tags here and there will, more often than not, be fixed on the fly so that your page is rendered correctly. However, the “smarts” built into desktop browsers in order to perform this error handling equate to more code, which means a bigger install and more processing power.

Mobile browsers, on the other hand, are much less forgiving. A browser running on a mobile device generally won’t have the luxury of a 2 GHz processor and 100MB of disk space. Therefore, you must check, validate, and recheck your markup, time and time again.

Much of the checking and validation of a mobile web site can be done through a normal desktop browser. If you’re developing in XHTML, for example, you can reuse all of the same tools that you use to validate traditional sites:

• The W3C validator can be used to find simple markup errors — there’s even a mobile-specific version.
• The Ready.mobi site lists a few additional mobile specific checks.

You’ll notice at this point that we haven’t yet discussed checking to see if the mobile site works correctly on a mobile device. Once you’ve received the green light from several validators, you’ll need to get a few different types of phones to perform some actual tests.

Test, Test, TEST!

Testing your site with a web browser on a desktop computer can only get you so far in terms of simulating the mobile experience. There are many elements of mobile device usage that can’t be replicated accurately in this way. For example, a mobile operator might restrict packet sizes to something smaller than you expected, and therefore won’t even send your web page or its images! Additionally, content mime types could be an issue between browsers — are you serving the pages with the correct text/html or application/xml+xhtml? What kind of image formats can the phone display?

Due to the small footprint in memory and on disk, mobile browsers are not as robust as desktop browsers, so the best advice is test, test, test! Granted, not everyone can afford to test on every phone that’s available on the market, but there are alternatives:

1. Emulators

There are plenty of online emulators and offline emulators that allow you to quickly see images in context and the general layout, but they’re not real devices, and therefore they have their own quirks and differences. These tools can act as a good first pass to find common issues. Also, they’re free to use, so there’s no reason to not have a peek in an emulator, but you can’t call a site viewed on an emulator “tested”.

2. Rent Time

Renting time is another option. There are services that allow you to upload or view the content one multiple phones in real time. You control the different phone’s features remotely. This service does cost money, but it’s still cheaper than purchasing lots of different phones. For a basic mobile web site, this service probably isn’t needed.

3. Buy a Handful of Phones

Buying a small subset or representative phones is a possibility. If you’re planning on doing more mobile development, spending a little money up front can really help. You probably need to purchase 5 or 6 phones representing the major brands and types.

You’ll need some sort of Windows smart phone — we test on an HTC Mogul PPS-6800 using Internet Explorer on Windows CE, which gives a representative coverage for all Windows Mobile devices. You’ll also need a Nokia model phone. We test on a Nokia 6600 running Symbian Series 6 OS and the built-in Services and optional Opera browsers. You’ll need a Sony Ericsson phone. The model we use is a T630, which covers Sony’s Internet Services. Lastly, you should test in whatever model is most popular in your audience. You do not need these exact phones, but these types of devices will allow you to quickly see the minor differences in the phone browsers and cover the majority of potential customers.

4. Ask Your Friends

Finally, you can simply ask your friends. We all know at east 5 or 6 co-workers or colleagues who would happily lend us their phone for a couple of minutes. Once you’ve tested your web site with the online emulators and validators, test it on the borrowed mobile phones. The pre-tests should have fixed all but the issues that are specific to each phone. Take notes, make corrections, and test again, and again — and again! — until you’re satisfied.

Depending on your budget, one of those options will suit you. Spending just a little time and money really can go a long way — especially if this is your first mobile web site. Getting your test suite right will allow you to find common issues, while helping you to build a library of working HTML, CSS, and JavaScript code that’s known to be tested and can be reused in future projects.