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. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 174 reacties
Submitter: job_h

Google zou niet langer veiligheidslekken in oudere versies van de standaardbrowser van Android willen repareren. Hierdoor zijn gebruikers van met name verouderde toestellen kwetsbaar voor cybercriminelen.

Android logoHet gaat volgens The Wall Street Journal om de stock-browsers van het mobiele besturingssysteem tot en met Androidversie 4.3, die ook bekend staat als Jelly Bean. Uit cijfers van Google blijkt zestig procent van de gebruikers met een Play Store-app over een verouderde versie beschikt.

De browsers draaien op een oude versie van WebView, dat wordt gebruikt voor het renderen van pagina's. Dat onderdeel verving Google in recentere versies door een variant op basis van de Chromium-browserengine. Google zou tegen Rapid7 hebben gezegd dat browsers die niet over die engine beschikken, te oud zijn om nog langer te ondersteunen. Het gaat daarbij om software op apparaten van derde partijen.

Rapid7 ontwikkelt de populaire Metasploit-hackerstoolkit. Die kit biedt al exploits om onder andere stock-browsers met WebView aan te vallen. Daarnaast duiken er nog geregeld kwetsbaarheden op voor de stock-browser. Zo was die vorig jaar tot en met versie 4.3 kwetsbaar voor een ernstige bug waarbij de websites de content en cookies van andere webpagina's via javascript konden uitlezen.

Moderatie-faq Wijzig weergave

Reacties (174)

Enige nuance is op zijn plaats.

Google is al een tijdje bezig om fragmentatie aan te pakken. Dit door zo veel mogelijk componenten update-baar te krijgen via het google play services framework. Dat lukt ze aardig, maar de browser was het eerste hekelpunt, aangezien deze enkel geupdate kon worden door middel van een fiirmware update.

Google pusht daarom al sinds Android 4.0 Chrome als de default browser en heeft sinds de intrede van ICS de stock browser op pensioen willen sturen.
Helaas hebben fabrikanten als Samsung, LG en HTC vťťl te lang geteerd op de stock AOSP browser. Daarnaast pasten de fabrikanten de AOSP browser aan, waardoor ze ook weer afwijken van de AOSP browser. Net zoals de verschillende skins zoals TouchWiz en Sense hebben fabrikanten de AOSP versies van de browser, e-mail clients en dergelijke apps stevig aangepast om zich te kunnen differentiŽren op de markt. Die differentiatie maakt firmware updates ook een stuk moeilijker. Net zoals de truckload aan devices met verschillende hardware-specificaties. (Samsung)

Kortom, zelfs al zou Google een manier vinden om de AOSP browser als system app te updaten buiten een firmware update om, dan zou dit nog niet gaan omdat de builds van Samsung, LG, etc niet compatibel zijn.
Het is wederom aan de fabrikant zelf om updates door te voeren aan de hand van firmware updates en deze lekken te dichten. Helaas is het update-beleid van deze fabrikanten niet bepaald denderend te noemen en kunnen gebruikers fluiten naar hun firmware update en dus ook fluiten naar een "veilig" toestel.

Kijk eens hoe snel en vlot Motorola weet te updaten. Zij nemen Google's Android zoals het is en bouwen adhv apps extra functionaliteit toe. Door hun firmware redelijk stock te houden, en geen al te afwijkende hardware te gebruiken, kunnen zij updates ook sneller testen en uitrollen.

Gelukkig is er licht aan het eind van de tunnel. Door de apps meer los te trekken van het OS in latere Android versies, kunnen ze ook beter up-to-date gehouden worden. Ook leveren de meeste fabrikanten halverwege 2013 Chrome als default browser, al is het vaak enkel op hun high-end toestellen.

Kortom, het originele artikel is met een totaal controversiŽle insteek geschreven om zoveel mogelijk page views te genereren, maar feit blijft dat Google's eigen ROM al enige tijd Chrome als default browser gebruikt in plaats van de AOSP browser. De AOSP browser heeft Google overigens al een tijdje niet meer bijgewerkt. Hoog tijd dat deze gewoon ook niet meer meegeleverd wordt als default browser!
Enige nuance is op zijn plaats.

Google is al een tijdje bezig om fragmentatie aan te pakken. Dit door zo veel mogelijk componenten update-baar te krijgen via het google play services framework. Dat lukt ze aardig, maar de browser was het eerste hekelpunt, aangezien deze enkel geupdate kon worden door middel van een fiirmware update.
Opzich een nobel streven, maar met deze actie benadelen ze alleen de gebruikers. De fabrikanten worden hier alleen maar beter van, je krijgt immers mensen die een nieuwe telefoon kopen om dat de oude niet meer veilig is.
Google pusht daarom al sinds Android 4.0 Chrome als de default browser en heeft sinds de intrede van ICS de stock browser op pensioen willen sturen.
Helaas hebben fabrikanten als Samsung, LG en HTC vťťl te lang geteerd op de stock AOSP browser. Daarnaast pasten de fabrikanten de AOSP browser aan, waardoor ze ook weer afwijken van de AOSP browser. Net zoals de verschillende skins zoals TouchWiz en Sense hebben fabrikanten de AOSP versies van de browser, e-mail clients en dergelijke apps stevig aangepast om zich te kunnen differentiŽren op de markt. Die differentiatie maakt firmware updates ook een stuk moeilijker. Net zoals de truckload aan devices met verschillende hardware-specificaties. (Samsung)
WebView is niet alleen de AOSP browser, maar een intergraal onderdeel van het OS dat pas in 4.4 is aangepast. Google had het in 4.1 al kunnen doen, chroniumView was toen al beschikbaar. Om een of andere reden uitgesteld tot 4.4, waarschijnlijk was ChroniumView nog niet helemaal af. Gebruikers van 4.3 en eerder zitten aan WebView vast, of ze willen of niet.
Kortom, zelfs al zou Google een manier vinden om de AOSP browser als system app te updaten buiten een firmware update om, dan zou dit nog niet gaan omdat de builds van Samsung, LG, etc niet compatibel zijn.
Het is wederom aan de fabrikant zelf om updates door te voeren aan de hand van firmware updates en deze lekken te dichten. Helaas is het update-beleid van deze fabrikanten niet bepaald denderend te noemen en kunnen gebruikers fluiten naar hun firmware update en dus ook fluiten naar een "veilig" toestel.
Dat is meer Googles designfout dan de fout van de fabrikanten. Al ontwerp je een OS zorg je eroor dat het mogelijk is om veiligheidsupdates uit te rollen. Windows vista krijgt ook nog steeds updates voor IE, waarom zou Google WebView niet meer kunnen updaten?
[/quote]
Kijk eens hoe snel en vlot Motorola weet te updaten. Zij nemen Google's Android zoals het is en bouwen adhv apps extra functionaliteit toe. Door hun firmware redelijk stock te houden, en geen al te afwijkende hardware te gebruiken, kunnen zij updates ook sneller testen en uitrollen.
Gelukkig is er licht aan het eind van de tunnel. Door de apps meer los te trekken van het OS in latere Android versies, kunnen ze ook beter up-to-date gehouden worden. Ook leveren de meeste fabrikanten halverwege 2013 Chrome als default browser, al is het vaak enkel op hun high-end toestellen.

Kortom, het originele artikel is met een totaal controversiŽle insteek geschreven om zoveel mogelijk page views te genereren, maar feit blijft dat Google's eigen ROM al enige tijd Chrome als default browser gebruikt in plaats van de AOSP browser. De AOSP browser heeft Google overigens al een tijdje niet meer bijgewerkt. Hoog tijd dat deze gewoon ook niet meer meegeleverd wordt als default browser!
het artikel vergeet juist te vermelden van WebView een onderdeel is van het OS en niet alleen de browser. ook de browsers van diverse fabrikanten draaien erop. Het probleem is groter als het artikel schetst, niet kleiner. De grootste Andriodfabrikant levert nog steeds een WebView browser mee, WebView is nog lang niet uitgefaseerd als browser. Google maakt hier de keuze om 60% (930 000 000 stuks)van de gebruikers helemaal kwetsbaar te maken en nog veel meer gebruikers lopen een hoog risico met hun standaard browser. Google neemt hier een een beslissing die ik weinig anders als schandalig kan noemen.
Ik heb vroeger ook zo'n telefoon gehad op 4.4.3 Android. Daar kon ik gewoon Chrome opzetten of Firefox. Dat fabrikanten je een nieuwe telefoon proberen te verkopen vanwege dit is overdreven.
Webview is, zoals al vaak opgemerkt, meer als alleen de browser. Alle webbased apps worden er mee gerendeerd, net als ie op windows
Het gaat niet om de browser, het gaan om WebView. WebView wordt niet alleen door de browser gebruikt, maar ook door apps die op Android draaien. Een andere browser installeren waart je nog niet veilig voor de exploits in Android 4.3 en lager.
Even vanuitgaande dat dit klopt.

Wat Google dan gezegd zou hebben is dat ze de code base van AOSP niet meer updaten mbt Webview.

Webview is een core onderdeel van het OS en kan dan daarom niet bijgewerkt worden via de Play Store of door Google. Het updaten van Webview op een device is dus een verantwoordelijkheid van de leverancier.

Alle apparaten ouder dan KitKat draaien dan dus sowieso al een niet gepatchte Webview, omdat de fixes geÔntroduceerd bij Kitkat en Lollipop niet geÔnstalleerd zijn op Jelly Bean en ouder. Tenzij de leverancier ook hun oudere toestellen blijft updaten, ook al is dit geen upgrade naar Kitkat of Lollipop.

Het feit dat Google dan dus de codebase niet meer zou bijwerken, betekent niks voor toestellen die al Łberhaupt op een verouderde Webview draaien.

Daarnaast heeft Google een mogelijkheid geÔntroduceerd om gepackagede webapps (die via de Play Store aangeboden worden) te voorzien van een ingebouwde ChromeView. Dat is echter wel aan de developer om te doen.

