Hacker News Reader

Comment by jonknee | Hacker News Reader

> While Mozilla are pumping out stellar designs like this, Google are pushing crap like Native Client and their proprietary, binary-only Foxit Reader solution instead, complete with the hundreds of thousands of LOC of insecure C this entails. Rock on, Mozilla!

Why are you dumping on Google? Their browser has been able to handle PDFs for years (including forms!).

View on HN

Chrome's PDF plugin is closed source, and written in C. It is very useful, but not free as in FOSS.

And... ?

Something being closed source matters to some people. You might not be one of them, but other people might have different perspectives that cause them to value an open source option above a closed source equivalent.

Yes but the masses don't care if it's open or closed source.

No, but we should. For the masses that don't.

That the masses don't care about open source is reason to work really hard to educate them; not reason to not care either.

... from there comes most infections on windows PCs running chrome.

Source?

Actually, that would be Java.

Source? I don't believe this since so many levels of confirmation is required. I think the biggest source is the simple links to "KimKSexTape.jpg.exe".

Source: http://www.kaspersky.com/about/news/virus/2012/Oracle_Java_s... (Chrome uses its own PDF system, not Adobe Reader, so it's not even close to the threat level of Java).

Java has had multiple drive-by exploits discovered in just the past few months, which by definition don't require confirmation.

I was inaccurate, however. Java is almost certainly the cause of most exploits, but I daresay that user inexperience (to put it kindly) is probably the source of most infections. Touchè.

This is ridiculous. The foxit plugin is fully sandboxed and I have not seen any exploits via any of the netsec lists I subscribe to.

With a couple Google queries, you can find out that the Chrome PDF viewer has had multiple vulnerabilities that allow code to be executed in the sandboxed environment, and that there have also been Chrome vulnerabilities that allow sandboxed code to escape the sandbox.

Sandboxing is certainly a good thing, but it's not perfect. Sandboxed code still increases the attack surface. The rationale behind pdf.js is that, because it's almost entirely unprivileged JavaScript, it's unlikely that there's a way to exploit a browser in the presence of pdf.js that wouldn't work in the absence of pdf.js.

The browsers themselves have also been subject to such vulnerabilities. I dare say the attack surface of a full browser implementation is much larger than just the sandboxing, and sandboxing ideally sits behind all I trusted operations in the browser, providing a single common last line of defense.

It's not just a matter of open/closed source. Bundling in yet another C binary is only going to widen the surface area for security vulnerabilities for millions of people, and there's really not a great reason to do so anymore. PDF.js proves that it's possible to write high-performance javascript to do this stuff, without introducing any security risks and it's completely cross-platform. Computers are only going to get faster, and js compilers are only going to get better too.

But Chrome's works better and has been around (and useful for millions) for years. Perhaps they'll move to a JS solution in the future, but if I had to choose between the two right now I'd take the faster more complete one.

>But Chrome's works Citation needed, pdf.js has performed better for me personally than Chrome's viewer.

