<CA+c2ei-9ZuE-L4w49o7Pm9-Jh4aLFbGbGf1PjmgCZvAVy1HuzA@mail.gmail.com>
Current votes: None.
On Mon, Jan 23, 2012 at 8:44 AM, Hans Muller <hmuller@adobe.com> wrote: > 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=3D76102 > ProgressEvents for cross-origin images should not reveal the actual > resource size per > http://www.w3.org/TR/progress-events/#security-considerations. =A0This co= uld > be avoided by dispatching ProgressEvents with lengthComputable=3Dfalse (a= nd > loaded=3D0, total=3D0) for cross-origin images. =A0 Alternatively we coul= d > dispatch a subclass of ProgressEvent with normalized total and loaded > attributes. =A0A normalized image ProgressEvent wouldn't expose the actua= l > size of the resource being downloaded but it would still enable developer= s > to observe relative progress. =A0Normalization would set total to a const= ant > like 1000, and loaded to a relatively correct value. > > A normalized image ProgressEvent would still reveal a little bit about th= e > server, even dispatching ProgressEvents with lengthComputable=3Dfalse wou= ld > do so. =A0As 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. I don't know if this would still leak some information. For example, are packet sizes reliable enough that you can estimate the downloaded size by simply counting the number of ProgressEvents? I don't have a strong opinion as I don't feel that I know enough. / Jonas