Samenvattend:
- Alle oudere devices dan Kitkat hebben sowieso al een niet bijgewerkte Webview (let op: tenzij leverancier end-of-life toestellen blijft updaten).
- Google biedt een workaround voor webapps die via een APK geÔnstalleerd worden.
- Voor normale websites geldt dit euvel sowieso niet, wanneer je niet internet met een op Webview gebaseerde browser.
- ChromeView is standaard bij Kitkat en hoger.
- Chrome voor Android draait op ChromeView.

Ik vind het een begrijpelijk actie dat Google dan ook echt volledig stopt met Webview. Voor Jelly Bean en eerdere versies moet er gekeken worden naar de fabrikanten van de toestellen voor een update naar Kitkat of hoger, of zelf beslissen om een nieuw toestel te kopen. Ook kan de fabrikant zelf updates maken voor Webview, die dan door Google geaccepteerd worden. Voor de gebruiker maakt het dus niet uit dat Google Webview niet meer bijwerkt. Het gaat er om dat zij een nieuwere Android versie krijgen.

Ik ben zelf developer geweest van een Webapp op Android dat geÔnstalleerd werd. Alle verschillende versies van Webview en Chromeview werd een hoofdpijn dossier na een poosje :).

Links:
Chrome Embedded: https://code.google.com/p/chromiumembedded/
Crosswalk: https://crosswalk-project.org/

[Reactie gewijzigd door teusink op 13 januari 2015 12:39]

Met als nadeel dat elke app die je daarmee uitrolt 20mb groter wordt. Of is daar inmiddels al iets slims voor bedacht in de vorm van een shared library? Dat zal rechten technisch lastig worden zonder root vermoed ik?
Klopt, dat is inderdaad een zeer vervelende nadeel. Zover ik weet kun je niet libraries delen. Apps communiceren op Android met elkaar op basis van Intents. En zover ik weet kunnen deze niet ingezet worden voor library zaken.

[Reactie gewijzigd door teusink op 13 januari 2015 09:45]

Ik las dat het tegenwoordig wel mogelijk is om hem te delen via shared mode. Geen idee of de shared runtime dan ook apart via de Play Store verspreid kan worden.

https://crosswalk-project.org/documentation/about/faq.html:
Can one Crosswalk installation be shared between multiple applications?

Bundling the runtime with the application (aka "embedded mode") is the simplest approach for distribution purposes. But Crosswalk applications can share a single Crosswalk runtime library (in "shared mode"); and a package which enables shared mode is part of the Crosswalk for Android distribution. However, you would have to distribute this shared runtime package yourself..
Die fixes zouden echter gewoon beschikbaar moeten zijn voor 4.3 en lager. Waarom kan er geen nieuwe 4.3.x update komen voor toestellen die de update naar 4.4 of hoger niet krijgen? Daarbij, waarom krijgt Microsoft maar 90 dagen tijd om lekken te dichten van Google, maar zet Google een enorme meerderheid van zijn gebruikers te kijken. Het gaat hier om zomaar even 11 exploits die gevonden zijn de voorbije maand.

Jij zegt dat het niks uit maakt dat vele toestellen die update niet krijgen omdat ze toch al een verouderde WebView draaien, maar is dat niet juist het punt van patchen? Die toestellen ook een veilige versie van WebView geven?

Bron: https://community.rapid7....view-jelly-bean-and-prior
Het is niet Google. Google kan niet de updates pushen naar de gebruikers.

De leveranciers zouden een nieuwe compile moeten doen van de Android code (desnoods van Jelly Bean oid, maar liefst Kitkat of Lollipop natuurlijk) en dat pushen naar hun klanten. Alleen er is geen leverancier ter wereld die nog updates verspreidt voor toestellen die op dit moment Jelly Bean of ouder draaien.

Dus Google kan 'fixen' wat hij wil, maar als de leveranciers de updates niet verspreiden, dan heeft het geen zin. Google zet zijn gebruikers niet te kijk, maar HTC, Samsung, Motorola, LG, Sony, etc etc etc. De kans is zeer groot dat naast de 11 exploits die Google niet gaat fixen, dat ťťn van de hiervoor genoemde leveranciers de door Google reeds gerepareerde bugs nog niet eens gepushed heeft.

Verschil met Microsoft is, is dat Microsoft de updates pushed.
Google pushed zelf ook updates naar onder andere Nexus en Play Edition, de meeste daarvan zitten al op een nieuwe software dan 4.3.x, maar ook daar zijn sommige die zijn achtergelaten. Het maakt niet uit of die fabrikanten die update pushen of niet, het probleem ligt nu bij Google, en ze doen er niks aan. Opnieuw: het gaat hier om 11 exploits die pas ontdekt zijn, god weet wat er daarvoor al gevonden is. Google beheerd Android, zij zijn degene die verantwoordelijk zijn om die fixes te maken voor oudere versies, fabrikanten moeten ze daarna verspreiden. Maar als die fabrikanten geen bijgewerkte versies voor die oude versies krijgen, kunnen ze niks.

Maar ondertussen wel hun concurrenten zwart maken over 1 exploit met een proof-of-concept te publiceren, waarvan ze wisten dat er een patch bestond en morgen uitgerold zou worden.

[Reactie gewijzigd door Loller1 op 12 januari 2015 21:05]

Nexus S en Galaxy Nexus zijn al heel oud en ontvangen begrijpelijk geen updates meer. Mijn Nexus 4 draait Lollipop.

Het probleem ligt niet bij Google. Er zijn geen fabrikanten meer die nog Jelly Bean of lager updates uitbrengen voor Jelly Bean of lagere toestellen.

Die toestellen missen niet alleen de fixes voor de 11 exploits, maar ook van de exploits daarvoor. En dit is een blamage van de fabrikanten en niet van Google.

Voorbeeld:
Samsung Galaxy S3 heeft sinds zijn laatste update tot aan nu gťťn updates ontvangen van Samsung (let op dat ik hier geen Google zeg). Hoe lang is dat? 1 of 2 jaar? Al die tijd zijn er geen updates voor Webview geÔnstalleerd, ondanks dat Google deze wel gefixt heeft in de code.

Het is compleet onnodig om AOSP code bij te werken als fabrikanten geen updates uitbrengen op basis van die nieuwe code.

Fout van de fabrikant, niet slim van de consument om zo lang een oud toestel te gebruiken, en verstandig van Google om de stekker er uit te trekken. Hopelijk triggert het de fabrikanten om alsnog hun end-of-life toestellen bij te werken naar tenminste Kitkat.
Laat ik het dan zo zeggen, beide zijn schuldig zowel de fabrikanten als Google. Maar het is Google die deze situatie geschapen heeft en het is Google die nu besluit om honderden miljoenen gebruikers af te schepen.
Dus de kern van het probleem ligt zeker bij Google en ik vind het eerlijk gezegd een beetje vreemd dat je het zo krampachtig probeert goed te praten.
Het is niet krampachtig. Het zijn de feiten. Dat merk x jouw apparaat niet bijwerkt heeft niks met Google te maken. Of Google Webview nu fixt of niet. Het zijn de leveranciers die hun klanten afschepen. Het zijn de leveranciers die hun devices niet updaten. Al zou Google nog steeds nieuwe fixes releasen voor Webview, als een leveranciers deze updates niet verspreiden (en op een kleine uitzondering na, gebeurt dit massaal niet), dan heb je echt helemaal niks aan die fixes die Google maakt.

En dit even los van het feit dat fabrikanten nog steeds zelf fixes/patches kunnen aanleveren voor kwetsbaarheden. Google accepteert deze fixes dan gewoon in de codebase.

Ik weet dat iedereen er op gebrand zit om een vinger te wijzen naar Google, maar ik vind dat je de vinger in dit geval moet wijzen naar je fabrikant van je toestel. Als jij nog Jelly Bean draait dan vind je of beveiliging niet belangrijk, of je maakt jezelf slachtoffer van de leverancier van je telefoon. Tenzij je fabrikant met regelmaat updates stuurt, ook al is het op basis van Jelly Bean.

In smartphone land is 2 jaar support ruim voldoende. De levenscyclus is gewoon veel sneller dan bij desktops en ik ben blij dat Google niet dezelfde legacy-problematiek wilt gaan creŽren als Microsoft dat doet/heeft gedaan.

Dit is uiteraard alleen maar mijn mening en visie op dit onderwerp. Het staat je vrij om het totaal met mij oneens te zijn,

[Reactie gewijzigd door teusink op 13 januari 2015 09:57]

Ik blijf het heel makkelijk vinden hoe Google hier volgens jou onder zijn verantwoordelijkheid uitkomt en alles op de fabrikanten wordt afgeschoven. Webview behoort tot de kern van Android en Android IS van Google.
Ik weet dat iedereen er op gebrand zit om een vinger te wijzen naar Google, maar ik vind dat je de vinger in dit geval moet wijzen naar je fabrikant van je toestel.
Het betreft hier nog steeds een fix aan een gedeelte van het OS wat Google levert. Hoeft Microsoft ook geen patches meer uit te brengen voor Dell-laptops?
Je kan het overigens ook andersom zien: wij zijn er niet per se op gebrand om de vinger richting Google te wijzen, jij lijkt erop gebrand o mde schuld volledig bij de fabrikanten te liggen in plaats van ook Google hierbij te betrekken.
Als jij nog Jelly Bean draait dan vind je of beveiliging niet belangrijk, of je maakt jezelf slachtoffer van de leverancier van je telefoon.
Dus nu is het ook de schuld van de consument maar Google blijft nog steeds volledig buiten schot? Er worden dus 930 miljoen mensen hierdoor getroffen, hoeveel daarvan denk je dat daarvan weten uberhaupt dat ze updates kunnen installeren. Zeker met security updates kan dat makkelijk automatisch over the air. Dat werkt bij andere mobiele OS-en ook zo, waarom dan niet bij Google.
In smartphone land is 2 jaar support ruim voldoende. De levenscyclus is gewoon veel sneller dan bij desktops
Volgens het bronartikel worden er nog steeds 930 miljoen gebruikers direct hierdoor getroffen:
In terms of solid numbers, it would appear that over 930 million Android phones are now out of official Google security patch support, given the published Gartner and WSJ numbers on smartphone distribution).
Dus die 2 jaar support lijkt voor een hele grote groep mensen toch behoorlijk te kort te zijn en daar gaat Google (maar zeker ook de fabrikanten) gemakshalve even aan voorbij. Het zou ze dus sieren die groep gewoon van patches te voorzien.
Dit is uiteraard alleen maar mijn mening en visie op dit onderwerp. Het staat je vrij om het totaal met mij oneens te zijn,
Die vrijheid neem ik dan maar ;)
[...]

