BUGabundo Shared Feed

CLASSIC FAIL: Aisle FAIL

Cheezburger Network — Tue, 31 Aug 2010 13:37:40 -0700

Submitted by: Unknown

Originally Posted on: November 11, 2008

We’re bringing back some of those CLASSIC FAILS so you can add them to your profile FAVORITES. Enjoy it again and add them to your favorites!

Newsbeuter, Mutt and Google

Aaron — Tue, 31 Aug 2010 16:26:37 -0700

I just discovered Newsbeuter supports synchronization with Google Reader. Not only your read/unread feed items, but you can also share and star items in Newsbeuter as you can in the Google Reader interface. This blog post is documenting how. Further, by using Buzz, you can also comment on your shared items, and others. I’ll cover that as well.

First, I like the command line. I like minimalist function and design. It’s always pulled me in. So, this solution is a command line solution. With that said, the command line doesn’t work well for viewing images, does it? This can be problematic for RSS feeds. I understand this. However, since using Newsbeuter for the time I have, I’ve found that I read a lot of blogs that are 100% images, and when push comes to shove, it’s adding a lot of noise to my RSS signal. As a result, I’ve removed a great deal of those feeds, and haven’t missed them. Again, going back to minimalism, I read fewer feeds now, and the signal is much, much higher. However, the link to the RSS feed is in the post itself, so you can follow the link from Newsbeuter to the browser of your choice if you wish. This will be the minority of the time for myself.

Second, this solution is not only using Newsbeuter, but also Mutt. Really, any mail client will work, but I like Mutt, so I’ll be using it in the solution here. Further, we’ll be tying Reader and Buzz together to make a few things work. But, everyone hates Buzz, right? Well, I don’t. I love the tight integration it has with Gmail and with Reader. Yeah, the design is lacking, that’s for sure. And some of the keystrokes are completely bass-ackwards compared to reader, and can cause problems with Gmail. However, because of the integration, and the reply-by-mail feature, which we’ll take advantage of here, you’ll find you won’t miss your Google Reader much (unless you absolutely have to view images in your feeds).

With that said, let’s begin. First, you need to install Newsbeuter 2.2 or greater and an mail client (Mutt, as already mentioned, will be used here). After installing Newsbeuter, you need to configure it to sync with your Google Reader account. Here’s what I set in my ~/.newsbeuter/config:

# setup google reader sync support
urls-source "googlereader"
googlereader-login "username@gmail.com"
googlereader-password "my-password"
googlereader-flag-share "S"
googlereader-flag-star "s"

Make sure you read the documentation about the Google Reader support. Now, fire up Newsbeuter. After authenticating, you will notice that it has populated your feeds, and you can start pulling down the updates to unread items. Here’s a screenshot of my Newsbeuter “home”:

You now have access to your starred items, your shared items, popular items and people that you follow (what others are sharing), but not the comments. That’s okay, we’ll cover how to get access to that in a second. However, if you have access to your starred items and shared items, how do you share or star an item in Newsbeuter? This is done through flags. Newsbeuter has a flagging system that allows a custom categorization of feeds by the user. The flag must be a letter, ether uppercase or lowercase, A-Z and a-z. You set the flag by pressing “Ctrl-e”, then entering the flag you wish to set. Now, you’ll notice that in my config, I have two options that are for flags: “googlereader-flag-share” and “googlereader-flag-star”. If I press “S” for my flag, then it will share the item. If I press “s” for my flag, then it will star the item. Test it, then log into the Google Reader interface to see it work.

Now, when I would share items, they usually were shared with a comment to encourage discussion with those who are following me (or anyone who can read the shared item). However, in Newsbeuter, there is no way to comment on a flagged item directly. Further, when you read items that your friends share, and they have comments with them, how do you add your own commentary? Well, I have a solution, but it doesn’t involve Newsbeuter. Rather, it requires that you use Buzz and an email client.

With Buzz, you can add your Google Reader shared items as a connected page. This means that whenever you share an item on Reader, it will show up as a new item in Buzz. Further, Buzz will send you an email of all the items you’ve posted to your wall, as well as your items that have been commented on. When you receive the email, the body of the message might be something like this (text copied and pasted from Mutt):

