Chrome gaat traditionele plug-ins uitfaseren

Google gaat traditionele plug-ins in zijn Chrome-browser uitfaseren. Traditionele plug-ins maken nog altijd gebruik van de plug-in-api van Netscape, maar volgens Google is die onveilig, instabiel en te complex. Eind 2014 wordt de ondersteuning voor de api volledig beëindigd.

Vanaf januari worden alle Chrome-plug-ins die de Netscape Plug-in Api gebruiken, geblokkeerd, zo heeft Google bekendgemaakt. Alleen de zes populairste plug-ins worden ontzien, waaronder Silverlight, Unity en Google Earth. Ook Java hoort bij de populairste plug-ins, maar die plug-in moet apart worden geactiveerd als een website Java wil gebruiken. Overigens kunnen gebruikers en systeembeheerders zelf ook bepaalde plug-ins whitelisten, zodat ze alsnog kunnen draaien.

Het is vanaf nu al niet meer mogelijk om plug-ins die de npapi gebruiken toe te voegen aan de Chrome Web Store; vanaf mei zijn die niet meer vindbaar en vanaf volgend jaar september worden alle npapi-plug-ins compleet uit de Chrome Web Store verwijderd. Eind volgend jaar wordt de ondersteuning van de Netscape Plug-in Api bovendien compleet uit de code van Chrome verwijderd. Vanaf dan zullen andere api's moeten worden gebruikt om functionaliteit zoals die van de npapi aan te spreken, zoals de native client-interface van Chrome.

Volgens Google is de plug-in-api niet meer van deze tijd, en zorgt hij voor veel crashes, freezes, beveiligingsproblemen en complexere code. Veel exploit kits, zoals BlackHole, gebruiken beveiligingsproblemen in plug-ins als Java om ongemerkt malafide software te installeren. De plug-in wordt dan ongemerkt geladen, vaak zonder dat een gebruiker het merkt.

Eerder kondigde Firefox al aan dat het plug-ins standaard gaat blokkeren; gebruikers moeten er per website voor kiezen om een plug-in alsnog te activeren. Firefox maakt gebruik van dezelfde plug-in-functionaliteit als Chrome: die stamt uit de jaren negentig en werd samen met Netscape Navigator 2.0 geïntroduceerd. Het was de eerste mogelijkheid om op internet andere content te tonen dan enkel tekst en statische afbeeldingen. Het gebruik van npapi werd aangedreven door Adobe, dat zijn Acrobat-software graag in de browser wilde laten draaien. Ook Safari en Opera ondersteunen npapi; Internet Explorer ondersteunde de api tot Service Pack 2 van versie 5.5.

Reacties (62)

[Soldaatje]

De officiële Flash voor Linux is ook een npapi.
De Pepper-flash versie die je uit Chrome kan halen, die ook nieuwer en beter is, is natuurlijk een ppapi.
Die kan je ook gebruiken in Chromium en Firefox, de Pepper versie, door wat zaken in te stellen.

[epias]

Ik zou niet zeggen dat pepper flash beter is. Bij het gebruik van Adobe flash (npapi) is de CPU load, bij het kijken naar flash video, een heel stuk lager. Pepper (Chrome) flash ondersteunt nog steeds geen volledige hardware acceleration.

Dit is de reden dat ik nog steeds Adobe flash gebruik.

[MrEddy]

Goede zaak, werd hoog tijd.

[sfranken]

Ik snap niet waarom je door 8 (!) mensen als "offtopic" wordt gemod. Je hebt gewoon gelijk, dit soort "oude" legacy code zorgt ervoor dat de browser minder veilig is.

[mae-t.net]

Het is absoluut on-topic en een begrijpelijke beslissing maar niet per definitie een goede zaak.

Zijn er al standaards (liefst eentje) die algemeen door de markt geaccepteerd worden of gaan worden, om deze oude standaard te vervangen? Zo nee dan gaan er vroeg of laat gebruikers en beheerders héél lelijke woorden mompelen.