Het betreft hier nog steeds een fix aan een gedeelte van het OS wat Google levert. Hoeft Microsoft ook geen patches meer uit te brengen voor Dell-laptops?
Maar Dell verkracht Microsoft Windows niet dusdanig dat het incompatible wordt met de Windows Update service. Dat is wel wat (bijna) alle fabrikanten doen. Google is al veel verder met Android, de updates zijn gewoon beschikbaar tot Lollipop (Android 5.0.1), maar door al die aanpassingen van fabrikanten worden oudere telefoons niet meer van updates voorzien omdat ze het zichzelf zo moeilijk maken.

En juist daardoor hoopt iedereen dat Google dan maar tot in lengte van dagen onderdelen van Android blijft patchen. Ik snap dat ze daarvoor passen. Als fabrikanten al die moeite die ze steken in apps waar bijna niemand op zit te wachten nu eens zouden steken in het schrijven van drivers voor oudere hardware zodat die ook de nieuwste Android-versies kunnen draaien.
Dus nu is het ook de schuld van de consument maar Google blijft nog steeds volledig buiten schot? Er worden dus 930 miljoen mensen hierdoor getroffen, hoeveel daarvan denk je dat daarvan weten uberhaupt dat ze updates kunnen installeren. Zeker met security updates kan dat makkelijk automatisch over the air. Dat werkt bij andere mobiele OS-en ook zo, waarom dan niet bij Google.
Omdat fabrikanten die updates niet doorsturen? Het is bij Android nu eenmaal zo gegroeid dat je grote updates van je fabrikant moet krijgen, alleen Play-edition en Nexus-toestellen zijn daar de uitzondering op. Ik had dat ook liefst anders gezien en hierboven wordt al uitgelegd hoe Google dat probeert aan te pakken, maar fabrikanten willen graag hun eigen stempel blijven drukken op Android. Ik bedoel: de efforts van Google zijn toch duidelijk op de telefoons die ze wel (mogen?) supporten? Nexus 4, 5 en 6 en de Play editions draaien toch zonder deze problemen?
Dus die 2 jaar support lijkt voor een hele grote groep mensen toch behoorlijk te kort te zijn en daar gaat Google (maar zeker ook de fabrikanten) gemakshalve even aan voorbij. Het zou ze dus sieren die groep gewoon van patches te voorzien.
Daar kan ik het alleen maar mee eens zijn, maar dit is toch de constructie die fabrikanten wilden? Stel dat Google zou zeggen: klaar met al die zut die jullie aanpassen, we maken stock Android voor iedereen, dan vinden die hardware fabrikanten naar verwachting dat Android niet interessant meer is. Misschien voorziet Google dat ook en hebben ze daarom Motorola gekocht? :P Worden ze straks een soort Apple met eigen hardware en software met snelle updates en lange support. De consument is toch al Android-verslaafd :X
Let's agree to disagree :).

Ik zeg niet dat Google geen fixes zou moeten uitbrengen voor Webview. Ik zeg alleen dat de impact hiervan verkeerd uitgelegd wordt.

Webview is primair een OS feature inderdaad, primair ontwikkeld door Google. Maar Samsung heeft onder andere een eigen aangepaste Webview (wel API compatible) meegeleverd op haar toestellen. En die Webview zit niet in de codebase AOSP. Dit ben ik o.a. tegen gekomen met het ontwikkelen van een Webapp (jaartje geleden). Dus daarmee geeft Samsung ook al aan dat zij verantwoordelijk zijn voor de software op hun telefoons. Niet Google, want Google is dat alleen voor de Nexus, Android One en Play-Edition lijnen.

Ik blijf van mening dat wanneer de fabrikanten alle telefoons van 2 jaar en nieuwe gewoon hadden bijgewerkt (i.p.v. alleen de high-end lijn) dat er dat geen vuiltje aan de lucht was (m.b.t. dit onderwerp). Google kan die toestellen niet updaten. En fabrikanten nemen hun verantwoordelijkheid niet.

M.b.t. de consument, ja, ik vind dat zij ook een verantwoordelijkheid hebben. Ik zie met enige regelmaat nog telefoons voorbij komen met Gingerbread (meestal HTC Desire trouwens :)). De awareness op dit gebied vind ik ver onder de maat. Het is immers gewoon een gegeven dat de ontwikkeltijden ontzettend snel gaan. En als je telefoon geen updates meer ontvangt, wordt het tijd voor een nieuwe. Dit is de primaire reden dat ik alleen een Nexus, Motorola, Play-Edition of een Android One zou nemen.

Met betrekking tot de 930 miljoen. Deze 930 miljoen worden op dit moment al reeds getroffen, namelijk door hun eigen fabrikanten die kennelijk geen support meer willen leveren. Met dien verstande dat onder die 930 miljoen ook nog classic Android gebruikers vallen en je maar moet afvragen hoe reŽel het is om een smartphone van 4 jaar oud nog te updaten.

En formeel is Android van Open Handset Alliance: http://www.openhandsetalliance.com/android_overview.html

[Reactie gewijzigd door teusink op 13 januari 2015 12:33]

de Phillips picopix projectoren die op het helemaal verouderde 2.3.1 draaien krijgen wel nog steeds updates.
laatste update was van 24 oktober 2014
dit is echter wel een uitzondering.
de meeste bedrijven doen niet meer aan updates voor zulke oude versies.
Dat is inderdaad een hele bijzondere uitzondering zelfs. Leuk om te horen!
niet echt.
ze hadden eigenlijk bij 4.3 moeten beginnen, of minstens op een 4.X versie.
het is een apparaat uit 2013.
Dat is wel een bijzondere keuze dan (voor Gingerbread). Jammer dat het Gingerbread is, wel weer goed dat ze het blijven updaten :). Wel met die kanttekening dat ik niet weet of Google de Gingerbread code nog uberhaupt bijwerkt of niet.
Die fixes zouden echter gewoon beschikbaar moeten zijn voor 4.3 en lager. Waarom kan er geen nieuwe 4.3.x update komen voor toestellen die de update naar 4.4 of hoger niet krijgen?
Om dezelfde reden waarom je geen 4.4 hebt?! Namelijk dat je fabrikant geen updates doorvoert voor jouw toestel.
Zelfs als zou Google een specifieke versie maken die zich enkel bezig houdt met bugfixes, dan zou het nog niets uitmaken want de fabrikanten van al deze <4.4 devices houden het qua support voor bekeken.
Een update van 4.3 naar 4.4 vereist echter grotere wijzigingen dan van 4.3.1 naar 4.3.2 bijvoorbeeld. Dat is ook al een serieuze drempel minder voor OEMs.
Schandalig dat ze hier zo mee omgaan en ondertussen hun concurrenten zo hard mogelijk door het slijk proberen te halen met 1 exploit als mogelijk is. We praten hier over 11 exploits in Android 4.3 en lager! 11! Die wijd open blijven staan. Op 60% van de Android toestellen. Dat maakt 930 miljoen gebruikers! Ben benieuw of Microsoft zich eens gaat bezig houden met een paar proof-of-concepts online te zetten, net zoals Google heeft gedaan met Microsoft.
Ik wil met dit bericht graag reageren op de volgende reacties:
Slechte zaak. Android 4.3 is nog geen 2 jaar uit. iets langere support is toch wel gewenst.
Dat is 1.5 jaar na verschijnen van de 4.3 release. Tamelijk kort voor een serieus OS, tenzij dat alle Android devices ook naar een hogere versie kunnen. Uiteraard zijn er andere browsers, maar dit draagt niet bij aan een 'milieuvriendelijk' gebruik. Een langere levensduur vereist ook minder materialen voor fabricage.
Mijn ervaring bij Windows was dat wanneer ze van bepaalde zaken af willen zoals bijv. een verouderde messenger ze je in een doolhof terecht laten komen van allerlei componenten die om onduidelijke reden op elkaar leunen en er samen voor zorgen dat die oude messenger het niet meer doet. Dat was naar mijn idee geen samenloop van omstandigheden maar doelgericht de gebruiker afhankelijk maken en bijna dwingen tot de aanschaf van nieuwe hard- en software.
De nadelen van een commercieel OS nodig hebben... Ze gaan er bij Google waarschijnlijk vanuit dat het toch wel blijft verkopen en ze veel kunnen maken. En ik vermoed dat dat ook klopt.
Het gaat hier niet om de browser, het gaat hier om een integraal onderdeel van android API namelijk WebView. (bron) WebView is een onderdeel van de API dat al zo lang mee gaat dat er op enkele functies 21 reviesies uit zijn gevoerd. WebView stampt zelf nog minimaal vanuit versie 2.1 en sinds dien zijn er al problemen mee. (bron)

Wat Google met Android niet doet t.o.v. bijv. een Microsoft met Windows is het hele OS op de schop gooien. Dit is een keuze die gemaakt wordt. Natuurlijk kunnen ze zeggen we blijven oude source code ondersteunen zoals ze tot nu toe hebben gedaan. Echter soms is het gewoon beter om op nieuw te beginnen en te leren van de oude code. Android zelf heeft ook een mogelijkheid om het OS te updaten (bron). Dus voor de mensen met stock OS'en is dit geen probleem.

Voor de overige mensen die bijv. een samsung hebben of een HTC die moeten wachten tot die fabrikant een nieuwe update plaatst voor hun OS. Maar met alle respect, als je 1,5 jaar lang geen updates heb gedaan aan je systeem, is het dan niet redelijk dat je kan verwachten dat er exploits in het OS gevonden worden die niet gepatched zijn?

