Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 164 reacties, 56.594 views •

Apple heeft de Java-plug-in op OS X geblokkeerd nadat er een beveiligingslek is ontdekt. De software van Oracle staat op een blacklist en wordt waarschijnlijk pas gedeblokkeerd als het beveiligingslek door Oracle is verholpen.

Dat ontdekte Macrumors, die een verwijzing naar de blokkade van de Java-plug-in vond in het Xprotect.plist-bestand. Daarin wordt een Java-versie vereist die nog niet bestaat, waardoor effectief bestaande Java-plug-ins worden geblokkeerd. Apple voerde de blokkade door via een update van het Xprotect.plist-bestand, iets dat werkt voor gebruikers van Mac OS X versie 10.6 en hoger. Bij oudere versies kan Java alleen handmatig worden gedeïnstalleerd.

Hoewel er geen officiële verklaring is uitgegeven, is het aannemelijk dat de blokkade is doorgevoerd nadat er een beveiligingslek is ontdekt in Java. Die stelt kwaadwillenden in staat om via een exploit ongemerkt software te installeren op de computer van de gebruiker. Eerder kwam al naar buiten dat het lek misschien al wordt misbruikt. Eerder verwijderde Apple al de plug-ins voor Java uit zijn browser, waardoor deze niet meer standaard staat geïnstalleerd. Ook maakt Java sinds versie 10.7 geen deel meer uit van OS X.

Naar aanleiding van de ontdekking van het beveiligingslek in Java heeft de Amerikaanse overheid geadviseerd om geen Java meer te gebruiken. De overheidsinstantie US-CERT raadt, evenals onder andere de Nederlandse overheid, gebruikers aan om de bewuste plug-ins in hun browsers uit te schakelen.

Java-blacklist Apple

Reacties (164)

Reactiefilter:-11640159+1120+216+31
Moderatie-faq Wijzig weergave
waarom krijg ik het gevoel dat java de zelfde richting gaat als flash op de iphone( uit eindelijk geband woord)?
vroeger kwamen ze toch ook in het nieuws dat java een lek had en het duurde maanden tot die gefixt was, en die java werd ook niet uitgeschakkeld.
ik denk dat apple gewoon probeeren de zelfde richting te gaan als met de iphone met zulke acties.
stel je voor dat morgen een ernstige lek zit in itunes woord die dan ook uitgeschakeld op de windows en apple computers?
Flash en Java staan compleet los van elkaar. Flash hebben ze geweerd uit iOS omdat dit te batterij- en processorintensief zou zijn, heeft dus totaal niets te maken met een beveiligingslek ofzo.

Java update trouwens maar eens in de zoveel maanden, omdat ontwikkelaars de tijd moeten hebben hun programma's aan te passen op het nieuwe Java. Ik vind dit een zeer stomme regeling en Java moet gewoon updates uitbrengen als dat echt nodig is, dan kunnen ontwikkelaars daarna wel aan de slag met hun eigen programma's.

P.S. Volgende keer een goed idee om je bericht even over te lezen voordat je post? Er staan zoveel fouten in, waaronder ook fouten die door Chrome en Firefox een rood kringeltje krijgen en je dus makkelijk kan zien dat ze fout zijn.
Gezien mijn bank Java gebruikt om in te loggen, ging ik toch maar even kijken over het hoe en wat. Toen kreeg ik deze melding te zien. Wat ik me nu dus afvraag: Moet ik wel updaten na het lezen van dit artikel?

Toch wel schokkend dat zo'n groot "programma" als Java zo'n groot beveiligingslek heeft dat het veiliger is om het gewoon op alle computers uit te schakelen.
Het maakt niet uit of je update of niet omdat zelfs de nieuwste update van de java website geblokkeerd word.
Hierdoor krijg je dezelfde melding. (Ik heb het zojuist getest op mijn eigen mac)
weet iemand hoe ik java terug kan activeren? Mijn ma heeft het namelijk nodig voor citrix
Scroll even door de reacties heen:

Cheap Apps in 'nieuws: Apple blokkeert Java op Mac OS X'

Herko_ter_Horst in 'nieuws: Apple blokkeert Java op Mac OS X'

OkselFris in 'nieuws: Apple blokkeert Java op Mac OS X'

