Google blokkeert vanaf januari in Chrome plug-in-api van Netscape

Google blokkeert vanaf januari standaard de plug-in-api van Netscape in Chrome. De internetgigant faseert de api al tijden uit, maar hanteert in de browser nog een whitelist voor populaire plugins. Vanaf volgend jaar zal ook de whitelist verdwijnen.

De whitelist geldt standaard voor de populairste plug-ins, zoals Silverlight, Unity en Google Earth. Gebruikers en systeembeheerders kunnen zelf ook bepaalde programma's aan de lijst toevoegen, zodat ze die alsnog kunnen draaien. Google gaat echter de whitelist vanaf januari standaard uitschakelen, meldt het bedrijf in een blogpost.

Het Amerikaanse bedrijf faseert al langer traditionele plug-ins uit in zijn Chrome-browser. Die maken nog altijd gebruik van de plug-in-api van Netscape, die ook wel bekend staat als de npapi. Volgens Google is die alleen onveilig, instabiel en te complex. Om die reden staat Google plug-ins die npapi gebruiken al niet meer toe in de Chrome Web Store.

Uit cijfers van Google blijkt dat het gebruik van npapi-plug-ins gestaag afneemt. De meestgebruikte plugin is tot dusver Silverlight, waar elf procent van alle Chrome-gebruikers wel eens iets mee doet. Op de tweede en derde plek staan respectievelijk Google Talk en Java. Die laatste moet overigens wel apart worden geactiveerd als een website Java wil gebruiken.

Er staan volgens Google nog meer veranderingen voor npapi-plug-ins op stapel in Chrome. Vanaf april volgend jaar zal de ondersteuning standaard zijn uitgeschakeld en worden plug-ins die ervan gebruikmaken uit de Chrome Web Store verwijderd. Voor geavanceerde gebruikers en bedrijven die ook dan afhankelijk zijn van de technologie, zal die periode een tijdelijke oplossing komen voor het opnieuw inschakelen van npapi. Die oplossing werkt tot september, benadrukt Google.

Reacties (43)

[Blaise]

Waarom gebruikt Google zelf die API nog? (Het artikel noemt Earth en Talk)

[Reactie gewijzigd door Blaise op 23 juli 2024 19:02]

[Firefly III]

Een plugin geschreven in de Netscape API heeft de rechten van de gebruiker zelf. Dat is handig, en makkelijk bij het implementeren van legacy code: geen sandbox geklungel als jouw plugin ergens hardcoded $USER/Mijn Documenten probeert te lezen (denk aan de oude HEMA foto upload applicatie). Je kan je bestaande DLL bestand zo in Chrome hangen.

Op de NPAPI pagina's van Google kan je er meer over vinden.

[halofreak1990]

Een plugin geschreven in de Netscape API heeft de rechten van de gebruiker zelf.

Dan vraag ik me af waarom SilverLight met deze API werkt, aangezien SilverLight bijna geen rechten nodig heeft.

[RobinJ1995]

Erm... Wat? Bron?

[wizekid]

Dat zijn ook alleen legacy plugins die somige websites nog gebruiken. Talk (Hangouts) is allang beschikbaar als nieuwe Chrome Browser app sinds de Chromebooks op de markt kwamen. Maps heeft nu een WebGL gebaseerde engine dus die heeft earth ook nergens meer voor nodig.

Die plugins zijn dan ook de laatste 2+ jaar niet meer geupdate, volgens mij ondersteunen ze ze ook niet meer. (Wat begrijpelijk is)

[Umbrah]

Earth is wel wat meer dan zelfs de nieuwe WebGL app. De KML/Shape support is niet/nauwelijks aanwezig, je kan geen tours/paden er in programmeren, je kan niet een area pre-cachen en opslaan, je kan niet eens traploos roteren. Tevens geen 3D modellen, alleen hun eigen meshes... je merkt dat Google Earth Pro aan alle kanten uitgefaseert wordt maar het is gewoon nog niet een vervanging, de nieuwe WebGL app. Als je iets gemaakt hebt in earth desktop, dan kan die plugin nog wel eens relevant zijn, zeker als 3D je doel is... ESRI, de open source gemeenschap, eigenlijk stellen ze allemaal grandioos teleur als het aan komt op 3D & kaarten. Google was er ver mee maar zet nu een stap terug dus.

[- peter -]

Ik zou graag extensies compleet verbieden in Chrome. Maar kon nergens een optie daarvoor vinden.

[i7x]