Mensen zijn al snel geneigd om schade en schande te roepen op het moment dat een software versie exploits, leaks, backdoors of bugs heeft. Voor die mensen zou ik het volgende willen zeggen. Software ontwikkeling is nooit perfect. Perfectie vraagt namelijk veel tijd en veel geld. Software wordt zelden tot nooit volledig afgetest omdat er gewoon geen enkele manier is om rekening te houden met elke mogelijke use cases. Mijn ervaring als programmeur is gewoon dat het niet te doen is, er zijn altijd gebruikers die denken aan dingen waar jij niet aan denkt, die software gebruiken zoals jij het niet bedoelt heb. Het is gewoon simpel weg onmogelijk om alle mogelijke manieren van gebruik vooraf in te schatten. Dit wordt nog een paar graatjes erger als je backwards compatibility wil bewaren voor je software. Een patch laat uitbrengen als je hem al af heb vindt ik een ding. Een stuk code niet meer supporten en zeggen dat mensen moeten updaten is iets totaal anders.

Waar dit wel impact op zal hebben is een hele berg apps die deze API gebruiken. Dit betekend dat een aanzienlijk deel van de android store geupdate moet worden. Dit is een massieve onderneming of je loopt het risico dat je Apps niet ondersteund worden. Als een ontwikkelaar die er dag en nacht mee bezig is (zoals ik zegt de gek) komt dit niet echt als een grote verrassing en veel ontwikkelaars zullen hun apps ook bijgewerkt hebben of doen dat binnen een afzienlijke tijd. Waar dit wel een issue wordt is voor de ontwikkelaars die af en toe een app maken voor bij hun product. Deze moeten of 2 versies maken, of 1 versie die beiden ondersteunen of 1 versie die een van de twee ondersteund.

Begrijp me niet verkeerd ik heb misschien wel als persoon een voorkeur voor windows phone maar ik heb als software ontwikkelaar geen voorkeur voor een OS, nog desktop versie nog mobile versie. Dit is een stuk code die gewoon te gevoelig is voor exploits en soms moet je er gewoon voor kiezen om het mes er in te zetten. Het is alleen jammer dat niet alle techneuten de ervaring hebben met software ontwikkeling om deze keuze te begrijpen, maar ik hoop hierbij met deze post wat aan het begrip bijgedragen te hebben.

offtopic:
Mijn excusses aan Loller1, ik ben nog niet helemaal gewent aan de nieuwe manier van het ordenen van berichten

[Reactie gewijzigd door _wolf_ op 12 januari 2015 22:51]

Mag ik er vanuit gaan dat je op de verkeerde reactie antwoord? Ik heb niet je hele tekst gelezen, maar ze sluit niet echt aan op mijn reactie daar ik nergens claim dat het om de browser gaat in plaats van WebView (in tegendeel, ik zeg al op meerdere plaatsen zelf dat dit niet zo is).
Even te duidelijkheid, we hebben het hier over de stock browser en niet de Chromebrowser. Google heeft de meeste onderhoud van alle opensource applicaties op een laag pitje gezet en stopt nu al de energie in de grotendeels gesloten software van Google, zoals Chrome, Google Music, Google Calender, etc. Alle telefoonfabrikanten die aangesloten zijn bij Open Handset Alliance installeren deze Apps (verplicht) mee.

Fabrikanten die nog de oude browser meeleveren, kunnen daarom het beste zelf dit onderhoudt uitvoeren of gewoon niet meer meeeleveren en overschakelen op Chrome, Firefox of Opera.

[Reactie gewijzigd door Bliksem B op 12 januari 2015 21:11]

Het gaat niet om de stock browser, het gaat om WebView - dat ding eronder - dat ook gebruikt wordt door andere apps. Gewoon een andere browser installeren lost het probleem niet op.
Uit cijfers van Google blijkt zestig procent van de gebruikers met een Play Store-app over een verouderde versie beschikt. De browsers draaien op een oude versie van WebView
Staat gewoon in het artikel.

Niet dat dat nou alles meteen goedpraat, maar wel even lezen voordat je je vol emotie in de strijd werpt ;)

[Reactie gewijzigd door olivierh op 12 januari 2015 22:07]

Het is zeker een probleem. De meeste 'apps' zijn niets anders dan veredelde websites met een webview wrappertje eromheen. Google zegt zelf dat 't zo moet. hoewel een aantal exploits specifiek in de browser zelf zitten zitten de meesten in de onderliggende library zelf.

Als deze webview gebruikende apps externe content embedden, dan ben je net zo goed de sjaak.
Lezuuuuuuh
Uit cijfers van Google blijkt zestig procent van de gebruikers met een Play Store-app over een verouderde versie beschikt. De browsers draaien op een oude versie van WebView
En met 'de browsers' (meervoud) doelen ze dan op de verschillende versies van de stock browser die nog rondzwerven
Schandalig dat ze hier zo mee omgaan en ondertussen hun concurrenten zo hard mogelijk door het slijk proberen te halen met 1 exploit als mogelijk is. We praten hier over 11 exploits in Android 4.3 en lager!
Is dat wel goed vergelijkbaar? Voor zover ik weet ging het bij Microsoft om een lek in de laatste up-to-date versie van Windows waarbij de gebruiker sowieso blootgesteld is zonder een keuze te hebben.

In dit geval gaat het om de stock browser van een verouderde Android-versie. Bij mijn weten gaat dat niet over Chrome maar om de vorige stock browser. Ondertussen levert Google Chrome als stock browser in Android. Daarnaast kan iedereen die op Android 4.3 zit de laatste versie van Chrome downloaden, of eender welke browser die ze willen. De gebruiker heeft hier dus wel degelijk keuze.

Lijkt me dus weinig schandaligs aan en sowieso geen vergelijkbare situatie.

edit: en hoe is dit nu in godsnaam weer off-topic? Allemaal weer lekker aan het meningmodden ja?

[Reactie gewijzigd door MatthiasDS op 12 januari 2015 22:00]

Verouderde android versie van hoeveel jaar oud ?
3 jaar ?

Stelt je eens voor als MS nu ineens zegt windows 7, updaten we niet geen geen patches niet meer. Eens kijken naar de reacties. Oeps nee die hebben we bij xl meer dan 10 jaar oud al gezien, Boel herrie en MS blijft het voor sommigen nog ondersteunen.

Nee google trekt er na een paar jaar de stekker uit en zoek het maar uit. Tja dietzelfde google geeft MS 90 dagen. Datzelfde MS ondersteund updates voor vaak meer dan 10 jaar en datzelfde google vindt het na een paar jaar wel genoeg.

Trek zelf maar de conclusie hoe serieus je google qua ondersteuning moet nemen.
Nee google trekt er na een paar jaar de stekker uit en zoek het maar uit. Tja dietzelfde google geeft MS 90 dagen. Datzelfde MS ondersteund updates voor vaak meer dan 10 jaar en datzelfde google vindt het na een paar jaar wel genoeg.
Nu vergelijk je desktop OS'en met mobile OS'en. Dat lijkt me ook alweer appelen en peren. Het valt nog te bezien hoe lang MS hun mobile OS'en gaat ondersteunen. Hoe verloopt het de WP7-gebruikers tegenwoordig?

Daarnaast zijn mobiele apparaten de dag van tegenwoordig bijna tot wegwerpapparaten vervallen. Ik kan niet zomaar zeggen hoe snel de gemiddelde consument zijn smartphone of tablet vervangt maar ik durf wel stellen dat dat een pak sneller zal zijn dan gekochte licenties voor een desktop OS.

[Reactie gewijzigd door MatthiasDS op 12 januari 2015 21:26]

Windows phone 7 kregen geen 8 zelfde geld ook voor 7.5...
windows phone 7.5 en ouder krijgen geen Skype bijvoorbeeld ook...
Dat gaat om apps. Krijgt android 4.0 nog steeds alle apps?
https://play.google.com/s....naver.line.android&hl=nl
zelfs android krijgt apps op 2.3!!
line app bijvoorbeeld die het moet doen met een kwart winst van skype woord langer ondersteund!!
Enable to search chat room names (Android 2.3 or later)
Niet alle, wel veel. De meeste apps worden 2.3 compataibl gebouwd. Zo heel veel nieuwe functies heeft Google niet toegevoegd tijdens de 4.x reeks
Ondersteuning voor Windows Phone 7 is beŽindigt in oktober 2014. 4 jaar na het uitkomen van Windows Phone 7. 2 jaar na het uitkomen van Windows Phone 8 (n 3 jaar na de aankondiging dat Windows Phone 8 niet naar Windows Phone 7 toestellen kwam). Ondersteuning voor Android 4.3 wordt hier al opgeschort na 1,5 jaar. Dus ja, Windows Phone 7 gebruikers hebben ook niks te klagen.
Gek, ik heb heel veel WP7 gebruikers net WEL weten klagen een hele tijd geleden.

Vind je nu trouwens niet dat je vrij arbitrair bezig bent? Google laat support voor een onderdeel van AOSP vallen na anderhalf jaar, Microsoft laat support voor een volledig OS vallen na 4 jaar. Ook dit lijkt me weer appelen en peren vergelijken. Tenzij je gaat stellen dat het support voor WP7 4 jaar lang op alle fronten is doorgegaan, maar is dat wel zo?
Ja, er kwamen geen feature updates meer na 7.8 (die ook al haast 2,5 jaar na de release van Windows Phone 7 uitkwam), maar de security patches voor het OS liepen wel nog door voor 1,5 jaar. Google laat alle ondersteuning al vallen na slechts 1,5 jaar, ondersteuning voor 4.3 is toch ook volledig stop gezet? Ik snap je punt niet helemaal. WP7 4 jaar ondersteuning heeft gekregen, Android 4.3 heeft maar 1,5 jaar ondersteuning gehad, en toch is WP7 slechter op dat vlak?
WP7 had na anderhalf jaar geen 11 expliots waar niets meer aan werd gedaan. Al stopt een fabrikant de veiligheidsupdates van een OS kan je gerust stellen dat de ondersteunig gestopt is.(zolas al vaak hier gezegd: WebView is meer als de browser)
WP7 had na anderhalf jaar geen 11 expliots waar niets meer aan werd gedaan.
Volgens mij was WebView eigenlijk heel wat ouder dan anderhalf jaar.

