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.

Firefox 35 was released this week and became the first browser to enable support for the HTTP/2 protocol by default.

The HTTP/2 specification has not been finalised so Firefox actually enabled the Draft 14 version of HTTP/2 but little is expected to change in the final draft. Google is now supporting HTTP/2 draft 14 on its web servers alongside the SPDY protocol giving us a chance to compare the performance of raw HTTPS, SPDY and HTTP/2 on the same web page.

We also updated HttpWatch this week so that it supports HTTP/2 within Firefox. It has new columns to display information about the protocols being used by each request:

The Performance Comparison

The performance test used HttpWatch with Firefox to run a series of simple page load tests against the Google UK home page using the three protocols:

• Raw HTTPS
• SPDY/3.1
• HTTP/2

We switched between the protocols by enabling and disabling the following entries in Firefox’s about:config page:

Each test was performed in a fresh instance of Firefox with an empty browser cache. Although this testing was simplistic and only used a simple page it does highlight some important differences between the protocols.

Test #1 – Size of Request and Response Headers

Most sites already use compression when downloading textual content as it provides a significant performance benefit. Unfortunately, HTTP/1.1 doesn’t support the compression of HTTP headers that are attached to every HTTP request and response. SPDY and subsequently HTTP/2 were designed to address this shortcoming using different types of compression.

SPDY uses the general purpose DEFLATE algorithm whereas HTTP/2 uses HPACK that was specifically designed to compress headers. It uses predefined tokens, dynamic tables and Huffman compression.

It’s possible to see the difference in the generated header sizes by looking at a request that has no content. On the Google UK home page there is beacon request that returns no content (a 204 response). These screen shots from HttpWatch show the size of the request headers in the ‘Sent’ column and the size of the response headers in the ‘Received’ column:

WINNER: HTTP/2

HTTP/2 has significantly smaller header sizes due to its use of the HPACK algorithm.

Test #2: Size of Response Message

The response message from the server is made up of the response headers and the encoded response content. Given the fact that HTTP/2 creates the smallest headers shouldn’t it always have the smallest response message?

In HttpWatch this seems to be the case for image resources:

However, for textual resources SPDY consistently has smaller response messages even though its headers would be larger than HTTP/2:

The reason for this is the optional padding bytes that can be added to the HTTP/2 DATA frame. HttpWatch doesn’t currently show the padding but in our debug logs we can see that the Google servers add padding to the data frames of textual resources. The reason given in the HTTP/2 spec for using padding is:

Padding can be used to obscure the exact size of frame content, and is provided to mitigate specific attacks within HTTP. For example, attacks where compressed content includes both attacker-controlled plaintext and secret data (see for example, [BREACH]).

Padding isn’t used for image resources because they already have a compressed format that will not contain attacker controlled plain text.

WINNER: SPDY

The larger response bodies seen on the Google servers are due to the use of padding in data frames. Although, HTTP/2 produces larger responses than SPDY its encrypted connections could potentially be more secure. This may be an area where tuning can be performed in a trade off between security and performance.

Test #3 : Number of TCP Connects and SSL Handshakes Required During Page Load

Browsers achieved a performance boost in HTTP/1.1 by increasing the maximum number of connections per host name from two to six or more. This allowed greater concurrency during the download of a page at the cost of extra TCP connections and SSL handshakes . Increasing concurrency allows the bandwidth of the network to be used more effectively because it reduces the blocking of requests.

SPDY and HTTP/2 support concurrency on a single TCP and SSL connection by using multiplexing to allow more than one request at a time to send and receive data on a single connection.

By adding the ‘Connect’ and ‘SSL Handshake’ timings as a columns in HttpWatch you can see that SPDY:

And HTTP/2:

Only create connections for different host names. Whereas, raw HTTPS may create more than one connection per host name to improve concurrency:

EQUAL WINNERS: SPDY & HTTP/2

The multiplexing support added in SPDY and HTTP/2 reduces the number of connections that have to be setup to download a page. As a side benefit web servers will not have to maintain as many active TCP connections when HTTP/2 usage becomes more widespread.

Test #4: Page Load Time

The ‘Page Load’ event in HttpWatch shows when the page was fully downloaded and available for use. In most cases this a reasonable measure of the speed of the page as seen by a visitor to a web site.

The screeen shots below show the Page Load time for each of the three protocols:

WINNER HTTP/2

The Page Load timing was worse for raw HTTPS probably due to the lack of header compression and the additional TCP connections and SSL Handshakes required. For more complex pages the speed advantage of SPDY and HTTP/2 should be even greater.

We also found that HTTP/2 was consistently faster than SPDY even though its response messages were often larger. The advantage was probably due to the smaller GET request messages produced by HPACK compression. Our network connection to the internet, like many others, is asymmetric in nature – the network upload speed is less than the download speed. This means that any saving in uploaded data has much more impact than the equivalent saving in downloaded data.

Conclusion

HTTP/2 is likely to provide significant performance advantages compared to raw HTTPS and even SPDY. However the use of padding in response messages is an area of potential concern where there could be a trade-off between performance and security.

You can check for HTTP/2 using our new SSL test tool SSLRobot . It will also look for potential issues with the certificates and TLS/SSL configuration used by your site. Try it now for free!