Bugzilla

When this issue was filed, the concept of "precursor" did not exist. It does exist now, so we can feasibly consider using a null principal for PDF viewers.

A potential way to resolve this issue is to force all PDF viewers to have an opaque origin:

1. E.g. by rewriting the CSP in [PdfStreamConverter.sys.mjs](https://searchfox.org/mozilla-central/rev/c414b4538dd3c7e1dc674f7b66176e7c309afa95/toolkit/components/pdfjs/content/PdfStreamConverter.sys.mjs#1162) and (and something else for non-http channels).
   - alternatively: mint a null principal [before setting aRequest.owner](https://searchfox.org/mozilla-central/rev/c414b4538dd3c7e1dc674f7b66176e7c309afa95/toolkit/components/pdfjs/content/PdfStreamConverter.sys.mjs#1259), with the precursor set to the PDF viewer (and/or the original URL).
2. With the above change, the viewer document is now a null principal instead of a content principal. There are several internal checks that confirm that the principal is `resource://pdf.js`. These would have to change, to check that the principal is a null principal with the precursor `resource://pdf.js`.
3. Besides these internal checks, the stream converter itself also needs to be updated: it [currently uses `postMessage`](https://searchfox.org/mozilla-central/rev/c414b4538dd3c7e1dc674f7b66176e7c309afa95/toolkit/components/pdfjs/content/PdfStreamConverter.sys.mjs#716,729,740,771,782,824,835) to send data to the PDF.js origin. An alternative mechanism would be to use `CustomEvent` to send data from system privileged code into the viewer. CustomEvent does not support transferables (an optimization to reduce memory overhead). An alternative to that would be to construct a `MessageChannel` and send a port to the viewer. Then the viewer can use the same logic that it had before to send data via the MessagePort.
  - using CustomEvent would also fix bug 1685092. Side note, in that bug CustomEvent was also proposed and accepted as an alternative to `postMessage`.

When this issue was filed, the concept of "precursor" did not exist. It does exist now, so we can feasibly consider using a null principal for PDF viewers.

A potential way to resolve this issue is to force all PDF viewers to have an opaque origin:

1. E.g. by rewriting the CSP in [PdfStreamConverter.sys.mjs](https://searchfox.org/mozilla-central/rev/c414b4538dd3c7e1dc674f7b66176e7c309afa95/toolkit/components/pdfjs/content/PdfStreamConverter.sys.mjs#1162) and (and something else for non-http channels).
   - alternatively: mint a null principal [before setting aRequest.owner](https://searchfox.org/mozilla-central/rev/c414b4538dd3c7e1dc674f7b66176e7c309afa95/toolkit/components/pdfjs/content/PdfStreamConverter.sys.mjs#1259), with the precursor set to the PDF viewer (and/or the original URL).
2. With the above change, the viewer document is now a null principal instead of a content principal. There are several internal checks that confirm that the principal is `resource://pdf.js`. These would have to change, to check that the principal is a null principal with the precursor `resource://pdf.js`.
3. Besides these internal checks, the stream converter itself also needs to be updated: it [currently uses `postMessage`](https://searchfox.org/mozilla-central/rev/c414b4538dd3c7e1dc674f7b66176e7c309afa95/toolkit/components/pdfjs/content/PdfStreamConverter.sys.mjs#716,729,740,771,782,824,835) to send data to the PDF.js origin. An alternative mechanism would be to use `CustomEvent` to send data from system privileged code into the viewer. CustomEvent does not support transferables (an optimization to reduce memory overhead). An alternative to that would be to construct a `MessageChannel` and send a port to the viewer. Then the viewer can use the same logic that it had before to send data via the MessagePort.
   - using CustomEvent would also fix bug 1685092. Side note, in that bug CustomEvent was also proposed and accepted as an alternative to `postMessage`.