7 ms·

> And what a pdf reader has to do with javascript is a mystery as well. The whole reader is written in Javascript: https://mozilla.github.io/pdf.js/ https://mo

> And what a pdf reader has to do with javascript is a mystery as well. The whole reader is written in Javascript: https://mozilla.github.io/pdf.js/ https://mozilla.github.io/pdf.js/

jacquesm 11y ago
Oh great. What could possibly go wrong, give javascript access to local storage through some 'hard to trigger' gate. That's just asking for it. Hindsight and all that but still, this is not a good idea. A browser should not use it's own internal language sandboxed for the web to have access to the local system through some loophole. It's only a matter of time before such a loophole becomes an exploit. I wonder if javascript has access to devices such as cameras and microphones through similar loopholes. That would be a bit of a problem.
- st0p 11y ago
  WebRTC ;) https://en.wikipedia.org/wiki/WebRTC https://en.wikipedia.org/wiki/WebRTC
- k8tte 11y ago
  Uh, welcome to the web @ 2015
- stingraycharles 11y ago
  You're getting old and grumpy, Jacques, before you know it you will start your sentences with "back in the day..." :) On a more serious note, I guess this is the toll we have to pay for innovation pushing. I can understand the reasoning behind writing everything in JS: it allows you to consolidate a lot of mechanisms in a single platform. Once you have that platform secure, any application you will write will (should?) be secure too. Too bad that theory and practice are usually not the same, in practice..
  - baghira 11y ago
    I disagree that this is innovation. What innovation and what benefits do I reap by using pdf.js? It's slower and has less features than okular. It's stuck inside a firefox window, so I cannot add a window rule for it (barring adding one for firefox in general). The same holds on windows: why would I use pdf.js when there are faster, lighter pdf readers (e.g. sumatra) or the actual adobe acrobat reader and its eight bilions features? Heck, I've also noticed that many users will skim the file and then forget to save it, so it doesn't even help less tech savy users. There are genuine improvement in the new web technologies, but they are mixed with a lot of stuff that simply does not belong there, and with the insufferable attitude "you can do in javascript, hence you should it in javascript" (I'm not criticizing you, eh, and there is some security argument to be made).
    - stingraycharles 11y ago
      I agree with you that this innovation isn't a particulary good one. However, a single platform in a language that allows you develop and test rapidly (which, arguably, javascript is) is a consequence about the ever increasing push for innovation, which I can understand. In addition to that, I am very glad that Chrome and Firefox ship with their own PDF readers and I don't have to deal with Adobe anymore to read a portable document format.
    - anc84 11y ago
      Everyone is punished for Windows' Adobe Reader. I never got it either. PDF is not a web format. I would not want to read doc files in my browser either. Evince(-light) starts up in milliseconds.
      - randallsquared 11y ago
        > PDF is not a web format. Sure it is: http://tools.ietf.org/html/rfc3778 http://tools.ietf.org/html/rfc3778 ;) > I would not want to read doc files in my browser either. This doesn't make sense to me. Why should the viewer care about the implementation details of a document? If I click on a link to a document, I want to see the result in the browser, and I think that that's the correct default. Only if I'm clicking on something which produces something that isn't intended to be a document (an archive, for example) does opening another program make sense as the default.
  - JustSomeNobody 11y ago
    Writing a PDF viewer in JS isn't innovation. That word gets thrown around way to much. It's more like renovation.
  - jacquesm 11y ago
    The old is hard to avoid, I'll work on the grumpy :)
- _wmd 11y ago
  You haven't the slightest understanding of software security, PDF.js was written to replace a component authored in a memory-unsafe language for which exploits were being found at a rate measured in tens per year. Since introduction PDF.js has only had 2 holes that were directly exploitable, neither leading to remote code execution which was the default behaviour for pretty much any bug found in Acrobat. If you don't want a browser that has some notion of "local file context" you should just sell your laptop and go live in a cave. FWIW the entire Firefox UI and every plugin for it is _written_ in Javascript served from local disk. Chrome, Safari and IE aren't far behind
  - anon1385 11y ago
    If large amounts of code written in memory unsafe languages is such a concern then Mozilla should immediately stop adding large numbers of highly complex new features implemented in unsafe code to Firefox every year, mostly to do things that have absolutely nothing to do with displaying web pages but are enabled by default for political reasons. Just like switching to PDF.js was a decision taken to try and reduce the security attack surface, the decisions to add webgl, webrtc, webfonts, webm, websockets, new css features and so on were all decisions taken in the full knowledge that adding those things would vastly increase the attack surface and inevitably lead to security exploits. These new web features are responsible for a slew of new vulnerabilities and new classes of information leaks.
    - deleted 11y ago
      [deleted]
    - ronjouch 11y ago
      > (a) If large amounts of code written in memory unsafe languages is such a concern then Mozilla should immediately stop adding large numbers of highly complex new features implemented in unsafe code to Firefox every year, > (b) ... mostly to do things that have absolutely nothing to do with displaying web pages but are enabled by default for political reasons. (a) Mozilla is working on adding/replacing parts of Firefox with a language emphasizing security (among other things). First Rust push in Firefox landed a Rust mp4 parser [1], on 2015-06-17. Others will come; in the meantime, the world keeps turning, and users / web. developers expect these new web features, which Moz devs implement with the infrastructure they have and know. They're not going to cross their hands and declare a moratorium until Rust (or other security-mitigating features/changes) are fully integrated. (b) Not sure what you mean by political reasons and maybe you want to stay stuck in 1992, but I don't, and like many users I do want "webgl, webrtc, webfonts, webm, websockets, new css features and so on" . EDIT I'd have added "You can install links if you want a simple browser letting you read static html documents", which you would have answered with "But I can't, every website require these features now", to which I'd have answered "a. Yeah, not everyone (that's an understatement) does progressive enhancement, but ultimately b. The times they are a-changing" [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1175322 https://bugzilla.mozilla.org/show_bug.cgi?id=1175322
- wglb 11y ago
  Hindsight and all that but still, this is not a good idea. Do you mean the browser, or just this particular feature? Recommended reading: http://lcamtuf.coredump.cx/postxss/ http://lcamtuf.coredump.cx/postxss/ and http://lcamtuf.coredump.cx/tangled/ http://lcamtuf.coredump.cx/tangled/. If you do choose to read them, I recommend doing it earlier in the day--fitful sleep has been observed after evening reading of the above.
  - jacquesm 11y ago
    I'm aware of those. It's the 'inband/out-of-band' problem of old rearing its ugly head again, if you mix code/control and data in one stream it's asking for trouble.

> And what a pdf reader has to do with javascript is a mystery as well. The whole reader is written in Javascript: https://mozilla.github.io/pdf.js/ https://mozilla.github.io/pdf.js/

jacquesm 11y ago

Oh great. What could possibly go wrong, give javascript access to local storage through some 'hard to trigger' gate. That's just asking for it. Hindsight and all that but still, this is not a good idea. A browser should not use it's own internal language sandboxed for the web to have access to the local system through some loophole. It's only a matter of time before such a loophole becomes an exploit. I wonder if javascript has access to devices such as cameras and microphones through similar loopholes. That would be a bit of a problem.

st0p 11y ago
WebRTC ;) https://en.wikipedia.org/wiki/WebRTC https://en.wikipedia.org/wiki/WebRTC
k8tte 11y ago
Uh, welcome to the web @ 2015
stingraycharles 11y ago
You're getting old and grumpy, Jacques, before you know it you will start your sentences with "back in the day..." :) On a more serious note, I guess this is the toll we have to pay for innovation pushing. I can understand the reasoning behind writing everything in JS: it allows you to consolidate a lot of mechanisms in a single platform. Once you have that platform secure, any application you will write will (should?) be secure too. Too bad that theory and practice are usually not the same, in practice..
- baghira 11y ago
  I disagree that this is innovation. What innovation and what benefits do I reap by using pdf.js? It's slower and has less features than okular. It's stuck inside a firefox window, so I cannot add a window rule for it (barring adding one for firefox in general). The same holds on windows: why would I use pdf.js when there are faster, lighter pdf readers (e.g. sumatra) or the actual adobe acrobat reader and its eight bilions features? Heck, I've also noticed that many users will skim the file and then forget to save it, so it doesn't even help less tech savy users. There are genuine improvement in the new web technologies, but they are mixed with a lot of stuff that simply does not belong there, and with the insufferable attitude "you can do in javascript, hence you should it in javascript" (I'm not criticizing you, eh, and there is some security argument to be made).
  - stingraycharles 11y ago
    I agree with you that this innovation isn't a particulary good one. However, a single platform in a language that allows you develop and test rapidly (which, arguably, javascript is) is a consequence about the ever increasing push for innovation, which I can understand. In addition to that, I am very glad that Chrome and Firefox ship with their own PDF readers and I don't have to deal with Adobe anymore to read a portable document format.
  - anc84 11y ago
    Everyone is punished for Windows' Adobe Reader. I never got it either. PDF is not a web format. I would not want to read doc files in my browser either. Evince(-light) starts up in milliseconds.
    - randallsquared 11y ago
      > PDF is not a web format. Sure it is: http://tools.ietf.org/html/rfc3778 http://tools.ietf.org/html/rfc3778 ;) > I would not want to read doc files in my browser either. This doesn't make sense to me. Why should the viewer care about the implementation details of a document? If I click on a link to a document, I want to see the result in the browser, and I think that that's the correct default. Only if I'm clicking on something which produces something that isn't intended to be a document (an archive, for example) does opening another program make sense as the default.
- JustSomeNobody 11y ago
  Writing a PDF viewer in JS isn't innovation. That word gets thrown around way to much. It's more like renovation.
- jacquesm 11y ago
  The old is hard to avoid, I'll work on the grumpy :)
_wmd 11y ago
You haven't the slightest understanding of software security, PDF.js was written to replace a component authored in a memory-unsafe language for which exploits were being found at a rate measured in tens per year. Since introduction PDF.js has only had 2 holes that were directly exploitable, neither leading to remote code execution which was the default behaviour for pretty much any bug found in Acrobat. If you don't want a browser that has some notion of "local file context" you should just sell your laptop and go live in a cave. FWIW the entire Firefox UI and every plugin for it is _written_ in Javascript served from local disk. Chrome, Safari and IE aren't far behind
- anon1385 11y ago
  If large amounts of code written in memory unsafe languages is such a concern then Mozilla should immediately stop adding large numbers of highly complex new features implemented in unsafe code to Firefox every year, mostly to do things that have absolutely nothing to do with displaying web pages but are enabled by default for political reasons. Just like switching to PDF.js was a decision taken to try and reduce the security attack surface, the decisions to add webgl, webrtc, webfonts, webm, websockets, new css features and so on were all decisions taken in the full knowledge that adding those things would vastly increase the attack surface and inevitably lead to security exploits. These new web features are responsible for a slew of new vulnerabilities and new classes of information leaks.
  - deleted 11y ago
    [deleted]
  - ronjouch 11y ago
    > (a) If large amounts of code written in memory unsafe languages is such a concern then Mozilla should immediately stop adding large numbers of highly complex new features implemented in unsafe code to Firefox every year, > (b) ... mostly to do things that have absolutely nothing to do with displaying web pages but are enabled by default for political reasons. (a) Mozilla is working on adding/replacing parts of Firefox with a language emphasizing security (among other things). First Rust push in Firefox landed a Rust mp4 parser [1], on 2015-06-17. Others will come; in the meantime, the world keeps turning, and users / web. developers expect these new web features, which Moz devs implement with the infrastructure they have and know. They're not going to cross their hands and declare a moratorium until Rust (or other security-mitigating features/changes) are fully integrated. (b) Not sure what you mean by political reasons and maybe you want to stay stuck in 1992, but I don't, and like many users I do want "webgl, webrtc, webfonts, webm, websockets, new css features and so on" . EDIT I'd have added "You can install links if you want a simple browser letting you read static html documents", which you would have answered with "But I can't, every website require these features now", to which I'd have answered "a. Yeah, not everyone (that's an understatement) does progressive enhancement, but ultimately b. The times they are a-changing" [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1175322 https://bugzilla.mozilla.org/show_bug.cgi?id=1175322
wglb 11y ago
Hindsight and all that but still, this is not a good idea. Do you mean the browser, or just this particular feature? Recommended reading: http://lcamtuf.coredump.cx/postxss/ http://lcamtuf.coredump.cx/postxss/ and http://lcamtuf.coredump.cx/tangled/ http://lcamtuf.coredump.cx/tangled/. If you do choose to read them, I recommend doing it earlier in the day--fitful sleep has been observed after evening reading of the above.
- jacquesm 11y ago
  I'm aware of those. It's the 'inband/out-of-band' problem of old rearing its ugly head again, if you mix code/control and data in one stream it's asking for trouble.