Overigens ironisch dat Google Earth dit oude systeem gebruikt. Zouden afdelingen van Google wel intern communiceren, of hebben ze dit over de schutting gesmeten onder het roepen van "je hebt nog minder dan een jaar om je meuk weer werkend te krijgen". Het lijkt erop dat dit wel al minstens gedeeltelijk in orde gemaakt was, dus minder ironisch.

[Reactie gewijzigd door mae-t.net op 25 juli 2024 17:46]

[sfranken]

Maar als bewezen is dat de standaard "lek" is en slecht geschreven waarom dan nog een oude standaard behouden? Als we er allemaal zo over dachten klopten we nog HTML 2.1 met tabellen..

Een mooi voorbeeld van een omarmde maar wel voortschrijdende standaard is HTML (en CSS ook, CSS3 komt mooi rond zo).

Als Google een standaard voorschrijft (die door iedereen eerst geaccepteerd meot worden) die veiliger is maar wel de functionaltiet behoud is daar toch niks mis mee?

[mae-t.net]

Als het lek is en patchen niet meer zou helpen, zal het vroeg of laat uitgefaseerd moeten worden, helemaal mee eens, maar dat is dan een technisch besluit en geen politiek. Standaarden die plompverloren door 1 browsermaker worden neergezet inplaats van gezamenlijk tot stand komen, hebben in het verleden nogal een slechte reputatie opgelopen, en naar mijn idee niet ten onrechte. Denk aan alle perikelen rond MS Internet Explorer.

[Reactie gewijzigd door mae-t.net op 25 juli 2024 17:46]

[sfranken]

de NPAPI plugin voldoet zover ik weet aan al je eisen. Je kunt blijven patchen maar ooit is het het niet meer waard.

[MrEddy]

Haha, mensen hebben vaak de neiging om vast te houden aan oude standaarden. Een hoop bevriende webontwikkelaars schrijven nog steeds gewillig HTML 4.1 en schrijven hele CMS software in procedure oriëntatie. Na verloop van tijd zie je gelukkig steeds vaker dat de marktleiders door systematische veranderingen de ontwikkelaars gaan forceren om te gaan vernieuwen.

[gitaarwerk]

Je kan tegenwoordig een hoop niuewe dingen maken zonder 4.1 te schrijven hoor Alleen denk aan de fallbacks .

engie nadeel is dat proces-software; vaak interne systemen, worden aangeschaft en IT moet implementeren. Die weten vaak ook dat hetgeen waar je nog IE(6-7) moet voor hebben kut is

[martijnvanegdom]

(Off-topic) misschien om er geen enkele redenatie komt waarom het een goede zaak is? Dat MrEddy het hoog tijd vind, is irrelevant, waarom hij het vind mogelijk interessant ; en zouden we natuurlijk graag horen.

[MrEddy]

In het nieuwsbericht staat één zin die elk tegenargument de grond in drukt.

"Firefox maakt gebruik van dezelfde pluginfunctionaliteit als Chrome: die stamt uit de jaren negentig en werd samen met Netscape Navigator 2.0 geïntroduceerd."

[supertheiz]

Je moet eens kijken hoeveel code in Windows, Linux en Unix zit, die nog veel ouder is als deze functionaliteit.
Is dit dan de reden om maar geen OS meer te installeren op je computer?

Bijvoorbeeld in Unix: De cross-platform reverse-polish desk calculator
http://en.wikipedia.org/wiki/Dc_(computer_program)
Die is uit de jaren 60. In 2011 hebben ze overigens nog een bug gevonden in dit programma

[MrEddy]

Ik geef toe dat mijn reactie misschien ietwat ongenuanceerd is maar ik ben het toch niet helemaal eens met je.

Het programma dat jij noemt, de Unix Desk Calculator vind ik niet vergelijkbaar met de Netscape API Plug-in. In een browser als Chrome, een van de nieuwste en meest efficiënte browsers die op dit moment op de markt is hoort geen API Plug-in te zitten uit de jaren 90, simpelweg omdat API contact veranderen en vernieuwen. Steeds willen gebruikers meer en meer, daar moet de API op gebouwd zijn. Ik ben niet van mening dat die API daarin nog kan voorzien.

