Oracle opfordrer udviklere til at udfase arbejde med Java-plugins

Jeg programmerer ikke selv, så jeg er lidt nysgerrig over hvorfor et så udbredt format skrottes.

Er det pga sikkerhed og at der er kommet nye og bedre effektive værkøjer til browserne?

Eller der det noget helt tredige?

Hvad er alternativerne? Andet plugin format? Har HTML5 og .NET osv overtaget pladsen for plugins? Hvad er alternativet hvis plugins ikke længere understøttes? Der må være flere måder at programmere et plugin på - eller det der minder om det - vil jeg gætte på, for ad-blockers står en kende stærkt på den platform (lidt som om det er dem der holder plugins populære) :D

Så vil det vel snart betyde at nets måske får sig taget samme og for lavet nemid om til erhverv (nøglefil), da så er IE den eneste tilbage der kan klarer det. Såfremt jeg ikke lige har glemt en anden browser der tillader java plugin på denne måde. :D

#2 Nøglefilen var netop det man ville væk fra, da de var nemme for scammere at få fat i :-D

#1
NemID var oprindeligt et Java-plugin. Det er nu et JavaScript-plugin.

Grundlæggende kan Java ikke mange ting, som JavaScript ikke kan - udover at udstille computeren for hackere.

Java-plugins er i øvrigt ikke meget udbredt, bedst eksemplificeret i at det kun er Firefox som stadig understøtter dem.

#1
Grunden til at man gerne vil af med disse plugins, er at de er for nemme at udnytte til at give uønsket adgang til brugernes harddisk med fulde læse, skrive og evt. slette-rettigheder.

Ideen med dem var god, da de blev lavet.. som indholds-udbyder fik man jo pludselig direkte adgang til computerens ressourcer på samme niveau som alle andre programmer på computeren. Dvs. man kunne køre video, lyd og endda 3D direkte fra grafikkortet, ubegrænset adgang til pc'ens RAM og mulighed for at gemme dokumenter mm. på computeren til online dokument håndteringsprogrammer el. lign.

Desværre gav det også mulighed for ondsindede at få adgang til alt på din computer.
Selvom man forsøgte og stadig forsøger at begrænse det, så er det alt for nemt at tilgå brugernes computer gennem disse plugins.

Grunden til der bl.a. er så mange opdateringer til Adobe Flash og Oracle Java, er netop fordi de prøver at lukke alle kendte huller i deres programmer, så det gør det sværre at få adgang til brugernes computere.

Som du kommer ind på, så er der nu alternativer gennem HTML5 standarden - for det meste i hvert fald.
I stedet for mange af disse plugins, er der udviklet mere sikre standardiserede browser-indbyggede features, der kan kobles sammen. Herunder video og lyd afspilning, der tidligere kun var mulighed med flash eller anden medie-afspiller plugins (ja tænk bare.. det var kun muligt at vise tekst og billeder en gang!)
En lidt sjov ting man kan kigge på: https://whatwebcando.today

Adgang til grafikkortet, til f.eks. spil eller hæftige matematiske beregninger er også muligt, dog pt. stadig i et tidligt stadie, der er under fortsat udvikling af "canvas" og "WebGL".

.NET er ikke en browser teknologi, men bruges i hjemmeside-regi på serverne til at styre hvilke data der leveres til brugeren, holder øje med at man er logget ind, gemmer data i databasen, når man gemmer et indlæg og meget meget mere. Det er det lag man ikke ser, men som gør at hjemmesider reelt kan levere indholdet - der er også andre teknologier, der kan gøre det samme, php, Java (her er det sikkert at bruge!) og ja, mange andre.


Sikkerheden er også flyttet ud i browseren med sikkerhedscertifikater, hvor det i de tidlige dage kun var gennem Java at man fik en ordentlig kryptering - dette var bl.a. NemID's grund til at bruge Java i stedet for en "Javascript" løsning, som de kalder det, som andre kommentarer også kommer ind på..
Men NemIds grundlag var så helt forskruet, for da NemID blev udviklet for ganske få år siden, havde alle browserne fuld understøttelse for sikkerhedscertifikater og det var allerede i alle medier at Java-plugins blev udfaset i browserne, så det var bare en meget dårlig undskyldning for at lave noget meget kompliceret, man vidste der skulle laves om allerede få år efter, i stedet for at bruge browsernes egen teknologi fra starten. Men jeg er sikker på at dem der har udviklet det - TDC og PBS, dog trak TDC sig ud inden lancering - klapper i hænderne over alle de penge, som de kan skrabe ind 2 gange i stedet for kun den første gang.

Man skulle næsten tro at det var KMD eller CSC, men hvad pokker, flere kan kopiere deres forretnings-model åbenbart.


Hmm.. Det blev lidt langt, men der var meget der skulle siges, håber det kan bruges :-)

Java-udviklere bliver derfor nødt til at finde alternativer hurtigt, hvis de gerne fortsat vil udvikle plugins til Firefox.

Skal vi lige få lidt terminologi på plads:

plugin framework = framework som gør det muligt at lave plugins til en bestemt browser, udvikles af browser udviklere, eksempler: ActiveX (IE), NPAPI (FireFox etc.)

