> The plugin seeks permission to do three things; "read and change all data on the websites you visit," "manage your downloads," and "communicate with cooperating native applications." [...]
> it's likely that the extension itself is harmless enough
That seems unlikely given Adobe's history of truly awful security flaws. It wasn't that long ago when they thought that it would be a good idea for their add-on to pre-render PDFs in RAM silently in the background, including executing any embedded code without any sandboxing. Combined with browsers' prefetching of urls in a page (so that it would load quicker in case you clicked it), this caused a number of rootkit and other malware infections - from links that people didn't even click in search results and URLs served up in advertising or in comments/forum posts.
The only permission needed by a PDF viewer should be 'display PDF document content'. It shouldn't need to read or change other data, manage downloads, or communicate with anything to display an e-book or document. If it does, it's probably not harmless.
I'm not saying the permission request isn't overbroad, but "manage downloads" seems potentially reasonable. I'd imagine that some permission along those lines would be required for a PDF viewer to start displaying a document before it is completely downloaded.
Now I don't know that that is what they were using it for, whether they could have made a narrower permission request, and so on, but permissions are permissions because we want to permit them some of the time. I think it is counterproductive to dismiss requests before evaluating them. That's the kind of behavior that leads to kitchen-sink permission requests from the start (when users are most motivated to try something) because a developer doesn't trust that they'll get a reasonable targeted request tomorrow.
"The extension also collects basic information and sends this to Adobe. This tracking appears to be on by default, though it can be disabled through the extension's options page."
Another company collecting telemetry that you have to opt-out of. This needs to be illegal because often, by the time most people learn of the option, their information has already been snarfed.
At this point, browsers should block all plugins not explicitly installed through the browser. I can't think of any circumstances in which I would be happy to find that some software I installed has automatically installed a browser plugin.
Chrome, to its credit, doesn't automatically load extensions that are installed this way. (Or at least it shouldn't; I've seen enough malicious Chrome extensions in my tech support years that I suspect there's a way to bypass this prompt.) That doesn't excuse the practice though; no software update should install additional features without the user's consent, and this is a practice that seems to be all too common in the industry.
I'd presented a short talk on bypassing the prompts in both Chrome and Firefox a few years ago (2013), and it was possible by just recreating the appropriate registry entries for Windows and few changes in preferences.json.
Was slightly easier for Firefox (few entries in SQLite, iirc). However both browsers lock the data stored, so you had to force a restart as well.
How could a browser protect itself from being "infected" from the underlying OS layer? Given that the malicious installer has administrative access, it's a hole new set of challenges if they can't trust their own filesystem.
It really can't, at the end of the day, which was the major point raised during the QA. Also, you don't need Admin rights, seeing as Chrome installation works without admin rights, and all user data is maintained on a user-directory structure.
I expect to see these same companies try ever more fragile and bad methods to bypass these restrictions. If chrome refuses to load extensions from disk, they'll inject themselves into the process address space somewhere, which as a bonus will likely introduce sandbox escape vulnerabilities. This is what the AV vendors are doing these days.
They already try to do that. Hell some have even gone as far as to remove chrome, and install their own "infected" chromium compiled with their extension whitelisted and updates disabled.
It's terrifying. And while you could make a case for this "not being chrome's problem", the fact is that it's really hurting their user base, so they can't not do something about it.
AIUI, many of the top crashes of Chrome are from code injected into the address space (or rewriting the binary on disk). So yeah, it is hurting their user base and as a result it is hurting them.
It's pretty easy to open up a webpage that says "install this extension to finish installation" or update or what have you. Simple fact is, most computer users are not very tech savvy and will trust what their computers tell them if it looks official enough - especially if it's from a major player like Adobe.
The problem is how do you distinguish plugins installed through the browser versus not: at the end of the day, this falls into the typical DRM problem of how do you enforce restrictions (in this case, what can install plugins).
The direction browsers are all taking is requiring them to be signed by the browser vendor, effectively making them gatekeepers (and you can't have a preference to disable it, because if you did you could just install a plugin by disabling the preference (i.e., edit the config file) and then install the plugin normally). That really sucks too, sadly.
The alternative to DRM would be OS level sandboxing of applications, and particularly their installs. There are a multitude of benefits that would come from that.
Meanwhile, in the same ethical bucket, Oracle as recently as a week ago is adding a Yahoo! toolbar to your browser when you update Java, unless you uncheck their pre-checked opt-in checkbox. Sigh.
The scary things that happen when as a company, "hey, it's not like our users could possibly hate us more!" is true...and you're doing well financially for long periods of time.
Which is why I'm so glad openjdk for Windows has a clean installer now. Malware free installer, works identically to the Oracle version performance wise (according to me, no real tests done), etc.
My recollection is that this behavior in the Java updater actually pre-dates Oracle's acquisition of Sun. I think at one time it was for a different toolbar ('Ask!' maybe)... but it's not new by any means.
Having said that, of course just because Sun may have started the practice doesn't mean Oracle gets a pass for merely continuing it.... unless there was some long, long terms sort of contractual things: which I highly doubt.
My mom was a bit upset when I told her she couldn't install Adobe or Oracle software on her new computer (iMac) a few years ago, but today the thing still runs like it just came out of the box.
Do the right thing, and tell your family and friends to stay away from this malware.
I have a vague recollection of an incident, years ago, whereby Adobe installed Macafee whenever you installed a flash update. There was a little checkbox to control this, but it was checked by default. Pissed me off, i had get macafee off my computer pronto as it didn't get along with the anti virus i had already installed.
Yup. There was a huge internal commotion about this on our employee only general mailing list. The person who reported it was very shrewd, reporting the behavior as an open ended performance question. Employees in the Bay Area inmediately hated it. A VP had to step in and stop the discussion because it was happening in spite of our collective objection.
It was a Backchannel story about an "adtech" company in Philly: "The Perks Are Great. Just Don’t Ask Us What We Do."
Basically, a surprisingly large number of employees don't know or don't care about the ethics of what a small number of leaders in their company do. Others justify such actions to themselves in convoluted ways. Only a small number truly can't deal with it.
My current beef with Adobe is that they took a perfectly good mobile version of Photoshop for Android, broke it into 5 separate applications, that when combined, don't even reach the full functionality of the application they are replacing.
Someone really really needs to fix browser plugin permission system so that control can be very very fine-grained, and it's easy to review what information has been passed back and forth.
Well, do the users know that Chrome itself sends a bunch of data to Google? On principle, I consider both Adobe and Google's practices to be abhorrent, but practically speaking Google definitely has the better record on product reliability and security.
> it's likely that the extension itself is harmless enough
That seems unlikely given Adobe's history of truly awful security flaws. It wasn't that long ago when they thought that it would be a good idea for their add-on to pre-render PDFs in RAM silently in the background, including executing any embedded code without any sandboxing. Combined with browsers' prefetching of urls in a page (so that it would load quicker in case you clicked it), this caused a number of rootkit and other malware infections - from links that people didn't even click in search results and URLs served up in advertising or in comments/forum posts.
The only permission needed by a PDF viewer should be 'display PDF document content'. It shouldn't need to read or change other data, manage downloads, or communicate with anything to display an e-book or document. If it does, it's probably not harmless.