Back to the point: UDC is een rekenprogramma en geen API voor plug-ins. Rekenkunde is statisch en veranderd niet, het tegenovergestelde is waar voor plug-ins.

[supertheiz]

De grootste fout die netscape heeft gemaakt, is de code opnieuw schrijven.
Dat was hun ondergang.

Puur de overweging maken: "API + Jaren 90 = slecht" is niet terecht.

* De meeste bugs zullen inmiddels zijn gevonden. Bugs zijn de grootste beveiligingsrisico's
* Er zit geen houdbaarheidsdatum aan programmacode. Het wordt niet vaal van lang in de zon liggen en het gat niet schimmelen. Puur omdat het oud is, maakt het niet slecht.
* De meeste aanroepen van deze API zijn geoptimaliseerd, en de meeste fouten bij deze aanroep zullen inmiddels zijn opgelost.

Ik denk dat het makkelijker én veiliger is, om voor deze plugin de bekende veiligheidsproblemen op te lossen. Niet om deze te vervangen.
Performance verbeteren is ook makkelijker voor een API met zo veel ervaring.

[R4gnax]

Er zitten bakken met race condities en andere problemen met resources als drawing contexts vast aan de NPAPI.

Die hele API is gewoon niet gebouwd om goed met dat soort zaken om te gaan; het is gewoon een totaal inadequate oplossing.

[dasiro]

het is gewoon een totaal inadequate oplossing.

en toch werkt ze al bijna 20 jaar, misschien dat ze nu legitiem misbruikt wordt om dingen te doen, maar het boeltje draait toch nog altijd.

legacy is de bittere realiteit waar je rekening mee moet houden of vaak zelfs prioriteit is. Er is ENORM veel code geschreven die nog in productie wordt gebruikt, maar niet zomaar op 1, 2, 3 te vervangen is. Hetzij door een gebrek/stopzetting van ondersteuning, personeel dat er niet meer is/niet meer voor is opgeleid, ... Ik vind het dan ook redelijk kort door de bocht qua timing, maar anderzijds zullen bedrijven die bepaalde oude functionaliteit nog nodig hebben sowieso al geen chrome gedraaid hebben, maar gewoon (een oude versie van) internet explorer

[R4gnax]

en toch werkt ze al bijna 20 jaar

Definieer 'werkt'.

Persoonlijk vind ik dat een instabiel plugin contract wat bij de minste of geringste bug in een plugin of foute aanname van een plugin over de runtime state van de host, die hele host neer kan halen absoluut niet onder de noemer 'werken' vallen.

[RobIII]

Things You Should Never Do, Part I much?

[supertheiz]

Verplicht leesvoer.

[R4gnax]

Things You Should Never Do, Part I much?

Dat artikel wordt vreselijk te pas en te onpas aangehaald.

[RobIII]

Dat gebeurde hier dus, weliswaar "verkapt", ook

[RobIII]

hoort geen API Plug-in te zitten uit de jaren 90, simpelweg omdat API contact veranderen en vernieuwen

API of niet is weinig relevant; je draagt als argument aan dat 't "uit de nineties stamt" en dat 't daarmee dus elk "tegenargument de grond in drukt". Wat dacht je van HTTP? Dat stamt ook uit begin jaren negentig (en wat dacht je van TCP/IP dat uit de jaren 70 stamt). Het is niet eens een plugin maar de 'core' van je browser, 't ligt aan de basis van alles. Moet dat dan ook maar wieberen en vervangen worden door iets hips?

[Reactie gewijzigd door RobIII op 25 juli 2024 17:46]

[H!GHGuY]

Google denkt alvast van wel met SPDY en QUIC...

[RobIII]

Dat men SPDY prefereert (anno 2013) boven HTTP(s) maakt het "oude" niet meteen overbodig / vervallen. Daarbij is de penetratie ervan nog zo goed als nul.

