4 ms·
OK, but then again: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chrome+pdf https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chrome+pdf
by mastazi 10y ago
OK, but then again: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chrome+pdf https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chrome+pdf
- lucb1e 10y agoVersus Firefox': https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pdf.js https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pdf.js
- josteink 10y agoFirefox is so utterly underrated these days. Such a shame. It's a good browser which puts the user in control and just gets the job done.
- swiley 10y agoThey've been moving away from that though, try changing your user agent or disabling JavaScript.
- lucb1e 10y agoAgreed, they are moving with what's popular. I'm just afraid it's necessary to keep market share. When moving browsers people allow a lot more disruption compared to when a browser gets an update. To move forward, old thing probably have to break... or at least, that's what I like to believe because otherwise Firefox is becoming shit.
- smkdtr 10y agoCount the instances of "arbitrary code execution" for chrome vs adobe. Its a huge improvement! Granted its not just the pdf reader in the case of adobe.
- johansch 10y agoHuh. I had assumed PDFium ran in the NaCl sandbox or similar. Is that not the case?
- hannob 10y agoThis is a good exercise in learning why counting CVEs doesn't give you anything. If you look closer at the pdfium vulns (I reported some of those) they include all kinds of "safety violations" with unclear impact. E.g. integer overflows, invalid memory reads etc. Many of those are simply undetectable without source-level check tools (mostly the C sanitizers). The Chrome team has a policy of counting a lot of stuff as vulns if it "could" cause a security issue. This is good - better safe than sorry. But it blows up their CVE count and makes them look bad for people doing bad statistics.