Les Stroud Developer, Architect, Creative Thinker | |
web: lesstroud.com email: l...@lesstroud.com | linked in | twitter | facebook |
This is a pretty interesting idea. I'm not much of an expert here, but some comments follow.
----- Original Message -----
> From: "Les Stroud" <l...@lesstroud.com>
> To: dev-p...@lists.mozilla.org
> Sent: Tuesday, August 2, 2011 1:25:50 PM
> Subject: Printing...
> I don’t know if anyone is monitoring this list still….but I have an
> extension to pdf.js that might be interesting.
>
> For you guys, if you can render a pdf in javascript/html5, without
> needing native components, then it would not be a very long step to
> render postscript (or, even PCL).
PostScript output isn't trivial but it's doable. I don't know PCL at all.
> If you can render postscript and pcl
> you would cover 90% of the printers out there. With that, you could
> use the same mechanism to print from the browser without having to use
> native divers. Not only would it be kewl, but it would keep the entire
> printing process within the browser process sandbox.
It depends on what you mean by "browser process sandbox". The problem here is that web content by default can't do cross-origin HTTP requests, so since (presumably) pdf.js would be in a different origin from a discovered IPP printer, pdf.js wouldn't be able to talk to the printer by default. We could get around that problem by upping pdf.js's trust level to that of an "extension", but then we'd hit another issue: need to detect IPP printers, which can't be done with current web APIs. That's not an insurmountable problem either, but it would require adding a new web API for printer detection.
If you mean "browser process sandbox" as in the low-rights renderer processes like Chrome has (and Firefox will get eventually), then this scheme won't quite work because low-rights process can't do arbitrary networking, as would be required for IPP printer discovery. Low-rights renderers would need to use an IPP-discovery API implemented by a higher-rights process.
Another issue is that the PS (or PCL) we send to the printer, whether pdf.js is untrusted or not, needs to be validated to prevent maliciously-crafted PDFs from pwning a local IPP printer. This is new code someone would need to write, or we'd need to grab it from somewhere.
> This would have
> the following advantages:
>
> - Make firefox significantly more secure
This assumes that native printing code is insecure. Let's just fold this into "reduce native code" footprint and the statement won't be controversial.
> - Open up the possibility of http accessible print “drivers”
> (javascript renders for the printer control language)...simpler
> installs by simply parsing an http/ipp response from an ip address for
> printer model, querying a central service on the web, downloading the
> javascript renderer live for that printer, and printing. This would
> make rollouts and updates of print drivers a snap by taking advantage
> of browser caching.
It's not clear to me how much printer-specific "driver" code would be needed. Do you have a guess? But yes, "instant" updates to printing code by web-app-ifying it is very attractive.
> - Reduced native code footprint that has to be maintained across
> platforms.
Yes.
> With you guys headed toward becoming an operating system, this might
> be a really good fit…and it is a better answer than what google,
> apple, and hp have come up with….given you can render fairly quickly.
Possibly. Another problem though is that if the majority of printers nowadays aren't IPP-enabled (do you have numbers?), which is what I would guess, then using an IPP printing interface for all printers would require a translating proxy. Such a proxy would need to take the IPP and translate it into calls to native printing code, which wouldn't really improve overall system security, just move the problem out of firefox.exe.
Anyway, this is an interesting idea. I'll make sure to forward it along to people who know more about printing than I do.
Cheers,
Chris
CORS is now an industry standard/working draft for enabling cross origin requests. I’m not a great fan of it, because it requires the secondary origins to declare their support. I would argue that the browser/user should be in control of what public data it can access (after all the server put it out there, that should be interpreted as intent to share). With that said, not having been in on those discussion, I’m certain there were some sound security reasons for the model that was chosen. The problem is that CORS didn’t define a model that would work for hardware based, http accessible, restful services (unless the hardware implements CORS). One of these days I’ll have to filter through that email list to get an understanding of why they went with the server side.
Hi Les,
This is a pretty interesting idea. I'm not much of an expert here, but some comments follow.
----- Original Message -----From: "Les Stroud" <l...@lesstroud.com>To: dev-p...@lists.mozilla.orgSent: Tuesday, August 2, 2011 1:25:50 PMSubject: Printing...I don’t know if anyone is monitoring this list still….but I have anextension to pdf.js that might be interesting.For you guys, if you can render a pdf in javascript/html5, withoutneeding native components, then it would not be a very long step torender postscript (or, even PCL).
PostScript output isn't trivial but it's doable. I don't know PCL at all.
If you can render postscript and pclyou would cover 90% of the printers out there. With that, you coulduse the same mechanism to print from the browser without having to usenative divers. Not only would it be kewl, but it would keep the entireprinting process within the browser process sandbox.
It depends on what you mean by "browser process sandbox". The problem here is that web content by default can't do cross-origin HTTP requests, so since (presumably) pdf.js would be in a different origin from a discovered IPP printer, pdf.js wouldn't be able to talk to the printer by default. We could get around that problem by upping pdf.js's trust level to that of an "extension", but then we'd hit another issue: need to detect IPP printers, which can't be done with current web APIs. That's not an insurmountable problem either, but it would require adding a new web API for printer detection.
If you mean "browser process sandbox" as in the low-rights renderer processes like Chrome has (and Firefox will get eventually), then this scheme won't quite work because low-rights process can't do arbitrary networking, as would be required for IPP printer discovery. Low-rights renderers would need to use an IPP-discovery API implemented by a higher-rights process.
Another issue is that the PS (or PCL) we send to the printer, whether pdf.js is untrusted or not, needs to be validated to prevent maliciously-crafted PDFs from pwning a local IPP printer. This is new code someone would need to write, or we'd need to grab it from somewhere.
This would havethe following advantages:- Make firefox significantly more secure
This assumes that native printing code is insecure. Let's just fold this into "reduce native code" footprint and the statement won't be controversial.
- Open up the possibility of http accessible print “drivers”(javascript renders for the printer control language)...simplerinstalls by simply parsing an http/ipp response from an ip address forprinter model, querying a central service on the web, downloading thejavascript renderer live for that printer, and printing. This wouldmake rollouts and updates of print drivers a snap by taking advantageof browser caching.
It's not clear to me how much printer-specific "driver" code would be needed. Do you have a guess? But yes, "instant" updates to printing code by web-app-ifying it is very attractive.
- Reduced native code footprint that has to be maintained acrossplatforms.
Yes.With you guys headed toward becoming an operating system, this mightbe a really good fit…and it is a better answer than what google,apple, and hp have come up with….given you can render fairly quickly.
Possibly. Another problem though is that if the majority of printers nowadays aren't IPP-enabled (do you have numbers?), which is what I would guess, then using an IPP printing interface for all printers would require a translating proxy. Such a proxy would need to take the IPP and translate it into calls to native printing code, which wouldn't really improve overall system security, just move the problem out of firefox.exe.
Anyway, this is an interesting idea. I'll make sure to forward it along to people who know more about printing than I do.
Cheers,
Chris