Re: [chromium-dev] Re: PSA: Chrome for Linux planning to drop NPAPI support as soon as April

16864 views
Skip to first unread message

7th...@gmail.com

unread,
Jun 2, 2014, 9:38:09 PM6/2/14
to chromi...@chromium.org, hector...@gmail.com
Using two browsers is just tiresome especially if you are using services like gaikai (needs java plugin), play some java games (yep, there are tons of them written as java applets) or try to watch drm content (I seriously can't get it why only on Linux pepper flash doesn't have drm module) on daily basis. Switching to Firefox or other browser is just a better idea.

As you can see we are not complaining about ditching NPAPI but about killing it only on Linux, least popular platform, way ahead of others. This way chromium on Linux probably won't have any other plugins than crippled flash for year or more and websites won't switch to html5 (not possible in many cases) only because chromium on Linux doesn't support necessary plugins anymore. Whole switching, writing new plugins will take place probably shortly before dropping NPAPI support on Windows, maybe even after that which will give you enormous amounts of complaints if new plugins won't be there. Aura didn't give us any real benefits but keeping NPAPI for the same time as other platforms would at least prevent alienating Linux chromium users from plugin content.

W dniu wtorek, 3 czerwca 2014 01:57:38 UTC+2 użytkownik Stuart Morgan napisał:
On Mon, Jun 2, 2014 at 3:56 PM, Hector Garcia <hector...@gmail.com> wrote:
I agree. I  -parcially- solved my personal needs uninstalling chrome
Ver 3.5 and installing Ver 3.4.

Downgrading to Chrome 34 and staying there indefinitely is a *very* dangerous solution to the problem; it's really unfortunate that instructions are circulating advising users (especially the large majority who don't understand the security implications) to "fix" the problem this way. This means exposing yourself to every vulnerability that has been or will be patched in any post-34 version of Chrome. It makes all browsing more dangerous just to enable specific pages to work.

Using another browser (e.g., Firefox) to access those specific pages, while using the current version of Chrome for your general browsing, would be a far better approach.

-Stuart

T.J. Crowder

unread,
Jun 3, 2014, 9:44:18 AM6/3/14
to chromi...@chromium.org, hector...@gmail.com, sayan...@gmail.com, jsc...@chromium.org, wilt...@chromium.org, e...@chromium.org, be...@chromium.org, da...@chromium.org
PhistucK:

While forty million people may pay taxes online, how many of them are doing it using Linux?
The Linux worldwide market share is very, very small. You must factor that into your calculations.

Maybe you missed the part where this decision will be hitting Windows by the end of the year.

-- T.J.

On Friday, 30 May 2014 21:19:20 UTC+1, PhistucK wrote:
While forty million people may pay taxes online, how many of them are doing it using Linux?
The Linux worldwide market share is very, very small. You must factor that into your calculations.


PhistucK


On Fri, May 30, 2014 at 7:53 PM, Hector Garcia <hector...@gmail.com> wrote:

El jueves, 22 de mayo de 2014 01:06:24 UTC-5, Matt Giuca escribió:
I want to reiterate that this decision was a security decision, not a deliberate choice to shut down access to these services. (The point has been made many times before, but not recently on this thread.) The removal of NPAPI on Linux in Chrome 35 was not simply a policy decision.

NPAPI is a technology from the 1990s which basically predates modern computer security. Any NPAPI plugin can completely take over your machine, and frequently, NPAPI plugins run untrustworthy code from the Internet on interpreters with security vulnerabilities. Chrome is powerless to protect you from malicious or insecure NPAPI plugins owning your machine.

On Windows and Mac, there is a long deprecation plan so these plugins will continue to work a while longer while other work-arounds are found. On Linux, we ran into a practical problem: since we are moving the UI stack from GTK to Aura in Chrome 35, NPAPI plugins would not run on Chrome 35 without a serious amount of engineering effort. Since NPAPI is being deprecated, it did not make sense for Google to commit a lot of engineering effort to writing new NPAPI architecture that will be deleted within a year, especially not on Linux which has a very small market share.

The timing is unfortunate, but the number of Linux users that require NPAPI plugins that aren't Flash is just too small to justify this effort.

Suggestions along the lines of using sockets to allow PPAPI plugins to talk to stand-alone NPAPI plugins require a similar amount of engineering effort, and defeat the entire point of removing NPAPI, which is that it is insecure to let code downloaded from the Internet talk to arbitrary native applications.



Dear Matt

I think you haven't done a thorough analysis on how many people are actually being affected.

Let's talk about Mexico.  Our goverment tax office is "married" with third party -comercially licensed platforms , such Java and Silverlight. AFAIK the only  way to run Silverligh on Linux stations it's by piperlight, a NPAPI plugin.

Put it simply, without Java and Silverlight, we cannot pay taxes. 

Acording to official numbers, at November 2013, in Mexico,  we were ~ 40 million people who pay taxes. Is that a small user number for you?

Ok we can say that almost all the accounting professionals (who take the designation of paying  taxes from their customers, the taxpayers) use IE/Windows to do their job. 

Are we assuming that we, the 40 million people who pay taxes, we are forced to use IE / Windows in order to meet our obligations?

I know this is a discussion that we should keep with mexican government. But i think Google isn't doing a good job for a change opportunity.

Wouldn't be a good practice, to wait  (or develop) a good alternative to NPAPI (PPAPI only supporting for flash is far from it) before dropping it?


Anyway, things are done. I didn't paid anything for chrome, I understand that Google gave it to me on a free basis. I was happy with it. I have the right to take the decision of keep using it or not. Until there is an acceptable solution, goodbye chrome..



Para información de mis compratriotas, lo pongo en español..

Estimado Matt.
Me parece que no has hecho un análisis exhaustivo de cuantas personas están siendo realmente afectadas.
Hablemos de México. Nuestra oficina de impuestos esta "casada" con aplicaciones de terceros bajo licencias comerciales, como Java y Silverlight. Hasta donde sé, la única manera de ejecutar Silverlight en los equipos Linux es usando piperlight, un plugin NPAPI .

En pocas palabras, si no hay Java y Silverlight, no podemos pagar impuestos.

Según cifras oficiales, a Noviembre de 2013 en México éramos ~ 40 millones de personas los que pagamos impuestos. 
¿Eso es un número de usuarios pequeños para tí?

Ok , podemos decir que casi todos los profesionales de la contabilidad ( que toman la responsabilidad de pagar los impuestos de sus clientes , los contribuyentes ) utilizan IE / Windows para hacer su trabajo .

¿Asumimos que, los 40 millones de personas que pagamos impuestos, estamos obligados a usar IE/Windows para cumplir con nuestras obligaciones?

Sé que este es un debate que debemos mantener con el gobierno mexicano . Pero creo que Google no está haciendo un buen trabajo para una oportunidad de cambio.

¿No sería una buena práctica, esperar ( o desarrollar ) una buena alternativa a NPAPI ( PPAPI que solo soporta  flash está lejos de serlo) antes de desecharlo?


De todos modos , las cosas ya están hechas . Yo no pagué nada por Chrome , entiendo que Google me lo dio de forma gratuita . 
Estaba contento con él. 
Tengo el derecho de tomar la decisión de seguir usando o no. 

Hasta que no haya una solución aceptable , adiós Chrome .

Saludos /best regards



--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

PhistucK

unread,
Jun 3, 2014, 10:38:44 AM6/3/14
to t...@crowdersoftware.com, Chromium-dev, Hector Garcia, Sayantan Das, Justin Schuh, Tom Wiltzius, Elliot Glaysher, be...@chromium.org, Darin Fisher
I did not miss it, that was the reason Linux support was dropped so early.
It was not worth the effort when the platform is rarely used, relatively.

By the end of the year, most of the websites and organizations that want to support Chrome will have to implement new ways, or give up on it. This is known.


PhistucK

Thiago Farina

unread,
Jun 3, 2014, 2:05:00 PM6/3/14
to 7th...@gmail.com, Chromium-dev, hector...@gmail.com
On Mon, Jun 2, 2014 at 10:38 PM, <7th...@gmail.com> wrote:
Aura didn't give us any real benefits
The benefit may not be visible to the users, but for devs it meant they don't need to worry about porting UI changes to GTK+ port. So one less port you have to do, less disparity, less bugs creeping in, more time you have for fixing other bugs. So it is a big win IMO.

-- 
Thiago Farina

DG

unread,
Jun 10, 2014, 11:01:16 AM6/10/14
to chromi...@chromium.org, ddg...@gmail.com, sayan...@gmail.com, jsc...@chromium.org, wilt...@chromium.org, e...@chromium.org, be...@chromium.org, da...@chromium.org
The change from GTK to Aura has been in the works for multiple years

So then in essence this whole boondoggle really goes back to the Not-Invented-Here moment when Chrome/Chromium were first created, in lieu of collaborating to make an existing open-source, mainstream browser (Firefox) better.

This Linux ecosystem fragmentation monster just cannot be killed. All this effort could have been expended on other things more beneficial to end users. Instead, your own NIH project just created more disadvantages.