Wat betreft het nieuws, hier iets meer dan alleen wat Apple er mee doet:
http://www.reuters.com/ar...ity-idUSBRE90A0S320130111

De grootste reden voor mij om Java compleet te disablen, is de aanhoudende onwillendheid om te reageren op dit soort security issues door Oracle en co.

[Reactie gewijzigd door rotterdams op 12 januari 2013 14:46]

ChromeOS ondersteunt java on deze reden uberhaupt niet, en wie mist dat tegenwoordig nog? De meeste applets hebben wel een alternatief. Ik heb het in anderhalf jaar ChromeOS nog niet gemist in elk geval.

Ik zou zeggen: uitlaten.
ChromeOS wordt in het enterprise segment niet gebruikt om die reden. Want daar kom je dus wel heel veel Java tegen. Maar je hebt ietswat gelijk, consumenten gebruiken de Java plugin zelden nog, en Java is veelal een server based verhaal geworden.
Goed dat het kan - maar hoe komt het dat de gebruikers dat niet zelf kunnen opheffen indien nodig/nuttig/wenselijk?
Apple = een totalitair bedrijf - een bedrijf waarvan je de hard en software eigenlijk in een bedrijf niet kan inzetten.
Stel dat uw VPN-oplossing werkt met Java dan ben je door die setting van Apple gef*ck*d.

Het bewijst het nogmaals - geen enkel bedrijf is te vertrouwen als het er op aan komt moet de staat deze zaken "strak regelen".
Ik denk dat je het prima kunt opheffen, door dat versienummer weer te veranderen.
wat doen mensen die minecraft ofzo willen spelen op hun mac?
Getest en werkt gewoon. Ik weet niet hoe het precies zit, maar zal iets te maken hebben met het feit dat Javascript IN het programma zit ofzo?
Javascript IS GEEN java. Het gaat hier om java iets dat sommige webapplicaties en ook minecraft gebruiken (en nog veel meer apparaten). Ik weet niet zeker hoe het zit maar volgens mij gaat het hier vooral om de safari plugin die geblokkeert is. Java programmas die dus zonder browser gebruikt worden zouden dan geen last hebben van de blokkade, minecraft hoort bij de programmas die zonder browser draaien.

Ik heb geen mac (os) om dit te testen en controleren en dat zal voorlopig ook zo blijven. Dit is namelijk een van de vele redenen om geen apple te willen als computer. Ik wil nog altijd wel even zelf bepalen wat ik kan mag en doe op mijn pc. Of er nou een beveiligingsprobleem is of niet. Apple schijnt daar altijd problemen mee te hebben en wilt dat graag zelf bepalen voor de consument. Als het nu alleen een waarschuwing was geweest en de klant de keus kreeg om java te blokkeren of niet dan was het goed van ze maar ze schieten te ver door.
OpenJDK is een open source project, is de bug al gefixed of alleen de officiele Oracle release nog niet?

Maar Java heeft idd niet zoveel zin meer als browser plugin, wie gebruikt er nog applets anno 2013? Laat Java lekker serverside, daar is het goed in.

[Reactie gewijzigd door Dreamvoid op 12 januari 2013 12:22]

Ik vermoed dat de bug met de Java plug-in/VM zelf te maken heeft, dus ik verwacht dan ook dat OpenJDK mogelijk wel veilig is (tenzij OpenJDK er zelf ook op deze manier mee om gaat, waardoor ze allebei onveilig zijn). Even googlen op een eventuele update hierover voor OpenJDK zou ik zeggen ;)

EDIT: foutje verbeterd wat Dreamvoid onder mij noemde

[Reactie gewijzigd door Cheap Apps op 12 januari 2013 12:31]

'De Java applet' bestaan niet, er zijn duizenden applets op het web.
Waarom niet gewoon auto execute van java applets afzetten? Dan heeft de gebruiker zelf de keuze en als hij/zij een applet wilt gebruiken gewoon een melding geven van: "dit kan mogelijk onveilig zijn vertrouwd u de maker van deze applet?". Gebruiksvriendelijk en zonder dat mensen zonder technologische achtergrond zich gaan afvragen waarom bv hun bank applet niet meer werkt.
De vraag is dan wel waar dat eindigt: moet je dan ook bij elk blokje Flash, Silverlight of Javascript code een popup tonen? Dan kom je niet meer aan browsen toe, bijna geen enkele site draait meer op puur statische HTML.