plugin = komponent som gør det muligt at håndtere et bestemt indhold, udvikles af indsholds format udviklere, eksempler: Oracle Java plugin til Java applets, Adobe FlashPlayer til flash, udvikles af

indhold: udvikles af web udviklere som led i udvikling af web applikation

Så:

Mozilla dropper NPAPI plugin framework i fremtidige FireFox versioner.

Oracle beholder Java plugin men har deprecated brugen af det (det er de tvunget til når der ikke er nogen browsere som understøtter de nødvendige plugin framworks længere)

Diverse Java applet web udviklere skal finde en ny teknologi til deres indhold.

Hærmoriden (1) skrev:

Jeg programmerer ikke selv, så jeg er lidt nysgerrig over hvorfor et så udbredt format skrottes.

Java applets er ikke udbredt.

De var udbredt sidst i 90'erne og først i 00'erne. Men det er ved at være en del år siden.

Hærmoriden (1) skrev:

Hvad er alternativerne? Andet plugin format? Har HTML5 og .NET osv overtaget pladsen for plugins? Hvad er alternativet hvis plugins ikke længere understøttes?

Det var Flash som udkonkurerrede Java applets.

Nu er Flash ved at blive udkonkurret af "HTML 5".

SilverLight (.NET) var inde på markedet i en kortere år række, men MS satsede på "HTML 5".

dk_picard (2) skrev:

Så vil det vel snart betyde at nets måske får sig taget samme og for lavet nemid om til erhverv (nøglefil)

gramps2 (4) skrev:

NemID var oprindeligt et Java-plugin. Det er nu et JavaScript-plugin.

Har de også fået erhversvsløsningen over på JavaScript??

SwineDK (5) skrev:

I stedet for mange af disse plugins, er der udviklet mere sikre standardiserede browser-indbyggede features,

Jeg har svært ved at se hvorfor det at JavaScript er indbygget i browseren skulle gøre det mere sikkert.

Men man kan formode at JavaScript engine er mere sikker end JavaScript engine + Java plugin + Flash plugin.

SwineDK (5) skrev:

.NET er ikke en browser teknologi

SilverLight er en browser teknoligi og er/var en del af .NET.

arne_v (9) skrev:

SwineDK (5) skrev:

I stedet for mange af disse plugins, er der udviklet mere sikre standardiserede browser-indbyggede features,

Jeg har svært ved at se hvorfor det at JavaScript er indbygget i browseren skulle gøre det mere sikkert.

Men man kan formode at JavaScript engine er mere sikker end JavaScript engine + Java plugin + Flash plugin.

Den ene del er at Javascript har meget begrænset adgang til filsystemet på en brugers computer. Der er kun adgang via browserens egen filhåndtering, der kun kan aktiveres af brugeren, det er i hvert fald tanken bagved sikkerheden - der har været situationer, hvor denne del har været problematisk for nogle browsere.

I modsætning kan et aktivt Java (eller anden type) plugin, uden at spørge brugeren, åbne, læse og skrive filer på filsystemet, kopiere alt hvad brugeren har på computeren og sende det til en webserver uden at brugeren ved det.
Dette er bl.a. Hvorfor man i lang tid har skulle "acceptere" at et plugin blev aktiveret på hjemmesiden.


Der har der været op til den enkelte plugin producent (Microsoft, Oracle, Adobe, unity mm.) at begrænse adgangen for de udviklere, der så kan udvikle applets (i mangel af bedre ord) til disse plugins.

Sikkerheden ligger også i brugen af sikkerhedscertifikater og krypteret kommunikation mellem browser og server. Med dette er man (næsten) garanteret at ingen lytter med på linjen.


Men hensyn til #10 - omkring .NET og c#, er det korrekt at silverlight "køres" i browseren, men det er ikke en browser teknologi. Det er et plugin, der reelt er installeret på computeren ved siden af browseren og er helt adskilt fra browseren, dog med tilladelse til at vise indhold på et bestemt område af hjemmesiden gennem dette npapi (Netscape Plugin Application Programming Interface).

Men systemet er jo også over 20 år gammelt og fra en mere naiv tidsalder, hvor ondsindede udviklere nærmest var et ukendt fænomen. Det er det ikke længere ☺️

SwineDK (11) skrev:

I modsætning kan et aktivt Java (eller anden type) plugin, uden at spørge brugeren, åbne, læse og skrive filer på filsystemet, kopiere alt hvad brugeren har på computeren og sende det til en webserver uden at brugeren ved det.

Kun i tilfælde af fejl i implementationen.

De kører sandboxed.

Den traditionelle Java applet sikkerhed er:

unsigned applet => ingen adgang til fil system

signed applet *og* godkendt af brugeren => adgang

SwineDK (11) skrev:

Men hensyn til #10 - omkring .NET og c#, er det korrekt at silverlight "køres" i browseren, men det er ikke en browser teknologi. Det er et plugin, der reelt er installeret på computeren ved siden af browseren og er helt adskilt fra browseren, dog med tilladelse til at vise indhold på et bestemt område af hjemmesiden

Hvilket er præcist det samme som Java applets gør.