pdf.js supports PDF indexes (or whatever that's called), but AFAICT Chrome's doesn't.

JS-everywhere ideologues are always trying to buy a hamburger today and pay for it tomorrow. Someday machines will be faster. Someday the implementation will on par with the alternatives.

How it works today is what matters to users. Tomorrow the native stack will just make use of more hardware features, it will still be faster, and we'll still be having the same conversation that we'be been having with JS ideologues for 10 years now. "Someday ..."

This is what the XML ideologues used to say too. The problem wasn't XML, it was the libraries, or the lack of dedicated XML processing hardware. Then someone realized that if you got rid of the core complexity -- XML -- you could stop layering on piles of additional complexity while trying to work around the root of the problem.

Someday...

That has nothing to do with anything. If you're just having a dick measuring contest, Google has contributed a ton to the open source community. Google also provides nearly 100% of funding for Mozilla.

Open source is not about smelly dicks, it's about transparency, reusability, philsophy, politics. It's a lot of things (and they matter, because right now, society and technology are changing fast).

I am not against your main point but I am sure that Microsoft will provide at least 110% of funding if Google pulled their "funding".

If Microsoft were willing to provide pay as much or more, why aren't they doing it already to make Bing the default search engine?

Perhaps they had made an offer. We never would know.

We don't even know the details of the Mozilla-Google deal. For all the openness that Google and Mozilla appear to proffer, the agreement between them is a secret.

Mozilla has been saying for years that they will use the best engine, and take that engine's money if it's available. If Bing were clearly better than Google, they'd switch and be taking Microsoft's money.

They have said that during the time they are being offered the most money by the best search engine. That's easy. But Google keeps paying more which means Mozilla is after the highest bidder.

That is not how Mozilla's decision making works. There's considerably more to it than such simple economics.

As a non-profit, we are here to create a public good. It's actually goods, plural, and services too. Firefox and other Mozilla products and services exist to promote the Mozilla mission, not to enrich the Mozilla organization.

Yes. Sustainability is certainly a factor in some of our decision making. Mozilla would be foolish to ignore significant opportunities to increase its mission impact. But revenue for sustainability is not the sole or even the dominant factor in any major product decision at Mozilla.

My guess would be that if the offer is similar, Mozilla would be inclined to stick with Google. I'm sure you know how irritating it is to realise you missed a checkbox and now your homepage and default search are set to Bing - it's probably a user experience Mozilla was happy to avoid.

Plus, there are probably some advantages to having Google 'on side'.

If you're in the US, you may not notice it, but Bing is plain awful for international users. Google has spent a considerable amount of resources improving their engine to serve results based on your location and Google's Search Engine is clearly the best by a long shot. This is also why I'm not using DuckDuckGo.

Agreed. If Bing could match google's accuracy in scholar paper/reference searching I'd not mind to use it.

Bing on the other hand is much better than Google if you are searching for technical info on Microsoft products.

This product already exists, in at least proof of concept form: http://www.firefoxwithbing.com/

I think this is sufficient to show that they're at least thinking about it.

"Sorry, this download is not supported by your system." Meh.

For the average end user, it may not particularly matter that Mozilla's PDF implementation is open source and Google's isn't. However, for people like me who want to implement PDF-related functionality in their web/desktop application, it matters a great deal.

Chrome's built-in PDF plugin is actually from a Chinese company called Foxit.

http://googlesystem.blogspot.com/2010/08/google-chromes-pdf-...

Now start China bitching.

I've been using Foxit reader for years without knowing that it was Chinese. Its a great product - fast as hell - beats the pants off Adobe.

I'd started using Foxit for the same reason. But the speed advantage is no longer an issue. Adobe had closed the gap and Acrobat reader now loads just as fast as Foxit. Besides, Acrobat's rendering is far superior to Foxit's (not to mention Foxit fails to load some PDF document or displays garbage)

Acrobat is the new Foxit nowadays!

My problem with Adobe is that whenever I install any of their products I get the feeling I've just made my system more vulnerable to malware and the like. They've got an atrocious record when it comes to security bugs.

E.g. look at the size of this page: https://www.adobe.com/support/security/

I've not found anything that is even close to on par with Acrobat for fill-in PDF forms either.... Other viewers can sort-of handle it, but the results don't look right most of the time.

I like MuPDF. It doesn't really have an "interface" though. Just page-up, page-down, and +/- to zoom. But if all you're doing is reading pdfs...

The Chrome PDF Viewer is not really useful. There is no table of contents. You can't jump to specific pages. And so on. It is also closed source.

I wish Google would rather abandon their current viewer and start contributing/using pdf.js.

Google's PDF viewer refuses to save PDFs opened via the websites of some scientific journals. I'm not willing to play the proxy game every time I want to read journal papers so I save them locally. I stopped using Google's PDF viewer because of this misfeature.

Can you provide a citation or an example link for me to test? My understanding is that Chrome has the foxit plugin in a fully sandboxed environment. The PDF format nor the foxit system has any kind of DRM and shouldn't support this behavior.

There isn't any DRM, the plugin is just listening to a "suggestion" that it not let me save (no error, it just doesn't do anything when I click the save icon). Everything on ScienceDirect has this property. I just tested with this paper from my RSS feed (Chromium 24.0.1312.70).

http://www.sciencedirect.com/science/article/pii/S0045782513...

I'm using Chrome not Chromium, and there's no save icon. Are you sure you aren't viewing this in a proprietary viewer? Typically you should be able to right click and get a save as option.

I just confirmed that the same occurs with Chrome 24.0.1312.52 (Official Build 175374). I'm quite sure that I am viewing it in a proprietary viewer. Specifically, the Chrome PDF Viewer. Surely you've seen these buttons before?

http://i.imgur.com/80dO12V.png

In both Chrome and Chromium, clicking save here does nothing and "Save As" is greyed out in the right-click context menu. "Print" works in Chrome (though it takes time to produce a preview before I can print to PDF), but locks up Chromium.

This anti-user bullshit is usually less prevalent in non-proprietary software.

So long as you use their proprietary, binary-only version of it. The open-source Chromium cannot display PDFs, and as far as I can tell there's no way to make it capable of doing so.

Reply on news.ycombinator.com