Can data: URIs be used insecurely? I'm attempting to write a client-side script that processes a user selected file through an input element. Since the input element interface conceals the file: URI, the best solution I can think of is to access the file through the input element's interface, get its data: URI through readAsDataURL in FileAPI's FileReader interface, and process the data: URI. However, I get not-same-origin errors when I try to use this URI. Specifically, this happens when I try to use XMLHttpRequest to retrieve an XML resource with the data URI.
Is this correct? http://www.w3.org/TR/html5/origin-0.html#origin-0 appears to suggest it: "If url does not use a server-based naming authority, or if parsing url failed, or if url is not an absolute URL, then return a new globally unique identifier.", data URIs do not use server-based authorities, and opaque identifiers only have same origin with themselves. Is there a better way to process files in a client-side script? I considered using blob: URIs, but the support is not yet there. Can data: URIs be abused with the other same-origin policies in effect? I'm trying to imagine a situation where the data: URI origin policy is necessary for security. But I'm under the impression data: URIs literally are the resources they denote, and current policies allow input only from same-origin resources or the user, so scripts get input only from those sources. If that input literally is a resource, then that resource /should/ be treated as same-origin or from the user. Am I wrong?