Date: Tue, 31 Aug 2010 13:59:49 -0700 (PDT)
From: Aaron Toponce <z12dhj4psprvstctz23vcxg5wleozbfi104@gmail.com>
To: Aaron Toponce <aaron.toponce@gmail.com>
Subject: Buzz from Aaron Toponce [-- Autoview using /usr/bin/elinks -force-html -dump ''/tmp/mutt.html'' --] [1]Aaron Toponce – Google Reader Aug 31, 2010 [2]Man Already Knows Everything He Needs To Know About Muslims - [3]Aaron Toponce's Friends' Facebook Links [4]Man Already Knows Everything He Needs To Know About Muslims Source: [5]www.theonion.com [6][IMG] SALINA, KS—Local man Scott Gentries told reporters Wednesday that his deliberately limited grasp of Islamic history and culture was still more than sufficient to shape his views of the entire Muslim world. I seem to recall that in earlier times it was only the court jester who could get away with speaking unwelcome truth to power. Perhaps that is why comedy often forces us to see things about ourselves we don't want to see. ––––– Reply to this email to add a comment to this post. Link to this post: http://www.google.com/buzz/115784859563110525602/BaqgGreVqdT/Man-Already-Knows-Everything-He-Needs-To-Know References Visible links 1. http://www.google.com/profiles/aaron.toponce 2. http://www.facebook.com/profile.php?id=1068226280&v=wall&story_fbid=124010764315178 3. http://www.facebook.com/posted.php 4. http://www.theonion.com/articles/man-already-knows-everything-he-needs-to-know-abou,17990/ 5. http://www.theonion.com/ 6. http://www.theonion.com/articles/man-already-knows-everything-he-needs-to-know-abou,17990/

Notice the “From” address. It’s a long unique string that gives you access to comment on the post directly. As mentioned in the email, all you have to do is reply to the email, adding your commentary, and it will be posted as a comment on the shared item. You’re actually commenting on a Buzz post, not a Reader post, however, because you tied Reader and Buzz together, they become one and the same. Also, Buzz is smart enough to strip signatures and attachments from the reply, so your email signature and S/MIME PGP attachment will also be stripped. Just make sure you trim your email appropriately, so you’re not adding anything irrelevant to your comment (trim everything out of your reply).

Go back to Reader, pull up the shared item, and notice your comment on the post. Of course, you can comment on others shared items by sharing it first (the “S” flag for me), then replying to the mail sent from Buzz. When Buzz gives the ability to be notified of everything that your friends are posting, then you shouldn’t have to share it also. However, I usually reshare what others have shared, so this isn’t a show-stopper for me, even if it is less than perfect.

UPDATE: I forgot to mention Newsbeuter’s tagging feature. In Google Reader, I have separated my feeds into folders. However, when I sync with Reader, it seems all my feeds are in one massive “river of news”. I don’t like this, and wish the folders were preserved. Well, with Newsbeuter, it is through tags. When in the main window, press “t” and it will take you to your “tags”, or folders as Reader would call it. At which point, you can read only what specific topic you’re interested in. However, I do know that Google Reader supports tagging beyond their folders. I don’t know of a way to apply Reader tags inside Newsbeuter.

Revista zOOm i.t. de Setembro 2010

Carlos Martins — Wed, 01 Sep 2010 01:17:00 -0700

A zOOm it de Setembro já está nas bancas.

Nela podem encontrar alguns comparativos com alguns dos smartphones mais apetecíveis da actualidade, assim como alguns mini-equipamentos para quem não quer andar com a carteira demasiado cheia.

Como sempre, a não perder... e relembro que podem (devem ;) sempre optar pela assinatura, que vos permite poupar uns bons euros ao final de um ano.

Enquanto isso, podem sempre abrir o apetite na versão web da zOOm it, para saberem o que estão a perder.

Future os Screens - Experience video

marcus — Wed, 01 Sep 2010 02:02:00 -0700

Capacitive screens has now become a commodity for touch screen devices. Screen technology is now taking the next leap and the coming years imagination is the only thing stopping us. We will soon have dual screens, malleable screens, screens built into wifi connected mirrors, desks or backside of gadgets clothed with e-ink screens, tactile feedback, color screens with great contrast in sunlight, holographics/stereoscopic screens, color e-ink touch screens, or screens actually knowing where they are in relation to other screens thanks to ultrasonic emitters and microphones.

We want to show some of these things in an "experience video", that shows a normal day in a couple of years when all these technologies are affordable enough to be used everywhere. This video is the result of our experiment with open innovation, read more about our experiment here. Big thanks to all the people from TAT and around the world who helped out and sometimes shared their ideas and sometimes gave us homework on our own ideas.

Concurso de Programação AndroidPT

ESOP — Wed, 01 Sep 2010 04:51:35 -0700

