Missing Or Broken Media Files
When a file request is received by a hosting server, the server may validate your right to access the data, access databases to determine the proper response, and even track the IP Address and browser information associated with the URL request. The data stream returned may not represent the requested media file at all, it could represent the server 404 File not found response, the server 403 access denied response, or any other form of data the server deems an appropriate response for the URL request.
What Missing URL References Look Like
Image Surfer Pro supports several different media file types. Each is rendered in a way specific to their type on generated webpages. When data returned from a hosting server does not match the expected media file type or the media file simply does not exist, the display of the generated webpages may look odd.
Image Files
If the data provided by the hosting server can not be interpreted by IE as a supported image format, it will be discarded and a Missing Image Block. The Image Surfer Pro HTML encoding will cause IE to show a missing image X and the filename of the image (though not the full path).
Risk Assessment:
On gallery pages, images are used as hyper-links directly to the image URL. Clicking on a missing image block will
then navigate IE to the URL outside the construct of an <img> tag, and how the server and IE will handle the
URL request could vary greatly. We recommend not clicking on missing image blocks unless you have a good understanding
of why the image file is missing and what information it is accessing on the hosting server.
MP4 Video Files
MP4 Videos make use of both a Poster Image URL and an MP4 Video URL. If the data provided for the poster image can not be interpreted as an image, the video display area will remain a black box until the Play button is clicked. If the data provided for the video is not a valid MP4 formatted video, the video display will show Invalid Source.
Risk Assessment:
MP4 video displays are safe because any data received by IE which can not be directly interpreted is discarded. They are
not encoded as the visible portion of hyper-links so attempting to interact in any way with an MP4 Video Block
will not generate additional server traffic nor provide the hosting server any additional information, regardless of whether
or not the URL could be interpreted as an MP4 video.
Flash Video Files
MP4 and FLash videos differ on when the URL requests are generated. For MP4 videos, both the poster image and video URL access is requested when the gallery page is loaded. For Flash videos, the poster image request is generated when the gallery page is loaded, but the flash video request is generated when you click the Play button for the video.
When the detail page is loaded, IE will create an embedded shockwave flash active object in memory to load the Image Surfer Pro flash video player and provide the flash video and poster image URLs. The poster image is only provided if the URL extension is recognized as an image file. The player object will then request the poster image URL. If the data returned by the server can not be interpreted as an image, the data is discarded and the video display area will remain a black box.Once you click the Play, the flash player object will attempt to access the flash video URL and will display the Buffering progress text in the video display area. If the data provided by the hosting server can not be interpreted as a flash video it will be discarded and the Buffering progress will remain at 0% indefinitely.
Risk Assessment
Attempting to interact in any way with a Flash Video Block does not provide any additional information to the
hosting server. IE will pass the interactions to the Image Surfer Pro flash player object to process internally and
determine what corresponding action to take regardless of whether or not the URL could be interpreted as a flash video.
No interaction with the Image Surfer Pro flash video player will generate additional external traffic after the initial
URL access requests.
Windows Media Files
Similar to flash videos, windows media files are encoded to create an active object in memory. In this case the active object is created from the Windows Media Player DLL provided with your installation of Windows. The Windows Media Player does not support Poster Images and so the only URL request made of the hosting server is for the windows media file. This request is made when the page is loaded.
If the data response can not be interpreted as a media stream supported by the player, it will be discarded and clicking the Play button will have no effect.
Risk Assessment:
Displaying any URL with the Windows media player is safe because any data received by IE and the player which can not be
directly interpreted as a media file is discarded. Attempting to interact in any way with a Windows Media Block does
not provide any additional information to the hosting server. IE will pass the interactions to the media player to process
internally and determine what corresponding action to take. No interaction with the media player will generate any additional
external traffic after the initial URL access requests.
Shockwave Flash Files
When the detail page is first loaded, IE generates a URL request for the shockwave flash file. This URL request is subject to all the same verifications and processing as other URL requests to the same area of the server. IE will validate the data returned can be interpreted as a shockwave flash file. If the data can not be validated, IE displays something similar to the Missing Shockwave Block shown here. Results may vary, but essentially it will look like an empty red box.
Risk Assessment:
Unlike the players for Windows Media and Flash Videos, the player object for Shockwave Flash files is embedded in the
Shockwave Flash file itself. This means the active player source code is coming from an external source and not from
a known object installed on your computer. IE will use the Shockwave Flash addon to create an active object. The active
object is then given the Shockwave Flash code downloaded from the hosting server. At that point, interaction with the
frame on the browser window is directly passed to the Shockwave Flash active object. This object may generate subsequent
interactions with the hosting server (or even other servers). These interactions can vary greatly in format and content.
If the shockwave flash object was constructed to deliver video, it will typically be a video player similar to the Image
Surfer Pro flash video player. At a minimum it will need to make URL requests for the actual video and poster image.
Interaction with the active element may be limited to interaction with the internal object in IE memory, but the object
itself is only limited by the IE interfaces for Shockwave Flash.
Interaction with Shockwave Flash objects should be considered a Risk. We recommend always running IE in Enhanced Protected Mode to limit memory and disk access available through the installed shockwave flash IE extension and only interacting with shockwave flash objects from sites you trust.
Raw Frames
If the URL does not resolve to a valid hosting location it is the hosting server which provides the resulting error stream and not IE. Because of this, we can not accurately say what will be displayed by an incorrect Raw Frame reference. The most common response is simply the 404 File Not Found page for the hosted domain. However, when the intended purpose of the frame was to deliver video, the responses are more varied. Below are a few examples of Missing Frames we have encountered.
|
Some tube sites, including YouTube, allow their subscribers to block the embedding of their videos on pages outside the domain of the tube site. This is becoming a more common practice, but is dependant upon the tube site and who posted the video to the tube site. |
|
Some sites will indicate an error retrieving the video, but others will substitute a "similar" video into the frame. |
Risk Assessment
Technically Raw Frames are not file references but rather a data stream connection to a hosting server. They are
essentially a smaller browser window within the browser window. There is no Expected File Type response to
the open URL request and no data stream validation is done. IE processes the data response in the same way it would
if the URL had been typed directly into the IE Address Bar. Because of this, frames are Inherently Risky.
Interacting with a frame is the same as interacting with a webpage generated by the hosting server. The risk of such
interaction will vary greatly based on the source of the URL used to define the Raw Frame. Frames are often used to
display ads. If the Raw Frame was found "in the wild" by processing another webpage, that frame could represent any
number of malicious ad oriented objects. If the Raw Frame came from capturing the Embed Code from a tube site,
it is likely as safe as the tube site itself.
Page References
Because Pages are displayed as a browser window within a browser window,they are subject to the same errors as frames and may display in much the same way. If you are following the Best Practices guidelines in building your fusker collections, the more common case is the display of the 404 File Not Found reference page for the hosting domain. Often this is simply another webpage letting you know the desired content was not found and providing some helpful links on where content can be found on the hosted domain.
Risk Assessment:
Technically there is no difference between how a Raw Frame and a Page are rendered by Image Surfer Pro on gallery pages.
The reason for Pages is to allow you to accurately differentiate between URL references which reference video (Raw Frames),
and general webpage URLs. Because there is no difference in how they are encoded in the HTML of gallery pages, the same
risks associated with Raw Frames apply to Pages.
What To Do With Broken Links
Whether or not you purposefully added a file to your fusker collection you are likely to encounter situations where references in your fusker collection are invalid or not the right data type. This can happen for many different reasons, but here are a few common instances which can cause this to happen:
- Auto Range Fusking includes files which do not exist
- Client side hot-linking to an media file is blocked by the web domain
- The URL used to access the media file had a Time To Live parameter component
- The file referenced by the URL has been removed from the hosting server
In all of these cases you will see something similar to the missing file blocks described above. While missing files are of little consequence in viewing the fusker collection they should be avoided. Not only is it important to avoid some of the risks, each missing file reference causes a hosting server error event which may initiate additional tracking by the server. If your IP Address is associated with causing a large number of 404 or 403 server errors, it may be considered a Denial of Service attack. In some cases your IP address may be temporarily or permanently blocked from accessing the domain. Therefore it is in your best interest to try and not generate missing file references and to eliminate any from fusker collections you utilize.
Utilizing the Image Surfer Pro Forms or automated page processing capabilities of Image Surfer Pro will help keep you from creating references to missing files as both techniques reference only files which are known to exist (or were at least referenced by other hosted pages).
Obviously changing the start or end values of a numerical fusk will remove references to missing files at the beginning or end of the sequence easily enough. A simple use of Image Surfer Pro Forms can be used to remove missing file references in the middle of any fusk:
- First display the "Expanded View" of the file segment
-
Create an Image Surfer Pro Form from the generated visualization page with the
button
- Use the Add All and Add Item boxes to select files which display correctly and not those associated with the missing files.
- Delete the file segment from your fusker collection
-
Process the form with the
button.
