Re: [chromium-dev] Re: PSA: Chrome for Linux planning to drop NPAPI support as soon as April
17,688 views
Skip to first unread message
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.
W dniu wtorek, 3 czerwca 2014 01:57:38 UTC+2 użytkownik Stuart Morgan napisał:
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 <[email protected]> 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
Jun 3, 2014, 9:44:18 AM6/3/14
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.☆PhistucKOn Fri, May 30, 2014 at 7:53 PM, Hector Garcia <[email protected]> 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 MattI 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: [email protected]
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 [email protected].
PhistucK
Jun 3, 2014, 10:38:44 AM6/3/14
to [email protected], Chromium-dev, Hector Garcia, Sayantan Das, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], 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
Jun 3, 2014, 2:05:00 PM6/3/14
to [email protected], Chromium-dev, [email protected]
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
Jun 10, 2014, 11:01:16 AM6/10/14
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
Jun 10, 2014, 11:11:41 AM6/10/14
to T.J. Crowder, [email protected], Hector Garcia, Sayantan Das, [email protected], Tom Wiltzius, [email protected], [email protected], Darin Fisher
On Tue, Jun 3, 2014 at 3:44 PM, T.J. Crowder <[email protected]> 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
Jun 10, 2014, 11:16:43 AM6/10/14
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
Jun 15, 2014, 12:26:02 PM6/15/14
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
Jun 21, 2014, 3:30:09 AM6/21/14
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.
 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
