Some additional features I’d like to see are:

• Search based filtering. Many sites will fire off a couple of hundred urls in a single page load, drilling down through the mess to those specific urls you’re looking for would be easier with some sort of filtering. httpWatch has probably the best filtering I’ve seen on any similar tool to date, I couldn’t see any search functions at all
• On the timeline I’d like to see the a clearer indication of the various aspects of each connection eg; have the DNS lookup in one colour, connection in another, first-byte download in another etc. Whilst this is available if you go into each call/line-item it would be nice to have the option to customise this output.
• It would be great to have the ability to export the data in different formats eg; CSV.
• Display Flash objects in the preview tab. Currently it renders GIF, JPG PNG etc, it would be nice to have the Flash object rendered as well.
• Display any video data eg; dimensions, codec, audio/video bitrates etc.
• Non HTTP traffic such as streaming services, eg; RTMP, RTMPT, RTMPE, RTSP & MMS

It’s certainly a step in the right direction and I’m most grateful for this latest addition to Chrome. My continued favourite tool is httpWatch, not only does it provide excellent filtering/search capabilites but genrally makes tracing HTTP calls a little easier than the curent Google Developer Toolbar does. However, a team licence (that’s four licences) for httpWatch will set you back just under £1000.

Further Information:
http://code.google.com/chrome/devtools/docs/network.html

On the desktop I have access to numerous tools that help me understand and debug what my adserver is doing. Tools such as httpWatch, httpFox, Fiddler2, Charles, HTTPScoop and FireBug. These tools intercept HTTP traffic and allow you to analyse, check and view the response from the remote adserver. I use this extensively to test response times, debug connectivity & delivery issues, view mimetypes & cookie data amongst other tasks. Once you’ve used these tools it’s difficult to understand how you’ve managed so long without them… that is until you start delivering ads outside of your desktop environment where these tools no longer exists or the devices are unable to provide this information natively or without jailbreaking/rooting your phone.

So, when we started developing the next iteration of our iPhone app we needed to create an environment where we could replicate the tools we’ve come to expect on the desktop for the mobile app as well. Having just moved our entire team to MacOS from Windows based machines this proved to be interesting.

How this works:
Basically we are creating an ad-hoc network on your Mac desktop which the iPhone or other device can connect to. We are then going to route the mobile traffic through your desktop’s Ethernet connection. HTTPScoop sits on the ethernet connection watching and reporting all traffic that flows through it to port 80 (or whatever port you have decided to monitor). This method allows you to visualise the HTTP traffic of your iPhone/Android etc on your desktop and enable you to check these calls are being made correctly. This tutorial describes how to setup your desktop (I’ve used Snow Leopard, MacOS X here) to intercept and display HTTP requests using HTTPScoop made by your mobile device. it requires that you have or are running the following:

Requirements:

• MacOS X (I’m using 10.6 – Snow Leopard) running Airport
• A working copy of HTTPScoop (http://www.tuffcode.com/) Free 14 day trial or only £10 per licence
• An active internet connection.
• Mobile device running the app you need to test

Process Outline: This is what we’ll be covering.

1. Using Internet Sharing create an ad-hoc wireless network through your Airport card.
2. Connect mobile device to the ad-hoc wireless network
3. Start HTTPScoop and configure to show http ethernet traffic
4. Activate the mobile app and watch the results.

Create an ad-hoc wireless network through your Airport card.

1. Got to System Preferences and click Sharing under the ‘Internet & Wirleess‘ group.
2. If needed click the padlock to make changes
3. In the Services list click Web Sharing, we need to activate this as otherwise internet sharing will not work properly for some reason.
4. Next click the Internet Sharing service, options (‘Share your connections from’ and ‘To computers using’) will appear to the right of this.
5. Choose Ethernet from ‘Share your connection from:‘
• tick Airport from the list ‘To computers using‘
• click ‘AirPort Options‘
• Name your Network eg; ‘AdOps’
• Enable WEP encryption and add suitable password if needed (it is WEP after all!) & click OK
• Tick the Internet Sharing box (in the Services list) to activate it, this will grey out the Internet Sharing options., the icon should now have turned green (previously it may have been red). You will be asked for your password to authrorise this.
6. Tick the Internet Sharing Box this will activate Internet Sharing, you will be asked to confirm this is what you want, click ‘Start‘ to continue.
7. Retick the padlock to submit and lock the changes.
8. Your ad-hoc wireless is now setup and ready for you to connect your mobile device to it.

Start HTTPScoop and configure to show http traffic: Connecting to and tracing/view those HTTP calls.

1. Start your copy of HTTPScoop. Next we will configure it to show the traffic you want.
2. Choose the Ethernet (‘eth0‘ or ‘en0‘) option from the dropdown to the right of the HTTPScoop window) then click ‘Scoop‘ – this will start to track all HTTP traffic on your ethernet connection NB: You may see other traffic appear if you have other apps/browser running in the background which are active. To make things simpler close any browsers and other apps using HTTP Traffic down (eg; RSS readers).
3. Click the ‘Scoop’ button, this will start recording the HTTP traffic, as this is a privileged service you will need to enter your password.

Connect mobile device to the ad-hoc wireless network:

1. Connect your iPhone/Android/Tablet or other device to the newly created ad-hoc network.
2. Start the application you wish to monitor, after a while & when the app is making HTTP calls you will start to see data being recorded into HTTPscoop.