Mijn bovenstaande vraag blijft eigenlijk onbeantwoord: in hoeverre valt het wegvallen van ondersteuning voor een onderdeel binnen een OS na anderhalf jaar te vergelijken met het volledig wegvallen van ondersteuning van een volledig OS na 4 jaar?
Maar webView werd anderhalf jaar geleden nog wel een intergraal onderdeel van het OS gebruikt. WP7 is gebouwd op WinCE en gebruikte veel delen die wel wat ouder waren als WebView... Als WebView te ud was, waarom gebruikte Google het dan nog? Chronium bestond toen al lang, net als ChroniumView.

En zoals ik al zei, ik stel dat als een OS geen veiligheidsupdates meer krijgt je kan stellen dat de ondersteuning is gestopt. 11 bekende gaten in de beveiliging is meer als genoeg om een OS te onveilig te maken om nog te gebruiken.
Maar webView werd anderhalf jaar geleden nog wel een intergraal onderdeel van het OS gebruikt. WP7 is gebouwd op WinCE en gebruikte veel delen die wel wat ouder waren als WebView...
Niet zeker welk punt je hier wenst te maken. WP7 gebruikte ook nog oude delen als integraal onderdeel van het OS.
En zoals ik al zei, ik stel dat als een OS geen veiligheidsupdates meer krijgt je kan stellen dat de ondersteuning is gestopt. 11 bekende gaten in de beveiliging is meer als genoeg om een OS te onveilig te maken om nog te gebruiken.
OS <=> deel van het OS.
Niet zeker welk punt je hier wenst te maken. WP7 gebruikte ook nog oude delen als integraal onderdeel van het OS.
^dat was ik dus zei :) Het was Googles eigen keuze om het, inderdaad veroudere, WebView te gebruiken ipv ChroniumView. Het is dus hun eigen fout dat ze nu twee systemen hebben die ze moeten onderhouden. Het grote verschil tussen MS en Google is is dat MS alles vier jaar lang onderhoudt en dat Google gewoon direct de ondersteuning stopt. Er word op dit moment nog gewoon hardware uitgebracht met andriod 4.2(philips TV), WP7 word al tijden nergens meer verkocht.
OS <=> deel van het OS.
Hoeveel gaten wil je hebben voordat je een OS als onveilig ziet? 11 gaten in een intergraal onderdeel om de interface van veel apps te redenderen(en veel van de backendcode in het geval van webbased apps) is al genoeg om de hele beveiliging waardeloos te maken. Je hebt echt geen 12 expliots nodig om toegang te krijgen, eentje is genoeg. Andriod 4.3 en eerder hebben er op dit moment 11 die netjes gedocumenteerd zijn. Dat geld zelfs voor WP7 nog niet.
OS <=> deel van het OS.
Wat maakt dat uit? De problemen zitten in WebView, dus zitten ze in Android. 4.3 en lager worden niet meer ondersteunt. Als ik al je reacties goed begrijp ga jij er van uit dat de ondersteuning voor WebView in 4.3 is geŽindigd. Dat is waar, maar ook het hele OS daarmee aan.
Wat is je redering hierachter precies? Microsoft is ook gewoon doorgegaan met het ondersteunen van de volgende versie van Windows Phone. Ze hebben het hele OS niet laten vallen. Google stopt nu ook met het ondersteunen van Android 4.3. Het probleem is, in tegenstelling tot Microsofts 4 jaar, doet Google dat al na 1,5 jaar, en dat terwijl er nog steeds apparaten worden verkocht met 4.3 (en lager). Google ondersteund niet alleen WebView niet meer.
Mag ik je "paar jaar" corrigeren naar 1,5 jaar? Aub?

Komt nog eens bij dat er nog steeds een hoop toestellen met de 4.3 (en lager) worden verkocht.
Probleem is dat het niet over de stock browser gaat, maar WebView zelf. Je weet wel, dat ding dat verschillende apps ook gebruiken om webcontent te tonen? Dus nee, gebruikers van Android 4.3 of lager hebben niet de keuze, welke browser ze ook gebruiken, ze blijven kwetsbaar. Dit is zo'n beetje net hetzelfde als dat er een lek in Trident zou zitten ipv IE (of in Webkit ipv Safari voor OS X), door de browser niet te gebruiken, maakt je wel nog steeds gebruik van de engine in andere applicaties.

Als Google dat lek niet had gepubliceerd (met een proof-of-concept!) en netjes had gewacht tot morgen, was er dat probleem niet eens om mee te beginnen.
Probleem is dat het niet over de stock browser gaat, maar WebView zelf. Je weet wel, dat ding dat verschillende apps ook gebruiken om webcontent te tonen? Dus nee, gebruikers van Android 4.3 of lager hebben niet de keuze, welke browser ze ook gebruiken, ze blijven kwetsbaar.
- Elke fabrikant staat het vrij om zelf AOSP aan te passen, bij mijn weten heeft Google hier geen alleenrecht op
- Elke fabrikant staat het vrij om nieuwe Android-releases uit te brengen voor hun toestellen, daar heeft Google geen beslissingsrecht over
- Zoals teusink stelt kan elke developer blijkbaar ook zijn apps van Chromeview voorzien
De Android versies die door Google worden geleverd moeten echter wel via Google komen (wat HTC in een infographic heeft bevestigd). Het is dus uiteindelijk alsnog Google die de patches moet toestaan, want anders komen die er gewoon niet voor Google Android toestellen. Fabrikanten kunnen die patches wel doorsturen naar AOSP, dat is waar, maar dat brengt hen nog geen stap dichter bij als Google het niet toestaat.
En heb je dan ook informatie over of de fabrikanten dit ook proberen? Waarom zou Google het weigeren?
Ik zou zelf nog verder gaan en stellen dat het echt niet de fabrikanten zijn die horen te klagen hierover. De fabrikanten laten doorgaans (tenzij misschien voor hun absolute toptoestellen) een pak eerder dan Google zelf alle support voor de overgrote meerderheid van hun toestellen vallen.

Daarnaast kiezen de fabrikanten er, onder meer voor het gemak, zelf voor om Google's versie van Android te nemen, en dat heeft een aantal gevolgen. Dit is er dan eentje van. Ze kunnen altijd een eigen ROM maken bovenop AOSP ook.
Google heeft gezegd dat als men fixes wil zien voor oudere versies, dat de community die dan maar zelf moet maken.

Brong: https://community.rapid7....view-jelly-bean-and-prior
De grote vraag is nu...

Gaat Google al die Apps in de Playstore, die de oude Webview core nog gebruiken, verwijderen?

Aan de ene kant, de app deugt niet meer met 11 lekker in het onderliggend framework ---> Als je hem nu in zou dienen, zou hij er niet meer door komen waarschijnlijk. Al die in de playstore laten staan lijkt me instant een security risk.

Aan de andere kant, (en ik weet niet hoeveel apps webview.oud gebruiken maar ik doe ff een gooi) zou dat 5% van all Google Play apps opruimen..... HIer gaat Google niet blij van worden

Dus linksom of rechtsom, als Google echt stopt met deze support, zullen ze ook 1 van de twee bovenstaande opties moeten gaan uitvoeren (leven met security risk of apps verwijderen).


Mijn persoonlijke mening, Google speelt het spelletje vrij hard/lelijk. Fabrikanten zijn nu gewoon de lul door een soort van vendor lockin.
Ben benieuwd wanneer dit verhaal echt nadelig gaat worden voor gebruikers..... (als dat al niet het geval is met het verzamelen van bigdata)
Ja het is vergelijkbaar. 4.3 is 1.5 jaar oud o.i.d., en ze maken de web onderdelen niet updatebaar, dus alles wat ook maar iets met web doet is meteen zo lek als een mandje zonder mogelijkheden om het te patchen.
Ja het is vergelijkbaar. 4.3 is 1.5 jaar oud o.i.d., en ze maken de web onderdelen niet updatebaar, dus alles wat ook maar iets met web doet is meteen zo lek als een mandje zonder mogelijkheden om het te patchen.
Neen, een lek in de laatste versie van software is niet gelijk aan een lek in een versie van software die ondertussen al 2 versies achter ons ligt.

Maar zoals gezegd, daar zijn nog genoeg oplossingen voor. Ondermeer dat de fabrikanten hun nog geen anderhalf jaar oude toestellen gerust een OS-update zouden kunnen geven.

Als ze dat willen, natuurlijk.
Jawel, om dat het niet zoals Tweakers rapporteert over de browser gaat, maar over WebView, wat door belachelijk veel apps gebruikt wordt.

Verder is het aan Google om support te leveren voor Google software. Als ze daar mee stoppen gebeurt er gewoon niet. Dat is nou juist precies het hele model met Android en ook de reden waarom fabrikanten er zo veel toestellen van voorzien. In de meeste gevallen verdienen ze geld door sales. Sales krijg je niet als mensen hun toestel heel lang gebruiken. Dus geen updates = meer geld. En om dat ze het allemaal doen is er ook geen concurrent die als pluspunt heeft dat hun software wel updates krijgt. Alleen Google's eigen toestellen hebben dat. Bovendien willen mensen helemaal geen nieuw toestel kopen of een grote firmware update, ze willen een ding dat werkt en hebben het liefst dat dit soort security issues op de achtergrond onzichtbaar automatisch opgelost worden.
WebView is meer als alleen de browser, het is ook het platform voor webbased apps.
Het is helemaal niet zo schandalig. Vůůr Android 5.0 is WebView onderdeel van de ROM en wordt het steeds geŁpdate. Android 4.4 heeft niet meer de klassieke WebView, maar de Chromium WebView, welke nieuwer is. Na Android 4.4 is WebView los te updaten. Fabrikanten en netwerkproviders die wensen hun apparaten veilig te houden zijn hier verantwoordelijk nieuwe updates van WebView.

