Bug 1223720

Summary: Konqueror starts downloading hidden video on start.fedoraproject.org, even when it's not exposed and has to be killed
Product: [Fedora] Fedora Reporter: David Howells <dhowells>
Component: kde-baseappsAssignee: Than Ngo <than>
Status: CLOSED CANTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 21CC: dvratil, jreznik, kevin, ltinkl, rdieter, rnovacek, than
Target Milestone: ---Keywords: MoveUpstream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-05-23 00:11:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Compressed wireshark capture file showing konqueror starting up none

Description David Howells 2015-05-21 10:25:13 UTC
Created attachment 1028068 [details]
Compressed wireshark capture file showing konqueror starting up

Description of problem:

When konqueror opens the start.fedoraproject.org page, there's a hidden video that a kioslave starts pulling immediately:

    https://mattdm.fedorapeople.org/council/2015-05-11_Fedora-Council_Subproject-Status-Marketing.webm

despite the fact it's not exposed.  Konqueror won't then go away but has to be killed.

I didn't realise this was happening until I hit the ISP's monthly bandwidth cap on the 18th of the month having apparently inadvertently downloaded around 24G from this file during working hours.

I used wireshark to capture a trace (attached) which shows almost 8000 packets being shifted in around 15 seconds.  Konqueror is started 15 seconds into the trace (at packet 2) and killed at about 30 seconds in (at around packet 7600).

The vast majority of packets are to/from local TCP6 port 56477, starting with packet 51.

Address 2001:8b0:194:0:96de:80ff:feb4:ecc3 is my home machine (warthog).

Address 2610:28:3090:3001:5054:ff:fedb:7f5a is {mattd,mattdm}.fedorapeople.org - though there's no reverse DNS mapping for it, the server name can be picked out of the opening TLS packet.

Grabbing the source for the start page, the only URL to mattd is this:

<img src="https://mattdm.fedorapeople.org/council/2015-05-11_Fedora-Council_Subproject-Status-Marketing.webm">

which seems to be placing a streaming video as a static image.  The video should be hidden according to the previous line:

<div class="col-xs-1 col-sm-1 hidden-xs">

and shouldn't be played until it is exposed.

It appears that the IMG tag is assumed to be a static image (or an animated image) and just downloaded to the cache by the kioslave - with bad results when the image turns out to be video.

Version-Release number of selected component (if applicable):

konqueror-15.04.0-1.fc21.x86_64

How reproducible:

100%

Steps to Reproduce:
1. Start konqueror at start.fedoraproject.org
2. Observe lights on switch go beserk as the kioslave hammers the network.
3.

Comment 1 David Howells 2015-05-21 10:32:25 UTC
This problem affect Chrome also.

Comment 2 Rex Dieter 2015-05-22 20:02:16 UTC
I suspect the website code doesn't work as intended, probably ought to raise issue with websites team.

Comment 3 Rex Dieter 2015-05-22 20:05:39 UTC
Opened ticket,

https://fedorahosted.org/fedora-websites/ticket/327

Comment 4 David Howells 2015-05-22 22:26:16 UTC
The website has already been fixed.  However, it may be worth limiting the amount of data that will be downloaded for an IMG tag, just in case something like this happens again.  Also, if I close my browser, the IMG tag downloads it is waiting for should perhaps be aborted rather than accruing konqueror corpses.

Comment 5 Rex Dieter 2015-05-23 00:09:16 UTC
Sounds like a potentially good report/feature-request for upstream (at bugs.kde.org)

Comment 6 Rex Dieter 2015-05-23 00:11:38 UTC
Closing (cantfix here, upstream needs to implement the fix/feature), and since the immediate problem is fixed.

Comment 7 David Howells 2015-05-26 12:32:54 UTC
Should I raise it?

Comment 8 Rex Dieter 2015-05-26 13:41:14 UTC
That's up to you, if you want.