QUIC maakt nog steeds gebruik van UDP

Maar je snapt mijn punt wel, er zitten in zo'n beetje elke applicatie wel sporen/flarden/resten van code uit de eighties, seventies en mogelijk nog eerder.

[H!GHGuY]

Jij gaf voorbeelden aan die moesten bewijzen dat oude dingen niet per definitie slecht zijn.

Ik geef 2 tegenvoorbeelden die aangeven dat er voor beide gekeken wordt naar vervanging.

Dat QUIC trouwens op UDP draait was voor zover ik weet enkel en alleen omdat veel intermediate hops iets anders als TCP/UDP blocken en het de enige manier was om met minimale overhead iets over het netwerk te krijgen.

Met andere woorden:
De requirements die aan oplossingen gesteld worden veranderen met de tijd. Als de oplossing niet mee kan evolueren dan moet er naar vervanging gekeken worden.

[curumir]

Een api is geen plugin.

https://en.wikipedia.org/...ion_programming_interface

Een Application programming interface is een afspraak van calls die een programma kan doen om lager-level zaken te kunnen gebruiken op een veilige manier. Er zijn vast en zeker API's uit lang vervlogen tijden die nog volop gebruikt worden, denk low-level UNIX API's etc. Normaal poogt men een API juist zo te maken dat het een lange levensduur heeft, iets wat (natuurlijk) lang niet altijd lukt.
Het doel van een API is dan ook normaal gesproken dat je in Chrome, 'een van de nieuwste en meest efficiënte browsers die op dit moment op de markt' los van de API-implementatie deze calls veiliger en sneller kunt maken.

Helaas is de situatie weerbarstiger, en is deze API blijkbaar niet meer te redden. Het gaat natuurlijk te ver op te zeggen dat deze uit de jaren negentig is en *dus* vervangen moet worden.

[sfranken]

Code waarvan is aangetoond dat het zo lek is als een mandje (of lekken makkelijker maakt) én waarvoor een alternatief is mag van mij per direct ge-rm-min-rt't worden hoor, óók in een OS.

Moet wel de functionaliteit (grotendeels) overeen komen natuurlijk.

[jGS]

http://en.wikipedia.org/wiki/Windows_NT_3.1

Wil je niet weten hoeveel belangrijke code (al dan niet aangepast) nu nog steeds in Windows 8.1 zit!!

[Reactie gewijzigd door jGS op 25 juli 2024 17:46]

[RobIII]

In de windows kernel (en geloof me, zowat élk OS) zit zelfs nog code uit het pre-DOS tijdperk hoor (Bijvoorbeeld stukken uit de "standard C library") NT 3.1 is wat dat betreft nog relatief jong.

[Reactie gewijzigd door RobIII op 25 juli 2024 17:46]

[jGS]

Yep, maar ik had het bijvoorbeeld onder andere over de NT kernel api zelf (Zw/Nt functies, andere core kernel code etc).

Dat bijvoorbeeld een prinft nog tot oudere code behoort geloof ik best

[Brummetje]

Het is nog steeds on-topic wat die zegt.. Informatief/Spotlight is iets anders

[Amito]

Dat kan het misschien zijn, maar zorg er dan tenminste voor dat je je eigen plugins het goede voorbeeld geven. Als je naar de whitlist kijkt dan zitten daar twee plugins van Google zelf tussen(Earth en Talk).
Dit is eigenlijk een zelfde soort verhaal als dat ze hun eigen Youtube apps niet met HTML 5 hebben opgebouwd voor Android en iOS, maar als Microsoft voor WP een app wilt maken dan moeten ze dat doen in HTML 5.
Het wordt steeds krommer en krommer bij Google...

[awenmaek]

De nieuwe versie van google maps bevat reeds een "google earth" in webgl. Daarnaast ging Hangouts gebruik maken van webrtc.
Waarom ze deze dan willen whitelisten is raar vermits voor deze diensten dan geen plugin nodig is.