Michał Gołębiowski

unread,
Jun 10, 2014, 11:11:41 AM6/10/14
to T.J. Crowder, chromi...@chromium.org, Hector Garcia, Sayantan Das, jsc...@chromium.org, Tom Wiltzius, e...@chromium.org, be...@chromium.org, Darin Fisher
On Tue, Jun 3, 2014 at 3:44 PM, T.J. Crowder <t...@crowdersoftware.com> wrote:
PhistucK:

While forty million people may pay taxes online, how many of them are doing it using Linux?
The Linux worldwide market share is very, very small. You must factor that into your calculations.

Maybe you missed the part where this decision will be hitting Windows by the end of the year.

Please stay on topic. This thread is about dropping NPAPI on Linux assuming (and not questioning) dropping it at the end of the year on other platforms. The argument for it is that it's not worth to put engineering effort just to make NPAPI work on Linux for 6 months longer considering its low market share.

Dropping NPAPI on Windows & OS X is a separate topic and doesn't belong in this thread.

P.S. Re-posting as the previous one didn't go through; I wasn't in the group.

--
Michał Gołębiowski

T.J. Crowder

unread,
Jun 10, 2014, 11:16:43 AM6/10/14
to chromi...@chromium.org, t...@crowdersoftware.com, hector...@gmail.com, sayan...@gmail.com, jsc...@chromium.org, wilt...@chromium.org, e...@chromium.org, be...@chromium.org, da...@chromium.org
My reply to PhistucK was entirely on-topic, as Linux is just the first step. To justify adding to the noise with "please stay on topic" would require something much, much more off-topic than that.

-- T.J.

ALAA MURAD

unread,
Jun 15, 2014, 12:26:02 PM6/15/14
to chromi...@chromium.org, jsc...@chromium.org, wilt...@chromium.org, e...@chromium.org, be...@chromium.org, da...@chromium.org
Java and Linux is Liberty for us, most Windows' made applications run in Linux because of Java, calculating the raw usage of Java is "stupidity". Java Applet importance comes from high-class applications for professional users, like Stocks trading software, VPN access, in browser VNC and list can go on and on. 

Saying only 1% used Java Applet in the last 30 days and it's enough reason to drop it, is nonsense , this like saying , you only log-in to your bank account once a month , so it's fair to drop such support. Lets take it even further, how many POST HTTP calls vs GET getting called, maybe less than 0.001% of all calls are POST, please don't remove that (we do need the POST as well)

Google's "Don't be evil" motto , is breaking day by day. Linux is the best OS, only if you can strip it down and put you Android OS on top of it, Java is the perfect companion to Android if you can cut-off Oracle and package it for free to make billions (tens of billions) from ads. 

How about Google to stop being self centered and stop thinking about stuff strategically , because you're becoming like Micro$oft, they linked everything almost directly to how much benefit this will bring to Windows and Office, and you're linking everything to the possibility of showing ads on it.

Richard Lloyd

unread,
Jun 21, 2014, 3:30:09 AM6/21/14
to chromi...@chromium.org, jsc...@chromium.org, wilt...@chromium.org, e...@chromium.org, be...@chromium.org, da...@chromium.org
It seems the dropping of NPAPI support wasn't triggered by lack of usage or security reasons, but actually because Google are moving away from GTK and re-jigging their graphics layer from GTK to Aura (why? If there's issues with GTK, why not talk to GTK devs and get some changes made to it?). This move is being made without any possibility of supporting NPAPI plug-ins on Linux apparently - Google are claiming that they will do the same on other platforms before the end of this year.

 However, I can bet any amount of money that they won't drop NPAPI support on Windows or Mac OS X until all the major NPAPI plug-ins (Java in particular) on those platforms have PPAPI support. This is because there would be massive uproar and browser defections potentially in the millions - but apparently the Linux platform is small enough for Google to ignore these complaints.

BTW, for Linux system administrators using Google Chrome, VNC console support (think Dell iDrac, HP iLO etc.) uses Java, so bang goes any support for that - well done, Google, you've just annoyed half the people who maintain Web servers.

Mike Frysinger

unread,
Jun 21, 2014, 3:38:21 AM6/21/14
to rkl...@gmail.com, chromium-dev
anyone who understands anything about NPAPI knows it is impossible to do anything security related to it.  the API needs to die, and it should have died years ago.

if you want a VNC client in Chrome, then use one of the apps that are in the CWS.  there's at least one free one in there and has been for a long time.  then again, i've maintained a lot of web servers and have never needed VNC ... that's what ssh is for (also free clients in the CWS).
-mike

Richard Lloyd

unread,
Jun 21, 2014, 3:55:31 AM6/21/14
to chromi...@chromium.org, rkl...@gmail.com


On Saturday, 21 June 2014 08:38:21 UTC+1, Mike Frysinger wrote:
anyone who understands anything about NPAPI knows it is impossible to do anything security related to it.  the API needs to die, and it should have died years ago.

The problem here is that it unfortunately *hasn't* died yet. Installing Oracle Java proudly reminds us that Java is on "3 billion devices" and it's still only supporting NPAPI at the moment. The earliest possible time to drop NPAPI support is when at least one Java implementation supports NPAPI - that hasn't happened yet on any platform, so no matter what the Aura/security/usage reasons are, Google have 100% jumped the gun here. Google should have been talking to all major Java distributors and persuaded them to support PPAPI (even if it means funding a developer or two on each platform to do it if there's resistance to it), but I guess that's just too sensible for them to consider.


> if you want a VNC client in Chrome, then use one of the apps that are in the CWS.

You do realise that these VNC viewers are embedded into the appropriate Web user interface and often generate dynamic Java Web Start JNLP files and therefore can't have a Chrome VNC viewer substituted for them?
 
> i've maintained a lot of web servers and have never needed VNC ... that's what ssh is for (also free clients in the CWS).

You've obviously never remotely installed an OS or ever rebooted a Web server and wanted to monitor its boot sequence remotely - both of which many sysadmins do regularly. Yes, once the full multi-user OS is up and running, ssh is what everyone uses, but not when you want to reboot to make BIOS changes remotely etc. Many of us don't like traipsing down to the machine room to do stuff on the physical console that could be done remotely instead. Linux Chrome is now pretty well dead to most sysadmins now I reckon.

Mike Frysinger

unread,
Jun 21, 2014, 4:43:08 AM6/21/14
to rkl...@gmail.com, chromium-dev
On Sat, Jun 21, 2014 at 12:55 AM, Richard Lloyd wrote:
On Saturday, 21 June 2014 08:38:21 UTC+1, Mike Frysinger wrote:
anyone who understands anything about NPAPI knows it is impossible to do anything security related to it.  the API needs to die, and it should have died years ago.

The problem here is that it unfortunately *hasn't* died yet.

it will when it stops working in browsers

Installing Oracle Java proudly reminds us that Java is on "3 billion devices"

feature phones running java isn't terribly interesting.  the trend is moving away from native installs and Java and to only the web platform.  certainly hasn't been a blocker for iOS being accepted in the marketplace.

> i've maintained a lot of web servers and have never needed VNC ... that's what ssh is for (also free clients in the CWS).

You've obviously never remotely installed an OS or ever rebooted a Web server and wanted to monitor its boot sequence remotely - both of which many sysadmins do regularly.

your limited experience does not a generalization make.  i have no problem power cycling, reimaging, watching boot output, etc... with only a ssh connection.  been doing it for years now.

at this point, people are kicking a dead horse and it realistically isn't coming back.  if Chrome doesn't work for you, then feel free to use a different browser / OS.  no one is forcing you to use Chrome.
-mike

ALAA MURAD

unread,
Jun 21, 2014, 5:03:30 AM6/21/14
to chromi...@chromium.org, rkl...@gmail.com
So now, Google has Apple as the figure to follow ?!! Most of Google's success came because we believed on you guys, we believed that you're different !

At least Apple didn't benefit from Linux or Java, but you guys did.

And finally it's clear from what you saying that you're trying to kill "Java Applet" and this has nothing to do with the limitation of APIs, this gray box is not indexable , you can't crawl it or stick ads on it ... this is the bottom-line !  when it came to Flash , no way to drop it, you making billions from youtube and other flash ads. 

So Flash is great, because it plays your videos and ads, but some bank systems running in Java is not important ...

Plain Selfish !

Mike Frysinger

unread,
Jun 21, 2014, 5:10:18 AM6/21/14
to alaa...@gmail.com, chromium-dev, Richard Lloyd
well, i never said any of that, so at this point you're just making up random stuff.  if you want to pontificate for the fun of it, use a different forum (i.e. not this mailing list).
-mike

Solerman Kaplon

unread,
Jun 21, 2014, 9:26:45 AM6/21/14
to chromi...@chromium.org
Em 21-06-2014 04:55, Richard Lloyd escreveu:
> You do realise that these VNC viewers are embedded into the appropriate Web
> user interface and often generate dynamic Java Web Start JNLP files and
> therefore can't have a Chrome VNC viewer substituted for them?