Net zoals Google Play Services het hele Play gebeuren buiten de handen van de ROM-bakkers en providers probeert te houden, gebeurt dat vanaf Android 5.0 ook met de browserengine. Maar bij oudere ROMs is dit gewoon hard ingebakken in Android zelf.
Om dit voorbeeld nog maals aan te halen: Microsoft en Apple zouden dus ook gewoon mogen stoppen met het uitsturen van updates naar oudere versies van hun besturingssystemen? Want het is voor jou dus okť dat die exploits alleen in de laatste versie worden hersteld, blijkbaar. Niks schandaligs aan als de ondersteuning van Windows Vista, 7, 8, Phone 8, OS X 10.7, 10.8 en 10.9 stopt. Zolang Windows 8.1, Windows Phone 8.1, iOS 8.1 en OS X 10.10 maar ondersteund worden. Toch?
Google kan geen support bieden voor ROMs van Samsung, Sony, HTC en dergelijke. Google maakt enkel Android. Andere fabrikanten dan Google zitten op de default browser engine die Google sinds Android 5.0 uit het filesystem heeft gesloopt en apart updatebaar heeft gemaakt om dit probleem in de toekomst onmogelijk te maken.

Je begrijpt volgens mij niet het concept dat de WebView versie vast zit geroest in het Android systeem en enkel met een systeemupdate kan worden verholpen. Google is hier machteloos. Enkel de telefoonmakers en (in sommige gevallen) providers hebben dit soort updates in handen.

De enige lijn die Google in handen heeft is de Nexus lijn. Vanaf de Nexus 4 is dit geen probleem meer en Google heeft het systeem zodanig geŁpdated dat dit nooit meer voorkomt. De Galaxy Nexus is ongelukkig gevallen door gebrekkig/geen driversupport voor de GPU-chip van de OMAP processor door TI's terugtrekking uit de mobiele markt. Het zijn echt de telefoonfabrikanten die het vertikken telefoons een update te geven, dan dat Google verantwoordelijk is. Android 4.4 is retelicht tegenover Android 4.3 dus er is geen enkel excuus voor telefoons met een niet-Texas Instruments chips om nog achter te blijven.

[Reactie gewijzigd door ikt op 12 januari 2015 22:05]

Maar Google levert de basis voor die ROMs. Als die niet worden voorzien van de fixes voor oudere versies, dan kunnen fabrikanten er ook niet veel meer aan doen.
Ze leveren zelfs de basis voor de nieuwste versie... ze mogen ook gewoon 5.0 uitleveren in plaats van 4.3 of 4.4.
Kwestie van updaten naar een versie die wel ondersteuning heeft. Bij Apple is het niet anders. De oude apparaten die niet naar hoger iOS kunnen blijven ook verstoken van updates op een gegeven moment.

Bij Android is het natuurlijk wel zo dat de fabrikant de upgrade moet regelen bij iOS zit je met dezelfde vendor. Ik denk dat Google door ook op probeert te sturen met dit statement om een nieuwere versie te pushen en fragmentatie te onderdrukken.

[Reactie gewijzigd door mjl op 12 januari 2015 21:53]

Op welke manier heeft Google er iets mee te maken dat fabrikanten het onmogelijk maken om (stock) naar de laatste versie van het OS te updaten, zelfs als het device het makkelijk aan kan?
Of dat een bende gebruikers nog steeds op 2.3.x blijven hangen?

Persoonlijk heb ik zodra een stabiele ROM beschikbaar was m'n Galaxy S II (stock blijft 'ie op 4.1.2 oid hangen) geŁpdatet naar 4.4.2. Juist om dit soort redenen (security, privacy, etc).

Zo verschrikkelijk moeilijk is dat niet, maar mensen zijn er vaak niet in geÔnteresseerd, nemen de moeite niet om te kijken of te vragen (bijna iedereen heeft wel een bekende die goed is met PC's/telefoons of hier wat van weet), of zijn in het geheel te lui om er over na te denken.
Dan moet je helaas geen Android kopen, maar een iPhone halen. Dan ben je verzekerd van x jaar updates die vrij eenvoudig via de iTunes bloatware geÔnstalleerd kunnen worden :)
Maar Google de schuld geven is natuurlijk veel makkelijker.
Dus.....de stock-browser behorend bij de versie van een besturings systeem wat in 2013 is uitgebracht word niet meer ondersteund? Ik zou dit graag bevestigd willen zien door Google zelf: dit zou toch te gek zijn. Dat zou Microsoft eens moeten doen....dan was de wereld te klein.
Mijn ervaring bij Windows was dat wanneer ze van bepaalde zaken af willen zoals bijv. een verouderde messenger ze je in een doolhof terecht laten komen van allerlei componenten die om onduidelijke reden op elkaar leunen en er samen voor zorgen dat die oude messenger het niet meer doet. Dat was naar mijn idee geen samenloop van omstandigheden maar doelgericht de gebruiker afhankelijk maken en bijna dwingen tot de aanschaf van nieuwe hard- en software.
De nadelen van een commercieel OS nodig hebben... Ze gaan er bij Google waarschijnlijk vanuit dat het toch wel blijft verkopen en ze veel kunnen maken. En ik vermoed dat dat ook klopt.
Daar kun je MS tegenwoordig toch niet van betichten? Het lijkt wel of elke nieuwe Windows met steeds minder resources genoegen neemt. Als ik eerlijk moet zijn vind ik MS de laatste jaren innovatiever bezig dan Apple. Maar ja....als je eenmaal je imago tegen je hebt.

Ik vind Android eerlijk gezegd een gedrocht. En niet om wat het OS in de basis is, maar wat Google er van gemaakt heeft. Laten we wel wezen....als je geen custom ROM installeert dan heb je gewoon een grote data-miner in je handen. En bij iOS is het iets minder erg...maar veel scheelt dat ook niet. Daarnaast heeft Android ook de nodige hardware-specs nodig om soepel te kunnen draaien. In vergelijking met Windows Phone of BB OS10 zelfs abnormaal veel....

Om heel eerlijk te zijn: het grote verkooppunt van Android is de grote app-store. Maar staat helaas de nodige rotzooi tussen....je moet niet gaan experimenteren ;)
Dat zou Microsoft eens moeten doen....dan was de wereld te klein.
Nog erger is dat dit uitkomt dezelfde tijd dat Google Microsoft een poot lapt.

Maar ja, dit is bevestigd door Google zelf. 2 maal. Ze zeggen dat als men wil dat er security updates komen voor Android 4.3 en lager, dat de community die dan maar moet maken.

Bron: https://community.rapid7....view-jelly-bean-and-prior
Google zou tegen Rapid7 hebben gezegd dat browsers die niet over die engine beschikken, te oud zijn om nog langer te ondersteunen. Het gaat daarbij om software op apparaten van derde partijen.
Wel, Xiaomi heeft werk voor de boeg.
Gebruikt Xiaomi wel de stock browser dan? De integratie met Google services in de Xiaomi-browser werkt zo goed dat ik denk dat het een aangepaste versie van Chrome is. Maar ze mogen nu wel eens over naar Lollipop ja.
Nou denk het niet, hun hebben een eigen ROM met een eigen browser :)
Wat niet eens baseert op die van de standaard webbrowser in android.

+ het feit dat XIAOMI een super grote community achter zich heeft, en dus makkelijk mocht het toch een lek zijn makkelijk zelf verhelpt (hebben toch de sourcecode etc)
Android en een stock browser.. waarom niet gewoon Chrome (of elke andere browser)?
Omdat Android niet Google Android is ;) Google Android is ( duh) wat Google ervan gemaakt heeft en distribueert. Android is gewoon een OS van de Open Handset Alliance, en de stock browser daarvan heeft verder niets met Google te maken.
Als je op een wat trager toestel zit is chrome niet vooruit te branden. (chrome is volgens mij pas soepel op een dual core met 1gb ram). Veel mensen snappen ook het verschil niet echt denk ik tussen de twee, want 'Browser' lijkt meer to the point dan 'chrome'.
Het wordt tijd dat smartphones ssd controllers krijgen zodat vaak flashen geen probleem is en voor een nieuwe generatie mobiele besturingsystemen die net als de desktop besturingssytemen ook echte systeemupdates kunnen krijgen.
Nu heb je alleen app updates en hoewel dat flink helpt blijft het achterlopen van het OS zelf een probleem. Al die OS aanpassingen die de telefoon fabrikanten zelf doen en die vrijwel altijd ver achterlopen als je toestel uberhaupt nog een update krijgt zorgen ervoor dat oudere telefoons snel minder veilig worden.
Daarom is het nu zo (/te m.i.) belangrijk dat als je een nieuw toestel koopt je zorgt dat het recent model is met een hele recente versie van Android zodat je niet meteen achteloopt en een redelijke kans hebt dat je ook daadwerkelijk een OS update krijgt later.

Alternatieve ROMS zoals Cyanogenmod zijn ook lang niet altijd een uitkomst, want als je toestel ondersteund wordt zijn er vaak veel bugs en daarnaast is updaten naar nieuwere OS versie dan de fabrikant levert vaak lastig of niet te doen, vooral vanwege de vele closed source hardware drivers.

Apple doet het hier beter maar is er ook nog niet, daarnaast is een iPhone ook flink duurder dus dan is het fijn dat die ook wat langer meekan.