[Reactie gewijzigd door awenmaek op 25 juli 2024 17:46]

[Anoniem: 508381]

Helemaal mee eens, uiteindelijk zijn er betere middelen dan een oude netscape api. En mensen moeten niet zeuren dat het legacy code is oid, software ontwikkeling gaat altijd verder.

[Martinspire]

Misschien handig om even te melden:

The company said it will "temporarily whitelist" these popular plug-ins on Chrome to run through NPAPI starting in January 2014:

• Silverlight (which Google said was launched by 15 percent of Chrome users in the last month, though not necessarily used by them)
• Unity (launched by 9.1 percent)
• Google Earth (9.1 percent)
• Java (8.9 percent)
• Google Talk (8.7 percent)
• Facebook Video (6.0 percent)

And of that list of most-popular NPAPI plug-ins, Java is already blocked by default for security reasons.

Grote kans dat die straks ook grotendeels wel via de andere API zullen gaan werken lijkt me?

[CyBeR]

Hm. Hoewel ik zulks toejuich mis ik Flash in dat lijstje, of gebruikt die al een andere api?

[Rafe]

Die maakt gebruik van Pepper (aka PPAPI), de NaCl (native client) plugin API van Chrome ipv NPAPI.

[Anoniem: 325463]

Flash gebruikt de npapi(getuige de nodige nspluginwrapper lib op linux onder rekonq/midori)

[Reactie gewijzigd door Anoniem: 325463 op 25 juli 2024 17:46]

[Xanaroth]

Natuurlijk. Google gaat bijvoorbeeld niet zijn eigen Google Talk/Google earth permanent ondermijnen, dus dat ze dit doen terwijl eigen plug-ins het gebruiken, zegt op zich genoeg.

Het zal eerder vooral een heads-up zijn richting de organisaties, dat ze vanaf nu 1 jaar hebben om de api zelf uit te faseren en merkt niemand het volgend jaar als de verandering is doorgevoerd.

[awenmaek]

Google Talk -> hangouts met webrtc
Google Earth -> Nieuwe Google Maps met webgl

Voor deze plugins zijn er reeds opvolgers.

[CuBras]

Maar betekend dit dat je helemaal geen plug ins meer kan gebruiken, of kan je ze nog wel side-loaden? Want ik wil m'n adBlocker, Facebook ad removal e.d. behouden ... Anders wordt FB écht een ramp. Die reclame troep hoef ik namelijk niet.

[Reactie gewijzigd door CuBras op 25 juli 2024 17:46]

[skatebiker]

Daar heb je /etc/hosts voor.
Je download ADFREE (niet meer in de Play store) maar wel te vinden op het web en die hosts file kun je zo 1:1 op Mac en Ubuntu (en Windows denk ik ook) gebruiken.
Hoef je geen adblock meer per browser te installeren.

[Anoniem: 533809]

CuBras zegt dat hij graag zijn add blockers wil blijven gebruiken en jij geeft als antwoord dat dan maar het hosts bestand moet gebruiken , want die is daar volgens jou voor.

Dat lijkt mij nou niet echt terecht. Het hosts bestand was oorspronkelijk toch echt bedoeld om een IP adres te geven voor een domein zonder dat dat er een dns request naar een dns server hoeft te worden gestuurd Bron , en niet om bepaalde onwenselijke verbindingen tegen te houden.
Nu weet ik ook wel dat dat tegenwoordig wel vaker gedaan word , maar dat betekend nog niet dat dat hosts bestand daar voor (gemaakt) is.

Sterker nog , ik kan de regels zoals ik ze in mijn add blocker heb absoluut NIET voorelkaar krijgen via het hosts bestand. Zo kan ik er met mijn add blocker bijvoorbeeld voor zorgen dat hij geen add's filtered op tweakers , zie dat maar eens via hosts te doen ? Dat gaat namelijk niet , omdat het hosts bestand niet in staat is om onderscheid te maken tussen de verschillende websites die ik bezoek en daar zijn regels op aan te passen. Dat lijkt mij toch een duidelijk gemis ten opzichte van een add blocker.

