HttpWatch added support for Firefox 2 & 3 back in 2008 and we’ve updated it to support the 39 major versions released since then.

Sadly, the last Firefox version HttpWatch will support is 40 (the one released this week, August 11, 2015). The main reason is that Firefox 41 will drop support for native extensions like HttpWatch:

https://blog.mozilla.org/addons/2015/05/04/dropping-support-for-binary-components/

Unfortunately, porting the HttpWatch extension to JS/XUL or using JS c-types is not feasible due to the large development effort required, the inability to maintain a low performance overhead and the limited interfaces available to the underlying Firefox web and network components.

It’s not just the dropping of binary extension support that has forced this decision. The rapid 6 week release cycle has made it increasingly difficult for developers and Firefox users to keep their extensions working with each new release. We have come to the conclusion our development time would be better spent adding more features to HttpWatch on Internet Explorer and adding new ways to sniff HTTP traffic from other browsers.

If you want to carry on using HttpWatch, for as long as possible, the best option is to use Firefox ESR version 38. It will work with HttpWatch version 10 and receive security fixes until approximately March 2016.

UPDATE: Mozilla is also deprecating the XPCOM and XUL technologies that have been the foundation of the Firefox extension system.

UPDATE: You can still Firefox 40 to test HTTP/2 with HttpWatch by downloading it from https://ftp.mozilla.org/pub/firefox/releases/40.0.3/win32/en-US/

This blog post isn’t about HTTP performance or HttpWatch itself but you may find it useful if you advertise a software product with Google Adwords. Hopefully, you’ll also find our conversation with Google amusing!

What Happened ?

We received an email like this:

Subject: Your AdWords account: Ads not running due to AdWords Advertising Policies

Hello,

We wanted to alert you that one of your sites violates our advertising policies. Therefore, we won’t be able to run any of your ads that link to that site, and any new ads pointing to that site will also be disapproved.

Here’s what you can do to fix your site and hopefully get your ad running again:

1. Make the necessary changes to your site that currently violates our policies:

      Display URL: httpwatch.com

      Policy violation: Unwanted software

      Details & instructions: 

https://support.google.com/adwordspolicy/answer/50423?hl=en_GB

…

At first it looked like a phishing email as we go to great lengths to ensure that our software is easily uninstalled and that we never mislead anyone into installing it (e.g. bundling with other applications).
After a few checks it was clear that the email was legitimate and that our ads had been dropped from Google search.

The page linked by the email didn’t suggest anything that applied to our software. The two main points were:

• Malicious software or “malware” that may harm or gain unauthorised access to a computer, device or network
• Promotions that violate Google’s Unwanted Software policy

We got in touch with Google Support as there were no obvious violations of their advertising policy.

Our Conversation With Google Support

Here’s a subset of our conversation with Google Support:

Google Support: How can we help you? *

Simtec: We received a ‘Policy violation: Unwanted software’ notification with no detailed explanation of why this occurred. It makes no sense. Our software is only installed when users download and run the setup program. It is uninstalled in the standard way by going to the Windows Control Panel ‘Uninstall Program’ section.

Please can you tell us how we can get our ads re-instated? We’ve been advertising the same software on Adwords for almost 12 years and have spent over a $ 1 million. We are amazed that you would just drop our ads with no pre-warning or at least a decent explanation of the problem

Google Support:  Hi there, thanks for chatting in today! I have your question here, so just give me a moment to take a look

Google Support: Did you make any recent changes to your website or anything?

Simtec: Our website was updated in February to make it mobile friendly

Google Support: Hm, but otherwise nothing else?

Simtec: Nothing else. Don’t you have a detailed reason why this occurred?

Google Support: Just one second, let me find the right form. ? I want to see if I can get more visibility for you

Simtec: Frankly, we’re furious that we have spent so much money with Google to have our ads dropped without any details or warning

Google Support: Unfortunately I don’t have control over that right now but I can look into it for you

….

Google Support: I looked through this, and it seemed that one of the issues was a lack of an End User Agreement (EULA)

