In other words, if you're the owner of a jailbroken phone, you should now be concerned.

Unlike the relatively innocuous iKee worm which the creator designed more as a "public service" to alert users to the potential for malware on the iPhone, the new hacker tool, dubbed "iPhone/Privacy.A," is the real deal. Where iKee simply switched the iPhone wallpaper to display a photo of singer Rick Astley (a nod to the internet meme of rickrolling), Privacy.A gives the user no indication that it is running on the device.

The new hacker tool also operates a bit differently than iKee does, as it doesn't have to sit on the iPhone itself in order to inflect its damage or spread. The hacker can either load the worm onto their personal device and then monitor the network for jailbroken devices to attack or they can load the malicious program onto a computer. As Intego points out in their post, this computer could be on a public network at an Internet cafe or retail store. In that scenario, the tool would then scan for any other jailbroken iPhones that came within range of the Wi-Fi network and attack them.

How to Secure your iPhone

Although many jailbreakers are tech-savvy enough to know how to lock down their devices to protect themselves from attack, there are quite a few who have simply followed online instructions such as these to perform the jailbreak. This group, while arguably somewhat tech-savvy, doesn't necessarily know all the nitty-gritty details about the iPhone filesystem or its security mechanisms.

To make it easy on these users, we've provided steps on how to change your iPhone's root password - the common denominator required in order for the malware to gain access to your device.

While some may argue there's no need to change your root password if you haven't also installed the SSH program, another necessary element for these attacks to work, we think that's a little short-sighted. It would be easy enough for a malicious hacker to trick jailbreakers into installing SSH by bundling it with some other third-party application offered through underground App Stores like Cydida or Icy. By masquerading as something innocent like a wallpaper-changer or ringtone bundle, a hacker could easily set up a number of jailbreakers with SSH without the victims even being aware that it has been installed. Although we haven't heard of anything like this happening yet, if we thought of it then you can bet that the hackers out there have thought of it too.

Changing the Root Password

The best protection is to simply change your iPhone root password. That will keep you safe from the current iPhone malware...as least for now. Here's how:

1. Install the MobileTerminal application from Cydia.
2. Reboot your iPhone.
3. Launch MobileTerminal and type in the command: passwd
4. At the prompt which asks for the "Old Password," type in: alpine
5. At the new password prompt, type in a new password of your choosing, making sure to pick something strong.
6. Re-enter the password to confirm.
7. You'll then be returned to the Mobile$ prompt which means the change was successful.
8. Now you'll need to change the password for the secondary admin. Type in the command login root.
9. Again, you're prompted for the old password. Type in alpine.
10. Now type in the command passwd
11. You'll then go through the change password routine a second time, entering in alpine as the old password, creating a new password and then re-entering it to confirm.
12. When you are finished, close the application.

Note: these instructions assume you are running iPhone OS 3.0 or higher.

According to the pending class-action suit, Storm8 used a well-known backdoor method to "access, collect, and transmit" the wireless phone numbers belonging to their software's users.

Now the company has publicly responded to the suit by posting on their forums a sort of mea culpa as well as their plans to ask for a dismissal of the lawsuit due to its "complete lack of merit."

The complaint, filed on behalf of Michael Turner (and available in its entirety here), states that all the games retrieved the user's cell phone number and sent it over to the company without informing the user that this is being done. The suit also points out that there's no reason for this to occur since playing an iPhone game doesn't require the developer to have access to this sort of personally-identifiable information.

While initially Storm8 claimed the harvesting of these phone numbers was due to a "bug" in their code, attorneys for the plaintiff were quick to point out that specific software code was required in order to retrieve the numbers - no bug could have done that. In other words, the collection was intentional.

Storm8's Response: We Erred, We Fixed It, Lawsuit is Meritless

Now the company is changing its tune - well, a bit. Instead of calling it a "bug," they're claiming that the phone number collection was due to legacy code that was put in place very early on in the software development process as a way to identify specific devices. Later, the company decided to use the iPhone's Unique Device ID (UDID) instead - a much more common and accepted practice for developers needing an identification method. UDID's aren't associated with a person's name or phone number - they just identify the iPhone itself. However, even though the company changed methods, they didn't remove the old code that performed the phone number collection.

Storm8 claims that they did nothing with those phone numbers nor did they provide them to any other company. They also say that the database housing the numbers was destroyed in August after they were alerted to the issue. At that time, they took voluntary actions to update their applications to new versions with the legacy code removed.

The company states that they plan to ask for a dismissal of the suit because no user "has incurred any damage or loss" as a result of their actions. Unfortunately, they may be right. As despicable as those actions were, the law may be on their side. According to legal news site FindLaw, the law requires that not only was a personal computer accessed, but that the computer was also damaged. Turner's lawyer then will have to prove that Storm8 caused damage because it "impaired the integrity of the data stored on a protected computer." Additionally, cell phone numbers are not considered "protected data" in the same way that social security numbers or bank account numbers are. In other words, despite how icky this privacy violation makes you feel, it may not actually be illegal.