Extensies zijn anders dan plug-ins. Het probleem met extensies is al grotendeels opgelost. In het verleden wilde applicaties nog wel eens automatisch extensies toevoegen aan Chome die lastig waren te verwijderen en vaak compleet ongewenst waren (bijvoorbeeld het injecteren van tool bars). Tegenwoordig kan men enkel nog extensies toevoegen uit de Chrome web store. Dat komt er op neer dat ze zichzelf niet meer continue opnieuw kunnen toevoegen (want dan mogen ze niet in de store) en verder, als het goed is, onschadelijk zijn (want anders worden ze ook verwijderd uit de store.

Plug-ins zijn iets heel anders. Met een plug-in kun je op een webpagina content laten zien die geen standaard web code zoals html gebruikt. Flash is wel de bekendste. Maar Flash zal nog gewoon blijven werken omdat deze gebruik maakt van de Pepper api, en niet van de zwaar verouderde, en dus wellicht onveilige Netscape api. Veel andere plug-ins zoals Silverlight en Java.

Deze zullen dus niet meer te gebruiken zijn.

Ik ben hier wel blij mee want, ondanks dat ze soms handig zijn, kunnen veel sites die ze gebruiken ondertussen dezelfde functies ook wel bieden dmv html5 (Magister bijvoorbeeld). Dat is stukken veiliger.

Ik vind het ook goed dat Google het voortouw neemt met dit soort ingrijpende veranderingen. Dat doen ze bijvoorbeeld ook al door langzaamaan het gebruik van verouderde ssl certificaten te ontmoedigen. Veranderingen die nu misschien wel vervelend zijn voor sommigen, maar op de lange termijn echtt een verbetering vormen.

[Reactie gewijzigd door i7x op 23 juli 2024 19:02]

[Pyrone89]

Ik check net even in OSX hoe dat zit, en daar geeft de nieuwste Flash bij mij toch echt aan de NPAPI versie te zijn.

Overigens draai ik Yosemite met Safari, geen Chrome. Maar Flash versies zijn hetzelfde, alleen is die bij Chrome ingebakken.

[i7x]

Dat kan kloppen. Flash heeft een versie voor beide plug-ins, in ieder geval op Windows (Pepper). Je zult over een tijdje dus moeten wisselen van versie. Ik vermoed dat, omdat de NPAPI variant in een toekomstige versie gewoon niet meer aanwezig zal zijn, je automatisch een berichtje zult krijgen zodra je een Flash site bezoekt met daarin een link om de nieuwe versie te installeren, of ze stoppen hem er al standaard in.

EDIT: voor mensen die willen kijken welke versie ze gebruiken. Dat kun je hier zien:
[url]chrome://plugins/[/url]
Als je op "details" klikt zie je of je PPAPI gebruikt (op mijn pc is dat het geval), of NPAPI (de variant die uitgefaseert wordt)

EDIT2: Verkeerd gelezen dat je de Safari gebruikt en geen Chrome.

[Reactie gewijzigd door i7x op 23 juli 2024 19:02]

[Pyrone89]

Ik heb even Wiki afgezocht en het lijkt erop dat naast Chrome (en Chromium) en Opera (wat tegenwoordig afgeleid is van Chrome) er geen browsers ondersteuning bieden voor PPAPI en dit ook niet van plan zijn (in de woorden van Mozilla, Apple zal ook niet staan te springen om Google technologie te implementeren).

[i7x]

Mozilla werkt aan een eigen variant (Shumway). Verder kun je PPAPI Flash ook gebruiken in Firefox en Opera dmv een wrapper, maar die wordt niet door Mozilla ontwikkeld. We zullen zien hoe die browser bowers dit uiteindelijk aan zullen pakken.

[--Andre--]

Als je PPAPI plugins via een wrapper aan een browser die enkel NPAPI snapt kunt geven, zou het dan niet mogelijk zijn ook voor de andere richting een wrapper te schrijven.

[Umbrah]

Mwoah, hij gebruikt dus geen chrome, maar safari. Safari volgt Chrome dus niet, en is afhankelijk van de npapi voor flash, etc... er zijn op die manier al wat meer beveiligingslekken ontstaan waar Apple reactief op bezig is geweest, terwijl google door die hele legacy er uit te slopen (iets wat traditioneel qua hardware juist weer een Apple ding is...) hoopt permanent van het non-sandboxed-extention-gedoe af te zijn.

Het heeft als voordeel dat safari wel lekker snel/zuinig kan zijn, maar als nadeel... tsja... het is per definitie onveilig. Er worden op het moment drie flash branches onderhouden in principe: Chrome, ActiveX, en npapi, waar de eerste twee vrij duidelijk zijn, maar de laatste dus een algemene verzameling (hier is de versie voor 32/64, en selecteer hier je package format (MSI/DEB/RPM/Apple) is van, tsja, eigenlijk alles wat webkit en/of gecko gebruikt en wat >NIET< Chrome is. Het is goed dat ze de versienummers gelijk houden, en gelijktijdig releasen (hoeft niet vanzelfsprekend te zijn, apple zut op windows loopt traditioneel wat achter, terwijl het tegenovergestelde natuurlijk ook waar is).

Als Apple beveiliging eens serieus ging nemen hadden ze misschien ook dapper de stap gezet om in safari-PC de npapi los te laten, of zelfs de hele iOS-stap te zetten van "compleet geen plugins".

[nAffie]

Here you go: https://www.google.com/in...e/business/browser/admin/

[Niosus]

Je installeert ze gewoon niet?

[FreshMaker]

Je installeert ze gewoon niet?

Hij is sysadmin en wil zijn gebruikers inperken ....

[- peter -]

Mijn moeder inperken beter gezegd. Die heeft telkens weer toolbars die ze helemaal niet wil.

[Reactie gewijzigd door - peter - op 23 juli 2024 19:02]

[cyberstalker]

chrome://settings/content

Onder 'Plug-ins' kies je vervolgens voor 'Block all'.

[Umbrah]

Tsja, IE11 is geen slechte browser en je kan er nét wat meer mee tegenhouden via group policies/domain policies. Hoewel addins en extensions volgens mij bij Chrome nog nét wel te doen zijn. Je kan iig altijd nog de config read-only zetten, het ontkoppelen van een google account, en in die config extentions uitzetten. Nadeel: tenzij je handmatig de GOEDEN installeert (als je moeder zo'n probleem is dat je haar in een volle AD/niet-IT-bedrijf-stijl lockdown wiltt hebben is dat misschien dus aan de orde) en up-to-date houdt, dan zul je er niet aan ontkomen om dat dan ook echt handmatig te doen per user. Domain policies zijn een leuk ding.

Chrome heeft volgens mij wel wat meer policy-templates trouwens:

https://support.google.com/chrome/a/answer/187202?hl=en

[Verwijderd]

downloads: Unchecky 0.3.4 even installeren .

[RoestVrijStaal]

In mijn ogen is Google te goedkoop bezig met het blokkeren van de api.

De NPAPI deprecation guide is meer een logboek met losse verwijzingen van wat je als ontwikkelaar kan gebruiken dan een tutorial om simpel en snel je plugin om te zetten in "nieuwe API's". Laat staan dat Google een tool vrijgeeft wat ontwikkelaars met de migratie helpt.

Google wil hier gewoon zelf voordeel halen en het gebruik van haar Native Client en PPAPI/Pepper technologie stimuleren.

Oftewel er wordt gebroken met een de facto standaard cross-platform plugin architectuur, ten gunste van eigen technologie. Jammer.

[Wolfos]

En native client werkt alleen voor 'apps' die uit de Chrome web store zijn geinstalleerd. Of de gebruiker moet zelf in chrome://flags een optie aanzetten.

Nee lekker. Als je van de Unity plugin gebruik maakt is er nog geen alternatief, en WebGL export heeft nog niet eens half de performance van de webplayer straks.

[_David_]

Firefox is npapi ook al aan het uitfaseren hoor, niet alleen chrome/google dus.

[revertive]

Microsoft ondersteunt het al lang niet meer in Internet Explorer dus waarom zou het een probleem zijn als Google de ondersteuning laat vallen? En als er niemand iets nieuws wilt bedenken dan moet Google het zelf maar doen, we spreken hier over een plug-in-api die uit het Netscape tijdperk komt oftewel genoeg tijd om iets nieuws te bedenken.

En over de NPAPI deprecation guide ik als 'leek' op plugin gebied vind het vrij duidelijk, en er staan redelijk wat voorbeelden bij. Waarom moet alles voorgekauwd worden aan de developers? Die snappen toch zelf wel wat ze doen.

En tuurlijk gaat Google hier voor eigen voordeel, welk bedrijf zou dat niet doen?

[halofreak1990]

Waarom moet alles voorgekauwd worden aan de developers?

Omdat de meeste developers zo lui zijn als <insert vergelijking hier>. Die werken met een "write once, update never" mentaliteit.

[Fish]

Ik kreeg een soortgelijk verhaal van slingbox maar dan met een 32 <-> 64 bits verhaal

As you may be aware of, Google just launched its brand new 64-bit Chrome browser as a required upgrade for Mac OS X customers, and has made the upgrade on Windows-based systems a user opt-in update. In the process, Google has decided to discontinue the support of 32-bit browser plug-ins for Mac OS X and Windows systems. The current Web-based Slingplayer for Mac and PC is a 32-bit browser plug-in and will therefore no longer be supported in the Chrome browser with this upgrade.

[i7x]

Heb ik ook mee te maken. Ik gebruik daarom IE voor Sling. De rede dat ze zo graag die api willen gebruiken heeft overigens te maken met drm-zaken. Op zich zouden ze zo'n player makkelijk in html5 kunnen maken, maar dan krijgen ze dus gezeur van rechthebbende. Echt lang zullen ze dit niet vol kunnen houden. Miljoenen mensen gebruiken Chrome, dus ze zullen met een oplossing moeten komen. Bijkomen voordeel is, hoop ik, dat de player ook meteen een stuk stabieler zal worden. Dat is nu echt een drama.

[Skagerak]

Dit maakt mogelijk de weg vrij voor een (automatische )update van de 32-bit naar 64-bitversie van Chrome. Op dit moment is deze natuurlijk wel al los te installeren, maar het is wel wat vreemd dat deze overgang niet automatisch gaat. Eén reden daarvoor was dat de Nescape plugins niet werken op de x64versie. Wanneer deze plugins op de 32-bitversie zijn uitgefaseerd zou een dergelijke update wel kunnen.

[_Thanatos_]

Met de nieuwe(?) API kun je natuurlijk nog steeds 32-bits plugins hebben, die dan uiteraard niet werken in een 64-bits hostapplicatie.

[Megamind]

Helaas is in Chrome 39 Silverlight al uitgeschakeld. Zo werkt NLZIET niet meer in Chrome.

[Allard Pruim]

Dit betreft natuurlijk de Windows en Mac OS X versie. De Linux versie heeft al een lange tijd geen ondersteuning meer voor NPAPI.

[HetIsNiels]

Handig voor mensen met het wel bekende Magister

Edit: Meteen 3 reacties over Magister 6, oeps.

[Reactie gewijzigd door HetIsNiels op 23 juli 2024 19:02]

[hherrie]

Gelukkig is er (voor leerlingen althans) Magister 6, dat geen Silverlight nodig heeft.

[Juzzby]

Gelukkig werkt dat zo mogelijk nog slechter dan het oude magister.

Zo bestaat er geen native Android app meer, dus als je wifi wegvalt is het ook meteen gedaan met je rooster checken (:

En bestanden openen die erin staan opgeslagen is ook een onmogelijke opgave. Nergens een download knop te vinden...

[sypie]

Maar dat gaat niet lang meer duren. Voor veel leerlingen is Magister 6 al beschikbaar, alleen voor personeel nog niet (vanwege allerlei functies die nog niet gefixt zijn).

[Annoying-Orange]

Hoeft niet uit te maken, omdat magister 6 geen gebruik meer maakt van silverlight.

[FreshMaker]

Nee, maar een irritante webpagina is, die nog eens onhandig op de mobieltje werkt.

De oude app was een stukje handiger in gebruik imo

[Annoying-Orange]

Ik vind de mobiele versie niet onhandig werken, misschien niet handiger dan een app, maar ik kan nu eindelijk mijn cijfers bekijken op mijn Windows Phone . Volgens mij wordt de app nog wel ondersteund bij ons.

[JoepVK]

Bij mij op school wil de ICT geen Magister 6.

[hherrie]

Op een gegeven moment zullen ze wel moeten denk ik, omdat Magister 5 dan niet meer wordt ondersteund.
Maar wellicht is het beter om het hier verder niet over Magister te hebben. Althans, het lijkt mij een beetje off topic...

[_Thanatos_]

Google gaat echter de whitelist vanaf januari standaard uitschakelen, meldt het bedrijf in een blogpost.

Geen probleem dus. Installer aanpassen en klaar.

De whitelist uitschakelen is niet de whitelist verwijderen en wegslopen. Voor de installer van een plugin moet het een koud kunstje zijn om een vlaggetje in Chrome weer aan te zetten en net als zo'n IT-admin een whitelist-entry toevoegen.

[Cerius]

Netscape?

What year is it?!

- on topic: Zal vast wel iemand een addon voor schrijven mocht het echt nodig zijn, kan me echter niet voorstellen waarvoor het nodig zou zijn..?