De smartphone hard- en software heeft nog een lange weg te gaan, het lijkt me ook dat als het wat volwassener wordt en de snelheid van updates omlaag gaat de ondersteuning ook makkelijker beter kan.
Het domme van die hele smartphonemarkt vind ik het feit dat een smartphone gewoon een computer met netwerkaansluiting is, waarbij vanwege het kleine scherm een enigzins andere GUI vereist is. Een minimalistisch basisplatform waarop alle software draait die compatible is met de hardware zou voor de consument veel meer perspectieven bieden dan wat er nu in de winkel ligt. Je krijgt bij je computer verplicht een softwarebrouwsel door de strot gedouwd die eerder beperkend is dan innovatief. Daar komt dan een mooi praatje over gebruiksvriendelijkheid en veiligheid bij maar de realiteit is dat we al een flink aantal decennia software op consumentencomputers draaien en er ontelbaar veel partijen zijn die voor goede en veilige systeemsoftware kunnen zorgen. Dat alleen een paar grote multinationals dat kunnen lijkt me onzin.
Maar goed, zolang iedereen dat spul blijft kopen verwacht ik niet dat er iets gaat veranderen. Vroeger bepaalde de hardwarefabrikant de grenzen van het kunnen van je systeem. Nu hebben softwaremakers de touwtjes in handen gekregen en die hardwaremakers in de zak. Zou het komen omdat te veel meeste mensen het verschil niet begrijpen?
Hoewel ik het voor een gedeelte met je eens ben, ben ik het niet eens met je oplossing voor een SSD. De opslag van de broncode heeft geen effect op het wel of niet hebben van exploits. Dit heeft ook geen invloed op het veiliger maken van code. Hier heb je er wat achtergrond informatie over (bron). Flash geheugen is herprogrammeerbaar geheugen net als een SSD herprogrammeerbaar geheugen is. Het verschil tussen een FlashROM en SSD is dat, FlashROM in een keer gewist kan worden en niet zomaar herprogrammeerbaar is. Dit maakt FlashROM een veiligere techniek om te gebruiken dan SSD of een ander medium wat on the fly aan gepast kan worden.

Daarnaast moeten hand held devices zo energie zuinig zijn als mogelijk is. Om dit voor elkaar te krijgen kiezen fabrikanten ervoor om ARM microcontrollers te gebruiken. Dit zijn slimme chips die een subset van activiteiten aankunnen zonder de complexe processor architectuur van een PC. Dit maakt het mogelijk om steeds kleinere slimmere apparaten te maken. Om dit voor elkaar te krijgen ben je dus afhankelijk van een stukje hardware dat op basis van gecompileerde code werkt. Microsoft probeert deze dichter bij elkaar te krijgen, echter ook hun komen er niet onderuit dat ze hun OS moeten compileren voor smartphones. x86 en Arm zijn twee architecturen die niet met elkaar te vergelijken zijn. x86 is meer geschikt voor grote vermogens en de Arm architectuur meer voor embedded toepassingen.

Apple doet het niet beter nog slechter, deze leveren met iedere generatie een volledige nieuwe versie van een OS. Vaak zie je helaas ook dat deze OS'en wel geoptimaliseerd zijn voor de generatie die er mee uit komt maar niet oudere generaties waardoor deze apparaten trager lijken te worden.

Waar ik het wel volledig met je eens ben is dat smartphone hard-en software nog een lange weg te gaan heeft en dat de ondersteuning beter moet.

[Reactie gewijzigd door _wolf_ op 12 januari 2015 23:15]

De reden dat ik een SSD controller of iets dergelijks wil is omdat Flash slechts beperkt herprogrammeerbaar is. Met een slimme controller kan de levensduur omhoog en/of kan de telefoon vaker een nieuwe firmware krijgen zonder dat de levensduur korter wordt. Daarnaast zou het ook sneller zijn. Ik ben dus niet voor een SSD qua veiligheid van de storage an sich, en dat had ik niet vermeld.

Ik heb het idee dat een Apple smartphone langer ondersteund wordt qua nieuwe firmwares dan het gemiddelde Android apparaat en dat lijkt me een goede zaak. Als de oude hardware daardoor niet goed meer werkt is dat wel een minpunt ja, maar ik heb nooit een Apple gehad en dus geen ervaaring mee, want ik vindt een Apple veel te duur voor een apparaat dat ik maar een paar jaar gebruik.
Ik nam veiligheid als voorbeeld dit het enige verschil is tussen beide. FlashROM en SSD is exact dezelfde techniek met 1 verschil. FlashROM wordt in zijn geheel gewist i.p.v. byte sized elementen zoals mogelijk is bij een SSD. Het verschil is de controller niet het geheugen. Dus je argument van beperkt programmeerbaar kan ik niet echt plaatsen zou je dit willen toelichten?
Bij een SSD zorgen een stukje extra (niet zichtbaar Flash geheugen) en een slimmere controller ervoor dat niet steeds dezelfde stukken geheugen overschreven worden (waardoor de levensduur snel achteruit gaat) Bij een simpele USB stick of flash geheugen zonder deze features wordt precies hetzelfde stukje overschreven als je een bepaald stukje van de code steeds update.
Stel we updaten elke week de linux kernel dan gaat een SSD veel en veel langer mee dan een USB stick ook al zijn ze even groot en voorzien van diezelfde flash chips
Waar jij op doelt is storage, Storage is niet hetzlefde als FlashROM. Voor ik uitleg waarom SSD niet de oplossing is ff een stukje uitleg voor andere mensen want ik denk dat je het al begrijp (skip naar -> om de uitleg te skippen)

FlashROM kan je een beetje vergelijken met de flash in een computer waar je BIOS op staat. Dit is een stuk fysiek geheugen wat niet aangepast mag worden on the fly. In de BIOS staat de verwijzing en beveiligingen naar je hardware. Dit gedeelte staat vaak los van de rest van het OS die ook bij embedded devices uit Storage (vaak ook NAND memory) geladen wordt.

De communicatie tussen de fysieke laag aan de API laag is bij een microprosessor architectuur is modulair, dit houd in dat deze communiceert met een specifieke chipset die omgaat met je hardware. Een microcontroller architectuur werkt anders. De microcontroller is zowel de microprocessor als de chipset. Daarom moet het OS gecompileerd zijn voor een embedded device omdat een microcontroller overweg moet gaan met machine taal instructies. Het verschil tussen hardware laag en software laag is gewoon vervaagt.

Omdat OS's (Android, iOS, Windows) instructies bevatten voor de hardware laag, (anders heeft het geen zin om een OS te ontwikkelen) betekend dat ook deze geÔntegreerd dienen te worden voor een gedeelte op Flash. Een OS is niet iets wat communiceert met een microcontroller maar code die voor een gedeelte bestaat uit microcontroller code.

->

Je kan de machine code natuurlijk ook op de bootsector plaatsen van je storage device. En ja natuurlijk heb je gelijk als je zegt dat meer geheugen er voor zorgt dat je vaker de embedded code kan wijzigen. Echter je gaat hier totaal voorbij aan de reden waarom het initieel in Flash zit. In Flash zitten de instructies voor de microcontroller. In tegenstelling tot microprocessor zijn dit veel meer instructies en dus ook een groot deel van je OS (zie eerdere uitleg).

Je wil de machine booten met de juiste instellingen, dit is zelfs voordat de memory management systeem actief wordt. Voor je de software initialiseert wil je al dat je machine weet welke hardware deze heeft en hoe deze aan te sturen. Eenmaal opgestart maakt het niet meer uit hoe je storage benadert. Doe je dit vanaf SSD dan moet je minimaal al weten op welke IO pinnen deze staan en hoe hier mee te communiceren. Ook hier geld weer dan moet je weten welke instructies uit te voeren en dat moet je dus ergens vandaan halen. Daarnaast zit in een SSD ook een microcontroller met zijn eigen flash geheugen om te weten hoe de memory chips te benaderen. Dus het op een SSD zetten van de instructies van een microcontroller, die weer zijn eigen flash heeft om te weten hoe geheugen te benaderen is een beetje zinloos. Dus op dit punt ben ik het met je oneens, je kan het veel beter op 1 flash chip hebben staan.

Wat je eigenlijk wil hebben is een universele API en een gedefinieerd hardware ontwerp voor embedded oplossingen. Dat is ook precies wat OS's zijn. Er zijn nu een aantal organisaties die hun oplossing hiervoor pushen (Apple, Google, Microsoft, Linux foundation). Het probleem hiermee is dat de hardware niet genoeg gestandaardiseerd is. Dit is zowel de kracht als het zwakte punt van embedded devices. Het is de kracht omdat het daardoor makkelijk mee gaat met nieuwe technologische ontwikkelingen, het zwakte punt omdat software organisaties hun oplossing willen pushen.

Maar laat ik mee gaan in je theorie. ARM krijgt native ondersteuning voor NAND memory los van toepassing. Geen gedoe meer met controllers, gewoon benadering van massief geheugen. Dat zal een betere oplossing zijn. In dat opzicht ben ik het wel met je eens.
Dat is 1.5 jaar na verschijnen van de 4.3 release. Tamelijk kort voor een serieus OS, tenzij dat alle Android devices ook naar een hogere versie kunnen. Uiteraard zijn er andere browsers, maar dit draagt niet bij aan een 'milieuvriendelijk' gebruik. Een langere levensduur vereist ook minder materialen voor fabricage.
En dan een lek openbaar maken van Microsoft omdat ze niet snel genoeg reageerden op de melding van het lek 8)7

[Reactie gewijzigd door Swerfer op 12 januari 2015 20:17]

Als je veiligheids bewust en duurzaam kiest, heb je lange tijd meer zekerheid als je een telefoon koopt met een os gemaakt door de fabrikant zelf.
Bij externe fabrikanten die het gratis en populaire os van de advertentie-verkoper heb je niet altijd garantie op langdurige software support. Wat dat betreft kun je nu veiliger en duurzamer kiezen voor een apparaat met:
  • Apple IOS
  • BlackBerry, met Bbos10 .x
  • Windows Phone 8.x
Of gaan voor een nexus apparaat van Google zelf, want daarbij wordt de software ontwikkeld door het bedrijf zelf en is de fabrikant ook de os-maker. dan heb je langer de zekerheid van updates.

[Reactie gewijzigd door nul07 op 12 januari 2015 20:28]

De Nexus is ook geen betrouwbare keuze want Google garandeert ook maar maximaal 18 maanden aan updates. Ik krijg steeds meer de indruk dat Google absoluut geen interesse heeft in de ondersteuning van Android. Met mijn Oneplus One leun ik nu op Cyanogenmod. Hopelijk gaat dat wel beter.
iphone 4 verkocht tot Eind 2013, laatste update juni 2014.