In our opinion, that's terrible news. Of course we wouldn't want this to start some sort of "sue the programmer" trend, but we do need to have more control over who's doing what with the personal data stored on our mobile phones - especially if Apple isn't going to look out for us in this case. Shouldn't there be some way to punish developers who go after this private info without our knowledge - whether intentionally and maliciously or not? It seems like we have enough concerns over privacy issues these days, we shouldn't have to worry if our iPhone apps are spying on us, too.

Late last week, a federal judge in California gave preliminary approval to a settlement of the class action lawsuit regarding Facebook's Beacon program. The controversial program, launched back in November of 2007, allowed Facebook users to share online purchases made on third-party affiliate websites with their social networking friends. The problem with the program was that it was opt-out instead of opt-in, angering many Facebook users who unknowingly shared information they wished they wouldn't have.

Details of the Agreement: Shutting Down Beacon, Paying Damages, Non-Profit Foundation

The case has been in litigation since last year, but now looks like it's drawing to a close. U.S. District Court judge, Richard Seeborg in San Jose, has approved the proposed Facebook settlement that would have the company paying out $9.5 million, two-thirds of which would go to setting up a non-profit foundation to fund "projects and initiatives that promote the cause of online privacy, safety and security." The remaining money would then be split among the lawyers and the plaintiffs, each of whom would receive damages of $1000-15,000, according to MediaPost.

The other major part to the Facebook settlement is the required termination of Facebook's Beacon program in its entirety. Although Facebook had quickly reacted to the Beacon outcry after its launch, changing the system over to opt-in and even issuing a formal apology, the program still exists today. (You can check your settings by going to Settings -> Privacy Settings -> Applications -> Settings tab. Then scroll down to the bottom to see if "Beacon websites" is checked or unchecked. Checked will ensure no Beacon stories get posted to your profile).

If the proposed settlement goes through, Facebook would then be relieved from liability from any future lawsuits regarding the same complaint and even those still pending like the Facebook/Blockbuster class action suit brought in April 2008.

Settlement Sounds Great...Especially for Facebook

On the surface, the proposed settlement sounds fair enough to all parties involved. Damages are paid and Facebook has to promote online privacy. However, as David Johnson points out on the Digital Media Lawyer Blog, Facebook is already required by law to promote online privacy and the safety and security of its users' information per FTC mandates. In addition, Facebook would get to nominate one and have say over the other two board members on the proposed Privacy Foundation's board of directors.

Says Johnson: "Facebook effectively gets most of its money back to fund projects that it is already has an obligation to perform."

Sounds like the real winner here may be Facebook.

You can read the Settlement Agreement here, courtesy of CircleID. The settlement was proposed last month, but only received preliminary approval on Friday. The affected parties have until February 1st to object to the proposed settlement.

While this incident alone wouldn't generate much excitement given the low-profile nature of the applications affected, it's not the only example of unsafe applications on Facebook. Another researcher just spent an entire month scouring Facebook apps for security vulnerabilities and what he found is disturbing: six of the hacked apps were in the top ten, 9700 applications were affected, and the potential victims totaled 218 million users.

In the case of the hacked Facebook apps found by AVG, the apps had been compromised by the use of "iframes," which are bits of code embedded in the applications themselves. The iframes were able to load content from malicious websites into the applications' pages on Facebook.com, directing app users to install software on their computers by purporting to be an update for an out-of-date Adobe Reader product.

At first, Thompson thought the apps had been hacked by the developers, but as it turned out, it was the developers who were the victims. After looking at the source code for the apps in question, Thompson found that the iframes had been injected into the apps' code due to infected software on the developers' PCs.

Facebook quickly reacted to the situation and took down the compromised apps while also contacted the developers to warn them of the issue.

Thousands of Apps Vulnerable to Attacks

While hacked Facebook apps may still be a bit of a rarity today on the popular social network, security vulnerabilities that could lead to malicious attacks are not. After spending a month on Facebook looking for application bugs, another security researcher made some disturbing findings.

Specifically, the researcher, who goes only by the handle "theharmonyguy" online, was looking for a specific vulnerability he referred to as a "FAXX Hack." FAXX stands for "Facebook Application + XSS + XSRF" or, in other words, a cross-site scripting vulnerability - a certain type of security hole that could allow a hacker to access profile information, including personal details, status updates, and photos of a victimized user and their friends.