Bovendien kan het hosts bestand geen onderscheid maken tussen verschillende pagina's op 1 website (domein) , iets wat wat met een echte add blocker absoluut geen enkel probleem is .
Zo block ik bijvoorbeeld "||1.hidemyass.com/assets/js/mootools/*" zonder het hele domein "1.hidemyass.com" te blocken.

Dus kom ik tot de conclusie dat het inderdaad mogelijk is om op een zeer gelimiteerde wijze add's te filteren via het hosts bestand , maar dat het toch echt geen goede vervanging is voor een add blocker.

[Anoniem: 405071]

Ja die kan je nog wel gebruiken. Want dat zijn geen plugins maar extensies. En dit gaat puur om de API richting plugins. Extensies maken gebruik van andere extensies

[Anoniem: 325463]

Dat zijn extensies, geen plugins

[Aham brahmasmi]

Maar betekend dit dat je helemaal geen plug ins meer kan gebruiken, of kan je ze nog wel side-loaden? Want ik wil m'n adBlocker, Facebook ad removal e.d. behouden

Nee. Plugins zijn zaken zoals Java, Silverlight, Quicktime, etc. Adblock e.d. zijn extensions en vallen in een volledig andere categorie.

[EGM360]

Wat ik graag wil weten is of dit ook bijdraagt aan het afslanken van Chrome als browser. Het begint op het moment echt een vrij zware browser te worden die veel van je geheugen vergt. Ik vind het persoonlijk erg jammer als ik dit vergelijk met de kleine browser die Chrome ooit was.

[- peter -]

Komt dat niet door dat elke tab in een afzonderlijk process draait? Oftewel door beveiliging?

[DeTeraarist]

Ja maar, ja maar, NPAPI was juist zo makkelijk omdat iedere niet IE browser daar vrolijk gebruik van maakte, zodat pluginbouwers maar 2 versies voor het windows platform hoefden af te leveren, één voor IE gebaseerde browsers en één voor de rest. Als Google hier een mooie variant op heeft dan zie ik dat graag terug in andere browsers zodat we straks niet een IE versie, een NPAPI versie en een Chrome versie hoeven te installeren.

[Origin64]

Zolang ik maar advertenties kan blokkeren kom ik ook via de adresbalk bij alle functionaliteit. De meeste plugins zijn toch toolbars die alleen maar browsegegevens verzamelen.

Echt achterlijk hoe vaak ik voor mijn werk wel geen snap.do, babylon, etc tegenkom, hele rijen toolbars met 5 verticale pixels voor de webpagina. Nee, echt niet slecht dat dit de nek om wordt gedraaid voor de gewone gebruiker.

Moet dan natuurlijk wel het een en ander mogelijk blijven voor power users, browsers zonder addons kunnen gewoon niet zo veel als soms nodig is.

[pizzafried]

het gaat om plugins, niet om extensions dus tooltjes als addblock en zaken handig voor webdeveloper blijven wel bestaan...anders ging google OOK de playstore uitfaseren

[Origin64]

Oh, even overheen gelezen.

[NTAuthority]

Hoe zit dit dan met applicaties als Battlelog, wat ook via een NPAPI-plugin werkt? Wordt er dan nog wel een niet-'sandboxed' interface aangeboden waarmee applicaties eventueel gestart kunnen worden?

[cappie]

De eerte stap richting het blokkeren van Adblock... 'k denk dat ik maar een donaties richting Mozilla moet gaan maken

[R4gnax]

De eerte stap richting het blokkeren van Adblock... 'k denk dat ik maar een donaties richting Mozilla moet gaan maken

AdBlock heeft hier geen moer mee te maken. NPAPI plugins zijn iets heel anders dan browser extensions.

[cappie]

Ah.. gelukkig

[rvdm88]

weet iemand of dit dus ook de "chrome extensions" betreft?

[jeroen3]

Nee, dit gaat over chrome://plugins/ niet over chrome://extensions/