844714 - Avira Webguard reportedly breaks incremental page loading

Status: RESOLVED INCOMPLETE

(Tech Evangelism Graveyard :: Other, defect)

Description

[Henri Sivonen (:hsivonen)]

According to 655682 comment 45 Avira browser protection breaks incremental page loading. If confirmed and if Avira doesn't fix, we should seek countermeasures.

Comment 1

[Jorge Villalobos [:jorgev] (he/him)]

I'm trying to find useful contacts at Avira.

Comment 2

[Howard Fried]

Henri & Sivonen:

Christopher Arnold has been in contact with us regarding this issue. I will be working with you to understand and resolve it as quickly as possible. For timezone purposes, I am located in the SF Bay area... :-)

Can you please provide me a bit more detail regarding the incremental page loading? Exactly how is it broken? Are you installing the standalone Avira SearchFree Toolbar, or one of the AV product bundles? Can you point me to the download you used, or the executable name and version?

OS & Browser versions would help, and steps to reproduce.

It seems this was discovered back in February. When was the last time it was re-tested?

I placed myself on the cc list for this bug, so feel free to comment here or email me directly.

Thanks for bringing this to our attention, and I look forward to getting it resolved as quickly as possible.

Best regards,

Howard

Comment 3

[Jorge Villalobos [:jorgev] (he/him)]

Karl, can you respond to the comment above, since you discovered the problem originally?

Comment 4

[Karl Riedling]

Hello,

At the time when I discovered this problem in February 2013 I was new to Avira. I had set up a new computer with Avira Professional Security on it, and in the course of testing the software and data installed on it I ran a web-based database application on localhost (with xampp). It worked flawlessly. The problem occurred when I ran the same web application from an external server: The page was displayed only after the 10 or 15 minutes it took to process the data with the database application, and build its output page completely. I first suspected Firefox's page rendering. Only after I had posted a comment with Bugzilla I remembered that the page had worked flawlessly when run from localhost. Obviously, the problem lay between the web and Firefox, so I tried to disable Avira's browser protection, and found that the page from the external server was then handled perfectly. Apparently, Avira steps between the internet connection (but not localhost) and the browser, collects the data and forwards them to the browser only when the page was completely received. (This is not so much of a problem with normal web pages, but very large pages or particularly pages built incrementally are inacceptably delayed.) I took the easy way out of the problem: Since there is only a handful of websites which I regularly access and which I know to provide pages incrementally, and since most of these sites are directly under my control (and hence require no particular browser protection), I simply added exceptions for them in the Avira configuration.

However, I would appreciate if somebody could convince Avira that it may perhaps be easier to check for content to block when you have an entire web page at hand, but that it certainly is not user-friendly!

Best regards,
Karl

Comment 5

[Jorge Villalobos [:jorgev] (he/him)]

Howard, do you have a sample of your add-on that we can look at? I'd like to check if there's something that can be done to improve page load performance. You can send me the file via email instead of attaching it here, if you prefer.

Comment 6

[Howard Fried]

Jorge: 

My apologies for the delayed response. Last night was an all nighter for our team, as we are preparing to release the next version of our add-on Monday. If you prefer to test "immediately", you can download one of our bundled installs (AV + Toolbar add-on) here: http://www.avira.com/en/avira-free-antivirus

Please note, the version we will release on Monday has substantial changes, fixes, etc. I am unable to determine at this time if this bug is fixed, but I would suggest waiting until Monday and try with that version. That being said, I will work this directly with you until resolved.

I appreciate your time and effort to assist us!

Please note that our development partner, Ask Partner Network, is now tracking this with us.

We will productize a "standalone" version of the toolbar add-on over the next few weeks, but the bundles will be updated on Monday morning, June 24.

Let me know how you would like to proceed.

If need be, we can probably arrange to get you a standalone installer (toolbar only) sooner if the bundle is a problem.


@Karl 

Thanks for the details in your report, it is quite helpful. The concept of "protecting" the user who is browsing their local filesystem is interesting. This is certainly an edge case we missed, and will review for consideration of design changes in the future.