The findings showed that many Facebook applications, even those that were widely used and considered trustworthy, lacked basic security precautions. There were some 9700 Facebook applications which were affected by vulnerabilities and nineteen of the applications in question had passed through Facebook's "Verified Application" program, a sort of "stamp of approval" designed to assure Facebook users of an app's general trustworthiness. Among the apps, six were ranked in the top ten by monthly active users including FarmVille, Causes, LivingSocial, Movies, Farm Town, and YoVille. The collective monthly active users counts for all the hacked apps totaled 218 million. However, that previous figure does include overlaps. Also, seven of the top ten application developers on Facebook were found to host at least one vulnerable app. (Note: the 9700 number may seem large but that's due to one vulnerability found in the "Make a Gift!" application. Make a Gift! lets users create their own custom applications for sending gifts, and the myriad of resulting applications are all hosted from the same server.)

While discovering the bugs, the researcher contacted each application developer to make him or her aware of the hole. For the most part, developers responded quickly and took the situation seriously. However, several developers took a while longer to respond. Nine took over a week to patch their application and one even took two weeks. And those delays were not due to the complexity of the required patches - these were, in terms of coding, simple fixes.

What's most concerning about these findings is how widespread the problem was. Unlike the apps AVG discovered, this wasn't a minor, isolated incident affecting a small handful of users. Although the apps in question here were just vulnerable to attacks as opposed to being comprised themselves, it shows how risky it is to use any application, Facebook Verified or not.

Is Any App Safe?

On top of all these security issues, in August many Facebook users were surprised to discover the vast amounts of personal information they were revealing by their use of Facebook quizzes. Even if you limit access to your profile through privacy settings, Facebook quiz applications can see everything on your profile page when you take a quiz...or even when your friend takes one. To make matters worse, Facebook does not screen developers for trustworthiness nor do they require developers to comply with a privacy policy.

With hacked apps, security vulnerabilities, lack of privacy policies, and apps that can read your private profile information, one has to wonder if using any Facebook application is appropriate and safe these days.

Update: Facebook's response: "Developers on Facebook Platform must comply with Platform Policy Guidelines, which require that applications provide a trustworthy user experience. Similarly, applications must post their own privacy policy if they collect any user information. We enforce these guidelines through spot checks and have disabled thousands of apps that we found in violation. We also encourage users to report suspicious apps and practice caution with all of their online activity."

As reported by Australian news outlet ITNews, Wave has multiple levels of security which are designed to prevent email spoofing. Spoofing, meaning when you receive an email that claims to be from either a person or company you know but is actually from someone else - a hacker in most cases.

D'alesandre says the Wave protocol is more secure because it includes something he jokingly refers to as "crypto fairy dust." That's obviously meant to be a simple and fun way to explain the security complexities built into Wave which involve detailed authentication mechanisms to keep users safe from malicious attacks. In Wave, every bit of info you receive from another Wave user has already been authenticated as to its origin so you can be assured that they are who they say they are.

"You know you are getting the Wave from the person that is sending it to you and it has not changed mid-stream. This is a very big problem in current communication technologies - data can be changed mid stream and you will never know," said D'alesandre.

HTTPS Enabled by Default

For an additional layer of security, all Wave traffic is by default encrypted via HTTPS, a protocol for secure communications. That represents a big change in Google's standard policy regarding use of this protocol. It wasn't until July of 2008 that Gmail users were even given the option to encrypt messages using SSL and to enable it, you had to go into your settings and make a change - something that most mainstream users would never have bothered with. By the end of 2008, Google was only offering SSL as a feature in its other Google Apps programs if users were on either the Premier or Education editions. That meant that for non-paying consumer users, Google Docs, Calendar and other online offerings were only available via unencrypted HTTP sessions.

Today, little has changed. Still, only users of Premier and Education Editions have access to SSL and it's not switched on by default. The protocol is now available for Gmail, Chat, Calendar, Docs and Sites but not the Start page, Google Video or the Google Talk desktop client. Consumers using free Google apps like Docs still don't have SSL unless they type it in the address bar manually.

D'alesandre admitted that switching on encryption in Wave slows down the service a little (which probably explains the company's hesitance to switch it on in other products, too), but they ultimately decided that the security it provides was worth it.

Whitelisting Kills the Noise

A third security feature of sorts coming to Wave in the future is the ability to do "whitelisting." Wave users will be able to select which people they want to collaborate with and place them on a whitelist of approved persons. Only those who are on the list will be able to contact you via Wave and everyone else will be ignored.

That feature should certainly help to address the concerns certain folks have about Wave's "noise level," to some, an overwhelming amount of activity that led them to call out Wave as a distraction and a time-waster instead of the futuristic productivity product it intends to be. By allowing those who can't seem to embrace Wave's cacophony the ability to limit their collaborators, Wave could transfer from noisy attention killer to useful tool in an instant.

Of the three features, the first two are already in place. No date was given on the whitelisting feature, only that it will be "coming soon."

He notes that the service-level agreements (SLAs) for all the hosted applications are the same as those offered in the operation's traditional on-site computing environment - that is, 99.999% uptime. Google only offers 99.9% as does Amazon S3...and yes, those extra digits make a world of difference.

In addition, DISA also uses the same information assurance process (the process of managing information-related risks) for the RACE applications as it does for any apps running on the traditional, on-site computing platform. They've even cut the security accreditation process from 80 days to 40 thanks to built-in information insurance controls in RACE. 

