Re: responseXML/responseText exceptions and parseError

Julian Reschke wrote:
> 
> timeless wrote:
>> On Thu, Jun 19, 2008 at 1:09 PM, Julian Reschke 
>> <julian.reschke@gmx.de> wrote:
>>> Can you provide an example where providing *XML* parse error information
>>> within *XHR* would be problematic?
>>
>> i really shouldn't have to. imagine a document that is not CSS and is 
>> not XML.
>>
>> now imagine an api that lets you try to load it as css. imagine that
>> this api exposes a dom object that describes *any* information from
>> that document in the case that it fails to parse as css.
>>
>> basically it meant that you can interrogate pages that you weren't
>> supposed to be able to look at to get information you weren't supposed
>> to have.
>>
>> now replace 'css' with 'xml'. The logic still applies.
>>
>> And yes, I understand you'll wave hands about "this is a trusted
>> application". I don't care. If it's a trusted application, then I
>> trust it not to make mistakes and to have ways to verify the
>> information server side before it's ever sent on any wires.
> 
> But you already can read the unparsed content using responseText, no? 
> Where's the leakage then?

Exactly. The problem with bug 35618 is that CSS can be loaded from a 3rd 
party site without that site opting in. In this case providing parsing 
error information could result in leakage of private information.

Though really, just the loading of the CSS is an information leak. 
However it has been deemed unlikely that someone will put private 
informaion into CSS rules.

There would be no risk of information leakage to provide parse error 
information for same-site CSS loads. Likewise, there is no risk of 
information leakage to provide parse errors for same site XML loads, or 
cross-site XML loads where the 3rd party site has opted in.

/ Jonas

Received on Thursday, 19 June 2008 16:45:19 UTC