Caveats & Postscript:

• HTTPScoop by default only monitors HTTP traffic on port 80. If you need to monitor other traffic eg; HTTPS on port 443 then this can be accomplished by turning HTTPScoop off and amending the ports monitored through HTTPScoop->Preferences.
• Yes, I am aware that this method does theoretically allow you to set up and adhoc network and monitor any attached device (whether it belongs to you or you have permission to view this data or not) so please use this method wisely. Be aware that you MUST have permission to intercept the mobile device’s HTTP Traffic, capturing unauthorised HTTP traffic may be illegal in some jurisdictions..
• HTTPScoop has more help/information here: http://www.tuffcode.com/support.html
• I’ll be posting alternative methods using different software (eg; Charles debugging Proxy) as well as methods that work on Windows very soon.

Links:
HTTPScoop

This technique uses the open-source ffmpeg package, you don’t really need to know exactly how ffmpeg works suffice to say it’s an extremely powerful command-line application that allows you to work directly on files, but I will try and explain a little of how it works here. This article is intended as a simple guide as to how easily you could amend a file’s attributes, this process for a 15s video will take approx 5s to process which would free up significant time and stop a lot of too-ing/fro-ing between Ops & Creative Agency.

To reduce (or increase) audio levels is a one line command like this:

ffmpeg -i myinputfile.flv -vcodec copy -acodec copy -vol 128 myoutputfile.flv

The above command is saying to the system – “Run ffmpeg using myinputfile.flv as the input file, copy all video and audio streams to the new file but amend the audio levels to be 50% of the original file”. This isn’t as complex as it looks, I’ll explain what this does:

ffmpeg -i myinputfile.flv -vcodec copy -acodec copy -vol 128 myoutputfile.flv
This runs the program and tells it the file you want to convert is called myinputfile.flv (or whatever you’ve called the file), the -i stands for ‘inputfile’.

ffmpeg -i myinputfile.flv -vcodec copy -acodec copy -vol 128 myoutputfile.flv
This part of the command is telling ffmpeg that you want to simply copy the video stream directly top the output file, ie; you don;t want to convert it or treat it in anyway

ffmpeg -i myinputfile.flv -vcodec copy -acodec copy -vol 128 myoutputfile.flv
This is the same as -vcodec but instead is telling ffmpeg that you simply want to copy the audio stream to the new file (don’t worry we’ll work with audio levels next)

ffmpeg -i myinputfile.flv -vcodec copy -acodec copy -vol 128 myoutputfile.flv
The -vol flag sets the output file’s volume relative to the input volume. To copy the audio at the exact same level as the input file you would write:
-vol 256
To set it to 50% of the input file you would put
-vol 128
To Set it at 150% of the input file’s audio levels you would put
-vol 384

ffmpeg -i myinputfile.flv -vcodec copy -acodec copy -vol 128 myoutputfile.flv
Lastly you need to specify the output file’s filename.

ffmpeg is an extremely powerful tool but the learning curve can be steep, however, it is open-source, there are plenty of training and informational resources available and best of all, it’s free.

Related links and tutorials:
http://ffmpeg.org/
http://linuxers.org/tutorial/ffmpeg-tutorial-beginners
http://www.wikihow.com/Use-FFmpeg
http://www.bala-krishna.com/convert-video-files-to-flv-using-ffmpeg-command/
http://www.tuxradar.com/content/ffmpeg-made-easy

The tool doesn’t expose data about what cookies were sent or how long each call took (which may be of more use to the more etch focused AdOps staff trying ensure data isn’t being exposed that they don’t want to, but it does provide a clean and simple view of which tagging systems are present in a page.

I’m not going to cover the implications of wide-scale blocking of such tags by users, there’s plenty of opinion, debate and research on these matters suffice to say that protecting your user’s privacy should be at the forefront of your every business decision you make in this area.  Failure to protect your users will only result in a user-base that drifts away to competitor sites where their privacy concerns are met.

It’s worth preparing some responses to individuals in your organisation to deal with questions from your non-techy savvy staff and senior management who may not be fully aware of the variety and sale of tagging systems.

http://www.ghostery.com/

“SWFTools is a collection of code for handling Flash .SWF-files. This includes a
merging tool (swfcombine), an extracting tool (swfextract),
PDF/JPEG/PNG/AVI/TTF/WAV to SWF converters (pdf2swf, jpeg2swf, png2swf, avi2swf,
font2swf, and wav2swf), a text parsing tool (swfstrings), an SWF parser
(swfdump), and a library for writing and reading SWFs (rfxswflib).”

http://freshmeat.net/projects/swftools#release_317771

In the past we used, and still do, tools such as Sothink SWF Decompiler and URLActionEditor to analyse flash files and amend them accordingly. But enter OneVision wo’ve been busy in the intervening years and by all accounts have built out a fully-featured pre-flighting tool called Contenio for use by online AdOps departments to check and authorise creatives as they come into the department. I haven’t yet seen the product working but I’m hopeful it will address some of the ore recurrent themes such as checking for clickTag() case sensitivity/spelling, fix _root. issues, check for embedded urls, check for target=”_blank” etc, but hopefully we’ll get to see this in action soon and report back our findings.

For those of you trying to automate out your QA process this could be of vital interest. I look forward to speaking to someone who’s currently or planning on working with this soon.

http://www.getfirebug.com/faq.html#Sothink