SwineDK (11) skrev:

gennem dette npapi (Netscape Plugin Application Programming Interface).

For browsere som bruger NPAPI. IE bruger ActiveX.

#12, jeg kan på ingen måde modsige dig, kun give dig ret i at det hele har med implementering af de enkelte plugins at gøre. Det hele afhænger udelukkende af hvordan plugin producenten har udviklet deres plugin, uanset om det er bygget på NPAPI eller ActiveX api / framework. Man kan endda argumentere for at det er api'et/frameworket der er problemet. Hvilket browser producenterne i nærmest fællesskab netop har konkluderet og derfor fjerner fuldstændigt.

Og med hensyn til silverlight og Java plugins, så er du helt spot on. Det er begge plugins og jeg beklager at jeg ikke fik tydeliggjort det mere. Jeg tror bare jeg selv ville skære dem alle over en kam, da jeg nævnte det som "plugin" i den sammenhæng, men kan godt se at det kan misforstås til at det kun var silverlight, der var et plugin i den sætning.. Det gælder alle plugins, herunder flash, Java, Unity Web player, VLC video player, MS media player og mange mange flere. Uanset hvilket framework de er udviklet til, så er det reelt et ekstra program man installerer og kører ved siden af browseren, selvom det ikke er synliggjort overfor brugeren at det fungerer sådan. Browseren tænder automatisk for programmet, når der er brug for det.

Så jeg tror at vi er enige om at det er en god ting at lukke for adgangen, uanset hvor tæt på kilden dette foregår.

#6

Mange tak for din feedback arne_v. Jeg har ændret i indholdet på nyheden så terminologien gerne skulle passe. Som du så, havde jeg rodet rundt i forholdet mellem et plugin og et framework til et plugin.

SwineDK (11) skrev:

Men systemet er jo også over 20 år gammelt og fra en mere naiv tidsalder, hvor ondsindede udviklere nærmest var et ukendt fænomen. Det er det ikke længere ☺️

Det vil jeg nu ikke sige :)

Går vi 20 år tilbage i tiden til 1997, så var der stadig udviklet meget virus og skidt og møg. Bare tænk på hvor let det var at få virus på en Amiga ?

Amiga'en var plaget af virus næsten fra sin fødsel i 1985 til sin død i 1994 og er det fortsat (dog i mindre grad) i sin nuværende genoplivede Zombie tilstand (Den er det eneste eksempel på et omvandrende lig, aka en zombie, i IT verdenen. Der kan fx. stadig købes helt nyt udstyr til en Amiga fra 1985).

#15, Du har helt ret. Der var masser af fortilfælde med virus mm. på stort set alle platforme.
Men udbredelsen foregik på en lidt anden måde. Her krævede det for det meste at man manuelt anskaffede en fil, enten via en disk eller downloadede filen og selv aktiverede virussen.

At udnytte selve browseren og tilknyttede programmer (plugins) til at foretage ondsindede handlinger, installere bagdøre, virus mm., helt uden brugeren blev informeret om en evt. installation, var ikke så udbredt på dette tidspunkt.
Bestemt, det fandtes - men det var ikke rigtigt før browserne introducerede disse plugin API / Frameworks at det tog til.

Og intet ondt om Amiga, det var/er en fantastisk maskine. Men at få virussen ind på den krævede stadig at man fysisk selv introducerede virussen på en disk (dengang i hvert fald).
Oftest var det fordi man anskaffede spil/programmer fra andet end butikshylderne - f.eks. gennem venner, loppemarkeder og andet.

Men efter lidt tid med at browsere blev introduceret med plugin-muligheder, ændrede dette sig til at man bare skulle besøge en forkert hjemmeside. Man behøvede ikke at gøre noget, men bare gå derind og gå ud igen, så var den ondsindede kode allerede kørt.

Man kæmpede bravt for at holde plugin systemerne i live ved at komme med sikkerhedsopdateringer løbende, men man er kommet frem til at det vist ikke længere er det værd. Sikkerhed og stabilitet bliver påvirket på enten godt eller ondt hver gang de lancerer en ny version med flere features eller løser tidligere sikkerhedsproblemer mm.

Så jeg ser det som en positiv ting at det bliver fjernet fra browserne. Stort set samme funktionalitet kan tilgås gennem browserens indbyggede features uden at man er afhængig af et eksternt plugin.
Det kræver så selvfølgelig at browseren er sikker :-)
Det sker jo en gang i mellem at nogen finder måder at komme ud af disse sandkasse-miljøer, som browser-producenterne ellers er så stolte af.

Men det er vist at gå off topic :-)

#16: jeg er enig i at det er fornuftigt at man vil forsøge at begrænse de muligheder der kan være i at misbruge browser plugins :-)

Og ja, dengang krævede det at man blev udsat for en floppydisk der allerede VAR inficeret :-)

CBM (15) skrev:

Går vi 20 år tilbage i tiden til 1997, så var der stadig udviklet meget virus og skidt og møg.

Og endnu tidligere.

https://en.wikipedia.org/wiki/Morris_worm

https://en.wikipedia.org/wiki/WANK_(computer_worm)