[Reactie gewijzigd door Dreamvoid op 12 januari 2013 13:10]

Daarbij het gros van de users klikt toch wel ok...
Ja maar het lijkt mij een betere manier dan het gewoon uit te zetten. Moet er niet iets in de configfile worden aangepast als je snel 1 applet wil gebruiken. Ik doelde ook meer op een klik to activate systeem.
Bijzonder. Ook vreemd dat Apple hier geen bericht van maakt, terwijl het toch wel wat is om Java af te sluiten voor je gebruikers.
Dit is idd wel een lastige zaak. gaat Apple in de toekomst ook bij elke Chrome of Firefox exploit de 3rd party browsers blokkeren?
Je moet het natuurlijk wel een beetje in perspectief zien. Het gaat hier om de ernst van de lek en of deze al actief wordt misbruikt. Bij deze Java exploit is dat het geval.
Tevens is denk ik de impact minder groot vele mensen die Java ge´nstalleerd hebben staan, zijn er niet eens bewust van dat er een browser plugin ge´nstalleerd is en dat deze aan staat. De grote groep zal er ook geen gebruik van maken.
Neemt niet weg dat dit iets is wat men beperken communiceren, maarja hoe?
Uitschakelen van apps is van heel andere orde, die worden waarschijnlijk bewust en actief gebruikt.
Het blijft moeilijk, waar ligt de grens.
Er zijn bakken met exploita voor oude Firefox versies, maar toch mag je die gewoon nog draaien. Maar goed, aangezien Apple zelf medeverantwoordelijk is voor lekken in Java (ze zijn mede-ontwikkelaar) is het begrijpelijk dat ze wat actiever actie ondernemen dan bij pure 3rd party software.
Apple ontwikkelde eerst inderdaad een eigen JRE voor OSX (welke bij default werd meegeleverd). Maar dat is sinds Lion oid niet meer het geval. Nu moet een persoon zelf dus eerst Java installeren en downloaden bij Oracle weg voordat de persoon Java heeft.
Apple ontwikkelt nog steeds aan de JRE, ze zijn lid van het OpenJDK project en werken onder supervisie van Oracle aan de OSX versie van Java.
Java wordt dan ook niet afgesloten, de browser plug-in wordt uitgeschakeld.
Da's toch kwalijk. Een boel sites gebruiken Java..
Op een bedrijfsintranet misschien maar in de praktijk komt het voor gewone gebruikers nauwelijks meer voor.
Java applets zijn ook niet meer van deze tijd, het heeft praktisch alle nadelen van Flash maar werkt VEEL slechter. Het is een plugin, maar werkt vaak maar in 1 browser, en 9 van de 10 keer laden de applets helemaal niet. Java is voor de desktop, niet voor het web.
Java op zich is een enorm fijne en krachtige programmeertaal (kwaliteit en snelheid is ongeveer hetzelfde als .NET applicaties). Het is alleen jammer dat het vaak in slecht licht komt door dit soort veiligheidslekken..
En het is niet meer dan terecht dat het zo vaak slecht in het nieuws komt. Ik loop inmiddels met een grote boog om Java heen en als ik een leverancier hoor welke een Java based applicatie uitbrengt dan gaan bij mij de nek haren overeind.
Het probleem is niet alleen de security, maar ook de compatibiliteit.
Veel bedrijven durfden geen Java updates uit te rollen uit vrees dat men een applicatie breekt.
Backwards compatibiliteit is zelfs bij minor updates niet gegarandeerd.
In potentie zal het allemaal best wel mooi en goed zijn. Praktijk leert dat het een zorgenkindje is.
We hebben het hier over de Java plugin die remote code draait, niet over lokale applicaties.
Met lokale Java applicaties is niets mis, ik (en het artikel ook) heb het over de web applets. Dat zijn onveilige rotdingen, het is net ActiveX.
Terecht dat Dreamvoid en jijzelf dit nog eens onderstrepen. Uit andere reacties in de draad blijkt dat meer gebruikers over deze "subtiliteit" heenstappen. Beseffende dat ik deze nuance ook miste ben ik even in een (stoffig) schoolbankje gekropen voor mijn eigen referentiekader (onder het mom van: "een Tweaker die zijn onkunde niet durft te erkennen is geen echte Tweaker":
Like applications, applets are created from classes. However, applets do not have a main method as an entry point, have several methods to control specific aspects of applet execution, and while applications run in the Java VM installed on a computer system, applets run in the Java VM installed in a web browser. You can also run an applet in a special tool for testing applets called applet viewer.
De werkelijkheid die ik uit het bovenstaande en de Wiki's voor Java applet en Java Virtual machine opbouw is dat zowel vanuit de Java plugin in de webbrowser, getriggerd door een Java applet in een webpage als vanuit de Java RuntimeEnvironment, getriggerd door een Java applicatie, een Java Virtual machine wordt gestart waarin de Java commando's worden uitgevoerd.

Om het ten aanzien van het bovenstaande een beetje aan te scherpen: de web applets geven de stoute opdrachten, maar het is de brouwser-plugin die de uitvoer toelaat. Wat mij betreft zijn de plugins in dit geval de onveilige rotdingen die de rottigheid van het internet zonder pardon uitvoeren.

Zo heeft ieder windows systeem minimaal twee Java implementaties, een voor de browser (plugin) en een voor het OS(JRE). Met een beetje pech komen daar nog een of meer toepassingsspecifieke JRE's bij met een verouderde versie time stamp als een soort safe haven. Ondanks alle rafels blijft Java als een van de weinige echt multiplatform van opzet. Dat dit een groot goed is blijkt wel uit het feit dat Microsoft dit gegeven met een .net implementatie op het Linux platform tracht te counteren. Los van dit ben het ook erg eens met de opmerking van Dreamvoid hierboven dat het actief maken van web pages een de brede zin van het woord de deur voor misbruik openzet. Misschien zijn actieve web pages toch een na´ef idee dat tegen de harde werkelijkheid van onze maatschappij aanbotst.

[Reactie gewijzigd door teacup op 13 januari 2013 00:34]

In principe niet minder onveilig dan Javascript, Silverlight en Flash - het hele principe van het huidige web dat je zo maar code van elke willekeurige website kan uitvoeren is fundamenteel onveilig. Wil je daar van af, dan moet je weer naar een web van puur statische HTML gaan, maar die geest kan allang niet meer terug de fles in.
Het probleem is niet alleen de security,
Wat is dan het fundamentele probleem van Java ten opzichte van bijvoorbeeld applicaties gemaakt in .Net, C, C++, PHP, Ruby? Alle software heeft gaten en Java ook.
maar ook de compatibiliteit. Veel bedrijven durfden geen Java updates uit te rollen uit vrees dat men een applicatie breekt.
Backwards compatibiliteit is zelfs bij minor updates niet gegarandeerd.
"Don't shoot the messenger" ?

Dat heeft helemaal niks met de taal (Java) of de default Java VM implementatie (Hotspot) te maken. Dat heeft te maken met programmeurs en bedrijven die rotzooi uit private API van bijvoorbeeld "com.sun" gebruiken. De compiler geeft zelfs warnings en errors als je dat doet. Tevens word het binnen de gemeenschap gezien als extreem bad practice. Java 7 kan prima Java 1.3 gecompilde applicaties draaien, zonder enig verschil. Als je een leverancier hebt welke zegt je moet op Java 1.4 blijven zitten want anders werkt het niet kan je die meteen een etiket met "incompetent" erop op ze voorhoofd plakken.

Java is juist extreem compatible. Software draait op verschillende implementaties van Java zonder recompilen out of the box; Hotspot, IBM Blackdown, BEA Webrockit en dan ook nog op verschillende platformen; Linux, Windows, FreeBSD, Solaris, etc.
In potentie zal het allemaal best wel mooi en goed zijn. Praktijk leert dat het een zorgenkindje is.
Ik loop inmiddels met een grote boog om Java heen en als ik een leverancier hoor welke een Java based applicatie uitbrengt dan gaan bij mij de nek haren overeind.
Voor iemand bij wie er in zijn profiel staat "IT Project Manager" vind ik dit allemaal wel erg kort door de bocht en kort zichtig. Je komt gaat zeker ook nooit meer naar je Turkse bakker om de hoek, hoe goed het brood wellicht ook is?
Sorry hoor, maar dat is flinke onzin. Backwards compatibiliteit van Java is zo extreem hoog dat het bijna vervelend is. Het is het 'nieuwe Cobol' waar het gaat om een strategisch platform te bieden. Wat jij signaleert is dat we inmiddels veelal in de 2e of hogere generatie Java programmeurs beland zijn die nu de, inmiddels legacy, systemen mogen onderhouden. Dit is voor ieder technisch platform een flink uitdaging en leidt tot de menselijke reactie om er maar vanaf te blijven. Ik heb menig upgrade/conversie traject voor klanten mogen doen en in een hele kleine minderheid van de gevallen was er sprake van een technische reden waarom de upgrade lastig was. En in alle gevallen waar dit het geval was waren het programmeurs die 'creatief' hadden zitten doen (afhankelijkheden op een specifieke applicatie server, de ordening van de VM voor entries in een HashMap en meer van soort domme dingen).
Veel bedrijven durfden geen Java updates uit te rollen uit vrees dat men een applicatie breekt.
Ik denk dat dit wel meevalt.Bij applicaties die ik ken die gebruik maken van Java functionaliteit wordt een compatibele versie van de java runtime environment (JRE) lokaal meege´nstalleerd. De software refereert bij zijn functioneren dus alleen aan deze lokale java installatie. Deze lokale Java gaat niet mee in de update van de java RTE waarhet OS aan refereert. Pas wanneer de software zelf een update ondergaat, wordt ook weer een bijbehorende recentere Java RTE meege´nstalleerd.

Is dit een charmante oplossing? Nou nee. Al die Java RTE versies verdienen geen schoonheidsprijs. De softwarebouwer houdt zo wel regie over de eigen environment. Het betekend echter ook dat de softwarebouwer zich hiermee verantwoordelijk maakt voor het gebruik van die verouderende Java RTE. Dat is een afweging voor de softwarebouwer.

Edit:
In reactie op JUDGExKTF
Als je een leverancier hebt welke zegt je moet op Java 1.4 blijven zitten want anders werkt het niet kan je die meteen een etiket met "incompetent" erop op ze voorhoofd plakken.
Zoals je hierboven kan lezen zit ik daar wat diplomatieker in. Zolang de software leverancier zich verantwoordelijk stelt voor de veiligheid van zijn software, is een lokale installatie een invalshoek. Blijkbaar heeft ook deze softwarebouwer problemen gekregen met veranderende Java versies, dat ze dit is gaan doen. Ik gaan geen namen noemen, maar de bouwer is geen kleintje. Over de programmeerkwaliteit van de software kan ik geen oordeel geven. Blijkbaar is de werkelijkheid wat genuanceerder dan je hierboven stelt.

[Reactie gewijzigd door teacup op 12 januari 2013 14:55]

Zolang de software leverancier zich verantwoordelijk stelt voor de veiligheid van zijn software, is een lokale installatie een invalshoek.
Helaas kan de software leverancier geen beveiligings gaten patchen in de officiele Sun / Oracle JRE. Lokale installatie of niet, je installatie is dan dus kwetsbaar. Dus ondanks dat hij er zegt voor garant te staan kan hij er in technische zin niet garant voor staan. In theorie zou hij zelf een build van OpenJDK kunnen leveren welke hij getest heeft met zijn software en daarin tevens alle security fixes stopt. Op die manier kan je tot in de oneindigheid Java 1.4 veilig in de lucht houden.
Ik gaan geen namen noemen, maar de bouwer is geen kleintje.
Ik weet uiteraard niet wie jij bedoelt maar ik kan denk ik een grotere naam noemen: Cisco. Cisco heeft er een handje van om specifieke versies van JRE's voor te schrijven. Dit deden ze bijvoorbeeld bij de SDM. Deze GUI applicatie werkte heel lang enkel met Java 5. Geen idee hoe dat nu is overigens, wellicht hebben ze daar verandering in gebracht.
Over de programmeerkwaliteit van de software kan ik geen oordeel geven. Blijkbaar is de werkelijkheid wat genuanceerder dan je hierboven stelt. Blijkbaar heeft ook deze softwarebouwer problemen gekregen met veranderende Java versies,
De discussie ging erover of je Java dit kan aanrekenen. Als deze partij de software in .Net had gemaakt had dat waarschijnlijk geen verschil uitgemaakt. Aangezien als deze partij zich gewoon gehouden had aan de regels er geen probleem was geweest. Aangezien ze dat niet doen maakt de taal / framework waarschijnlijk weinig verschil.

Ik heb zelf legio software geschreven en ontwerpen (veelal in Java) en ik heb nooit deze problemen gehad. Ik weet echter dat het heel aanlokkelijk kan zijn om "afstekertjes" te nemen tijdens het programmeren welke later slecht kunnen uitpakken (en resulteren in boven beschreven incompatibiliteit). Bijvoorbeeld wat doe je in Java als je iets Base64 moet encoden; Pak je even snel de Base64 encoder uit "com.sun"? Of pak je een opensource implementatie? Als je de implementatie uit "com.sun" pakt dan weet je dat dit vroeg of laat problemen kan gaan geven (en je moet het weten want de compiler waarschuwt je).
Nogmaals, ik ben geen programmeur. Wel denk ik je beschrijving over de "afstekertjes" te kunnen herkennen (prachtig omschreven trouwens). Daar ik de software al een tijdje meemaak herken ik regressieproblemen, versies die niet kunnen wat voorgaande versies wel konden. Bij een volgende update is die functionaliteit weer hersteld. Kijkend naar de software als een systeem, dan is de software die ik bedoel nerveus geregeld. Die nervositeit kan daar ontstaan waar de bouwer zelf geen invloed op heeft. Dit kan je dan weer lezen als een "zie je wel, Java is dus de oorzaak". En ik moet zeggen, de klantencommunity is de afgelopen jaren ruimhartig in die conclusie gesprongen. Een van de andere mogelijke oorzaken zijn de door jouw genoemde afstekertjes, want als juist de Interface, waarmee de software afhankelijk is van zijn omgeving, rommelig is geprogrammeerd kan ik me levendig voorstellen dat er voortdurend bonje is met het toepassen van Java routines.
De discussie ging erover of je Java dit kan aanrekenen. Als deze partij de software in .Net had gemaakt had dat waarschijnlijk geen verschil uitgemaakt.
Dit vind ik dus een eye-opener, in je eerdere post al uitgesproken maar juist deze zin zet me aan het denken. Als ik de emotie van klantencommunity beschrijf dan is ze zoiets als: "beweeg weg van Java en naar .NET, want met Java hebben we negatieve ervaringen, en het Windows is het meest gebruikte OS".

Na de bovenstaande discussie draait mijn vizier nadrukkelijk weg bij de Java, en meer richting softwarebouwer. Naast dit Java interface aspect heb ik daar zonder programmeerkennis ook genoeg redenen voor. De programmeer rommeligheid lekt namelijk ook door de functionaliteit naar buiten. Hoofdverdachte wordt dan het change management van de bouwer. Die conclusie heb ik het afgelopen jaar, los van deze draad al getrokken en zie ik nu versterkt.

Wordt dit off-topic? Op kwade intenties zullen applicatiebouwers niet snel betrapt kunnen worden. Op rommelig programmeren zijn zijn zowel de applet als de applicatiebouwers te betrappen. Maar daar gaat deze draad niet over. Een vraag die ik nog niet gesteld heb zien worden is of het een gelukkige keuze is om twee onafhankelijke Java engines (plugin in browser en JRE in OS) op een computer te hebben. De afzonderlijke lokale JRE's van applicatiebouwers worden als not done beschouwd. Waarom is de browser plugin dan wel een geaccepteerd verschijnsel? Iedere browser zijn eigen plugin??? Is dat geen analogie aan die lokale applicatie JRE?

Voor mijn laatste vraag is de topic al best wel oud aan het worden. Weten meer Tweakers van dit soort lokale Java implementaties met een oudere time stamp Het veiligheidsrisico dat JUDGExKTF noemt maakt deze vraag relevant, ofschoon niet geheel on-topic, verteld het wel iets over de programmeer etiquette bij onze software leveranciers, en daar horen de browsers volgens mij ook bij.

Op dit item kan niet meer gereageerd worden.



HTC One (M9) Samsung Galaxy S6 Grand Theft Auto V Microsoft Windows 10 Apple iPad Air 2 FIFA 15 Motorola Nexus 6 Apple iPhone 6

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True