IF they are JNLP files, you don't need a plugin to handle them, just pass them
to the underlying launcher in the JVM just like you do with eg: zip files and be
done with it. Only proper applets aren't going to work but I do get your point.

Solerman

Matt Giuca

unread,
Jun 22, 2014, 8:08:28 PM6/22/14
to rkl...@gmail.com, chromium-dev
To reply briefly, from an engineering perspective (re Aura):

On 21 June 2014 17:30, Richard Lloyd <rkl...@gmail.com> wrote:
It seems the dropping of NPAPI support wasn't triggered by lack of usage or security reasons, but actually because Google are moving away from GTK and re-jigging their graphics layer from GTK to Aura (why? If there's issues with GTK, why not talk to GTK devs and get some changes made to it?). This move is being made without any possibility of supporting NPAPI plug-ins on Linux apparently - Google are claiming that they will do the same on other platforms before the end of this year.

Yes, this is largely true, in some sense. The decision to drop NPAPI was triggered by security reasons, but dropping it early on Linux was due to changing GTK to Aura (we aren't going to go into the reasons for that here; that decision was made a long long time ago). If we were planning to support NPAPI in the long term, we would have supported it on Linux Aura, but because we're planning to drop it on other platforms, we aren't going to implement a brand new NPAPI stack on Linux just for a few months.

Sayat

unread,
Mar 17, 2015, 12:29:09 AM3/17/15
to chromi...@chromium.org, jsc...@chromium.org, wilt...@chromium.org, e...@chromium.org, be...@chromium.org, da...@chromium.org
Google couldn't find better solution than just stop supporting NPAPI. That's unbelievable! They have thousands of workers, and what they could do is just stop supporting

среда, 8 января 2014 г., 6:04:18 UTC+6 пользователь Max Heinritz написал:
Hi Chromium community,

In September 2013, we announced that NPAPI support will be phased out of Chrome in 2014, with the following schedule:
  • January: block NPAPI plug-ins by default
  • Mid-year: more aggressive blocking (different UI, smaller whitelist)
  • Before end of 2014: remove support completely
The update here is that Linux NPAPI support may be dropped as early as M34 (goes to Stable in early April).  The reason for this timeline is that we've decided not to implement NPAPI support in Linux Aura.  We feel comfortable doing so because affected plug-ins all have 30-day launch rates below .7% of Linux Chrome users.

A few things to keep in mind:
  1. So long as they are not too crazy, we might accept patches to add NPAPI support to Linux Aura. (We won't commit to supporting it or shipping it though.)
  2. Once we stop supporting NPAPI on Windows, we'll proceed to remove the code entirely for all platforms, including Linux Aura.
Let us know if you have questions.

Max

Victor Khimenko

unread,
Mar 17, 2015, 6:54:17 AM3/17/15
to saya...@gmail.com, Chromium-dev, jsc...@chromium.org, wilt...@chromium.org, e...@chromium.org, be...@chromium.org, Darin Fisher
On Tue, Mar 17, 2015 at 7:29 AM, Sayat <saya...@gmail.com> wrote:
Google couldn't find better solution than just stop supporting NPAPI. That's unbelievable! They have thousands of workers, and what they could do is just stop supporting

Thousands of workers couldn't solve all world problems, sorry. If it was solely about the number of workers then Foxconn which have more two times workers than Apple, Google, IBM, and Microsoft COMBINED would have had the best OS, best search engine and best mobile phone.

NPAPI is evil and was on the life support from the day one. How evil? Well, when Chrome was first presented to the world over six years ago it was done with a comic book. Said comic book ALREADY contained the part which explained why NPAPI is evil:

It was obvious to anyone who have read the words "in that way the rest of page can be still be sandboxed, even if plugin can't be" that it's unsatisfactory temporary solution which can have only one natural resolution: to remove NPAPI plugins out of the picture altogether. It just took somewhat longer then people expected: I'm sure developers hoped that they would be able to remove NPAPI in a year or two when said pages were drawn, but in reality it took six years.

среда, 8 января 2014 г., 6:04:18 UTC+6 пользователь Max Heinritz написал:
Hi Chromium community,

In September 2013, we announced that NPAPI support will be phased out of Chrome in 2014, with the following schedule:
  • January: block NPAPI plug-ins by default
  • Mid-year: more aggressive blocking (different UI, smaller whitelist)
  • Before end of 2014: remove support completely
The update here is that Linux NPAPI support may be dropped as early as M34 (goes to Stable in early April).  The reason for this timeline is that we've decided not to implement NPAPI support in Linux Aura.  We feel comfortable doing so because affected plug-ins all have 30-day launch rates below .7% of Linux Chrome users.

A few things to keep in mind:
  1. So long as they are not too crazy, we might accept patches to add NPAPI support to Linux Aura. (We won't commit to supporting it or shipping it though.)
  2. Once we stop supporting NPAPI on Windows, we'll proceed to remove the code entirely for all platforms, including Linux Aura.
Let us know if you have questions.

Max

--

Ricardo Ribalda Delgado

unread,
Mar 17, 2015, 7:31:06 AM3/17/15
to kh...@chromium.org, saya...@gmail.com, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, be...@chromium.org, Darin Fisher
I don't think anybody here disagrees that the NPAPI was insecure.

The issue is that there is no way to use the java plugin now. And that
plugin is needed to work with the Administration (tax, health....) in
multiple countries.

The same way that Google found provided a replacement for flash, they
should have worked on a solution for java.

To an uneducated eye, this just seems Google lobbying against a
technology that runs terribly bad on Android (java). But I am not part
of the develpment of chromium, and there might be a very good reason
for doing the things as they were done.

Google can have very good statistics about browser usage. Have you
seen any loss of market since NPAPI was not supported?

Regards!

--
Ricardo Ribalda

Alexis Menard

unread,
Mar 17, 2015, 7:39:50 AM3/17/15
to ricardo...@gmail.com, kh...@chromium.org, saya...@gmail.com, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, be...@chromium.org, Darin Fisher
That's difficult to measure. I myself just switch to Firefox when a
website requires me to use a Java applet but use Chrome as my daily
driver. I believe I'm not alone thinking that way.

>
> Regards!
>
> --
> Ricardo Ribalda
>
> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>

Ricardo Ribalda Delgado

unread,
Mar 17, 2015, 7:51:06 AM3/17/15
to Alexis Menard, kh...@chromium.org, saya...@gmail.com, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, be...@chromium.org, Darin Fisher
> That's difficult to measure. I myself just switch to Firefox when a
> website requires me to use a Java applet but use Chrome as my daily
> driver. I believe I'm not alone thinking that way.

In my case I use firefox for e-commerce and taxes... and chrome for
the rest. My bank uses java for its "secured by visa" system.

Thanks to this I have realized the amazing work the firefox people
have done in the last two years. Performance is getting close to
chrome.

Is has happened more than once that I have just realized I was not
using chrome because I had to login in the page again :)

Victor Khimenko

unread,
Mar 17, 2015, 8:19:58 AM3/17/15
to Ricardo Ribalda Delgado, saya...@gmail.com, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, be...@chromium.org, Darin Fisher
On Tue, Mar 17, 2015 at 2:30 PM, Ricardo Ribalda Delgado <ricardo...@gmail.com> wrote:
I don't think anybody here disagrees that the NPAPI was insecure.

The issue is that there is no way to use the java plugin now. And that
plugin is needed to work with the Administration (tax, health....) in
multiple countries.

There's little Google could do. Many NPAPI plugins are bad, but Java Plugin is a security disaster:

That's why most sensible institutions have stopped using it long ago. Once upon time my bank have also used it, e.g., but when it become clear that Java is a dead end it stopeed doing that - years ago. Yet some institutions have ignored all the warnings and continue to use it as before. Again: YEARS after it become clear that they should stop. This is unfortunate development, but I don't see exactly what Google could do there.
 
The same way that Google found provided a replacement for flash, they
should have worked on a solution for java.

Java and Flash are very different WRT security. Most flash sites out there don't need holes in a sandbox. The fact that Flash has security holes is unfortunate but they could be plugged - at least in theory. This makes Flash part of the web platform. Not a best part of it, but still legitimate part of it: the main difference between other platforms and web lies in the fact that you don't need to trust the website to visit it, browser is supposed to protect you.

But Oracle, not Google, broke this fundamental principle WRT Java: Oracle now does not even pretend that it could plug the holes in Java plugin anymore and, more impotantly, many "tax, health, ..." programs are written in a really sloppy way and couldn't be sandboxed without the crippling functionality loss. Yes, the fact that you couldn't run most Java applets out there and only could run few selected ones if you allow full access to the host system improves security situation short-term but it ALSO means that Java is no longer part of the web platform. Long-term it's dead, NPAPI or no NPAPI.

To an uneducated eye, this just seems Google lobbying against a
technology that runs terribly bad on Android (java). But I am not part
of the develpment of chromium, and there might be a very good reason
for doing the things as they were done.

Google can have very good statistics about browser usage. Have you
seen any loss of market since NPAPI was not supported?

I don't think there was a measurable change. But then each version brings many changes to the table, it's really hard to see how each induvidual one affects users and home many of them are leaving because of these changes. Unless change is really crippling and visible, that is.

Stuart Morgan

unread,
Mar 17, 2015, 9:47:44 AM3/17/15
to ricardo...@gmail.com, Chromium-dev
On Tue, Mar 17, 2015 at 4:30 AM Ricardo Ribalda Delgado <ricardo...@gmail.com> wrote:
The same way that Google found provided a replacement for flash, they
should have worked on a solution for java.

To an uneducated eye, this just seems Google lobbying against a
technology that runs terribly bad on Android (java).

I'd suggested uneducated eyes take a look at the statistics given in
before drawing conclusions. It's clear from those statistics that Java was not singled out. And while Flash numbers aren't there since it was already no longer NPAPI-based, I'd be shocked if there weren't an order of magnitude difference (and you'll notice that the Mozilla page linked from that post also treats Flash differently due to its qualitatively different level of usage).

-Stuart

Matt Giuca

unread,
Mar 17, 2015, 2:27:12 PM3/17/15
to stuart...@chromium.org, ricardo...@gmail.com, Victor Khimenko, Chromium-dev
Thanks, Victor, for sharing that comic. It's great to look back at the foundations of Chromium and see that, if you read between the lines, that replacing NPAPI with a properly sandboxed solution was really part of the Chromium game plan since day one.

--

Konstantin Boyandin

unread,
Mar 27, 2015, 10:57:30 AM3/27/15
to chromi...@chromium.org, jsc...@chromium.org, wilt...@chromium.org, e...@chromium.org, be...@chromium.org, da...@chromium.org
On no thread related to NPAPI dismantling there's plain response to simple question: how Google Chrome users are expected to view Web documents utilizing Java-driven elements?

It's obvious that Chrome developers will simply respond "That's not our business". Oracle, as you could notice, keeps silent. It's obvious they are not encouraged by idea to develop Java plugin utilizing Aura.

So, from plain "ordinary" user point of view: what do you offer me to use to still be able to run Java objects on Web pages? Open another browser, that hasn't yet abandoned Java support?

I do not want to raise any flame, but looks like developers do not even assumed the users' needs and actual requirements. I am only "pro" using modern technologies and discard older ones, but how about usability?

I will be surprise to read any answer from developers different from "We don't care" or "It's not our business to develop plugin compatible with Java".

Thanks.

Sincerely,
Konstantin

Stuart Morgan

unread,
Mar 27, 2015, 11:11:40 AM3/27/15
to konst...@boyandin.com, chromi...@chromium.org, jsc...@chromium.org, wilt...@chromium.org, e...@chromium.org, be...@chromium.org, da...@chromium.org
--

Stuart Morgan

unread,
Mar 27, 2015, 11:19:59 AM3/27/15
to konst...@boyandin.com, chromi...@chromium.org, jsc...@chromium.org, e...@chromium.org, be...@chromium.org, da...@chromium.org
[Whoops, somehow hit send immediately]

On Fri, Mar 27, 2015 at 7:57 AM Konstantin Boyandin <konst...@boyandin.com> wrote:
On no thread related to NPAPI dismantling there's plain response to simple question: how Google Chrome users are expected to view Web documents utilizing Java-driven elements?
[...]

Open another browser, that hasn't yet abandoned Java support?

Using another browser for pages that haven't yet moved away from depending on an NPAPI plugin (including Java) is a reasonable option, yes. That was in fact addressed earlier in this thread.

This is already the case for anyone trying to use such a site from a mobile device, except that they can't just open another browser, they have to move to a completely different device (assuming they even have one available).

-Stuart 

Konstantin Boyandin

unread,
Mar 27, 2015, 12:02:37 PM3/27/15
to Stuart Morgan, chromi...@chromium.org, jsc...@chromium.org, e...@chromium.org, be...@chromium.org, da...@chromium.org
Пт, 27.03.2015 в 21:19 Stuart Morgan писал(а):
This is what I am saying: proper policy would be to warn users about
Java upcoming demise long ago, not just tell them "You 're out of luck,
we don't support it in a couple of weeks".

I have now to use Chrome (since it supports more or less up-to-date
Flash), Firefox (which is now less greedy in memory appetites) and Opera
(since it still supports Java). I am getting tired of this zoo, since
all the developers are too distant from mundane woes, they just don't
care. "Just use another device/browser", as you've mentioned. Just buy
another device. Just upgrade to latest version. Just don't use that
application.

I would like to offer developers another strategy: when something is
obviously gets poorly or not supported, aggressively advocate against
it, encourage developing alternatives and so on - starting that few
years before abandoning the piece of technology..

Thanks.

Konstantin

Victor Khimenko

unread,
Mar 27, 2015, 12:03:13 PM3/27/15
to konst...@boyandin.com, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, be...@chromium.org, Darin Fisher
On Fri, Mar 27, 2015 at 5:57 PM, Konstantin Boyandin <konst...@boyandin.com> wrote:
On no thread related to NPAPI dismantling there's plain response to simple question: how Google Chrome users are expected to view Web documents utilizing Java-driven elements?

If they really need trojans and malware, there are easier ways to achieve that.
 
It's obvious that Chrome developers will simply respond "That's not our business". Oracle, as you could notice, keeps silent.

It's even worse that that. As I already wrote Oracle have given up on Java security. As in: completely. 

As everyone knows signed Java applets are a disaster:
And today everything else is forbidden:

Yesterday's story was "Java security is abysmal but we'll fix it, trust us". Today's story is "Java security is broken and we don't plan to fix it - ever".

When you hit Java applet today you only have two easy choices:
1. Don't run it at all.
2. Give it full access to your system, all it's files and documents.
I'm afraid a lot of guys don't understand that when they run Java applet these days they give it full access to everything on their system. 

It's obvious they are not encouraged by idea to develop Java plugin utilizing Aura.

Indeed.
 
So, from plain "ordinary" user point of view: what do you offer me to use to still be able to run Java objects on Web pages? Open another browser, that hasn't yet abandoned Java support?

If you *really* need to use Java Applet for some reason then the only sane approach is to use it from separate throw-away VM with separate installation of browser where no sensitive documents reside. You could use whatever browser you want there: old version of Chrome, MS IE, whatever. What you shouldn't do is to use it for anything else. You most definitely don't want to do regular browsing using the same VM. 
 
I do not want to raise any flame, but looks like developers do not even assumed the users' needs and actual requirements.

They did - but may be not in a way you expect. Java is a security hazard and should be treated as such.
 
I am only "pro" using modern technologies and discard older ones, but how about usability?

I will be surprise to read any answer from developers different from "We don't care" or "It's not our business to develop plugin compatible with Java".

We do care. For the last three (four?) years Java plugin was strictly forbidden in Google. The only approved way to use it was to ask for a test system on separate VLAN from corp. You were not supposed to use corporate accounts on that system and so on. It's time for the rest of the world to treat it the same way. 

Thanks.

Sincerely,
Konstantin


On Wednesday, January 8, 2014 at 6:04:18 AM UTC+6, Max Heinritz wrote:
Hi Chromium community,

In September 2013, we announced that NPAPI support will be phased out of Chrome in 2014, with the following schedule:
  • January: block NPAPI plug-ins by default
  • Mid-year: more aggressive blocking (different UI, smaller whitelist)
  • Before end of 2014: remove support completely
The update here is that Linux NPAPI support may be dropped as early as M34 (goes to Stable in early April).  The reason for this timeline is that we've decided not to implement NPAPI support in Linux Aura.  We feel comfortable doing so because affected plug-ins all have 30-day launch rates below .7% of Linux Chrome users.

A few things to keep in mind:
  1. So long as they are not too crazy, we might accept patches to add NPAPI support to Linux Aura. (We won't commit to supporting it or shipping it though.)
  2. Once we stop supporting NPAPI on Windows, we'll proceed to remove the code entirely for all platforms, including Linux Aura.
Let us know if you have questions.

Max

--

Konstantin Boyandin

unread,
Mar 27, 2015, 12:18:40 PM3/27/15
to Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, be...@chromium.org, Darin Fisher
Skipping anti-Java advocacy, since I do not have objections against it.

Пт, 27.03.2015 в 22:02 Victor Khimenko писал(а):
> When you hit Java applet today you only have two easy choices:
> 1. Don't run it at all.
> 2. Give it full access to your system, all it's files and documents.

OK. Typical situation: I am using hosting provider, utilizing Java
applet to access virtual machine's console.

Let me guess: you will advise me not to use services of such hosting
provider. Correct? Or create that mentioned throw-away VM every time I
need to look at VM console.

> I'm afraid a lot of guys don't understand that when they run Java applet these days they give it full access to everything on their system. 

This is not the problem, actually.

The problem is the vacuum the remains after some piece of technology is
discarded. OK, no objections against banning Java from Web. After all,
supporting high level of information security is my job. Java is evil,
since it's insecure.

The problem is that no one cares when it turns out that users just have
to either set up inconvenient, complex walkarounds, or don't use now
unsupported things altogether. Browser developers don't care: it's not
their business. Software owner doesn't care: no valid reasons, they just
don't care. Result: alternate solutions are either expensive or too
immature to use. Just don't use them, that simple.

Pray tell me this is normal, and old technologies should be removed via
this scenario. And if not normal, who should care? Do you expect end
users would develop alternate software themselves, when existing one is
phased out?

Thanks.

Konstantin

Mike Frysinger

unread,
Mar 27, 2015, 12:25:21 PM3/27/15
to konst...@boyandin.com, Stuart Morgan, chromium-dev, jsc...@chromium.org, e...@chromium.org, be...@chromium.org, Darin Fisher
On Fri, Mar 27, 2015 at 9:01 AM, Konstantin Boyandin <konst...@boyandin.com> wrote:
This is what I am saying: proper policy would be to warn users about
Java upcoming demise long ago, not just tell them "You 're out of luck,
we don't support it in a couple of weeks".

please actually read the thread and the pages/documents linked.  this has been announced publicly multiple times, and in fact this thread you're responding to is over a year old.  that is way longer than a couple of weeks.
-mike

Stuart Morgan

unread,
Mar 27, 2015, 12:31:33 PM3/27/15
to Konstantin Boyandin, chromi...@chromium.org, jsc...@chromium.org, e...@chromium.org, be...@chromium.org, da...@chromium.org
On Fri, Mar 27, 2015 at 9:02 AM Konstantin Boyandin <konst...@boyandin.com> wrote:
I would like to offer developers another strategy: when something is
obviously gets poorly or not supported, aggressively advocate against
it, encourage developing alternatives and so on - starting that few
years before abandoning the piece of technology..

You are describing exactly what has been happening, and is happening now, with NPAPI.

Encouraging and developing alternatives to things that in the past required NPAPI plugins has been happening in various forms for longer than Chrome has existed, and the official NPAPI deprecation in Chrome is in the midst of a widely announced multi-year process. (The timeline on Linux was shortened for specific technical reasons that have been explained several times in this thread.)

As you are learning though, advocacy doesn't completely solve the problem.

-Stuart

Victor Khimenko

unread,
Mar 27, 2015, 12:45:01 PM3/27/15
to konst...@boyandin.com, Stuart Morgan, Chromium-dev, Justin Schuh, Elliot Glaysher, be...@chromium.org, Darin Fisher
On Fri, Mar 27, 2015 at 7:01 PM, Konstantin Boyandin <konst...@boyandin.com> wrote:
Пт, 27.03.2015 в 21:19 Stuart Morgan писал(а):
> [Whoops, somehow hit send immediately]
>
> On Fri, Mar 27, 2015 at 7:57 AM Konstantin Boyandin <konst...@boyandin.com> wrote:
>> On no thread related to NPAPI dismantling there's plain response to simple question: how Google Chrome users are expected to view Web documents utilizing Java-driven elements?
>> [...]
>> Open another browser, that hasn't yet abandoned Java support?
>
> Using another browser for pages that haven't yet moved away from depending on an NPAPI plugin (including Java) is a reasonable option, yes. That was in fact addressed earlier in this thread.
>
> This is already the case for anyone trying to use such a site from a mobile device, except that they can't just open another browser, they have to move to a completely different device (assuming they even have one available).
>
> -Stuart 

This is what I am saying: proper policy would be to warn users about
Java upcoming demise long ago, not just tell them "You 're out of luck,
we don't support it in a couple of weeks".

Google started blocking Java plugin in Chrome 11 released amost four years ago. And reason was quite explicitly stated back then: "Java applets are a top vector for malware infections and cannot be secured to reasonable degree" (see http://crbug.com/81343 )

Sadly it's still true today and it does not look like there are reasonable hope for the future. Google does not hate Java per se. Indeed, many things in Google rely on Java. Unfortunately Java web plugin does not look a web technology with a future.

Konstantin Boyandin

unread,
Mar 27, 2015, 12:50:28 PM3/27/15
to Stuart Morgan, chromi...@chromium.org, jsc...@chromium.org, e...@chromium.org, be...@chromium.org, da...@chromium.org
Пт, 27.03.2015 в 22:30 Stuart Morgan писал(а):
It only means that either overall strategy isn't good enough, or that
advocacy is applied to wrong minds. From end user's perspective,
features are suddenly disappearing, causing one inconvenience after
another. The irony is that by advising to use other software that still
supports insecure technologies, the problem is rather worsened that
solved.

My viewpoint is that those who plan to introduce new technologies should
do all possible that transition would be as smooth as possible. I am a
Linux user and "reasons were explained" isn't valid argument why I am
left in vacuum when something gets discontinued.

Thanks.

Konstantin

Justin Schuh

unread,
Mar 27, 2015, 1:16:03 PM3/27/15
to Konstantin Boyandin, Stuart Morgan, Chromium-dev, Elliot Glaysher (Chromium), be...@chromium.org, Darin Fisher
We publicly announced our NPAPI deprecation strategy and timeline more than 18 months ago, and prior to that we spent many months assessing usage and reaching out to major sites and developers. In the intervening 18 months we've continued to closely monitor the data and feedback, and alter our timeline as needed while providing alternatives and assistance where we can.

I do realize that Linux users were impacted earlier than other platforms, due to a number of factors that made the burden of supporting NPAPI on Linux grossly disproportionate to the number of affected users. And while there was nothing preventing some third party from contributing support after the Linux Aura switch, the fact is that no one saw a point in investing the work required to keep NPAPI limping along for at most another year.

So, we really do appreciate that you are one of the users negatively impacted by these decisions, and no one is happy about that. However, we have to consider the entirety of our user base, and make decisions in the interests of the vast majority of that population. And unfortunately, that means we occaisionally have to make tough calls that serve the greater good and better move the Web forward.

In this case, the decision was to phase out a massive developer burden and address the single largest negative contributor to security, stability, and performance. And while we certainly would have preferred if all sites had migrated off of NPAPI by now, the fact is that experience has shown that at some point you reach a threshold where you have to define a cut off and move forward.


Victor Khimenko

unread,
Mar 27, 2015, 1:16:36 PM3/27/15
to Konstantin Boyandin, Stuart Morgan, Chromium-dev, Justin Schuh, Elliot Glaysher, be...@chromium.org, Darin Fisher
Ah, that. As a fellow Linux user I feel your pain, too. Unfortunately there are too few of us thus developer's attention to that platform is somewhat limited. That's why Linux users like you and me constantly get the short end of the stick. It's as simple as that. Google actually spends more resources on Linux port than it deserves judging from the number of users alone, but still there are limit for how much it could justify to spend on that fringe platform.

Konstantin Boyandin

unread,
Mar 27, 2015, 8:00:13 PM3/27/15
to Victor Khimenko, Stuart Morgan, Chromium-dev, Justin Schuh, Elliot Glaysher, be...@chromium.org, Darin Fisher
Пт, 27.03.2015 в 23:16 Victor Khimenko писал(а):
On one hand, I am not affected that badly, still it doesn't take one's
mind overload to find a workaround, usually. Linux users will either
have to be more educated that average Windows user, or be greatly
discouraged to use the platform by events like this. During last 12
months all major free software developers performed drastic changes in
their well-known products. Those improve the overall security, but at
the cost of immersing users into vacuum of mentioned kind (like
Thunderbird all of a sudden preventing users from utilizing self-signed
SSL certificates).

The problem, as I see it, is absence of evangelizing efforts closer to
end users. For example, major widely popular products in hosting
industry (such as WHM and several VM-controlling Web panels) still use
Java for crucial parts of their services (crucial - since there's often
no alternative to use instead, and those tools are of emergency value).
I doubt the developers of mentioned products are completely fat between
ears to ignore security issues, but the question is, then, why the
danger is still wide abroad? This community can only suggest using
inappropriate approaches (like using guinea pig VM to access Java
applets) or generally shrug their shoulders ("we talked about that so
long ago!").

Personally, I try to influence both hosters and general users about such
events, but there's definite lack of sustained communication between
developers and security experts on ine hand, and those who *could*
influence Web software developers to stop utilizing unsafe technologies
- on the other.

As Mr. Spock and Justin Schuh both mentioned, "the needs of the many
outweigh the needs of the few", but, in my not so humble opinion, Linux
users definitely should not be treated that way, unless free software
developers wish to have only a handful of red-eyed enthusiasts, left in
that area.

To end my speech in positive manner, I think I'll put more efforts into
advocating better, safer technologies all over 'Net, since, it seems, no
one else cares (in the sense I cited earlier) to allow me to further use
whatever I am accustomed to use.

Thanks.
Konstantin

PhistucK

unread,
Mar 28, 2015, 6:49:37 AM3/28/15
to konst...@boyandin.com, Victor Khimenko, Stuart Morgan, Chromium-dev, Justin Schuh, Elliot Glaysher, be...@chromium.org, Darin Fisher

On Sat, Mar 28, 2015 at 1:59 AM, Konstantin Boyandin <konst...@boyandin.com> wrote:
As Mr. Spock and Justin Schuh both mentioned, "the needs of the many
outweigh the needs of the few", but, in my not so humble opinion, Linux
users definitely should not be treated that way, unless free software
developers wish to have only a handful of red-eyed enthusiasts, left in
that area.

​Linux users just got it early, Windows and Macintosh users will get it by September.​ Everyone gets it eventually.


PhistucK

Michał Gołębiowski

unread,
Mar 28, 2015, 2:28:27 PM3/28/15
to phis...@gmail.com, konst...@boyandin.com, Victor Khimenko, Stuart Morgan, Chromium-dev, Justin Schuh, Elliot Glaysher, be...@chromium.org, Darin Fisher
On Saturday, March 28, 2015, PhistucK <phis...@gmail.com> wrote:
​Linux users just got it early, Windows and Macintosh users will get it by September.​ Everyone gets it eventually.

Actually, most users will get it in 3-4 weeks, right? It's just that a flag will be provided but most users won't know about it. 


--
Michał Gołębiowski

PhistucK

unread,
Mar 28, 2015, 3:58:41 PM3/28/15
to Michał Gołębiowski, konst...@boyandin.com, Victor Khimenko, Stuart Morgan, Chromium-dev, Justin Schuh, Elliot Glaysher, be...@chromium.org, Darin Fisher
Basically, yes, but the exact same situation the Linux users are experiencing (it does not work and the flag does not make it work) will be experienced by the rest of the platforms by September.


PhistucK

Matt Giuca

unread,
Mar 29, 2015, 7:15:26 PM3/29/15
to konst...@boyandin.com, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, be...@chromium.org, Darin Fisher
On Sat, 28 Mar 2015 at 03:18 Konstantin Boyandin <konst...@boyandin.com> wrote:
Skipping anti-Java advocacy, since I do not have objections against it.

Your latest email can be summarized as "I don't have a problem with dropping Java because it's insecure. I have a problem with the fact that there are no replacements." I'm not sure if you're suggesting that a) Google should offer a replacement technology to fill the gap of Java, or b) Google should rewrite every existing Java applet in that replacement technology. If it's (a), then we already have that: JavaScript is the standard scripting language for the web and it can do anything (sane) that Java can do. The problem is not the technology gap, but the fact that lots of legacy apps still use Java. Obviously (b) cannot be done by one browser vendor; it needs to be done by all the developers.

I've seen this line of argument several times on this thread and others: "Google should not remove Java while there are still sites using it; instead we should wait until they've migrated over to web standards and then remove it." Unfortunately, that simply can't work, because they have no incentive to migrate over. We'll have to wait another 20 years until they've all been long obsoleted (and hope nobody writes any new ones in that time). Sorry, the only way this will ever work is if browser vendors drop support for Java, forcing developers to rewrite their apps for modern platforms. It's not that we don't care. It's that there is no other way to stop support for a platform.

I think this comes down to your first sentence from your email two days ago: "how Google Chrome users are expected to view Web documents utilizing Java-driven elements?" Unfortunately for users who depend upon Java applets, this is really an oxymoron: a document with Java is not a "Web document", because the web is a collection of agreed upon standards across all browsers, and Java has never been through the Web standards committee. While it has long been a staple of web browsers, it has never been part of the web.

Konstantin Boyandin

unread,
Mar 29, 2015, 7:38:06 PM3/29/15
to Matt Giuca, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, be...@chromium.org, Darin Fisher
> Sorry, the only way this will ever work is if browser vendors drop support for Java, forcing developers to rewrite their apps for modern platforms.

Wrong. This is the simplest way for developers, since they don't really
- in most times - see the problems from end user's perspective.

In my case, I really didn't care about missing Java applets till one
moment I had to access a VPS which couldn't be accessed otherwise. There
was a problem, though, since
- Google Chrome stopped doing that without printing in big red letters
anywhere on its settings "Java plugin is not supported any more" etc.
- Firefox, though formally still working, crashed along with the Java
plugin.
Finally, I found an image of old Windows VM, with ancient Opera
installed, cloned it and run. That helped. Read the above carefully: I
had to still use old API using dangerous, insecure way, since there was
no other way around.

All the above made me feel that developers that stop any APi just assume
that
- after they stop supporting API, all the products are magically ported
to new, safer one
or
- end users are smart enough to find a secure way to the same task
or
- those who use older API should burn in hell and that will serve them
well.

The problem is there's no secure way. And not any user can easily handle
creating VM just to visit insecure page. They will just find all old,
insecure browser and use it, cursing developers during the process, and
use the out-of-date API again. This time with risk of spreading
something dangerous.

However, developers meanwhile can feel themselves rightful and saint,
since they Do The Right Thing. Of course, it's not your task to re-write
existing malicious code. But - please read that carefully - (it was your
task, when planning to obsolete old API, to do all possible to warn end
user about upcoming problems and influence those who developed insecure
software to provide alternatives, since <here a picture of dread
consequences>*. Appealing to security problems works almost with
everyone.

Formally, you can still state it's not your problem. But merely stopping
supporting old APi doesn't make it vanish, it only causes more problems
with insecure software still in use. But yes, you can repeat once more
it's not your business and not your responsibility; and your brave new
product isn't involved now (its last version) into insecure operations.
Looks like the latter is the only thing you really do care about.

Sincerely,
Konstantin

Пн, 30.03.2015 в 05:14 Matt Giuca писал(а):
> On Sat, 28 Mar 2015 at 03:18 Konstantin Boyandin <konst...@boyandin.com> wrote:
>> Skipping anti-Java advocacy, since I do not have objections against it.
>
> Your latest email can be summarized as "I don't have a problem with dropping Java because it's insecure. I have a problem with the fact that there are no replacements." I'm not sure if you're suggesting that a) Google should offer a replacement technology to fill the gap of Java, or b) Google should rewrite every existing Java applet in that replacement technology. If it's (a), then we already have that: JavaScript is the standard scripting language for the web and it can do anything (sane) that Java can do. The problem is not the technology gap, but the fact that lots of legacy apps still use Java. Obviously (b) cannot be done by one browser vendor; it needs to be done by all the developers.
>
> I've seen this line of argument several times on this thread and others: "Google should not remove Java while there are still sites using it; instead we should wait until they've migrated over to web standards and then remove it." Unfortunately, that simply can't work, because they have no incentive to migrate over. We'll have to wait another 20 years until they've all been long obsoleted (and hope nobody writes any new ones in that time). Sorry, the only way this will ever work is if browser vendors drop support for Java, forcing developers to rewrite their apps for modern platforms. It's not that we don't care. It's that there is no other way to stop support for a platform.
>
> I think this comes down to your first sentence from your email two days ago: *"how Google Chrome users are expected to view Web documents utilizing Java-driven elements?"* Unfortunately for users who depend upon Java applets, this is really an oxymoron: a document with Java is *not* a "Web document", because the web is a collection of agreed upon standards across all browsers, and Java has never been through the Web standards committee. While it has long been a staple of web browsers, it has never been part of the web.
>> http://groups.google.com/a/__chromium.org/group/chromium-__dev

Matt Giuca

unread,
Mar 29, 2015, 8:09:19 PM3/29/15
to Konstantin Boyandin, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, be...@chromium.org, Darin Fisher
On Mon, 30 Mar 2015 at 10:37 Konstantin Boyandin <konst...@boyandin.com> wrote:
In my case, I really didn't care about missing Java applets till one
moment I had to access a VPS which couldn't be accessed otherwise. There
was a problem, though, since
- Google Chrome stopped doing that without printing in big red letters
anywhere on its settings "Java plugin is not supported any more" etc.
- Firefox, though formally still working, crashed along with the Java
plugin.
Finally, I found an image of old Windows VM, with ancient Opera
installed, cloned it and run. That helped. Read the above carefully: I
had to still use old API using dangerous, insecure way, since there was
no other way around.

Let's be clear: we don't expect users to go through those hoops. If the technology is not working in Chrome, then we hope you'll find a web-standard replacement for it. If you absolutely need to use that technology, we expect you to go to another web browser (such as Firefox) where it continues working. If you cannot find a single other browser that can run this technology, then this has gone past blaming any one browser vendor. The technology you are trying to use has run its course, and you must find a replacement. If that means changing to a different VPN provider, then so be it. Send your VPN provider an email explaining that you are leaving because their service is not using any acceptable modern technology, and change providers.

You cannot blame all the browser vendors for not supporting a 20-year-old non-standard API designed before the concept of computer security. It sucks for users, but we are doing it in the users' long-term best interests.

Let's rip off this band-aid.

Formally, you can still state it's not your problem. But merely stopping
supporting old APi doesn't make it vanish, it only causes more problems
with insecure software still in use.

The point of my previous email is precisely that: merely stopping supporting an old API does make it vanish; maybe not right now, but maybe in a year or two. I guarantee that if all the browsers stopped supporting Java, your VPN provider would rewrite their software (or be out of business) in the next year.

It causes short-term problem for users, but I'm confident that browsers dropping support for Java are helping to fix the problem, not making it worse.

Konstantin Boyandin

unread,
Mar 29, 2015, 8:41:17 PM3/29/15
to Matt Giuca, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, be...@chromium.org, Darin Fisher
Looks like you still don't see the point.

Dropping old APIs/other insecure or inefficient components the way it
does *brings much problems on most end users immediately, since they
have no time to wait while vendors update the software the correct way,
nor they have quick and secure workaround at hand*. Nor they can just
drop the service that has security issues.

You get rid of old APi at expense of end users who carry the burden of
handling the problems coming all of a sudden. Whether you do accept it
as your (developers') fault or not, is not important. It's just fact of
real life.

I hope I shouldn't explain that further.

Sincerely,
Konstantin


Пн, 30.03.2015 в 06:08 Matt Giuca писал(а):
> On Mon, 30 Mar 2015 at 10:37 Konstantin Boyandin <konst...@boyandin.com> wrote:
>> In my case, I really didn't care about missing Java applets till one
>>
moment I had to access a VPS which couldn't be accessed otherwise. There
>>
was a problem, though, since
>>
- Google Chrome stopped doing that without printing in big red letters
>>
anywhere on its settings "Java plugin is not supported any more" etc.
>>
- Firefox, though formally still working, crashed along with the Java
>>
plugin.
>>
Finally, I found an image of old Windows VM, with ancient Opera
>>
installed, cloned it and run. That helped. Read the above carefully: I
>>
had to still use old API using dangerous, insecure way, since there was
>>
no other way around.
>
> Let's be clear: we don't expect users to go through those hoops. If the technology is not working in Chrome, then we hope you'll find a web-standard replacement for it. If you absolutely need to use that technology, we expect you to go to another web browser (such as Firefox) where it continues working. If you cannot find a single other browser that can run this technology, then this has gone past blaming any one browser vendor. The technology you are trying to use has run its course, and you must find a replacement. If that means changing to a different VPN provider, then so be it. Send your VPN provider an email explaining that you are leaving because their service is not using any acceptable modern technology, and change providers.
>
> You cannot blame all the browser vendors for not supporting a 20-year-old non-standard API designed before the concept of computer security. It sucks for users, but we are doing it in the users' long-term best interests.
>
> Let's rip off this band-aid.
>
>> Formally, you can still state it's not your problem. But merely stopping
>>
supporting old APi doesn't make it vanish, it only causes more problems
>>
with insecure software still in use.
>
> The point of my previous email is precisely that: *merely stopping supporting an old API does make it vanish*; maybe not right now, but maybe in a year or two. I guarantee that if *all* the browsers stopped supporting Java, your VPN provider would rewrite their software (or be out of business) in the next year.
>>  http://groups.google.com/a/____chromium.org/group/chromium-____dev

Thiago Farina

unread,
Mar 29, 2015, 8:57:03 PM3/29/15
to konst...@boyandin.com, Matt Giuca, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, be...@chromium.org, Darin Fisher
On Sun, Mar 29, 2015 at 9:40 PM, Konstantin Boyandin <konst...@boyandin.com> wrote:
You get rid of old APi at expense of end users who carry the burden of
handling the problems coming all of a sudden.
sudden does not seem to be accurate, don't you think?

--
Thiago Farina

Peter Kasting

unread,
Mar 29, 2015, 8:57:17 PM3/29/15
to konst...@boyandin.com, Matt Giuca, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, be...@chromium.org, Darin Fisher
On Sun, Mar 29, 2015 at 4:37 PM, Konstantin Boyandin <konst...@boyandin.com> wrote:
But - please read that carefully - (it was your
task, when planning to obsolete old API, to do all possible to warn end
user about upcoming problems and influence those who developed  insecure
software to provide alternatives, since <here a picture of dread
consequences>*. Appealing to security problems works almost with
everyone.

Despite the fact that you deny we have done so, I think that on non-Linux platforms, the teams in question have been doing as much as is reasonably possible to warn both developers and end users about this, precisely as you ask, and try to influence them to ensure secure alternatives exist, precisely as you ask.

The problem is not that we are blind to end-user pain.  The problem is that we believe your statement that we could have done more to lessen that pain is fundamentally false, and comes from a lack of understanding of just how broad the efforts have been to do precisely the kinds of things you think we haven't been doing.

Unfortunately it is quite untrue that "Appealing to security problems works almost with everyone."  In fact the vast majority of people who still use Java-based systems really don't care much about security, users, or any other motivational lever we can pry at.  Talking to them, warning them, cajoling them, offering them alternative technologies to implement their functionality -- all these have been tried, are being tried, and are in many cases failing utterly.

As for warning users, there's a more difficult balance to strike: as you note, you are perhaps more technical than most users, and with most users, there's a limit to what kind of information we can give them that is not (a) utterly confusing, (b) incredibly scary-looking and makes them do less-secure things, or (c) appearing to be actively hostile towards them (telling users you're going to stop supporting X, no matter what transition plan you have, will generally be interpreted as "you're a complete jerk that doesn't care about me at all").  What we want, if anything, is for users to migrate to safer technologies, which is often out of their hands.  The UI currently available in Chrome for non-Linux platforms and the publicity we've given our migration plan so far attempt to strike this balance.

Critically, the Linux UI doesn't: as has been said before, we dropped NPAPI support on Linux in a way we didn't particularly want to do, but because there were other large technical factors forcing our hand.  So if you're going to say that _on Linux specifically_ we could have done better, then sure, we could have, except for those other factors, which have been discussed before.  When it comes to non-Linux, I don't think we deserve the kind of criticism you're levelling.

PK

Konstantin Boyandin

unread,
Mar 29, 2015, 9:42:06 PM3/29/15
to Peter Kasting, Matt Giuca, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, be...@chromium.org, Darin Fisher
Just in case it's not yet clearly seen, I am eager to find how I,
personally, can assist in upcoming "September catastrophe", when the
cord will be pulled for Windows/Mac users. All of a sudden, of course
(we will see that by users' reactions).

I am mostly a Linux users; I use Windows/other OSes mostly in
virtualized form, as testing environment, or on other people's
workstations. The obvious means to communicate with users about some
drastic changes is through the product itself.

Now please tell me, exactly where Chrome warns Windows users about
upcoming NPAPI shutdown? I run Chrome on different Windows specii every
day. In all honesty, I do not see anything, while running Chrome,
indicating that
- this particular site contains elements that will not work since
September 2015, and/or
- this particular site contains elements that put your computer at risk
by mere opening the page

I may underestimate your efforts (you have agreed that in case of Linux
sequence of actions was far from perfect). At the moment, I warn all the
users of networks I am responsible for about security hazards and
requirements to drop using java/other insecure Web-related technologies
ASAP. But I don't see appeals of any kind from Chrome itself - the
browser is the only way you can deliver message to end users.

Thanks. No offense meant, of course.
Konstantin


Пн, 30.03.2015 в 06:56 Peter Kasting писал(а):

Matt Giuca

unread,
Mar 29, 2015, 9:53:24 PM3/29/15
to Konstantin Boyandin, Peter Kasting, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, be...@chromium.org, Darin Fisher
This is a fair point. I'm not sure what level of warning we present to users as I haven't encountered a Java applet on Windows for a long time. Do we currently state on Win/Mac explicitly that the plugin will stop being supported in September, 2015? (Aside from the security warnings, which don't actually give the user a sense of impending doom, just an annoyance.)

We also should update this support page:
https://support.google.com/chrome/answer/2429779?hl=en

Peter Kasting

unread,
Mar 29, 2015, 10:01:54 PM3/29/15
to Matt Giuca, Konstantin Boyandin, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, be...@chromium.org, Darin Fisher
On Sun, Mar 29, 2015 at 6:52 PM, Matt Giuca <mgi...@chromium.org> wrote:
This is a fair point. I'm not sure what level of warning we present to users as I haven't encountered a Java applet on Windows for a long time. Do we currently state on Win/Mac explicitly that the plugin will stop being supported in September, 2015? (Aside from the security warnings, which don't actually give the user a sense of impending doom, just an annoyance.)

We haven't yet given a date in our UI; I believe that's partly because we keep changing the date when we're going to do things.

However, if the date is now firm, then I think we should add such dates to our UI.

PK 

Konstantin Boyandin

unread,
Mar 29, 2015, 10:02:19 PM3/29/15
to Matt Giuca, Peter Kasting, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, be...@chromium.org, Darin Fisher
Thanks. Just a hint: you will easily find Java applets in case of
WHM/Cpanel, SolusVM or similar Web-products.

Since those are related to controlling one's hosting assets, the risk of
losing/leaking important data is high, when Java is still used.

Some of the above started to switch to HTML5-based replacement for Java,
but replacements are done very slowly. Wherever I looked at WHM during
last half-year, everywhere Java is still in use.

Regards,
Konstantin

Пн, 30.03.2015 в 07:52 Matt Giuca писал(а):

Stuart Morgan

unread,
Mar 30, 2015, 1:20:54 AM3/30/15
to konst...@boyandin.com, Matt Giuca, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, be...@chromium.org, Darin Fisher
On Sun, Mar 29, 2015 at 4:37 PM Konstantin Boyandin <konst...@boyandin.com> wrote:
Read the above carefully: I
had to still use old API using dangerous, insecure way, since there was
no other way around.

The only way to use NPAPI is the "dangerous, insecure way", which is the issue. The extra security features of modern browsers are largely irrelevant on a page where you are deliberately running an NPAPI plugin, because by instantiating that plugin you bypass the security model of the browser and grant the plugin full access to your entire computer.

Anyone who thinks they are safe using an NPAPI plugin as long as their browser is up to date is operating under a dangerous false sense of security.

-Stuart

Max Heinritz

unread,
Jan 7, 2014, 7:04:18 PM1/7/14
to Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, be...@chromium.org, Darin Fisher

Chad Miller

unread,
Jan 8, 2014, 9:30:38 AM1/8/14
to chromi...@chromium.org
I think that Adobe Flash only supports NPAPI for Linux outside of Chrome and CrOS.  Is this saying that no Flash will ever work on Linux in four months?

What are the plugin percentages, non-Chrome for Linux only?  I think the ratios might surprise us.  Not close to 0.7%.

- chad
Ubuntu

Torne (Richard Coles)

unread,
Jan 8, 2014, 10:12:26 AM1/8/14
to chad....@canonical.com, Chromium-dev
On 8 January 2014 14:30, Chad Miller <chad....@canonical.com> wrote:
On Tuesday, January 7, 2014 7:04:18 PM UTC-5, Max Heinritz wrote:
Hi Chromium community,

In September 2013, we announced that NPAPI support will be phased out of Chrome in 2014, with the following schedule:
  • January: block NPAPI plug-ins by default
  • Mid-year: more aggressive blocking (different UI, smaller whitelist)
  • Before end of 2014: remove support completely
The update here is that Linux NPAPI support may be dropped as early as M34 (goes to Stable in early April).  The reason for this timeline is that we've decided not to implement NPAPI support in Linux Aura.  We feel comfortable doing so because affected plug-ins all have 30-day launch rates below .7% of Linux Chrome users.

A few things to keep in mind:
  1. So long as they are not too crazy, we might accept patches to add NPAPI support to Linux Aura. (We won't commit to supporting it or shipping it though.)
  2. Once we stop supporting NPAPI on Windows, we'll proceed to remove the code entirely for all platforms, including Linux Aura.

I think that Adobe Flash only supports NPAPI for Linux outside of Chrome and CrOS.  Is this saying that no Flash will ever work on Linux in four months?

In Chromium-based browsers, unless someone does the work mentioned above to patch in NPAPI support for Linux Aura, yes, that's what this is saying. (and even if they do that work it will go away when it's dropped on other platforms later this year).
 
What are the plugin percentages, non-Chrome for Linux only?  I think the ratios might surprise us.  Not close to 0.7%.

UMA metrics only work on Chrome, so we don't know the percentage for Chromium builds. It's obviously going to be much higher because many Chromium builds are using NPAPI Flash instead of PPAPI Flash (though the rate for other NPAPI plugins will probably be about the same).
 
- chad
Ubuntu

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

Justin Schuh

unread,
Jan 8, 2014, 10:14:25 AM1/8/14
to chad....@canonical.com, Chromium-dev
On Wed, Jan 8, 2014 at 6:30 AM, Chad Miller <chad....@canonical.com> wrote:
On Tuesday, January 7, 2014 7:04:18 PM UTC-5, Max Heinritz wrote:
Hi Chromium community,

In September 2013, we announced that NPAPI support will be phased out of Chrome in 2014, with the following schedule:
  • January: block NPAPI plug-ins by default
  • Mid-year: more aggressive blocking (different UI, smaller whitelist)
  • Before end of 2014: remove support completely
The update here is that Linux NPAPI support may be dropped as early as M34 (goes to Stable in early April).  The reason for this timeline is that we've decided not to implement NPAPI support in Linux Aura.  We feel comfortable doing so because affected plug-ins all have 30-day launch rates below .7% of Linux Chrome users.

A few things to keep in mind:
  1. So long as they are not too crazy, we might accept patches to add NPAPI support to Linux Aura. (We won't commit to supporting it or shipping it though.)
  2. Once we stop supporting NPAPI on Windows, we'll proceed to remove the code entirely for all platforms, including Linux Aura.

I think that Adobe Flash only supports NPAPI for Linux outside of Chrome and CrOS.  Is this saying that no Flash will ever work on Linux in four months?

Adobe deprecated NPAPI Flash on Linux almost two years ago. Linux NPAPI Flash is currently seven releases behind the main release (11.2 versus the current 11.9) and only receiving updates for significant security vulnerabilities. PPAPI Flash is current and will continue to be supported on Linux indefinitely.


What are the plugin percentages, non-Chrome for Linux only?  I think the ratios might surprise us.  Not close to 0.7%.

Do you mean the percentages for Chromium based ports? We don't distribute or control such ports, so we have no way of getting reliable metrics for them.

Chad Miller

unread,
Jan 8, 2014, 10:39:13 AM1/8/14
to chromi...@chromium.org


On Wednesday, January 8, 2014 10:14:25 AM UTC-5, Justin Schuh wrote:


On Wed, Jan 8, 2014 at 6:30 AM, Chad Miller <chad....@canonical.com> wrote:
On Tuesday, January 7, 2014 7:04:18 PM UTC-5, Max Heinritz wrote:
Hi Chromium community,

In September 2013, we announced that NPAPI support will be phased out of Chrome in 2014, with the following schedule:
  • January: block NPAPI plug-ins by default
  • Mid-year: more aggressive blocking (different UI, smaller whitelist)
  • Before end of 2014: remove support completely
The update here is that Linux NPAPI support may be dropped as early as M34 (goes to Stable in early April).  The reason for this timeline is that we've decided not to implement NPAPI support in Linux Aura.  We feel comfortable doing so because affected plug-ins all have 30-day launch rates below .7% of Linux Chrome users.

A few things to keep in mind:
  1. So long as they are not too crazy, we might accept patches to add NPAPI support to Linux Aura. (We won't commit to supporting it or shipping it though.)
  2. Once we stop supporting NPAPI on Windows, we'll proceed to remove the code entirely for all platforms, including Linux Aura.

I think that Adobe Flash only supports NPAPI for Linux outside of Chrome and CrOS.  Is this saying that no Flash will ever work on Linux in four months?

Adobe deprecated NPAPI Flash on Linux almost two years ago. Linux NPAPI Flash is currently seven releases behind the main release (11.2 versus the current 11.9) and only receiving updates for significant security vulnerabilities. PPAPI Flash is current and will continue to be supported on Linux indefinitely.

PPAPI Flash isn't downloadable for Linux and heroic extractions of it from Google products aren't distributable. I don't think that counts as "current".

- chad
Ubuntu

Justin Schuh

unread,
Jan 8, 2014, 10:45:13 AM1/8/14
to chad....@canonical.com, Chromium-dev
Have you tried contacting Adobe about this? My understanding is that they're not opposed to working out solutions for distributing PPAPI Flash to other browsers. And with something carrying all the attack surface of Flash, I'd think a sandboxed and current PPAPI would be vastly preferable to an out-of-date, unsandboxed, NPAPI version.

Matt Giuca

unread,
Jan 8, 2014, 6:50:55 PM1/8/14
to jsc...@chromium.org, chad....@canonical.com, Chromium-dev
Can I just clarify some of these issues since it's a bit confusing to me. Let me know if I've gotten any of these things wrong:
  • NPAPI Flash is the main Flash you download from Adobe, and works with all browsers.
    • The Linux version of NPAPI Flash is horribly out of date, but that is what Linux Firefox and Chromium users currently use.
    • Chromium 34 for Linux will no longer support NPAPI Flash.
  • PPAPI Flash is the version of Flash bundled with Chrome. It will continue to receive updates from Adobe, and continue to be supported in Chrome/Chromium.
    • However, there is no stand-alone installer for PPAPI Flash, and currently no feasible way to use it with Chromium.
    • Chrome users can use PPAPI Flash, but Chromium users currently cannot.
If I'm understanding this correctly, it means Linux Chromium users will have no way to use Flash after April. This seems like A Bad Thing given that a lot of the web still uses Flash, and a lot of Linux users use Chromium.

It might help if we had some usage statistics about Chromium. I wonder if Canonical has any way to determine how many Chromium users there are on Ubuntu, so we can work out what the ratio of Chrome to Chromium users are on a typical Linux installation. I would guess there is a fairly high ratio of Chromium users, given that (at least on Ubuntu), Chromium is the path of least resistance. (You apt-get it or go to the Ubuntu Software Center to install it like you install all of your other software, instead of having to download and install a separate binary.) I personally used Chromium for years (before I needed a bugfix in the latest version so I switched to Chrome). Also many Linux users want to use as much free software as possible, so Chromium (even with a proprietary Flash plugin) is a better choice for them philosophically.

It seems like the best course of action would be to arrange for Adobe to provide a stand-alone binary of the PPAPI version of Flash for Chromium users, rather than trying to continue to support the ageing NPAPI Flash. Thoughts?