Best regards,

Howard

Comment 7

[Karl Riedling]

Howard,

I greatly appreciated that Avira did _not_ protect me from my own files on localhost; if it had I probably would not have identified it as quickly as the cause of the delayed page display ;-) .

I have been (and am still on some machines) using McAfee for years. They also claim that they provide browser protection, but apparently they do it less intrusively, at least in my installations. I never saw that problem there, anyway.

Best regards,
Karl

Comment 8

[Jorge Villalobos [:jorgev] (he/him)]

Howard, I can wait until the standalone version is available. We're currently investigating this matter and there's no rush to find a solution. We want to make sure that the add-on is as efficient as it can be and we're happy to work with you to accomplish this.

Comment 9

[Howard Fried]

Jorge/Karl/Henri:

After several internal discussions, it has been brought to my attention that this is not actually the result of the toolbar, but other web protection that is added during the install of our Free AV product. If a user chooses to install the toolbar during an AV install, they get this added web protection. 

I will post again soon, but I think this is not such a simple "fix".

Comment 10

[Jorge Villalobos [:jorgev] (he/him)]

Howard, do you have any updates on this?

Comment 11

[Jorge Villalobos [:jorgev] (he/him)]

Karl, do you know if this problem can still be reproduced with current versions of Avira?

Comment 12

[Karl Riedling]

Apparently yes. I have routinely excluded in Avira all sites that create HTML pages over a prolonged period, and hence do not see the problem in regular use. Just for testing purposes I have removed this exclusion for one site, and I am just running a 20 minute operation on that site. The browser still shows the page from which I started the operation (and, meanwhile, reports "The server at ... is taking too long to respond."). By excluding the site again in Avira and reloading the page, normal operation (i.e., incremental display of the page that consists of a number of HTML tables whose rows are created on the server one by one as processing continues) can be achieved again.

Therefore: Sorry, no improvement!

(I am running Avira Professional Security 14.0.5.450 of 2014-06-24, with Browser Protection 14.00.05.430 of 2014-07-03. My browser is Firefox 30.0; the latest release in the standard release channel.)

Comment 13

[Henri Sivonen (:hsivonen)]

Jorge, how are things going with contacting Avira or blocklisting Avira? I think we shouldn't wait on Howard responding on this bug. It's rather terrible that this level of brokenness has continued for over a year without a resolution.

Comment 14

[Jorge Villalobos [:jorgev] (he/him)]

I'm making a last attempt at pinging them about it. If I don't hear anything back in two weeks, we will block it.

Kris, what are we looking at in terms of enabled installs?

Comment 15

[Kris Maglione [:kmag]]

~600K

Comment 16

[PS]

Jorge & team,
It seems Howard has left Avira and that's the reason you are not getting any response. We will be reaching out to others within Avira and escalating. Hopefully someone will reach out to you/comment on this ticket soon.

Comment 17

[Jason Radisson]