One of the most obvious benefits of a cloud computing infrastructure, though, is the speed of deployment. The cloud platform has cut the acquisition time for a new server from 6 months to 24 hours - a change that means DISA will now be able to rapidly deploy new applications to the military in record time. "That's a must for worldwide missions with ever-changing computing requirements," says Sienkiewicz.

RACE runs using VMware on HP blade servers. Defense Department customers can choose either Microsoft Windows or Red Hat Linux and are able to configure their server with up to 4 CPUs, 8 GBs of memory and up to a terabyte of storage. Test servers are $500 per month and production servers are $1200 per month. Next year, RACE will be deployed on the DoD's classified network (SIPRNet) as well. 

In yesterday's attack, the list of comprised Hotmail accounts were limited to those where the usernames started with the letter "A" or "B." However, that seemed to imply that the posted portion might actually be a part of a bigger list containing even more login/password combinations. At the time, a Microsoft spokesperson said that the company determined "this was not a breach of internal Microsoft data and initiated our standard process of working to help customers regain control of their accounts." Instead, claimed the spokesperson, those users whose credentials were revealed were likely to be victims of an online phishing attack where a third-party website was involved.

Phishing attacks are typically carried out via email messages where the attacker tricks the recipient into revealing their username and password by pretending to be some sort of trustworthy entity such as the user's bank, IT administrator, a popular website, or an online service. In the case of the stolen Hotmail passwords, it's possible that the attacker sent emails which claimed to be from the end user's email provider. If the user then followed the link contained within the malicious email, they would have ended up not on the actual email provider's site, but on a third-party site whose sole purpose was to capture their username and password when entered.

Beyond Hotmail: More Webmail Providers Affected

According to a story in today's BBC News, the most recent list of compromised accounts, which includes login credentials for Gmail, Yahoo, AOL, Earthlink, and Comcast users, contains some accounts that appear to be old, unused, or fake. However, many others listed are, in fact, genuine.

There's no way to be sure at this point that the new list is a part of the same phishing attack as yesterday's or if it's a new and separate scam.

The website where the accounts were posted - pastebin.com - is now "down for maintenance." Visitors to the site today will receive a message that reads:

Pastebin.com is getting an unprecedented amount of traffic due to a news story in which some leaked Hotmail passwords have been pasted on this site

Pastebin.com was intended as a tool to aid software developers, not for distributing this sort of material. Filters have been put in place to prevent reoccurrence, but the current traffic level is unsustainable.

Pastebin.com is just a fun side project for me, and today it's not fun. It will remain offline all day while I make some further modifications

Paul Dixon

Regardless of whether or not you think your account was compromised, today would be a good day to change the password on whichever webmail service you currently use. Better safe than sorry!

While the glitch itself was minor and was fixed in a few days, the real concern - at least at Brown - was with how Google handled the situation. Without communicating to the internal IT department, Google shut down the affected accounts, a decision which led to a heated conversation between school officials and the Google account representative.

In the case of the Google Apps glitch, which began on Friday, September 11th, a couple of students notified Brown's Computing and Information Services department (CIS) that they were able to read emails belonging to other students. The CIS department contacted Google on the following day and sent out an email to the 200 students whose mailboxes were in transition, asking them whether or not they were experiencing the same problem. Some were. The affected students could either see entire inboxes belonging to another classmate or, in other cases, saw less than 100 messages that did not belong to them.

In the end, only 22 out of the 200 students were affected, but the fix was not put into place until Tuesday. That means that the students had access to each other's email accounts for three solid days (Saturday, Sunday, Monday) as well as parts of Friday and Tuesday before the accounts were suspended by Google.

Oddly enough, this situation seems to be acceptable, according to Tom, who, reports Brown's daily newspaper, "praised Google for its prompt response." (We don't know about you, but if someone else could read our email for three days, we wouldn't exactly call that "prompt.")

Massive data migrations are no small feat and Google's slip-up in this case is certainly not the first nor the last time that something has gone wrong. Still, Google is notably concerned when problems like this happen. "It was a small hiccup along the way and it's an issue we've taken extremely seriously," said Google's Rajan Sheth.

The Real Problem Wasn't Email, it was Lack of Communication

However, the real issue that concerned the university was the matter of communication between Google and the CIS department. Before fixing the issue on Tuesday, Google suspended the affected accounts, a necessary step that was taken so no more data was improperly shared. What angered the IT director, though, was that the accounts were suspended without first notifying CIS.

"I've spoken very forcefully with the account (executive), my boss, senior administrators at Brown -- including the president. (Google needs) to find a better way to communicate with us," said Tom.

When considering a move to a cloud service, most companies and institutions focus on how the change will affect budgets and the bottom line. They also think about data conversion issues and possible needs for re-training in some cases. However, one of the things that doesn't come up as often is exactly how communication will take place between the business and the company involved. Sure, companies may discuss the procedures (use this form, this phone number) and uptime guarantees, but they can't possibly imagine every scenario and spell out how they want the cloud provider to perform.