Jun 21, 2014, 3:38:21 AM6/21/14
to [email protected], 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
Jun 21, 2014, 3:55:31 AM6/21/14
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).
> 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
Jun 21, 2014, 4:43:08 AM6/21/14
to [email protected], 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
Jun 21, 2014, 5:03:30 AM6/21/14
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
Jun 21, 2014, 5:10:18 AM6/21/14
to [email protected], 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
Jun 21, 2014, 9:26:45 AM6/21/14
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
> 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?
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
Jun 22, 2014, 8:08:28 PM6/22/14
to [email protected], chromium-dev
To reply briefly, from an engineering perspective (re Aura):
On 21 June 2014 17:30, Richard Lloyd <[email protected]> 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
Mar 17, 2015, 12:29:09 AM3/17/15
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 напиÑал:
Ñреда, 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:
- 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.)
- 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
Mar 17, 2015, 6:54:17 AM3/17/15
to [email protected], Chromium-dev, [email protected], [email protected], [email protected], [email protected], Darin Fisher
On Tue, Mar 17, 2015 at 7:29 AM, Sayat <[email protected]> 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:
- 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.)
- 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
Mar 17, 2015, 7:31:06 AM3/17/15
to [email protected], [email protected], Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], 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
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
Mar 17, 2015, 7:39:50 AM3/17/15
to [email protected], [email protected], [email protected], Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
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: [email protected]
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>
> --
> --
> Chromium Developers mailing list: [email protected]
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>
Ricardo Ribalda Delgado
Mar 17, 2015, 7:51:06 AM3/17/15
to Alexis Menard, [email protected], [email protected], Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], 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
> website requires me to use a Java applet but use Chrome as my daily
> driver. I believe I'm not alone thinking that way.
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
Mar 17, 2015, 8:19:58 AM3/17/15
to Ricardo Ribalda Delgado, [email protected], Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
On Tue, Mar 17, 2015 at 2:30 PM, Ricardo Ribalda Delgado <[email protected]> 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
Mar 17, 2015, 9:47:44 AM3/17/15
to [email protected], Chromium-dev
On Tue, Mar 17, 2015 at 4:30 AM Ricardo Ribalda Delgado <[email protected]> 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
Mar 17, 2015, 2:27:12 PM3/17/15
to [email protected], [email protected], 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
Mar 27, 2015, 10:57:30 AM3/27/15
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.
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".
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
Mar 27, 2015, 11:11:40 AM3/27/15
--
Stuart Morgan
Mar 27, 2015, 11:19:59 AM3/27/15
[Whoops, somehow hit send immediately]
On Fri, Mar 27, 2015 at 7:57 AM Konstantin Boyandin <[email protected]> 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
Mar 27, 2015, 12:02:37 PM3/27/15
to Stuart Morgan, [email protected], [email protected], [email protected], [email protected], [email protected]
Пт, 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
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
Mar 27, 2015, 12:03:13 PM3/27/15
to [email protected], Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
On Fri, Mar 27, 2015 at 5:57 PM, Konstantin Boyandin <[email protected]> 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:
- 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.)
- 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
Mar 27, 2015, 12:18:40 PM3/27/15
to Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
Skipping anti-Java advocacy, since I do not have objections against it.
Пт, 27.03.2015 в 22:02 Victor Khimenko пиÑал(а):
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
Пт, 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
> 1. Don't run it at all.
> 2. Give it full access to your system, all it's files and documents.
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.Â
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
Mar 27, 2015, 12:25:21 PM3/27/15
to [email protected], Stuart Morgan, chromium-dev, [email protected], [email protected], [email protected], Darin Fisher
On Fri, Mar 27, 2015 at 9:01 AM, Konstantin Boyandin <[email protected]> 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
Mar 27, 2015, 12:31:33 PM3/27/15
to Konstantin Boyandin, [email protected], [email protected], [email protected], [email protected], [email protected]
On Fri, Mar 27, 2015 at 9:02 AM Konstantin Boyandin <[email protected]> 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
Mar 27, 2015, 12:45:01 PM3/27/15
to [email protected], Stuart Morgan, Chromium-dev, Justin Schuh, Elliot Glaysher, [email protected], Darin Fisher
On Fri, Mar 27, 2015 at 7:01 PM, Konstantin Boyandin <[email protected]> wrote:
Пт, 27.03.2015 в 21:19 Stuart Morgan пиÑал(а):
> [Whoops, somehow hit send immediately]
>
> On Fri, Mar 27, 2015 at 7:57 AM Konstantin Boyandin <[email protected]> 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
Mar 27, 2015, 12:50:28 PM3/27/15
to Stuart Morgan, [email protected], [email protected], [email protected], [email protected], [email protected]
Пт, 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
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
Mar 27, 2015, 1:16:03 PM3/27/15
to Konstantin Boyandin, Stuart Morgan, Chromium-dev, Elliot Glaysher (Chromium), [email protected], 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
Mar 27, 2015, 1:16:36 PM3/27/15
to Konstantin Boyandin, Stuart Morgan, Chromium-dev, Justin Schuh, Elliot Glaysher, [email protected], 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
Mar 27, 2015, 8:00:13 PM3/27/15
to Victor Khimenko, Stuart Morgan, Chromium-dev, Justin Schuh, Elliot Glaysher, [email protected], 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
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
Mar 28, 2015, 6:49:37 AM3/28/15
to [email protected], Victor Khimenko, Stuart Morgan, Chromium-dev, Justin Schuh, Elliot Glaysher, [email protected], Darin Fisher
​Linux users just got it early, Windows and Macintosh users will get it by September.​ Everyone gets it eventually.
☆PhistucK
Michał Gołębiowski
Mar 28, 2015, 2:28:27 PM3/28/15
to [email protected], [email protected], Victor Khimenko, Stuart Morgan, Chromium-dev, Justin Schuh, Elliot Glaysher, [email protected], Darin Fisher
On Saturday, March 28, 2015, PhistucK <[email protected]> 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
Mar 28, 2015, 3:58:41 PM3/28/15
to Michał Gołębiowski, [email protected], Victor Khimenko, Stuart Morgan, Chromium-dev, Justin Schuh, Elliot Glaysher, [email protected], 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
Mar 29, 2015, 7:15:26 PM3/29/15
to [email protected], Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
On Sat, 28 Mar 2015 at 03:18 Konstantin Boyandin <[email protected]> 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
Mar 29, 2015, 7:38:06 PM3/29/15
to Matt Giuca, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], 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 <[email protected]> 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.
>> 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.
>
Matt Giuca
Mar 29, 2015, 8:09:19 PM3/29/15
to Konstantin Boyandin, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
On Mon, 30 Mar 2015 at 10:37 Konstantin Boyandin <[email protected]> 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
Mar 29, 2015, 8:41:17 PM3/29/15
to Matt Giuca, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], 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 пиÑал(а):
>>Â http://groups.google.com/a/____chromium.org/group/chromium-____dev
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 <[email protected]> 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.
>> 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.
>
Thiago Farina
Mar 29, 2015, 8:57:03 PM3/29/15
to [email protected], Matt Giuca, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
On Sun, Mar 29, 2015 at 9:40 PM, Konstantin Boyandin <[email protected]> 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
Mar 29, 2015, 8:57:17 PM3/29/15
to [email protected], Matt Giuca, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
On Sun, Mar 29, 2015 at 4:37 PM, Konstantin Boyandin <[email protected]> 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
Mar 29, 2015, 9:42:06 PM3/29/15
to Peter Kasting, Matt Giuca, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], 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 пиÑал(а):
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
Mar 29, 2015, 9:53:24 PM3/29/15
to Konstantin Boyandin, Peter Kasting, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], 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=enPeter Kasting
Mar 29, 2015, 10:01:54 PM3/29/15
to Matt Giuca, Konstantin Boyandin, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
On Sun, Mar 29, 2015 at 6:52 PM, Matt Giuca <[email protected]> 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
Mar 29, 2015, 10:02:19 PM3/29/15
to Matt Giuca, Peter Kasting, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], 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 пиÑал(а):
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
Mar 30, 2015, 1:20:54 AM3/30/15
to [email protected], Matt Giuca, Victor Khimenko, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
On Sun, Mar 29, 2015 at 4:37 PM Konstantin Boyandin <[email protected]> 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
Jan 7, 2014, 7:04:18 PM1/7/14
to Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
Chad Miller
Jan 8, 2014, 9:30:38 AM1/8/14
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)
Jan 8, 2014, 10:12:26 AM1/8/14
to [email protected], Chromium-dev
On 8 January 2014 14:30, Chad Miller <[email protected]> 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:
- 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.)
- 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).
Â
- chadUbuntu
--
--
Chromium Developers mailing list: [email protected]
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 [email protected].
Justin Schuh
Jan 8, 2014, 10:14:25 AM1/8/14
to [email protected], Chromium-dev
On Wed, Jan 8, 2014 at 6:30 AM, Chad Miller <[email protected]> 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:
- 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.)
- 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
Jan 8, 2014, 10:39:13 AM1/8/14
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 <[email protected]> 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:
- 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.)
- 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
Jan 8, 2014, 10:45:13 AM1/8/14
to [email protected], 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
Jan 8, 2014, 6:50:55 PM1/8/14
to [email protected], [email protected], 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?
Benjamin Schwartz
Jan 8, 2014, 7:10:14 PM1/8/14
to [email protected], [email protected], [email protected], Chromium-dev
On Wed, Jan 8, 2014 at 3:50 PM, Matt Giuca <[email protected]> wrote:
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.
Ubuntu has a "popularity contest" (a.k.a. "popcon") that allows users to automatically report when they install a package.
The absolute numbers aren't meaningful (only a subset of users activate popcon) but they can give a sense of relative popularity.  Here are some graphs of popcon values for a few packages as of August:
Chrome Stable: 263K installs, 20-30K "votes" (i.e. frequent users)
Chrome Beta: 85K installs, ~300 votes
Chrome Dev: 35K installs, ~300 votes
Chromium: 408K installs, 20-40K votes
For comparison, Firefox: 2.4M installs, 81-172K votes
The numbers are very rough and the survey is problematic in several ways, but I conclude that Chromium, as built by Ubuntu, represents about half of Ubuntu Chrome+Chromium usage.
--Ben
P.S. Thanks to upopcon (http://www.lesbonscomptes.com/upopcon/) for the visualization.
Chad Miller
Jan 8, 2014, 7:27:23 PM1/8/14
to Matt Giuca, [email protected], Chromium-dev
On Wed, Jan 8, 2014 at 6:50 PM, Matt Giuca <[email protected]> wrote:
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: ...
All of them are correct. Â The only minor detail is that the NPAPI Flash Player from Adobe is not "old", but it gets no new features. It still gets security updates, according to Adobe.
Â
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.
With many download mirrors, we don't have the download countability of packages the same way Chrome does. We do have something called "popularity contest", which was a reporting tool used to suggest what would go on the install CD, which I'll look into. It's not quite comparing apples to apples, sadly, but might suggest a ratio we can extrapolate from.Â
Anecdotally, I would guess about 2:1 :: GoogleChrome:chromium-browser. Â Google has made it very easy to install Chrome and have it update automatically on Ubuntu. Â (Cheers!)
Maybe some other distro could offer their stats, too.
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?
I feel quite sure envoys have met in the past. That nothing has changed does not encourage me.
- chad
Xinwen Xue
Jan 8, 2014, 9:32:41 PM1/8/14
to [email protected], Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
I have one entry-level question,
Since ScriptableObject is deprecated in PPAPI, how to write a new one or port such kind of NPAPI plugin by using PPAPI?
Darin Fisher
Jan 8, 2014, 10:13:09 PM1/8/14
to [email protected], Elliot Glaysher, (Chromium), Tom Wiltzius, [email protected], Justin Schuh, [email protected]
There is no support for synchronous scripting between JS and a PPAPI plugin, except for the deprecated method you found.
Note: There is also no supported way to use PPAPI from a third party plugin outside of Native Client.
--
Stuart Morgan
Jan 9, 2014, 10:40:35 AM1/9/14
to [email protected], Matt Giuca, [email protected], Chromium-dev
On Wed, Jan 8, 2014 at 4:27 PM, Chad Miller <[email protected]> wrote:
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?
I feel quite sure envoys have met in the past. That nothing has changed does not encourage me.
What's the alternative? Even if someone builds out NPAPI support in Linux Aura, the same problem will come up again when the NPAPI code is removed from Chrome entirely, as mentioned earlier. Unless you expect Flash usage to drop substantially between April and the end of the year, or there's some other plan for addressing the issue in the longer term that can't be ready by April, it doesn't seem like delaying the problem would actually help.
-Stuart
Matt Giuca
Jan 9, 2014, 6:24:55 PM1/9/14
to Stuart Morgan, Chad Miller, Justin Schuh, Chromium-dev
FYI: I found this article in OMG! Ubuntu! about this issue:
(It quotes Justin Schuh from earlier in this thread.)
Another thing I found last night is a Debian package called PepperFlashPlayer. Apparently it works the same way as the existing FlashPlayer package (which downloads Adobe Flash from Adobe and installs it) -- it downloads Chrome from Google, extracts the PPAPI Flash plugin, and installs it for Chromium. That might be a good work-around for Chromium users in the interim. (Note: I am not endorsing this method, just making people aware of it.) But obviously it would be better if PPAPI Flash were available in a more "official" context.
Ali Sedaghatpour
Jan 14, 2014, 1:57:24 PM1/14/14
to [email protected], Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
What is your suggestion for a mouse gesture extension? I used to use Pig Toolbox and it worked great, but now it doesn't work anymore in Chrome 32 since NPAPI support has been removed. What can I do?
Thanks
PhistucK
Jan 14, 2014, 2:16:42 PM1/14/14
to Ali Sedaghatpour, Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
Extension provided NPAPI plugins are not blocked at this point. See the other thread for more details about this specific issue.
☆PhistucK
--
--
Chromium Developers mailing list: [email protected]
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 [email protected].
Marce l
Mar 2, 2014, 10:15:19 AM3/2/14
to [email protected], Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
Amazing, no more VDPAU for me! Goodbye Chromium :)
Max Heinritz
Mar 3, 2014, 3:06:59 PM3/3/14
to [email protected], Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
Update:
When I sent the original PSA a few months ago, we'd expected NPAPI support to be removed from Linux Chromium in M34 (goes to Stable in April). Â Now we're on track for M35 instead (goes to Stable in May).
--
Cliff Wells
May 20, 2014, 4:26:02 PM5/20/14
to [email protected], Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
On Tuesday, January 7, 2014 4:04:18 PM UTC-8, Max Heinritz wrote:
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.
While most of the discussion here centers around Flash, other products are also affected. For me, there are two:
1) GNOME Shell Integration plugin
2) VMware VSphere Client plugin
As many of you know, there is no native VSphere client for Linux. That means relying on the web UI. That is also no longer an option. So anyone on Linux managing a VMware instance is now sent running to Firefox. Given VMware's lack of rush to get out a native Linux client, I don't expect to see a rush to port their plugin to PPAPI anytime soon.
While I can't speak for anyone else, I have no plans on running two browsers . I understand the push to get rid of NPAPI, but at the same time, if the result is a browser that is no longer usable... well... I don't need to carry on about it. If I'm forced to use Firefox so be it. But do realize that will be the result for many people.
Ricardo Ribalda Delgado
May 21, 2014, 9:13:43 AM5/21/14
to [email protected], Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
Also Java!!
Which means chrome it is not usable in Denmark any more, since all the relevant logins (bank, taxex, city services, union, health....) are done with nemid.nu a java based product.
Any public plans for Java/IcedTea to support Peeper?
Torne (Richard Coles)
May 21, 2014, 9:47:58 AM5/21/14
to [email protected], Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
On 21 May 2014 14:13, Ricardo Ribalda Delgado <[email protected]> wrote:
Also Java!!Which means chrome it is not usable in Denmark any more, since all the relevant logins (bank, taxex, city services, union, health....) are done with nemid.nu a java based product.Any public plans for Java/IcedTea to support Peeper?
Nobody is working on this as far as we know.
Â
On Tuesday, May 20, 2014 10:26:02 PM UTC+2, Cliff Wells wrote:
On Tuesday, January 7, 2014 4:04:18 PM UTC-8, Max Heinritz wrote: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.
While most of the discussion here centers around Flash, other products are also affected. For me, there are two:1) GNOME Shell Integration plugin2) VMware VSphere Client pluginAs many of you know, there is no native VSphere client for Linux. That means relying on the web UI. That is also no longer an option. So anyone on Linux managing a VMware instance is now sent running to Firefox. Given VMware's lack of rush to get out a native Linux client, I don't expect to see a rush to port their plugin to PPAPI anytime soon.While I can't speak for anyone else, I have no plans on running two browsers . I understand the push to get rid of NPAPI, but at the same time, if the result is a browser that is no longer usable... well... I don't need to carry on about it. If I'm forced to use Firefox so be it. But do realize that will be the result for many people.
--
Ricardo Ribalda Delgado
May 21, 2014, 9:51:32 AM5/21/14
to [email protected], [email protected], Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
I have contacted nemid, as soon as I got a propper response I will copy it here. But with no nemid, chrome cannot be used in Denmark.
What about a NPAPI to Pepper wrapper? Any project working on that?
Torne (Richard Coles)
May 21, 2014, 9:54:58 AM5/21/14
to [email protected], Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
On 21 May 2014 14:51, Ricardo Ribalda Delgado <[email protected]> wrote:
I have contacted nemid, as soon as I got a propper response I will copy it here. But with no nemid, chrome cannot be used in Denmark.What about a NPAPI to Pepper wrapper? Any project working on that?
This can't realistically be implemented. NPAPI plugins expect to call OS functionality directly - they can do literally anything they want. Pepper sandboxes them and enforces that they can't touch the OS at all except via Chrome APIs. Such a wrapper would have to emulate basically the entire API of your operating system; not very practical.
Ricardo Ribalda Delgado
May 21, 2014, 10:11:30 AM5/21/14
to Torne (Richard Coles), Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
Can use sockets in pepper? .
What about a pepper plugin + a NPAPI broker server communicating via a socket
-The NPAPI server will be a different binary working outside the
sandbox. This will run the NPAPI plugin
-A Pepper plugin will interact with the user: render, events.....
So you can have an idea of the relevance of nemid: Anything you buy
in Denmark with a card requires nemid in the "secured by visa" stage.
Perhaps Google should have planned the schedule a bit better. Moving
away from NPAPI without having an alternative does not sounds like a
good idea.
Many users will have to use other browsers.
--
Ricardo Ribalda
What about a pepper plugin + a NPAPI broker server communicating via a socket
-The NPAPI server will be a different binary working outside the
sandbox. This will run the NPAPI plugin
-A Pepper plugin will interact with the user: render, events.....
So you can have an idea of the relevance of nemid: Anything you buy
in Denmark with a card requires nemid in the "secured by visa" stage.
Perhaps Google should have planned the schedule a bit better. Moving
away from NPAPI without having an alternative does not sounds like a
good idea.
Many users will have to use other browsers.
Ricardo Ribalda
Finnur Thorarinsson
May 21, 2014, 10:21:58 AM5/21/14
to [email protected], Torne (Richard Coles), Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
> Moving away from NPAPI without having an alternative does not sounds like a good idea.
If you look at last year's announcement that Max Heinritz linked to in his original message you'll find:
"There are several alternatives to NPAPI. In cases where standard web technologies are not yet sufficient, developers and administrators can use NaCl, Apps, Native Messaging API, and Legacy Browser Support to transition from NPAPI. Moving forward, our goal is to evolve the standards-based web platform to cover the use cases once served by NPAPI."
Jiang Jiang
May 21, 2014, 10:31:35 AM5/21/14
to [email protected], Torne (Richard Coles), Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
On Wed, May 21, 2014 at 4:11 PM, Ricardo Ribalda Delgado
<[email protected]> wrote:
> Can use sockets in pepper? .
>
> What about a pepper plugin + a NPAPI broker server communicating via a socket
>
> -The NPAPI server will be a different binary working outside the
> sandbox. This will run the NPAPI plugin
>
> -A Pepper plugin will interact with the user: render, events.....
>
> So you can have an idea of the relevance of nemid: Anything you buy
> in Denmark with a card requires nemid in the "secured by visa" stage.
Do banks in Denmark offer similar solutions to Mobile BankID [1, 2]?
<[email protected]> wrote:
> Can use sockets in pepper? .
>
> What about a pepper plugin + a NPAPI broker server communicating via a socket
>
> -The NPAPI server will be a different binary working outside the
> sandbox. This will run the NPAPI plugin
>
> -A Pepper plugin will interact with the user: render, events.....
>
> So you can have an idea of the relevance of nemid: Anything you buy
> in Denmark with a card requires nemid in the "secured by visa" stage.
In Norway and Sweden this seems to be the only viable solution when
Java support is completely gone in certain browsers. (Well, in fact when
it is still supported, I still prefer using this to authenticate.)
> Perhaps Google should have planned the schedule a bit better. Moving
> away from NPAPI without having an alternative does not sounds like a
> good idea.
>
> Many users will have to use other browsers.
[1] http://support.bankid.com/mobil
[2] https://www.dnb.no/privat/nettbank-mobil-og-kort/nettbank/bankid-paa-mobil.html
Oystein Eftevaag
May 21, 2014, 10:39:38 AM5/21/14
to [email protected], [email protected], Torne (Richard Coles), Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
Norway's BankID has also been working on a Java-less replacement for a while now; apparently it will be deployed in August. I would be surprised if Denmark's NemID isn't also working on a replacement (they'd have to in either case, if they want to support mobile browsers).
--
--
Chromium Developers mailing list: [email protected]
View archives, change email options, or unsubscribe:
  http://groups.google.com/a/chromium.org/group/chromium-dev
