Java-blokkade Firefox veroorzaakt storm van kritiek
De beslissing van Mozilla om de Java browserplug-in standaard in Firefox te blokkeren, waaronder ook de meest recente versie, heeft voor een storm van kritiek gezorgd. Gebruikers die op een website komen die een Java-applet bevat krijgen een waarschuwing te zien dat de Java-plug-in is geblokkeerd.
Het is mogelijk om de browserplug-in in te schakelen, maar dat bleek niet in alle gevallen goed te werken. "Dit is echt vervelend. Wat is de volgende stap, voorkomen dat mensen Java installeren?", aldus gebruiker 'Henk' op Bugzilla. Op deze website kunnen gebruikers allerlei bugs en problemen in Mozilla-producten rapporteren.
Ook een andere gebruiker begrijpt niet waarom Java opeens geblokkeerd wordt. "Zijn jullie helemaal gek geworden?". Weer iemand anders laat weten dat hij niet meer bij zijn bank kan inloggen.
Gebruikers
De meeste websites gebruiken geen Java meer, niet te verwarren met JavaScript dat op de meeste websites actief is. Bedrijfsapplicaties en spelletjeswebsites maken echter wel gebruik van de technologie en door de blokkade krijgen deze partijen opeens met ontevreden gebruikers te maken. Spelletjesplatform Pogo ontving na de nieuwste Java-update en blokkade van Firefox meer dan honderd reacties van boze spelers die opeens niet meer konden spelen. De boosdoener bleek in veel gevallen Firefox te zijn.
Aan de discussie op Bugzilla namen ook verschillende Oracle-werknemers deel, waaronder Donald Smith van het Java SE Product Management team. Hij stelt dat Oracle vaak contact met Mozilla heeft en zich ook gaat richten op de problemen rond Java 6. De Windows-versie van Oracle 6 voor consumenten wordt namelijk niet meer ondersteund, maar voor bedrijven met speciale onderhoudscontracten verschijnen nog wel updates. Mozilla wil echter alle Java 6-versies blokkeren.
Interface
Vanwege de storm van kritiek heeft Mozilla gisterenavond besloten om de blokkade terug te draaien. Bij de meeste systemen zal het één a twee dagen duren voordat de Firefox-blocklist is bijgewerkt en Java-applets weer standaard werken. Het gaat hier echter om een tijdelijke maatregel. Zodra de interface voor Click to Play is verbeterd zal Firefox Java weer gaan blokkeren, zegt Firefox-ontwikkelaar Benjamin Smedberg.
Click to Play is de technologie waardoor browserplug-ins worden geblokkeerd en via een extra muisklik zijn te activeren. Op dit moment zou de interface nog niet intuïtief genoeg zijn. Google Chrome blokkeert Java standaard ook, maar volgens verschillende critici is de interface van Chrome voor het inschakelen van de Java browserplug-in beter dan die van Firefox.
De taal op zich is niet slecht, maar lijkt sowieso sterk op C++ en C# zodat het overstappen op alternatieven goed mogelijk is. Maar eigenlijk is het tijd dat andere fabrikanten ook de nodige Java VM's en compilers gaan ontwikkelen zodat we een keuze hebben tussen Oracle of een betere omgeving...
De taal op zich is niet slecht, maar lijkt sowieso sterk op C++ en C# zodat het overstappen op alternatieven goed mogelijk is.
Alleen zijn C++ en C# gecompileerd naar executables die afhankelijk zijn van het platform waarop ze draaien. Dat is voor b.v. websites niet handig, want dan moeten ze veel varianten voor download hebben. Bij Java installeer je op je platform eigenlijk een interpreter en die voert e.e.a. dan uit. Als website bouwer hoef je dan niet zo na te denken. Dit maakt het ook zo aantrekkelijk voor kwaadwillenden.
Ik was ook behoorlijk verrast toen ik opeens een melding kreeg dat Java geblokkeerd was omdat deze onveilig zou zijn en ik geen update kon vinden. Het was pas mogelijk om uit te vinden wat er aan de hand was door op het plugin-legosteentje naast de adresbalk te klikken, naar "meer informatie" (o.i.d.) te gaan, een pagina te zien dat de plugin geblokkeerd is omdat 'ie onveilig is en pas door daar door te klikken naar de bugmelding kon ik zien dat Java alleen voor de zekerheid geblokkeerd was.
Nu is het blokkeren van Java geen slecht idee en bij Google Chrome pakt het goed uit, maar Firefox maakt geen onderscheid tussen "onveilig want verouderd met bekende lekken" en "onveilig want beveiliging voldoet niet aan de normen van vandaag, hoewel de software up-to-date is en er geen bekende lekken in zitten". Als je Java gaat blokkeren, zorg dan dat er geen verwarring ontstaat bij gebruikers. Nu loop je het risico dat gebruikers die écht een verouderde Java draaien denken dat dit komt door deze algehele Java-blokkade en dat ze zich dus geen zorgen hoeven te maken - en daardoor op een dag worden gehackt.
Alle zogenaamd oudere java versies blokkeren is alleen prima als ze dat zorgvuldig doen.
Java 6 voor Mac OS X heeft nog steeds security support van Apple, die fout of misvatting maken meer en meer bedrijven / websites (gebrek aan kennis of desinteresse?).
Klopt, daar wordt door Mozilla op dit moment aan gewerkt. De volgorde is natuurlijk wel verkeerd.
Ik draag al een aantal jaar bij aan een open source project in Objective C en juist het geheugenbeheer vraagt veel discipline of je krijgt lastig te traceren crashes. Ik ken Java niet als taal, maar zonder expliciet geheugenbeer lijkt het volgens mij dan meer op JavaScript, waar je ook niet aan geheugenbeheer hoeft te denken.
IBM maakt al meer dan 10 jaar een eigen JVM. En de Oracle JVM is tegenwoordig een herverpakking van de OpenJDK, dus ga je gang....
Dat is inderderdaad de normale gang van zaken. Wat niet wegneemt dat het een keuze is -- de GNU bijvoorbeeld maakt al jaren een native Java compiler. Vraag me niet waarom, maar ze doen het wel.
Voor C/C++/Objective-C was toch ook een bibliotheek voor memory management? Boehm of iets dergelijks?
Ja op zich is dat verbazingwekkend. Je maakt je hiermee wel extreem kwetsbaar. Je applicatie (ik verwijs daarbij
zowel naar de maker als de gebruiker) draait op een platform wat een moving target is. Je moet voortdurend op je
hoede zijn en opletten wat Oracle (vroeger Sun) nou weer doet. Vooral de laatste tijd.
Dat lijkt me toch niet zo fijn. Ik zou liever een wat stabieler platform kiezen als ik iets ging ontwikkelen.
We gebruiken op het werk een applicatie die via browser in java draait (alleen gebruikt door 3 man gelukkig) en na
de Java update zijn er ineens problemen. Dit blijkt puur door laksheid van de ontwikkelaars te komen, maar je moet
dan toch maar weer aan de slag om het te melden, te laten uitzoeken, en er omheen te werken met een lelijke fix.
Dat is toch niet fijn, zeker niet voor een bedrijfsapplicatie.
En dan gebruiken we nog niet eens Firefox...
hoede zijn en opletten wat Oracle (vroeger Sun) nou weer doet. Vooral de laatste tijd.
Dat lijkt me toch niet zo fijn. Ik zou liever een wat stabieler platform kiezen als ik iets ging ontwikkelen.
Excuseer? Ja, er wordt doorontwikkeld aan het Java platform. Maar die doorontwikkeling is backward compatible. Bij mijn weten heeft Sun ooit één ding gedaan dat backward compatibility zou kunnen breken (weghalen van ondersteuning voor hun eigen audio formaat) en dat was geheel theoretisch omdat geen kip het ooit gebruikte.
Sorry hoor, maar als je Java instabiel vindt, dan is stabiliteit toch echt alleen maar voorbehouden aan talen als COBOL, Algol60 en PL/I en platformen als de Electrologica machines....
dan toch maar weer aan de slag om het te melden, te laten uitzoeken, en er omheen te werken met een lelijke fix.
Dat is toch niet fijn, zeker niet voor een bedrijfsapplicatie.
Mja, je zegt het zelf al: slechte programmeur, slechte software.
Bij het bedrijf waar ik nu werk draait vrijwel alles op Java EE en is erg stabiel.
Het populairste platform krijgt de meeste aandacht van hackers...
In dat licht, als eigen baas beslissend over de inzet en toepassingen van Java, zeggen je bijdragen meer over je individuele afhankelijkheid ervan dan over de daadwerkelijke kwaliteit en populariteit van het Java platform.
Wel zo eerlijk voor de lezer hier dat kader weer eens mee te geven en wat vaker te herhalen.
Geposte argumenten ter ondersteuning van de populariteit van Java vind ik helaas zelden inzichtelijk en overtuigend, de schrijver van onderstaand link artikel doet dat stukken beter.
http://computerworld.nl/software/79788-12-redenen-waarom-java-een-blijvertje-is
Voortaan bovenstaand linkje posten?
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?