Com o objectivo de incentivar e premiar os programadores que em Portugal desenvolvam aplicações inovadoras com base no sistema operacional Android, a direcção do portal de informação AndroidPT, criou um concurso de programação. A data limite para as últimas inscrições e submissão de aplicações será até as 23h59m do dia 15 de Setembro de 2010.

Os projectos submetidos serão avaliados pela originalidade (30%); pelo uso efectivo da plataforma Android (20%); pelo grafismo e usabilidade (20%) e pelo valor da aplicação (30%). As aplicações submetidas devem ser compatíveis com a versão Android 1.5 ou superior e criadas a partir do Android Software Development Kit (SDK) disponibilizado pela Google em http://developer.android.com.

A todos os que participarem a ESOP deseja votos de boa sorte.

Para mais informações relativamente a este concurso sigam o link: http://concurso.androidpt.com/pagina.php?id=1

CLASSIC: Book FAIL

Cheezburger Network — Wed, 01 Sep 2010 06:00:38 -0700

Submitted by: Unknown

We’re bringing back some of those CLASSIC FAILS so you can add them to your profile FAVORITES. Enjoy it again and add them to your favorites!

Ad WIN

Cheezburger Network — Wed, 01 Sep 2010 08:00:16 -0700

Submitted by: Unknown

loving my class’s Little Moment of Win

Cheezburger Network — Wed, 01 Sep 2010 11:00:39 -0700

My professor paces back and forth while lecturing. Today he wore Heelys (sneakers with heel wheels) and rolled back and forth. IMMD!

Submitted by: loving my class

Apple Moves Forward with Announcements But No Real Surprises

Warner Crocker — Wed, 01 Sep 2010 12:28:08 -0700

Call me tired, call me bored, or just call me. But I think Apple did its usual fall announcement focused on music and Christmas sales today and did it well. That said, there were no real surprises, but this is all about pushing dollars through the cash registers this fall into December, and I think Apple proved, again, it is a master at doing so.

No surprise that Apple led off the event with pictures of some of its new stores in far flung places. The architecture is gorgeous, but the subtext to all those who keep trying to trying to mimic Apple’s success is, unless you can do this, you can only try to compete. Apple owns the retail market when it comes to consumer shopping for the kind of gadgets it sells. So, on to those gadgets.

Apple reinvigorated its iPod line, making the iPod Shuffle smaller still and squashing the iPod Nano into a small square that now features a tiny multi-touch screen. It’s wearable, just like the Shuffle. The iPod Touch got the long expected dual camera routine, and of course FaceTime is hyped big time. You can do some face time between iPod Touches and iPhones. The iPod Touch also gets the Retina Display. It’s running the same A4 processor as the iPhone 4 and priced between $229 and $399 depending on the storage.

Apple announced that iOS 4.1 will be available next week for all but the iPad. The iPad will see iOS 4.2 in November which is disappointing. The big features trumpeted in 4.1 are HDR photos, which is a way of bracketing a picture with different exposures for a supposedly better result, and Game Center, which will let you connect up your game playing with others. Apple continues to push gaming on the iPod Touch in a big way and this appears to be paying off.

The iOS 4.2 promises to add the features of iOS 4.1 (and earlier) as well as wireless printing from the iPad and also something called Air Play. Essentially Air Play allows you to share media (music, photos, videos). This was formally a feature known as Air Tunes, but the addition of photos and videos heralds the other product Apple updated today and that’s Apple TV 2.0.

Jobs as always called this a hobby and I guess he’s ready to go for it beyond that stage. The box is redesigned and allows streaming via WiFi as well as an ethernet connection. The box is tiny (about 1/4 of the size of it’s predecessor) and to fill it up with content you rely on streaming. Apple says that customers don’t want storage hassles, so its moving to a rental policy. TV shows (initially Fox and ABC) for $.99 and first run movies available on the same day as the DVD release for $4.99. The box will set you back $99.

Of course to tie it all together in a pretty holiday bow, Apple announced a new version of iTunes and as predicted it now has a range of social features. You can follow friends, music stars, and the like, and share info back and forth. I sure hope they did some work on the iTunes architecture because it is clunky enough without adding too much more to it that could slow it down. In any regard, Apple calls this social addition, Ping. Which I’m guessing is going to infuriate a lot of folks who don’t like Apple and use the jargon, “ping me” in a variety of ways.

It’s all entertainment, all the time, movies, music, photos, you name, and Apple continues to dominate, but as I said at the beginning, they can dominate so handily because of that retail experience and while the geeks may or may not be impressed, I look for the consumers to be come holiday shopping season.