http://www.intego.com/mac...-your-iphone-4-right-now/
Wat heeft dit met Microsoft te maken :S plus het feit dat bij Microsoft het zelfs in Windows 8.1 is gebeurd is nog een schandaligere punt.

Microsoft had de deadline niet gehaald en daarvoor boeten ze nu.
Als jij een boete krijgt, en jij betaald die niet op tijd. Dan krijg je een nieuwe boete waar je nog meer voor moet betalen.

Plus het feit dat dit niet eens om een ''Google chrome'' gaat maar om de standaard browser...
Verwarring kan wel ontstaan door de benaming "Standaard browser" aangezien Chrome for Android op dit moment de standaard browser is voor Android.

Overigens vind ik dit wel erg vroeg om hier voor te kiezen, zeker met een markt dat nog voor 60% bestaat. Alleen is het wel zo dat 60% moeilijk terug te dringen is als er mensen me oudere telefoons rond lopen die geen update meer ontvangen.

Het blijft een lastig verhaal met Google en updaten van Android. Ben benieuw of Google ooit in toekomst een mooie oplossing hiervoor kan gaan verzinnen.
En toch levert Samsung (ook bij bv. de Note 4) een andere browser dan Chrome standaard mee bij zijn toestellen. Waar zou die dan op gebaseerd zijn?
Samsung kennende op Webview. Die Koreanen hebben serieus last van het NIH syndroom. Bouwen overal een laagje omheen en maken de ene na de andere app die vaak meer kan maar waarvan minder werkt.

Aldus gepost vanaf mijn stock Galaxy S3 :+
Microsoft had de deadline niet gehaald en daarvoor boeten ze nu.
Als jij een boete krijgt, en jij betaald die niet op tijd. Dan krijg je een nieuwe boete waar je nog meer voor moet betalen.
Waarom zou een bedrijf precies akkoord moeten gaan met een "boete" die door een concurrent is opgelegd?
Plus het feit dat dit niet eens om een ''Google chrome'' gaat maar om de standaard browser...
Waarom maakt dat uit? Het is een veelgebruikt component, Google raadt ontwikkelaars aan het te gebruiken, het gaat om het meerendeel van de Androidgebruikers, en het is een van de meest gebruikte aanvalsvectoren voor Android-exploits. En Google heeft nu zoiets van "Tja, jammer." Beetje hypocriet dan om anderen de les te lezen dat ze een door jou opgelegde deadline niet halen, nietwaar?
Ik zie vele negatieve reacties ten aanzien van Google maar dit is in mijn ogen volledig ongegrond. Het is niet Google die ervoor zorgt dat menig telefoon niet meer wordt bijgewerkt naar een nieuwere versie Android; Dat moet je toch echt enkel en alleen bij de telefoon fabrikant zijn! Die zijn nalatig. Niets anders.
Je kan ook niet verwachten dat fabrikanten alle toestellen blijven ondersteunen. Ze kunnen zeker wel die toestellen updaten naar KitKat of Lollipop, maar de toestellen die op Jelly Beans blijven hangen moeten ook gewoon voorzien worden van security updates. Dit zijn kleine - maar belangrijke - aanpassingen aan de ROMs die fabrikanten gebruiken die dan gepushed moeten worden, simpeler dan even KitKat of Lollipop gaan gebruiken. Microsoft vereist toch ook niet dat je maar direct naar Windows 8.1 moet updaten als je nog security updates wilt hebben. Apple vereist toch ook niet dat je maar naar OS X 10.10 update om nog security updates te krijgen. Wat ze wel doen is fixes uitbrengen voor oudere versies van hun OS op desktop en mobiele apparaten die geen overdreven oude leeftijd hebben updaten naar de laatste versie (heck, zelfs de iPad 2 wordt nog ondersteund).
Nogmaals, dan is het aan de fabrikant om je stock firmware aan te passen, niet Google. Google heeft al meerdere malen geroepen dat de fabrikanten vaker en meer updates moeten uitbrengen. Dat het volgens vele fabrikanten niet kan (lees: niet rendabel, te duur) is wederom niet Google ten laste te leggen.

En nee, ik ben geen Google freak.
Dat is hetzelfde als zeggen dat Microsoft dan maar zomaar de stekker uit Windows Vista, 7 en 8 zou mogen trekken om enkel Windows 8.1 te ondersteunen en dan tegen hun klanten te zeggen dat ze maar naar Windows 8.1 moeten updaten.

Opnieuw: het is Google die eerste die updates moet maken, zij leveren die aan fabrikanten. Zij moeten fabrikanten voorzien van nieuwere versies. Of moeten OEMs nu ook fixes voor Windows gaan aanleveren aan Microsoft? De omgekeerde wereld noemen we dat.
Opnieuw: het is Google die eerste die updates moet maken, zij leveren die aan fabrikanten. Zij moeten fabrikanten voorzien van nieuwere versies.
En dat doen ze toch ook, we zitten inmiddels op Lollipop. Maar het zijn de fabrikanten die dat niet doorspelen naar de gebruikers.

Je vergelijking met Microsoft gaat helaas mank; bij een PC kun je fijn zelf kiezen welke OS je wilt installeren, bij nagenoeg alle telefoons heb je die vrijheid helaas niet.
Ze brengen upGRades uit, geen upDates. Oudere toestellen die niet naar 4.4 of 5.0 worden geŁpdatet worden nu gewoon aan de kant gezet terwijl het helemaal niet moeilijk is (relatief) die fix te maken en een nieuwe versie 4.3.2 te maken.

Het missen van die vrijheid is een reden om geen OS updates meer door te voeren?
Misschien begrijp ik jou niet maar ik zie het toch echt zo;
  • Google onderhoud de OS
  • Google geeft de nieuwe release vrij aan fabrikanten
  • Fabrikanten pushen deze niet naar de gebruikers
  • Gebruiker is de dupe van de nalatigheid van de fabrikant
Ik snap de verschillen wel tussen updates en upgrades wel. En ja, om het voorbeeld van Microsoft maar weer aan te halen, toen aangekondigd werd dat XP EOL was konden (en kunnen nog steeds) vele gebruikers overstappen naar een ander OS die wel ondersteuning geniet. Hetzij van Microsoft zelf en anders in ieder geval naar Linux.
Alleen maakt Google nu geen releases voor de oudere versies die deze bugs oplossen. Fabrikanten kunnen die veel makkelijker pushen dan volledig nieuwe versies van het OS. Het gaat al fout bij Google deze keer, niet bij de fabrikanten.
Ik ben het deels met je eens alleen vind ik dat dan de fabrikant (en in sommige gevallen is dat Google zelf) ervoor moet zorgen dat jij als gebruiker dan in dit geval naar 4.4 getild wordt, snap je? En daar zit 'm nou de crux. Ik vind dat het in veel gevallen te snel wordt gezegd dat het niet kan, om welke reden dan ook terwijl dat "kunnen" niets anders is dan een financiŽle barriŤre waar je als gebruiker geen invloed op hebt of boodschap aan hebt. Sterker nog, je bent dan juist de dupe ervan.

Menig telefoon is zeer goed in staat om stock 4.4 of zelfs 5.0 te draaien maar dan kan de fabrikant niet zijn eigen skin cq draai eraan te geven (Touchwiz van Samsung bijvoorbeeld).
Ik ben het daar ook mee eens, fabrikanten moeten zoveel mogelijk toestellen updaten naar de recentste versie, zoals al gebeurd bij Windows Phone en iOS. Maar je moet ook redelijk blijven: niet alle toestellen krijgen die updates, waaronder de oudere devices. Maar dat die geen nieuwe features meer krijgen zou niet mogen betekenen dat die geen nieuwe fixes meer krijgen. En dat moet gebeuren via X.X.1 releases, niet via X.1.0 releases.
niet alle toestellen krijgen die updates, waaronder de oudere devices.
Helemaal mee eens maar dan moet je toch erkennen (en daar draait mijn betoog juist om) dat Google daar geen invloed op heeft.

Ik zou juist dan willen zien dat de fabrikant dat toestel geheel vrij geeft zodat je dan als gebruiker een ander (lees: "beter") OS erop kan zetten.

[Reactie gewijzigd door pasarica op 12 januari 2015 22:41]

In de gevallen dat Google de fabrikant is, doen ze dat zelf ook niet voor langere perioden. Het is wel erg gemakkelijk van Google om te blijven wijzen naar de fabrikant. Google heeft een verantwoordelijkheid in deze. Windows 7 support krijg je tenslotte ook van Microsoft en niet van Dell of Lenovo.
Dat de ondersteuning van Android een drama is kan ik goed begrijpen. Als ik (als ontwikkelaar) kijk naar Android krijg ik niet het gevoel dat Google goed weet waar ze naar toe moeten. Een product ontwikkelen en onderhouden is iets anders als een leuke prototype maken. In dat laatste is Google wel sterk, dat eerste echter niet.
Hoe zit dit met browsers die op de AOSP browser zijn gebaseerd? Zoals de browser van Samsung bv. Zijn vanaf nu alle galaxy's vatbaar voor deze 11 exploits? Echt schandalig dat dit gebeurd, al kijk je in de PW worden er in NL 499 telefoonmoddelen verkocht met Andriod 4.3 of lager tegen over 376 telefoons me tAndriod 4.4 of 5.0. Er zijn dus meer modellen te koop die vatbaar zijn voor deze exploits dan modellen die niet vatbaar zijn 8)7
De AOSP browser is WebView, voor zover ik weet. En het probleem zit in WebView. Dus het antwoord op je vraag is ja.*

*Vele fabrikanten leveren een aangepaste versie van WebView mee, mogelijk zijn sommige varianten van die WebView (verschillend van fabrikant tot fabrikant, versie tot versie en device tot device) niet kwetsbaar voor al deze exploits, maar ga er maar van uit van wel.

[Reactie gewijzigd door Loller1 op 12 januari 2015 21:19]

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 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