[whatwg] ProgressEvents for Images

Thanks for the encouraging words.

For cross-site images for which crossOrigin is not set, we'd proposed
"normalizing" the loaded and size ProgressEvent attributes:

https://bugs.webkit.org/show_bug.cgi?id=76102
ProgressEvents for cross-origin images should not reveal the actual
resource size per 
http://www.w3.org/TR/progress-events/#security-considerations.  This could
be avoided by dispatching ProgressEvents with lengthComputable=false (and
loaded=0, total=0) for cross-origin images.   Alternatively we could
dispatch a subclass of ProgressEvent with normalized total and loaded
attributes.  A normalized image ProgressEvent wouldn't expose the actual
size of the resource being downloaded but it would still enable developers
to observe relative progress.  Normalization would set total to a constant
like 1000, and loaded to a relatively correct value.

A normalized image ProgressEvent would still reveal a little bit about the
server, even dispatching ProgressEvents with lengthComputable=false would
do so.  As you pointed out, we could avoid this issue altogether by not
dispatching progress events at all in the unauthorized cross-site case,
although doing so diminishes the utility of dispatching the events.


- Hans
 


On 1/23/12 4:58 AM, "Jonas Sicking" <jonas at sicking.cc> wrote:

>On Thu, Jan 12, 2012 at 4:19 PM, Hans Muller <hmuller at adobe.com> wrote:
>> A group of us at Adobe has been looking into adding support for
>>ProgressEvents to images.  The overall goal is to simplify image
>>download progress reporting by supporting roughly the same progress
>>events as XHR and the File API for image elements.   For example one
>>could connect an image to a progress element like this:
>>
>> <img id="image" src="sample.jpg"
>>    onloadstart="showProgressBar()"
>>    onprogress="updateProgressBar(event)"
>>    onloadend="hideProgressBar()"/>
>>
>> Developers have taken various tacks to enable progress reporting, for
>>example in some cases XHR can be used to download image files.  Max
>>Vujovic just published a blog about the practicalities of doing so:
>>http://blogs.adobe.com/openweb/2012/01/13/html5-image-progress-events/.
>>We think it would be preferable to provide support for image progress
>>events directly.
>>
>> We're working on a prototype implementation for WebKit and have filed a
>>bug that explains what we're up to in a little more detail:
>>https://bugs.webkit.org/show_bug.cgi?id=76102).
>>
>> It's probably worth pointing out that the beforeload event, which is
>>currently under discussion, addresses a different use case.  Our
>>proposal is intended to enable applications to give the user feedback
>>about image download progress, it's not intended to enable security or
>>efficiency by preemptively blocking or transforming image downloads.
>>
>> We'd appreciate feedback on this proposal.
>
>For cross-site images this would leak the compressed size in bytes of
>the loaded image (except when the crossorigin attribute is set). This
>would very unfortunately in many cases leak sensitive information.
>
>But if we restrict these events to only fire for same-origin loads, as
>well as loads where the crossorigin attribute is in effect, then this
>sounds like an awesome idea.
>
>/ Jonas

Received on Monday, 23 January 2012 08:44:02 UTC