Side Note: I watched most of the event via Apple’s streaming media using the iPad. It worked reasonably well. Supposedly this was a test to check out the load on Apple’s new server farm. Translated that means Apple is slowly taking steps towards doing even more streaming than was announced. The stream was pretty good, stuttered several times (this seemed somewhat universal as I would see folks experiencing a similar thing via Twitter) but all in all was basically a good experience. I also gave it a try on the iPhone 4 and it seemed to work well there as well, although I experienced more interruptions that threw me back to the start of the broadcast.

Securing Android LVL Applications

Tim Bray — Wed, 01 Sep 2010 13:13:00 -0700

[This post is by Trevor Johns, who's a Developer Programs Engineer working on Android. — Tim Bray]

The Android Market licensing service is a powerful tool for protecting your applications against unauthorized use. The License Verification Library (LVL) is a key component. A determined attacker who’s willing to disassemble and reassemble code can eventually hack around the service; but application developers can make the hackers’ task immensely more difficult, to the point where it may simply not be worth their time.

Out of the box, the LVL protects against casual piracy; users who try to copy APKs directly from one device to another without purchasing the application. Here are some techniques to make things hard, even for technically skilled attackers who attempt to decompile your application and remove or disable LVL-related code.

You can obfuscate your application to make it difficult to reverse-engineer.
You can modify the licensing library itself to make it difficult to apply common cracking techniques.
You can make your application tamper-resistant.
You can offload license validation to a trusted server.

This can and should be done differently by each app developer. A guiding principle in the design of the licensing service is that attackers must be forced to crack each application individually, and unfortunately no client-side code can be made 100% secure. As a result, we depend on developers introducing additional complexity and heterogeneity into the license check code — something which requires human ingenuity and and a detailed knowledge of the application the license library is being integrated into.

Technique: Code Obfuscation

The first line of defense in your application should be code obfuscation. Code obfuscation will not protect against automated attacks, and it doesn’t alter the flow of your program. However, it does make it more difficult for attackers to write the initial attack for an application, by removing symbols that would quickly reveal the original structure of a compiled application. As such, we strongly recommend using code obfuscation in all LVL installations.

To understand what an obfuscator does, consider the build process for your application: Your application is compiled and converted into .dex files and packaged in an APK for distribution on devices. The bytecode contains references to the original code — packages, classes, methods, and fields all retain their original (human readable) names in the compiled code. Attackers use this information to help reverse-engineer your program, and ultimately disable the license check.

Obfuscators replace these names with short, machine generated alternatives. Rather than seeing a call to dontAllow(), an attacker would see a call to a(). This makes it more difficult to intuit the purpose of these functions without access to the original source code.

There are a number of commercial and open-source obfuscators available for Java that will work with Android. We have had good experience with ProGuard, but we encourage you to explore a range of obfuscators to find the solution that works best for you.

We will be publishing a separate article soon that provides detailed advice on working with ProGuard. Until then, please refer to the ProGuard documentation.

Technique: Modifying the license library

The second line of defense against attack from crackers is to modify the license verification library in such a way that it’s difficult for an attacker to modify the disassembled code and get a positive license check as result.

This actually provides protection against two different types of attack: it protects against attackers trying to crack your application, but it also prevents attacks designed to target other applications (or even the stock LVL distribution itself) from being easily ported over to your application. The goal should be to both increase the complexity of your application’s bytecode and make your application’s LVL implementation unique.

When modifying the license library, there are three areas that you will want to focus on:

The core licensing library logic.
The entry/exit points of the licensing library.
How your application invokes the licensing library and handles the license response.

In the case of the core licensing library, you’ll primarily want to focus on two classes which comprise the core of the LVL logic: LicenseChecker and LicenseValidator.

Quite simply, your goal is to modify these two classes as much as possible, in any way possible, while still retaining the original function of the application. Here are some ideas to get you started, but you’re encouraged to be creative:

Replace switch statements with if statements.
Use XOR or hash functions to derive new values for any constants used and check for those instead.
Remove unused code. For instance, if you’re sure you won’t need swappable policies, remove the Policy interface and implement the policy verification inline with the rest of LicenseValidator.
Move the entirety of the LVL into your own application’s package.
Spawn additional threads to handle different parts of license validation.
Replace functions with inline code where possible.

For example, consider the following function from LicenseValidator:

public void verify(PublicKey publicKey, int responseCode, String signedData, String signature) { // ... Response validation code omitted for brevity ... switch (responseCode) { // In Java bytecode, LICENSED will be converted to the constant 0x0 case LICENSED: case LICENSED_OLD_KEY: LicenseResponse limiterResponse = mDeviceLimiter.isDeviceAllowed(userId); handleResponse(limiterResponse, data); break; // NOT_LICENSED will be converted to the constant 0x1 case NOT_LICENSED: handleResponse(LicenseResponse.NOT_LICENSED, data); break; // ... Extra response codes also removed for brevity ... }

In this example, an attacker might try to swap the code belonging to the LICENSED and NOT_LICENSED cases, so that an unlicensed user will be treated as licensed. The integer values for LICENSED (0x0) and NOT_LICENSED (0x1) will be known to an attacker by studying the LVL source, so even obfuscation makes it very easy to locate where this check is performed in your application’s bytecode.

To make this more difficult, consider the following modification:

public void verify(PublicKey publicKey, int responseCode, String signedData, String signature) { // ... Response validation code omitted for brevity … // Compute a derivative version of the response code // Ideally, this should be placed as far from the responseCode switch as possible, // to prevent attackers from noticing the call to the CRC32 library, which would be // a strong hint as to what we're done here. If you can add additional transformations // elsewhere in before this value is used, that's even better. java.util.zip.CRC32 crc32 = new java.util.zip.CRC32(); crc32.update(responseCode); int transformedResponseCode = crc32.getValue(); // ... put unrelated application code here ... // crc32(LICENSED) == 3523407757 if (transformedResponse == 3523407757) { LicenseResponse limiterResponse = mDeviceLimiter.isDeviceAllowed(userId); handleResponse(limiterResponse, data); } // ... put unrelated application code here ... // crc32(LICENSED_OLD_KEY) == 1007455905 if (transformedResponseCode == 1007455905) { LicenseResponse limiterResponse = mDeviceLimiter.isDeviceAllowed(userId); handleResponse(limiterResponse, data); } // ... put unrelated application code here ... // crc32(NOT_LICENSED) == 2768625435 if (transformedResponseCode == 2768625435): userIsntLicensed(); } }

In this example, we’ve added additional code to transform the license response code into a different value. We’ve also removed the switch block, allowing us to inject unrelated application code between the three license response checks. (Remember: The goal is to make your application’s LVL implementation unique. Do not copy the code above verbatim — come up with your own approach.)

For the entry/exit points, be aware that attackers may try to write a counterfeit version of the LVL that implements the same public interface, then try to swap out the relevant classes in your application. To prevent this, consider adding additional arguments to the LicenseChecker constructor, as well as allow() and dontAllow() in the LicenseCheckerCallback. For example, you could pass in a nonce (a unique value) to LicenseChecker that must also be present when calling allow().

Note: Renaming allow() and dontAllow() won’t make a difference, assuming that you’re using an obfuscator. The obfuscator will automatically rename these functions for you.

Be aware that attackers might try and attack the calls in your application to the LVL. For example, if you display a dialogue on license failure with an “Exit” button, consider what would happen if an attacker were to comment out the line of code that displayed that window. If the user never pushes the “Exit” button in the dialog (which is no not being displayed) will your application still terminate? To prevent this, consider invoking a different Activity to handle informing a user that their license is invalid, and immediately terminating the original Activity; add additional finish() statements to other parts of your code that get will get executed in case the original one gets disabled; or set a timer that will cause your application to be terminated after a timeout. It’s also a good idea to defer the license check until your application has been running a few minutes, since attackers will be expecting the license check to occur during your application’s launch.

Finally, be aware that certain methods cannot be obfuscated, even when using a tool such as ProGuard. As a key example, onCreate() cannot be renamed, since it needs to remain callable by the Android system. Avoid putting license check code in these methods, since attackers will be looking for the LVL there.

Technique: Make your application tamper-resistant

In order for an attacker to remove the LVL from your code, they have to modify your code. Unless done precisely, this can be detected by your code. There are a few approaches you can use here.

The most obvious mechanism is to use a lightweight hash function, such as CRC32, and build a hash of your application’s code. You can then compare this checksum with a known good value. You can find the path of your application’s files by calling context.GetApplicationInfo() — just be sure not to compute a checksum of the file that contains your checksum! (Consider storing this information on a third-party server.)

[In a late edit, we removed a suggestion that you use a check that relies on GetInstallerPackageName when our of our senior engineers pointed out that this is undocumented, unsupported, and only happens to work by accident. –Tim]

Also, you can check to see if your application is debuggable. If your application tries to keep itself from performing normally if the debug flag is set, it may be harder for an attacker to compromise:

boolean isDebuggable = ( 0 != ( getApplcationInfo().flags &= ApplicationInfo.FLAG_DEBUGGABLE ) );

Technique: Offload license validation to a trusted server

If your application has an online component, a very powerful technique to prevent piracy is to send a copy of the license server response, contained inside the ResponseData class, along with its signature, to your online server. Your server can then verify that the user is licensed, and if not refuse to serve any online content.

Since the license response is cryptographically signed, your server can check to make sure that the license response hasn’t been tampered with by using the public RSA key stored in the Android Market publisher console.

When performing the server-side validation, you will want to check all of the following:

That the response signature is valid.
That the license service returned a LICENSED response.
That the package name and version code match the correct application.
That the license response has not expired (check the VT license response extra).
You should also log the userId field to ensure that a cracked application isn’t replaying a license response from another licensed user. (This would be visible by an abnormally high number of license checks coming from a single userId.)

To see how to properly verify a license response, look at LicenseValidator.verify().

As long as the license check is entirely handled within server-code (and your server itself is secure), it’s worth nothing that even an expert cracker cannot circumvent this mechanism. This is because your server is a trusted computing environment.

Remember that any code running on a computer under the user’s control (including their Android device) is untrusted. If you choose to inform the user that the server-side license validation has failed, this must only be done in an advisory capacity. You must still make sure that your server refuses to serve any content to an unlicensed user.

Conclusion

In summary, remember that your goal as an application developer is to make your application’s LVL implementation unique, difficult to trace when decompiled, and resistant to any changes that might be introduced. Realize that this might involve modifying your code in ways that seem counter-intuitive from a traditional software engineering viewpoint, such as removing functions and hiding license check routines inside unrelated code.

For added protection, consider moving the license check to a trusted server, where attackers will be unable to modify the license check code. While it’s impossible to write 100% secure validation code on client devices, this is attainable on a machine under your control.

And above all else, be creative. You have the advantage in that you have access to a fully annotated copy of your source code — attackers will be working with uncommented bytecode. Use this to your advantage.

Remember that, assuming you’ve followed the guidelines here, attackers will need to crack each new version of your application. Add new features and release often, and consider modifying your LVL implementation with each release to create additional work for attackers.

And above all else, listen to your users and keep them happy. The best defense against piracy isn’t technical, it’s emotional.

Warning WIN

Cheezburger Network — Wed, 01 Sep 2010 16:15:36 -0700

Submitted by:

Ted-m

Picture by: Unknown

September 02, 2010

(author unknown) — Wed, 01 Sep 2010 21:00:00 -0700

ImgBurn 2.5.2.0

(author unknown) — Wed, 01 Sep 2010 22:29:11 -0700

ImgBurn is a lightweight CD / DVD / HD DVD / Blu-ray burning application that everyone should have in their toolkit!

Sharing a shell and monitoring the other party

Mackenzie — Wed, 01 Sep 2010 22:42:00 -0700

Recently, I had a reason to allow someone else to use a shell on a machine for which I'm the admin, but I wanted a way to track what they're doing. You might think the history command is just fine for this, but it's possible to clear the history, and I wouldn't want that. Screen to the rescue!

I ssh'd into the machine and created a new user for my visitor. Then I switched to that user. Once logged in, I ran screen -L, which logs the shell (both input and output) to ~user/screelog.0). Then I called up the user, gave them the IP address, username, and password. They logged in, and I told them to run screen -ls to see a list of open screen sessions. The output looks like this:

There is a screen on: 2119.pts-0.marlyn	(09/01/2010 06:32:03 PM)	(Attached)
1 Socket in /var/run/screen/S-maco.

The next step was for them to type screen -x 2119.pts-0.marlyn Once they did this, we could each see what the other saw in our SSH session, and it was all logged. Great! I could keep track of what they were doing as they were doing it and review the logs later for a double check.

It's not a VCS though. If you know what directory they'll be operating in, you might want to run bzr init ; bzr add ; bzr commit -m "starting point" first, so you can later run bzr diff | less to see what files changed and keep a record of what changed, since while it might all seem perfectly logical while it's happening, recalling the exact changes won't be easy. The point of watching can be to catch them in the act if they try to do something that violates your security policy or to be given a demonstration.

From http://ubuntulinuxtipstricks.blogspot.com