Simtec: An EULA is displayed by the setup program before installing starts. Also, the end user license agreements are linked to from here http://www.httpwatch.com/buy/orderingfaq.aspx#licensetypes

Google Support: Hmm, They do want it on the download page itself

Simtec: How come there isn’t one here? https://www.google.co.uk/chrome/browser/desktop/

Google Support: Lol

Simtec: No really?

Google Support: That’s a great question

Simtec: Seems like you guys should put our ads back up, apologise and then sort out your policies

…

Google Support: Ah okay, So if you click the download (for Chrome) there’s a popup with the TOS

Simtec: There is when the program (HttpWatch Setup) runs. You can’t install it without agreeing the EULA

Google Support: So after you download it? The install requires a EULA?

Simtec: Yes, the setup will not install anything unless you agree to the EULA. It has an ‘I Agree’ button. We’ve been doing that for more than a decade. Why the change now?

Google Support: I’m not sure when the change occurred, but if we do want to resolve this—we’?ll need to get the EULA there

….

Simtec: The changes (EULA Link) are live at http://www.httpwatch.com/download/

…

Google Support: I have an update from the policy team. They found that the website still does not fully comply:

 Website promoting software is required to have the following items present :

Uninstall guidelines should be clearly visible and/or accessible from the download page.  The uninstall information must be on the download page itself or accessible from the download page by a relevant link such as “Help”, “Support”, “Uninstall”, “Remove Program/Application”.  It should not be located within other pages that are not directly related to uninstall (e.g. privacy policy, terms of service)”

Simtec: We’ve updated the site. If you click the Support link on the download page the first paragraph explains how to uninstall HttpWatch. (i.e. in the standard way through the Control Panel). Is that sufficient to get our ads re-instated?

We checked https://www.google.co.uk/chrome/browser/desktop/ but couldn’t find anything similar there.

…

Google Support: Great news! We’ve re-reviewed your site and determined that the following site complies with our Advertising Policies

What did we change?

The two changes to make our site comply with Google policies was a link to the EULA next to the download link:

On our support page we included instructions on how to uninstall a Windows program:

Conclusion

If this happens to you the fastest way to get the problem resolved seems to be by using a chat window with Google Support.

Fortunately, our ads were back up after a couple of days and at least Google wasn’t trying to stop us using hyperlinks! See Google Bans Hyperlinks .

One of the commonly voiced concerns with previous versions of HttpWatch was that the log file  may record passwords used to log into web based systems. If you looked at the POST tab after logging into a site you would usually be able to find the password in clear text:

HttpWatch 10 for Windows and iOS now includes a feature that will mask out the passwords for most commonly used login pages. It works by looking for form submits where the POST parameter name suggests a password or some other form of sensitive data. Any POST field that meets the matching criteria will have each character of input replaced with an asterisk (*).

For example, here’s the POST Data tab in HttpWatch showing a login to a Google account:

The password characters have been masked out and colored in green. The banner and icon on the tab also confirm that password masking has occurred. The masking also applies at the network level in the Stream tab:

Although the actual password was sent to the web server, HttpWatch only records the masked version of the password in the Stream tab.

The criteria used to select POST fields for masking is based on checking whether a list of sub-strings occur in the name. The default sub-strings of ‘pwd’, ‘pass’, ‘secure’ and ‘secret’ catch passwords on most sites but the list is configurable in Tools->Options:

You could change the list if a password field is not being masked or if you want to turn off the feature completely.

The same masking functionality is built into the POST Data section of the iOS app:

and a new Settings view allows the substrings to be modified:

There are still some security related issues to consider when recording and sharing log files:

1. The password masking feature doesn’t hide the length of the underlying password as it uses a character for character substitution.
2. Cookies used for session management are still recorded in the log file and could be re-used to access the logged in session if they have a long expiration time.
3. Content seen in the logged in session is recorded, e.g. html and images
4. Query string values are recorded but it’s probably  best to not put anything of a security sensitive nature in a URL

However compared to previous versions, the masking of submitted passwords is a significant improvement to security when sharing log files with third parties.