(In reply to Jorge Villalobos [:jorgev] from comment #1)

Hi Jorge, 

We’ve researched the topic and can confirm: 

1. The behavior that you are experiencing is core security functionality from the Avira antivirus product "Webguard"
2. Because the issue is caused by Webguard, the core AV, it has no connection to Avira Browser Safety (ABS), or to the Avira Toolbar or any other Avira ad-on or extension for Mozilla/Firefox
3. Webguard was previously installed with the Toolbar (now EOL), in order to provide a higher level of security to our users. 
4. We are redesigning Webguard along with some other protection features in our AV and will be releasing enhancements later this year. But again this is core AV and unrelated to ABS. 

Since this issue #844714 has nothing to do with ABS, Toolbar or any other ad-on extension we would consider it resolved. Please confirm and thanks for your diligence! 

Best, Jason (EVP Online @avira)

> I'm trying to find useful contacts at Avira.

Comment 18

[Jason Radisson]

Hi Jorge, Just responded to your request for info. Awaiting your reply and please LMK if I can be of assistance on other topics in the future. Jason

Comment 19

[Henri Sivonen (:hsivonen)]

(In reply to Jason Radisson from comment #17)
> 1. The behavior that you are experiencing is core security functionality
> from the Avira antivirus product "Webguard"
> 2. Because the issue is caused by Webguard, the core AV, it has no
> connection to Avira Browser Safety (ABS), or to the Avira Toolbar or any
> other Avira ad-on or extension for Mozilla/Firefox

The end result is, though, that having Avira installed continues to interfere with Firefox in a way that affects both Web compatibility and the user's perception of Firefox performance, right?

> Since this issue #844714 has nothing to do with ABS, Toolbar or any other ad-on extension we would
> consider it resolved.

If the problem remains, I don't think it's "resolved" by saying the blame belongs on the core AV functionality instead of belonging on the Avira Firefox extension.

I think what would qualify as "resolved" would be no part of the Avira anti-virus package interfering with Firefox's ability to load pages incrementally.

> 4. We are redesigning Webguard along with some other protection features in our AV and will be 
> releasing enhancements later this year.

Will these enhancements include non-interference with Firefox's incremental page loading?

For the time being, is there anything Mozilla can do to work around the issue (other than instructing users to use a different anti-virus package)?

Comment 20

[Kris Maglione [:kmag]]

If this add-on is not responsible, there's no reason to block it. If the issue is still occurring, though, we need to do something about it.

Does Webguard use an add-on to do this, or is it entirely a separate application?

Comment 21

[Jason Radisson]

(In reply to Kris Maglione [:kmag] from comment #20)
> If this add-on is not responsible, there's no reason to block it. If the
> issue is still occurring, though, we need to do something about it.
> 
> Does Webguard use an add-on to do this, or is it entirely a separate
> application?

Hi Kris, I can confirm that Webguard is the core antivirus and has nothing to do with the ad-on. 
So if Mozilla were to block our ad-on it would not resolve the issue. 
While we are able to repeat the issue mentioned in ticket 655682 and 844714#c4, we consider it an edge-case because the tens of millions of consumers we are protecting from malicious content with webguard will generally not be parsing in a production server environment. I hope that this additional explanation is helpful.

Comment 22

[Karl Riedling]

(In reply to Jason Radisson from comment #21)
> (In reply to Kris Maglione [:kmag] from comment #20)
> > If this add-on is not responsible, there's no reason to block it. If the
> > issue is still occurring, though, we need to do something about it.
> > 
> > Does Webguard use an add-on to do this, or is it entirely a separate
> > application?
> 
> Hi Kris, I can confirm that Webguard is the core antivirus and has nothing
> to do with the ad-on. 
> So if Mozilla were to block our ad-on it would not resolve the issue. 
> While we are able to repeat the issue mentioned in ticket 655682 and
> 844714#c4, we consider it an edge-case because the tens of millions of
> consumers we are protecting from malicious content with webguard will
> generally not be parsing in a production server environment. I hope that
> this additional explanation is helpful.

Nevertheless, there _are_ cases like those I have experienced where Avira Webguard not only breaks incrementally generated pages but also the application in behind, since, having received nothing, the browser eventually resets the connection somewhere amidst the operation, which, in turn, preempts the operation itself. Although this can be overcome by excluding the sites in question (in my case nine different addresses, including localhost), it is extremely tedious and disturbing, particularly if you have not be warned about this "feature" of Webguard.

As a matter of fact, it escapes my imagination why it is necessary to block obviously totally harmless HTML text (where the most suspect contents may be links to image files on the same server) until the page has been fully loaded (if ever), only to find out that the totally harmless HTML text is totally harmless indeed. I agree that it is important to provide protection from malicious content; but I don't believe that this is only possible by analyzing a complete page. I doubt whether a scenario is possible where 1000 lines of plain text can be turned into malicious content by the 1001st line; and even if this were the case, the user would be sufficiently protected by blocking that 1001st line. Some overthinking of the concept of Webguard would indeed be beneficial, even if only a small number of users would notice it.

Comment 23

[Kris Maglione [:kmag]]

I agree that this is a problem that needs to be fixed, but it seems that it's not an add-on problem.