Ricardo Ribalda Delgado
May 21, 2014, 10:39:41 AM5/21/14
to Finnur Thorarinsson, Torne (Richard Coles), Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
On Wed, May 21, 2014 at 4:21 PM, Finnur Thorarinsson
<[email protected]> wrote:
>> Moving away from NPAPI without having an alternative does not sounds like
>> a good idea.
>
> If you look at last year's announcement that Max Heinritz linked to in his
> original message you'll find:
>
> "There are several alternatives to NPAPI. In cases where standard web
> technologies are not yet sufficient, developers and administrators can use
> NaCl, Apps, Native Messaging API, and Legacy Browser Support to transition
> from NPAPI. Moving forward, our goal is to evolve the standards-based web
> platform to cover the use cases once served by NPAPI."
As a java/nemid user:
<[email protected]> wrote:
>> Moving away from NPAPI without having an alternative does not sounds like
>> a good idea.
>
> If you look at last year's announcement that Max Heinritz linked to in his
> original message you'll find:
>
> "There are several alternatives to NPAPI. In cases where standard web
> technologies are not yet sufficient, developers and administrators can use
> NaCl, Apps, Native Messaging API, and Legacy Browser Support to transition
> from NPAPI. Moving forward, our goal is to evolve the standards-based web
> platform to cover the use cases once served by NPAPI."
NaCl: I cannot port a propietary plugin to another technology
Apps: I do not mantain my bank, citizen services, union site
Native Messaging API: I cannot port a the propietary plugin
Legacy browser: I don't use Windows, why don't use Firefox instead?
So no, there is no viable alternative for a normal user.
For an hiperaffeinated developer: perhaps an NPAPI broker using Native
Messaging API could have been an ok solution, but should be the person
causing the problem the one fixing it.
I personally think that you are using your users as bullets against
your competitors. And that is not good practice. Or maybe you have
underestimated the consequences of your decision.
From my point of view, since the 21st of may I cannot buy a plane
ticket (nor a chocolate bar) with my everyday browser.
Ricardo Ribalda
Ricardo Ribalda Delgado
May 21, 2014, 10:42:03 AM5/21/14
to Oystein Eftevaag, [email protected], Torne (Richard Coles), Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
Just received from nemid:
Dear Ricardo
Right now there's no alternative sollution for java. You can see the
requirements for your browser etc. by clicking here
https://www.nemid.nu/dk-da/support/faa_hjaelp_til_nemid/tekniske_krav/understoettede_programmer/.
Hjælp os med at forbedre vores support. Dette gøres nemt ved at du
svarer på et spørgsmål på følgende link
Venlig hilsen
Stephanie H
Servicedesk
Nets DanID A/S
www.nemid.nu/support
[email protected]
--
Ricardo Ribalda
Dear Ricardo
Right now there's no alternative sollution for java. You can see the
requirements for your browser etc. by clicking here
https://www.nemid.nu/dk-da/support/faa_hjaelp_til_nemid/tekniske_krav/understoettede_programmer/.
Hjælp os med at forbedre vores support. Dette gøres nemt ved at du
svarer på et spørgsmål på følgende link
Venlig hilsen
Stephanie H
Servicedesk
Nets DanID A/S
www.nemid.nu/support
[email protected]
Ricardo Ribalda
Oystein Eftevaag
May 21, 2014, 10:48:10 AM5/21/14
to Ricardo Ribalda Delgado, [email protected], Torne (Richard Coles), Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
It's being phased out in Denmark as well:Â http://politiken.dk/forbrugogliv/digitalt/internet/ECE2107661/nets-dropper-java-i-den-naeste-version-af-nemid/
Ricardo Ribalda Delgado
May 21, 2014, 12:55:54 PM5/21/14
to Oystein Eftevaag, [email protected], Torne (Richard Coles), Chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
Seems that is not ready yet, based on nemid support reply.
But happy to hear that someday there will be a replacement.
Anyway. There are other public services that rely on Java like the
Spanish tax office.
Let's see how the next months develop. Specially when this issue hits
windows platforms
--
Ricardo Ribalda
But happy to hear that someday there will be a replacement.
Anyway. There are other public services that rely on Java like the
Spanish tax office.
Let's see how the next months develop. Specially when this issue hits
windows platforms
Ricardo Ribalda
Markus Gutschke (顧åŸå‹¤)
May 21, 2014, 11:22:59 PM5/21/14
to Chromium-dev
One of the unexpected things that stopped working is the DNSSEC Validator from the Chrome Store.
I no longer have access to internal GOOG resources, but can somebody please notify the owners of https://developers.google.com/speed/public-dns/faq#dnssec and ask them to remove references to using the DNSSEC Validator with Chrome. The reference to Firefox can stay until (and if) there is a better option that works with all browsers.
Thanks,
Markus
I no longer have access to internal GOOG resources, but can somebody please notify the owners of https://developers.google.com/speed/public-dns/faq#dnssec and ask them to remove references to using the DNSSEC Validator with Chrome. The reference to Firefox can stay until (and if) there is a better option that works with all browsers.
Thanks,
Markus
Matthew Dempsky
May 22, 2014, 12:10:38 AM5/22/14
to [email protected], Chromium-dev
On Wed, May 21, 2014 at 8:22 PM, Markus Gutschke (顧åŸå‹¤) <[email protected]> wrote:
One of the unexpected things that stopped working is the DNSSEC Validator from the Chrome Store.
I no longer have access to internal GOOG resources, but can somebody please notify the owners of https://developers.google.com/speed/public-dns/faq#dnssec and ask them to remove references to using the DNSSEC Validator with Chrome. The reference to Firefox can stay until (and if) there is a better option that works with all browsers.
I'm happy to file an internal bug, but shouldn't that extension still work for Windows users in the mean time? Â I.e., it's only broken for Linux users?
Sayantan Das
May 22, 2014, 1:07:50 AM5/22/14
to [email protected], Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
This also breaks Citrix connections as Java is required.
On Wednesday, 8 January 2014 05:34:18 UTC+5:30, 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.
Matt Giuca
May 22, 2014, 2:06:24 AM5/22/14
to [email protected], chromium-dev, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
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.
--
Cliff Wells
May 22, 2014, 2:56:10 AM5/22/14
to [email protected], [email protected], Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
On Wednesday, May 21, 2014 11:06:24 PM UTC-7, Matt Giuca wrote:
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.
Conversely, a browser than cannot function as needed is about as useful as no browser at all. We'd be really secure if we just turned the entire computer off.
The argument that the number of users that require NPAPI plugins is too small contradicts your position that this is a security hole of significant magnitude - if there are few users then the security hole would only affect those few users. At the least there should be a way for people who simply must have NPAPI plugins to whitelist or reenable them. If I can't run the VMware VSphere console plugin, then I can't use Chrome. I could have lived with nag screens, hidden settings, etc, but blanket removal is unacceptable (not to mention the wasted hour I spent discovering why suddenly one morning I couldn't access the console during an IT crisis - love you guys for that). None of the nag screens that were claimed to be in planning ever appeared. Just went from working on Monday to utter failure on Tuesday.
I've been forced to switch back to Firefox, and I don't think I'll be back. Thanks for the fun couple of years.
Â
PhistucK
May 22, 2014, 3:12:46 AM5/22/14
to [email protected], Chromium-dev, [email protected], Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
The security based decision is to remove NPAPI from the browser at all (due by the end of the year, if I am not mistaken).
The effort-to-number-of-affected-users-ratio based decision is to remove NPAPI from the browser on Linux now.
The effort-to-number-of-affected-users-ratio based decision is to remove NPAPI from the browser on Linux now.
Note that Google is still a business - would you waste a lot of money and time on something that you know is going away anyway and that a relatively few people use?
Nothing is contradicting here. Every browser has features that only that particular browser supports. The (great) trend is to remove (or standardize) these features, especially if they have security issues or have non trivial engineering costs.
Examples include EcmaScript For XML ("E4X") by Firefox, VML by Internet Explorer, ActiveX on Internet Explorer for Windows RT (and I think, for the new Windows 8 experience, formerly known as "Metro").
Developers (and so also users) depended on these features, but not a lot of then and so those features were removed.
☆PhistucK
--
--
Chromium Developers mailing list: [email protected]
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 [email protected].
Matt Giuca
May 22, 2014, 3:22:19 AM5/22/14
to [email protected], chromium-dev, [email protected], Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
On 22 May 2014 16:56, Cliff Wells <[email protected]> wrote:
On Wednesday, May 21, 2014 11:06:24 PM UTC-7, Matt Giuca wrote: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.
Conversely, a browser than cannot function as needed is about as useful as no browser at all. We'd be really secure if we just turned the entire computer off.
That's a specious argument. Security is not black and white. We can significantly increase security in the browser by removing NPAPI, and retain the functionality that is useful for the vast majority of cases, which is rendering HTML and JavaScript, along with Flash and other PPAPI plugins.
The argument that the number of users that require NPAPI plugins is too small contradicts your position that this is a security hole of significant magnitude - if there are few users then the security hole would only affect those few users. At the least there should be a way for people who simply must have NPAPI plugins to whitelist or reenable them. If I can't run the VMware VSphere console plugin, then I can't use Chrome. I could have lived with nag screens, hidden settings, etc, but blanket removal is unacceptable (not to mention the wasted hour I spent discovering why suddenly one morning I couldn't access the console during an IT crisis - love you guys for that). None of the nag screens that were claimed to be in planning ever appeared. Just went from working on Monday to utter failure on Tuesday.
I said that the number of users requiring NPAPI plugins is too small to be worth spending significant engineering effort on. That does not mean we're happy to leave them with an insecure browser. Besides, the small user base I was talking about was the intersection of Linux users and NPAPI plugin users. The decision to deprecate NPAPI was about all platforms, not just Linux, so it affects a significantly larger number of users.
Have you not seen nag screens? I've certainly seen them. According to this page, you should have been seeing nag screens as pictured on that page since Chrome 32.
PhistucK
May 22, 2014, 3:38:26 AM5/22/14
to Matt Giuca, [email protected], chromium-dev, [email protected], Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
Actually, that nag screen (as shown in the screenshot) does not seem to notify the user that it will not be supported anymore. It just asks for permission to run it. I do not even see a "Learn more" link in there.
When I try this on Windows -
There is a "Learn more", but the page does not say that plugins will not be supported anymore later this year or anything like that -
☆PhistucK
--
--
Chromium Developers mailing list: [email protected]
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 [email protected].
Ricardo Ribalda Delgado
May 22, 2014, 3:54:17 AM5/22/14
to [email protected], [email protected], chromium-dev, [email protected], Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
I think that you have underestimated the functionality provided by it:
- Use on-line banking
- Pay taxes
- Make appointments with the doctor
- Rent a squash field
- VMWare
To sum up, the browser is now useless for everyday use for a high
amount of people, and we have no alternative using chrome.
And to make it even worse in some months this will reach all the
people, not just the linux users...
Perhaps a better collaboration with Oracle to have a Pepper plugin as
you have done with flash (might be difficult...), or even better,
implement yourself a Pepper plugin for iced tea.
>
>> The argument that the number of users that require NPAPI plugins is too
>> small contradicts your position that this is a security hole of significant
>> magnitude - if there are few users then the security hole would only affect
>> those few users. At the least there should be a way for people who simply
>> must have NPAPI plugins to whitelist or reenable them. If I can't run the
>> VMware VSphere console plugin, then I can't use Chrome. I could have lived
>> with nag screens, hidden settings, etc, but blanket removal is unacceptable
>> (not to mention the wasted hour I spent discovering why suddenly one morning
>> I couldn't access the console during an IT crisis - love you guys for that).
>> None of the nag screens that were claimed to be in planning ever appeared.
>> Just went from working on Monday to utter failure on Tuesday.
>
>
> I said that the number of users requiring NPAPI plugins is too small to be
> worth spending significant engineering effort on. That does not mean we're
> happy to leave them with an insecure browser. Besides, the small user base I
> was talking about was the intersection of Linux users and NPAPI plugin
> users. The decision to deprecate NPAPI was about all platforms, not just
> Linux, so it affects a significantly larger number of users.
>
> Have you not seen nag screens? I've certainly seen them. According to this
> page, you should have been seeing nag screens as pictured on that page since
> Chrome 32.
>
> --
> --
> Chromium Developers mailing list: [email protected]
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
--
> --
> Chromium Developers mailing list: [email protected]
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
Ricardo Ribalda
PhistucK
May 22, 2014, 3:57:26 AM5/22/14
to [email protected], Matt Giuca, Cliff Wells, chromium-dev, Sayantan Das, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
Most of the things you mention are actually country specific. In my country (Israel), we do not need Java (or any other plugin) for any of those.
VMWare is a different matter (and its market share is also very small, most users do not use it).
☆PhistucK
Ricardo Ribalda Delgado
May 22, 2014, 4:07:48 AM5/22/14
to PhistucK, Matt Giuca, Cliff Wells, chromium-dev, Sayantan Das, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
On Thu, May 22, 2014 at 9:57 AM, PhistucK <[email protected]> wrote:
> Most of the things you mention are actually country specific. In my country
> (Israel), we do not need Java (or any other plugin) for any of those.
> VMWare is a different matter (and its market share is also very small, most
> users do not use it).
I guess we will see the magnitude as soon as this reaches windows.
> Most of the things you mention are actually country specific. In my country
> (Israel), we do not need Java (or any other plugin) for any of those.
> VMWare is a different matter (and its market share is also very small, most
> users do not use it).
Again, I feel that I am been used as a bullet against Google's competitors:
http://en.wikipedia.org/wiki/Oracle_v._Google
And using the most common/cheap excuse: "for your own safety".
Ricardo Ribalda
PhistucK
May 22, 2014, 5:08:19 AM5/22/14
to Ricardo Ribalda Delgado, Matt Giuca, Cliff Wells, chromium-dev, Sayantan Das, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
This is unrelated to Oracle (Java) specifically, this is a battle between browsers and hackers.
And this is not an excuse and certainly not a cheap one. People do get hacked. Security is crucial.
Having no computer (some hackers can even destroy hardware) or having your credit card credentials stolen is significantly worse than having a computer that cannot perform some operations. The threat is real, exploits exist.
☆PhistucK
Daniel Bratell
May 22, 2014, 5:36:36 AM5/22/14
to Ricardo Ribalda Delgado, PhistucK, Matt Giuca, Cliff Wells, chromium-dev, Sayantan Das, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
On Thu, 22 May 2014 11:08:19 +0200, PhistucK <[email protected]> wrote:
> This is unrelated to Oracle (Java) specifically, this is a battle
> between browsers and hackers.
>
>
> And this is not an excuse and certainly not a cheap one. People do get
> hacked. Security is crucial.
> Having no computer (some hackers can even destroy hardware) or having
> your credit card credentials >stolen is significantly worse than having
> a computer that cannot perform some operations. The threat >is real,
> exploits exist.
Google/Chrome is also in a position to actually change things. In
> This is unrelated to Oracle (Java) specifically, this is a battle
> between browsers and hackers.
>
>
> And this is not an excuse and certainly not a cheap one. People do get
> hacked. Security is crucial.
> Having no computer (some hackers can even destroy hardware) or having
> your credit card credentials >stolen is significantly worse than having
> a computer that cannot perform some operations. The threat >is real,
> exploits exist.
Opera/Presto we did a lot of things to make our users more secure
(separated access between intranet and internet as just one example) but
every such decision cost users migrating to other browsers, in fact making
those users less secure(good intentions and all that). That will probably
happen to some degree here as well, but Google Chrome is a big enough
player to actually change stubborn people's views and with that ability
comes the responsibility to do the right thing for the open web and the
users even when it hurts.
(As I've worked at both sides of the (Presto) interaction layer between
scripts and npapi plugins it will be with some pleasure I see the last
npapi plugin being put in the cupboard)
/Daniel - returning to decoding trybot fails...
Markus Gutschke (顧åŸå‹¤)
May 22, 2014, 6:10:28 AM5/22/14
to Chromium-dev
Thanks for offering to file a bug.
Yes, it is quite possible that Windows still works for a while; I wasn't able to test that here. On Linux, the extension installs, but it then silently fails and doesn't appear to do anything. That's very confusing, and official Google documentation should not point users to a tool that fails this way.
Having said that, I fully understand why NPAPI is getting deprecated, and I mostly agree with the decisions made. As much as I hate having to go through the transition phase, I love the ultimate end result that promises a much more secure browsing experience.
Markus
Yes, it is quite possible that Windows still works for a while; I wasn't able to test that here. On Linux, the extension installs, but it then silently fails and doesn't appear to do anything. That's very confusing, and official Google documentation should not point users to a tool that fails this way.
Having said that, I fully understand why NPAPI is getting deprecated, and I mostly agree with the decisions made. As much as I hate having to go through the transition phase, I love the ultimate end result that promises a much more secure browsing experience.
Markus
Stuart Morgan
May 22, 2014, 11:03:36 AM5/22/14
to [email protected], PhistucK, Matt Giuca, Cliff Wells, chromium-dev, Sayantan Das, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
On Thu, May 22, 2014 at 1:07 AM, Ricardo Ribalda Delgado <[email protected]> wrote:
I guess we will see the magnitude as soon as this reaches windows.
We already know what the magnitude is—and can monitor the change in those numbers over the course of this year—because we have actual usage statistics for NPAPI plugins across Chrome's user base. Decisions about NPAPI deprecation and eventual removal are not being made blindly, or in a vacuum.
Please don't confusing coming to a different conclusion than you with not understanding the usage landscape.
-Stuart
Ricardo Ribalda Delgado
May 22, 2014, 11:32:56 AM5/22/14
to Stuart Morgan, PhistucK, Matt Giuca, Cliff Wells, chromium-dev, Sayantan Das, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
Stuart,
I am not saying that NPAPI should not be deprecated. It is obsolete,
unsecure and does not work on tables/phones. Just want to make you
understand that NPAPI is used for critical stuff like paying your
taxes or scheduling with your doctor. You only do this once per year
and therefore it is negligible on your stats.
Nobody uses java plugin because he decides to use java plugin. People
use it because they have no option and usually to do critical tasks. I
cannot even order a book in my library now! I believe that the
criticality of the tasks done with NPAPI should have been considered,
and not only the amount of users, and I guess that having stats about
his is difficult.
On the other hand, you have done a lovely job with Flash, the Pepper
plugin was ready and tested much before the NPAPI plugin was
deprecated. But in Java I humbly believe that you have made a mistake.
And if the reason is no collaboration from oracle, you could have
developed a pepper plugin for icedtea.
Anyway, I have no contributed a single line to chromium, I don't pay
for the product, nor pay a developer to work on it, so I have no vote.
This is only customer feedback: A critical usercase is not working now
for me or anybody living in Denmark and using Linux (or Windows in
some months)
--
Ricardo Ribalda
I am not saying that NPAPI should not be deprecated. It is obsolete,
unsecure and does not work on tables/phones. Just want to make you
understand that NPAPI is used for critical stuff like paying your
taxes or scheduling with your doctor. You only do this once per year
and therefore it is negligible on your stats.
Nobody uses java plugin because he decides to use java plugin. People
use it because they have no option and usually to do critical tasks. I
cannot even order a book in my library now! I believe that the
criticality of the tasks done with NPAPI should have been considered,
and not only the amount of users, and I guess that having stats about
his is difficult.
On the other hand, you have done a lovely job with Flash, the Pepper
plugin was ready and tested much before the NPAPI plugin was
deprecated. But in Java I humbly believe that you have made a mistake.
And if the reason is no collaboration from oracle, you could have
developed a pepper plugin for icedtea.
Anyway, I have no contributed a single line to chromium, I don't pay
for the product, nor pay a developer to work on it, so I have no vote.
This is only customer feedback: A critical usercase is not working now
for me or anybody living in Denmark and using Linux (or Windows in
some months)
Ricardo Ribalda
PhistucK
May 22, 2014, 12:59:35 PM5/22/14
to Stuart Morgan, Ricardo Ribalda Delgado, Matt Giuca, Cliff Wells, chromium-dev, Sayantan Das, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
Just to be accurate -
NPAPI usage statistics come only from those that enabled anonymous usage statistics, right?
If so, then this is not coming from all of the user base.
If so, then this is not coming from all of the user base.
☆PhistucK
Stuart Morgan
May 22, 2014, 2:13:18 PM5/22/14
to PhistucK, Ricardo Ribalda Delgado, Matt Giuca, Cliff Wells, chromium-dev, Sayantan Das, Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
On Thu, May 22, 2014 at 9:59 AM, PhistucK <[email protected]> wrote:
Just to be accurate -NPAPI usage statistics come only from those that enabled anonymous usage statistics, right?
If so, then this is not coming from all of the user base.
I never said it was from "all of the user base" I said it was from "across" the user base. As in, from a large sample across many types of users in many countries (as opposed to extrapolating from one specific user's experience and assuming it is representative).
-Stuart
Mike Cavedon
May 22, 2014, 5:59:48 PM5/22/14
to [email protected], Justin Schuh, Tom Wiltzius, Elliot Glaysher, [email protected], Darin Fisher
Just so I am clear on this. Does this mean java is not, and will not, be supported in Chrome moving foward?
If that is the case then I can't use Chrome as too much of what I do depends on the java plugin.
I am on Ubuntu 14.04.Â
It is loading more messages.
0 new messages