41–50 of 277 posts
Earlier quoted context omitted.
In that case, is the issue actually specific to pdf.js? If it's written entirely in javascript, could this not be exploited some other way? Or does pdf.js have special permissions in this context?
Well, if I recall correctly, pdf.js is an add-on, so it has special permissions, just like any add-on.
But sending hashes of your downloads to Google [1][2] is a feature, right?
1. https://support.mozilla.org/en-US/kb/how-does-phishing-and-m... 2. https://bugzilla.mozilla.org/show_bug.cgi?id=1138721
The lack of additional detail in this very sparse announcement really compromises users' ability to damage control effectively. Would like to know if an installation is vulnerable if: 1) If Applications, PDF is set to "Always ask" 2) Ublock and/or privoxy are used 3) Javascript is disabled 4) pdfjs.previousHandler.alwaysAskBeforeHandling == false 5) pdfjs.disabled == true Also which advertising network and which Russ…
Well, sending some user files to Ukrainian server is a bug. But sending hashes of your downloads to Google [1][2] is a feature, right? 1. https://support.mozilla.org/en-US/kb/how-does-phishing-and-m... 2. https://bugzilla.mozilla.org/show_bug.cgi?id=1138721
Note: If you use your Linux distribution's packaged version of Firefox, you will need to wait for an updated package to be released to its package repository
It would be particularly scandalous if they knew that disabling pdfjs would suffice yet refused to mention it because they couldn't bear to see their precious CPU/memory-hogging scribd knockoff no one asked for being disabled by their users, in effect putting their grandiose vision of the browser-as-OS ahead of their users' security.
I don't even want my browser to have a 'local file context', is there a way to switch such behavior off entirely until explicit permission is given? All these extra bells and whistles added to browsers to allow websites to pretend they're 'native apps' should require a very large switch to be thrown from 'safe' to 'unsafe' whenever an application requests such a thing. And what a pdf reader has to do with javascript…
Maybe it would be better if browsers didn't have a pdf viewer, though. Then I'd have to manually download it and open it in a viewer to get owned, which is not going to happen with an ad network.
The fact that every major pdf viewer app tries to install a browser plugin doesn't help.
Well, sending some user files to Ukrainian server is a bug. But sending hashes of your downloads to Google [1][2] is a feature, right? 1. https://support.mozilla.org/en-US/kb/how-does-phishing-and-m... 2. https://bugzilla.mozilla.org/show_bug.cgi?id=1138721
How can I disable this.
I don't even want my browser to have a 'local file context', is there a way to switch such behavior off entirely until explicit permission is given? All these extra bells and whistles added to browsers to allow websites to pretend they're 'native apps' should require a very large switch to be thrown from 'safe' to 'unsafe' whenever an application requests such a thing. And what a pdf reader has to do with javascript…
Run the browser in a container or in a sandboxed environment (kindof like chroot, but note that chroot itself should not be used for security purposes). There may be docker containers with just firefox, if not it's easy to create one. Or use vmware, though that is much more heavyweight than sandboxing or containers.
The lack of additional detail in this very sparse announcement really compromises users' ability to damage control effectively. Would like to know if an installation is vulnerable if: 1) If Applications, PDF is set to "Always ask" 2) Ublock and/or privoxy are used 3) Javascript is disabled 4) pdfjs.previousHandler.alwaysAskBeforeHandling == false 5) pdfjs.disabled == true Also which advertising network and which Russ…
Inquiring minds would like to know.
Earlier quoted context omitted.
> 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/
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 jav…
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..