No longer can company execs just stroll into the I.T. guy (or gal's) office and cry out "my email is messed up!" Now there are a few more hoops to jump through. And whether it's Google or someone else, the interactions that take place and the way the issues are addressed will be a learning experience on both ends.

Says Microsoft Associate General Counsel Tim Cranton in a recent blog post, "Although we don't yet know the names of the specific individuals behind these acts, we are filing these cases to help uncover the people responsible and prevent them from continuing their exploits."Those involved in the current lawsuit include Soft Solutions, Direct Ad, qiweoqw, ITmeter INC, and ote2008.

In addition to this current civil suit, Microsoft is actively pursuing actions against a number of instant messaging spammers and bot-powered click frauders. It will be interesting to see if the public education campaigns for web security can keep up with the influx of ad delivered trojan horse viruses. The public is directed to the Microsoft Online Safety page for more information.

Photo Credit: Dirk Heuer

But what can be done? It's not like you can just quit Facebook, right? No - and you don't have to either. You just need to take a few precautions.

The problem in implementing these privacy options is that they're just too confusing for most non-tech savvy people to handle. And often, folks don't want to bother to take the time to learn. To simplify the process, we're offering five easy steps you can take today to help make your Facebook experience safer, more secure, and more private.

Step 1: Make Friend Lists

Yes, it will take some time, especially if you're connected to a couple hundred friends already. But this step, while not the quickest, is fairly simple. And it will be one of the most useful things you can do on Facebook.

Friend lists, like they sound, are lists for categorizing your friends into various groups. The nice thing about this feature is that once you set these lists up, you won't have to do it again. We suggest that you put your work colleagues and professional acquaintances into a friend list designated "work," personal friends you're not very close with into a list called "Acquaintances," and people you're related to into a list called "Family." Those three main categories will separate out the groups of "friends" who you may want to hide some information from.

To create a friend list, click on "Friends" at the top of the Facebook homepage. In the left-hand column, click "Friends" again under the "Lists" section. Now you'll see a button at the top that says "Create New List". Click it. In the pop-up that appears, you can name your list and pick members. If you've ever shared an application with your friends, the process of doing this will be very familiar.

When you've finished making lists, you'll be able to use them when selecting who can see what (or who can't!) when configuring the security settings described below.

Step 2: Who Can See What on Your Profile

At the top right of Facebook, there's a menu that many people probably ignore: "Settings." But this menu is now going to become your best friend. To get started, hover your mouse over the Settings menu and click "Privacy Settings" from the list that appears. On the next page, click "Profile." This takes you to a page where you can configure who gets to see certain information on your profile.

Before making changes, think carefully about the sorts of things you want public and the things you want private. Should "everyone" get to see photos you're tagged in? Or would you like to limit this only to those you've specifically chosen as Facebook friends?

Underneath each section on this page (basic info, personal info, status, etc.), you can designate who gets to see that particular bit of information. For anyone not using custom lists (see step 1), the best thing to enter here is "Only Friends." Anything else opens up your profile information to people you may or may not know. For example, choosing "Everyone" makes that info public, "Friends of Friends" lets your friends' friends see it, "My Networks and Friends" opens up your info to anyone in your networks - that means anyone in your city, your high school, your college, a professional organization you listed, etc.

You can also block certain groups from seeing these sections, too. On any item that offers an "Edit Custom Settings" option, you can click that link to display a pop-up box where you can choose people or lists to block (see where it says "Except these people"). If you haven't made custom lists as explained in step 1 above, you can enter individual names here instead. (Sorry, mom, dad, boss - this is where you get blocked.)

Step 3: Who Can See Your Address and Phone Number

Did you list your address and phone number on Facebook? While that's a handy feature, you may not want everyone you friended to have this information. To access this configuration page, you follow the same steps as above in step 2 to display the Profile Privacy page. You'll notice that the page has two tabs at the top - click on the one that reads "Contact information."

As previously described above, you can again use the drop-down lists provided to designate who gets to see what and/or block certain people or lists from viewing this information. The sections on this page include "IM Screen Name," "Mobile Phone," "Other Phone," "Current Address," "Website," and your email.

Step 4: Change Who Can Find You on Facebook via Search

Sick of getting friend requests from old high school pals? While for some the beauty of Facebook is that it lets you reconnect with everyone you ever knew throughout your life, others find this intrusive and annoying. You're not friends with any of these people anymore for a reason, right?

As it turns out, you can still enjoy Facebook without some folks ever knowing or finding you thanks to the search privacy settings.

Click on the "Settings" menu on Facebook's homepage and then click "Search" on the following page. You'll be taken to a Search Privacy page where you can specify who gets to find you on Facebook. Want to be wide open? Change the "Search Visibility" drop-down box to "Everyone." Want to keep it a little more limited? Select "My Networks and Friends," "Friends of Friends," or "My Networks and Friends of Friends" instead. Don't want anyone finding you on Facebook? Change it to "Only Friends." That means only the people who you've already friended can find you in a Facebook search.

On this page, you can also configure what information displays when your info is returned as a search result (e.g. your profile picture, your friend list, etc.). In addition, you can check and uncheck the boxes for network-based searches too. For example, if you don't want anyone from high school to find you, uncheck the box next to "people in high school networks."

Step 5: Stop Sharing Personal Info with Unknown Applications

Remember when we told you about what Facebook quizzes know about you? Using Facebook's default settings, you're unknowingly sharing a plethora of personal information (and your friends' info too!) with various Facebook applications and the developers who created them. The problem is so bad that the ACLU recently created their own Facebook Quiz to demonstrate how much information an app has access to.

It's time to take back control! From the Facebook homepage, hover your mouse over the "Settings" menu and choose "Privacy Settings" from the drop-down list. On the next page, click "Applications" then click the tab that reads "Settings" which is next to the "Overview" tab. (Oh, and if you want to really be freaked out, read that overview!)

On this page, you can check and uncheck boxes next to your personal information (picture, education history, wall, religious views, etc.). This controls what the applications your friends are using can see about you. Yes, your friends' apps can see your personal info if you don't make this change! Believe it or not, you don't have the same control over your own apps. The best you can do is head over to the Applications page and delete the apps you're not using anymore. (Use the "X" to remove them.) You see, once you authorize an application, you're telling it that it's OK to access any information associated with your account that it requires to work. While some developers may only pull what's actually required, many others just pull in everything they can. Scary, isn't it?

Conclusion

While this is by no means a comprehensive guide to Facebook security and privacy, these five steps can help you get started in creating a safer, more secure, and more private environment on the social network.

However, if you choose not to take any precautions, then you'll only have yourself to blame when an errant wall post or naughty photo makes its way online and straight into Grandma's News Feed, or worse, your boss's. These days, it's better to be safe than sorry, so go ahead and delve into those settings!

Unfortunately, there seemed to be a problem with the new security feature: it wasn't working...or at least, so it seemed. As it turns out, the problem was that users weren't informed as to how to properly activate the anti-phishing protection, an issue that points to a poor implementation of what could and should have been a major breakthrough in mobile computing technology.

Although Apple touted the anti-phishing protection back in March when they announced their 3.0 update, the new feature didn't actually materialize until this month when the company released the OS 3.1 iPhone/iPod Touch software. According to Apple, the anti-phishing protection feature will display an on-screen warning message when you attempt to visit a known malicious website.

Once the update was released, security researchers and other Apple enthusiasts began testing the new technology. The results were immediately disappointing. "I've not been able to get it to block anything," Michael Sutton, vice president of research at security firm Zscaler was quoted as saying. He had been testing the feature using known phishing websites identified by the anti-phishing database hosted at PhishTank. The Mac Security Blog also found after extensive testing that it simply "does not seem to work." MacWorld, however, found that the feature worked sometimes, but the inconsistency hinted that the technology was not "ready for public consumption," they reported.

What gives? Did Apple really release a broken feature? Were they even aware of the problem? Blogger Jim Dalrymple of The Loop decided to go straight to the source: he asked Apple.

Apple Says "You're Doing it Wrong"

Apparently, this was not a case of the anti-phishing technology being broken. It was a case of everyone simply "doing it wrong." As it turns out, in order for Safari's anti-phishing database to update, there are a few particular steps that need to be followed, explained an Apple spokesperson. After updating the phone to the OS 3.1 update, users need to do the following:

1. Launch the Safari web browser.
2. Connect to a Wi-Fi network.
3. Charge the iPhone with the screen off.

The spokesperson added that for "most users" this process should happen automatically when they charge their phone. We would have to disagree. "Most users" don't launch the Safari browser prior to charging their device - if anything, they close down any open applications before plugging in the phone to charge.

Poorly Implemented, Poorly Explained

If you follow the above steps, the feature will work. However, most users will never know to do this unless they happen to closely follow technology news and blogs. The general mainstream population - the very demographic Apple so craftily attracts via their billion dollar marketing campaigns - expects things to "just work." That is the Apple promise, after all.

Yet even on Apple's own website where they detail the various new features in the OS 3.1 update, there is no mention as to how the anti-phishing protection should be utilized. It simply lists that the feature exists. A helpful link to a "how to" guide would seem appropriate here or, at the very least, a footnote.

Having to perform the somewhat unintuitive steps to get the anti-phishing protection feature to function properly seems like an unusual miss for a company who generally makes things simple and straightforward. Why does it need Wi-Fi, for example? Apple claims that the Wi-Fi connectivity is required so as not to incur any additional data fees for the end user. But launching the browser? We almost wonder if it wouldn't have made better sense for Apple to implement the feature in the new iTunes update instead. The desktop software could retrieve the updated anti-phishing database from the internet upon launch and could then sync it to the iPhone or iPod Touch the next time it was plugged in. That would also alleviate another common problem with the current implementation - if the phone isn't plugged in long enough, the update won't complete and users will only be partially protected. On the other hand, the inclusion of the database via a sync would have ensured that all the data was copied over to the phone.

In the end, though, Graham Cluley, a senior technology consultant at Sophos, reminds us that maybe we shouldn't be too hard on Apple. "Many other smartphones don't offer even the most elementary form of anti-phishing protection to their users," he says. That may be true but, unfortunately, the way Apple chose to deliver their anti-phishing protection feature means that most iPhone users won't be protected either.

Security researchers at Symantec recently uncovered a backdoor trojan whose spread is being dictated by commands hosted in Google Groups, Google's online discussion forums. The backdoor trojan, named Trojan.Grups, appears to be the first ever malware to use an online newsgroup as the "command and control" center for botnet communications. It's certainly the first time that Google Groups specifically has been compromised in this way. This new discovery points to what appears to be the latest trend in what you could call "Web 2.0 malware," that is, nasty computer programs that don't just spread in social networks, but actually use the infrastructure of the social networks themselves to do the spreading.

Botnets are groups of computers compromised by malware programs, often called "zombie computers," which are controlled by "bot herders," the person or persons responsible for remotely controlling the infected PCs, unbeknownst to the PCs' owners. Traditionally, a centralized server of some sort would issue the commands that instruct the computers what action to perform. In many cases, the zombie machines are used to send out spam, to perform click fraud, to aid in identity theft, or are directed to attack another web server on the internet, as was recently seen with the Twitter/Facebook/LiveJournal attacks of last month.

With this particular new trojan, the command-and-control center for issuing the botnet commands is not a single server on the internet. It's Google Groups itself. Using a private newsgroup, the trojan executes a command which logs it into the newsgroup and requests a specific page. The page contains the encrypted commands the malware is to carry out. The responses from the compromised machines are then sent back to Google Groups and are uploaded as posts to the newsgroup.

According to security company Symnatec's analysis of this new trojan, it appears that it is a prototype implementation meant to test the feasibility of using newsgroups in this way. The trojan is attempting to remain discreet and undetected, being used to subtly gather information and potentially determine its future attack targets. The researchers think that the trojan may have been developed for targeted corporate espionage where anonymity and discretion are priorities.

Using Web 2.0 as the C&C for Botnets

This latest trojan isn't the first to use a social network to aid in its spread. What is unusual about it, though, is that it actually uses the social network that is Google Groups to host the commands which control the malware's actions. This is a different sort of scenario than your typical social networking-based malware which simply uses popular online networks as the vector for the attack. This is using the network as the brains.

Another recent example of this sort of Web 2.0-controlled malware involves the recent discovery of a botnet which used Twitter.com to issue commands. In an arguably ingenious move, Brazilian identity thieves created a Twitter account for the sole purpose of sending out commands to its associated malware. Each command was posted as a status update to the Twitter account. As researchers noted at the time, this sort of setup could have used any number of web sites or services on the internet to do the same - all that was needed was an RSS feed. In fact, the same malware was later seen on both Jaiku.com, a Twitter-like service acquired by Google in 2007, and Tumblr, a simple blogging platform.

Given the open, "anyone-can-post" nature of Web 2.0 and social networking services, the online communities that have become the de facto standard on today's web, it was only a matter of time before that openness was compromised by hackers wishing to use the services for more nefarious purposes than just "sharing with your friends."

For now, there are still relatively few incidents where a botnet has been discovered as using a Web 2.0 service as the command-and-control center for operations. However, the idea must surely appeal to botnet operators as hiding these sorts of messages in the larger social networking infrastructures that house valid communications makes the botnets harder to identify and shut down. You can't simply blacklist the IP or URL once discovered - you have to rely on the social networking vendor to remove the malicious accounts. If any of these recent efforts at web 2.0-controlled malware are successful (and the Google Groups trojan has been - it's been around since November 2008!), then it's likely we'll begin to see even more programs like this in the future.

The Danger of Quizzes

With each question in the ACLU's Privacy Quiz, you're not only told what information a quiz author can see - you're shown it. For example, after answering the first question, you learn that almost everything on your profile, even if you use privacy settings to limit access, is available to the quiz. Then, a graphic is shown which reveals selected information retrieved from your profile including hometown, groups you belong to, events attended, favorite books, and more.

The second question is even more disturbing. It informs you that everything on your profile is made available to the developers when your friends take a quiz. To drive this point home, the ACLU's Quiz loads up information pulled from your friends' profiles and displays that data below the answer for your perusal. Here, information on your friends is shown including hometowns, favorite books, political views, networks, birthdays, number of wall posts, and even personal photos. Thanks to the quiz, all that info which you can see on your friends' profiles is now available to the quiz author, too.

Lest you think your info is safe because somewhere, somehow Facebook is looking out for you, the third question shatters any illusions you may have about that, too. According to the answer to this quiz question, not only do Facebook's default privacy settings do nothing to prevent application developers from scouring your information, Facebook also doesn't screen developers for trustworthiness, nor do they require the developer to comply with a privacy policy (something we've mentioned before). It's also noted that Facebook does not use any technical measures to limit how developers can collect and use personal information. Says Chris Conley, a technology fellow with the ACLU, it's difficult to know how developers use this data, which could, in theory, be collected and sold for marketing and advertising campaigns.

Finally, the last question prompts you to take action. When the quiz asks you what you should do, the correct answer is: "demand the right to control my information without sacrificing the right to use new technology." To get the word out there, the ACLU suggests you update your privacy settings, share their quiz on Facebook, and sign their online petition.

Is This True?

The nature of the quiz makes it sound a bit like fear-mongering, especially with statements like this: "Once details about your personal life are collected by a quiz developer, who knows where they could end up or how they could be used. Shared? Sold? Turned over to the government?" However, outside of these overly dramatic tactics, the claims made by the ACLU are true. According to CNET, Facebook doesn't even deny that quiz developers have access to this sort of information. The company does point out that users can limit how much information applications (including friends' applications) can see by tweaking their privacy settings.

Note: To do this yourself, go to Settings -> Privacy Settings -> Applications. From there, you can uncheck the boxes next to the items which you don't want apps to have access to.

Still, the ACLU suggests that access to personal information such as this be opt-in rather than opt-out, as it is now. Facebook spokesman Barry Schnitt says the company "generally agrees" with the ACLU's recommendations and notes that the social network recently disabled hundreds of applications that were inconsistent with Facebook Platform policies. He also mentions the company has been working with the Canadian Privacy Commissioner, Jennifer Stoddart, to improve user data controls on Platform. 

This is just one of the concerns that will be addressed later today when Stoddart announces the agreement that has been reached between her country and the social network in terms of privacy protocols. Stoddart ruled last month that Facebook had 30 days to come up with a plan to comply with Canada's Personal Information Protection and Electronic Documents Act or face court action.

Mitnick is probably a formidable security expert, but the simple fact of the matter is that one man, let alone one company, is unlikely to be able to defend against multiple and persistent attackers. While Mitnick spends up to $20,000 per year on his phone bill, companies are likely spending at least twice that to protect his accounts.

Said Mitnick, "You'd think they'd like to talk to me and say 'how do you think these guys are getting in?" Despite the fact that Mitnick has turned over a new leaf, one might understand why a company like AT&T would rather wash its hands of Mitnick as a client, rather than taking advice from him. After all, Mitnick's combination of hacking and "social engineering" once gave him illegal access to computer systems at Motorola, Nokia, Siemens and allegedly the Pacific Bell Telephone Company - better known as AT&T California.

As before, the new variant of Koobface still points users to a fake Twitter page (or a fake Facebook page, if you happened to come across Koobface on the Facebook social network). On the page, users are prompted to download a Flash Player update in order to view a video file. Of course, clicking the link to update Flash actually starts the malware's payload downloading instead. In order to get users to this point to begin with, Koobface sent out tweets reading "My home video :) [URL]."

Recently, Koobace has ramped up its complexity and is sending out unique tweets that have some sort of random component added to the end of the tweet, with strings like "HA-HA-HA!!", "W.O.W.", "WOW", "L.O.L.", "LOL", ";)" or "OMFG!!!"

What's even worse about the latest Koobface variant is that the landing page for the malware attack was also adding a random component to the URL, allowing it to get shortened to a different bit.ly URL each time a message was posted. As of late last week, security firm Kaspersky Lab had identified nearly 100 unique IP addresses hosting the Koobface worm. They've since been able to take the main Koobface site down to stop the current set of attacks, but don't be fooled - there's no doubt that it's only a matter of time before Koobface relaunches with yet another dangerous twist. In fact, that's been par for the course for this piece of malware which has been attacking social networks since July 2008. Taking down one Koobface vector of attack is like playing a game of "whack-a-mole" - you hit one and another pops up to take its place.

The Real Problem: Short URLs

One of the main reasons Koobface was able to so easily spread on Twitter was due to its use of the bit.ly URL shortener, now the default on Twitter. Not only was Koobface varying its URL to ensure a unique bit.ly link each time, Twitter's new malicious URL filtering system doesn't help protect users against pre-shortened URLs.

As we mentioned before, without a focus on shortened links, Twitter's filtering system is simply not good enough. It's far too easy to use bit.ly's website or a third-party Twitter client to shorten a URL before it ever hits Twitter's web interface to be checked. And naturally, this is precisely what malware writers do. The only malicious URLs Twitter's current system protects us against are those posted by unsuspecting Twitter users themselves. The bad guys certainly know better and Koobface is a perfect example of this.