Sommige Chromecast-gebruikers kunnen niets afspelen door verlopen certificaat

Gebruikers van de tweede generatie Google Chromecast hebben problemen met hun apparaat gemeld. Het accessoire zou niet meer functioneren vanwege een verlopen certificaat. Google is op de hoogte van de problemen en werkt aan een oplossing.

Op zowel de subreddit van Chromecast als een ondersteuningspagina van Google Nest zijn er meerdere klachten van gebruikers te lezen die aangeven dat hun Chromecast plots niet meer werkt. Het is volgens de gebruikers niet meer mogelijk om content via de Chromecast te streamen, ook al is er geen fysieke schade aan het product. In bijna alle gevallen lijkt het te gaan om de tweede generatie Google Chromecast, al bestaat daarover nog geen uitsluitsel.

Google heeft op het moment van schrijven nog niet officieel gereageerd op de klachten, maar het Amerikaanse bedrijf zou wel op de hoogte zijn van de problemen en een onderzoek hebben ingesteld. Een enkele Reddit-gebruiker claimt in een post dat er sprake is van een verlopen authenticatiecertificaat. De geldigheid van dit certificaat zou volgens de gebruiker op 9 maart 2025 om 16.44:39 zijn afgelopen. De gebruiker stelt dat Google dit probleem kan verhelpen. Het is niet duidelijk of en wanneer de techgigant dit zal doen.

Update, 09.35 uur - Google heeft via Reddit gereageerd op de problemen van de gebruikers en is op de hoogte van de problemen bij Chromecast van de tweede generatie en bij Chromecast Audio. Het bedrijf werkt aan een oplossing en raadt gebruikers aan om hun apparaten niet naar fabrieksinstellingen te herstellen. Het bedrijf komt op een later moment met een statusupdate en zal dan ook instructies delen om de problemen te verhelpen bij gebruikers die hun apparaten wel naar fabrieksinstellingen hebben gereset.

Chromecast 2

Door Jay Stout

Redacteur

10-03-2025 • 07:21

191

Submitter: mlacos

Reacties (191)

191
190
83
7
0
83
Wijzig sortering
clients die zich niet aan de optionele device authentication hielden werken nog:
device authentication is performed by the client (e.g. Chrome, the Android Cast SDK, or the Google Home app) and is optional. All of Google's official clients do it, but many unofficial clients don't. For example, VLC can still cast just fine to my device.
hierdoor is factory restten dus nog slechter:
Google issued an intermediate CA, presumably the one for all 2nd-gen devices, with a validity period of only 10 years, and it just expired. As a result, none of Google's official clients succeed in validating the device as genuine and they refuse to talk to it, including during initial setup.
*update* er zijn verschillende workarounds gepost waardoor de authenticatie wordt gebypassed:
  • Fix casting from Android (GUI method)
  • Fix casting from Android (ADB method)
  • Fix casting from Chrome and other Chrome-derived browsers
  • Fix device setup from the Google Home Android app

[Reactie gewijzigd door dasiro op 11 maart 2025 23:12]

Maar zo'n certificaat kun je toch vernieuwen? Je krijgt dan gewoon een nieuwe.

Beetje gek dat ze dit niet hebben gedaan. Maar Google vertrouw ik dan ook voor geen meter mee. Ze zijn bij hun hoofd allang hoe snel je mensen kunt pushen naar GoogleTV (of bestaat die ook al niet meer?).

De vorige gens waren echt dummy's, nu heb ik een Google TV met veel reclame, ook al zit ik enkel in de app mode.

[Reactie gewijzigd door HollowGamer op 10 maart 2025 09:50]

Alleen moet je dan het certificaat op het apparaat vervangen, en die wordt niet meer vertrouwd door de software die dat moet doen omdat het certificaat verlopen is...

Ik heb dat hele idee van een houdbaarheidsdatum voor een certificaat nooit begrepen, vooral voor embedded devices. Het zorgt ervoor dat ze (1) een betrouwbare klok nodig hebben en (2) dat ze periodiek diepgaande firmware upgrades nodig hebben om gewoon te blijven functioneren. Het levert een hoop ellende op en draagt nuchter bekeken helemaal niks bij aan veiligheid. Voor embedded devices is het effect juist dat ze er minder veilig van worden.

Stel dat een key uitlekt, dan maakt het niet echt uit of die geldig is tot 2035 of "eeuwig"...
Maar je hebt het hier over een device dat vooral gebruikt wordt om content te streamen en dus in verbinding staat met het internet.

Je trekt toch het hele nut van een vervaldatum binnen certificaten niet in twijfel?

Wat google had moeten doen, is tijdig hun certificaat vervangen. Dit zou ook gewoon een automatisch process moeten zijn en nooit voelbaar mogen zijn voor de gebruikers.
Je trekt toch het hele nut van een vervaldatum binnen certificaten niet in twijfel?
Jawel, dat is precies wat ik doe.
Die vervaldata zijn anders een fundamenteel onderdeel van het PKI-principe. En hoewel ik niet aan de tafel zat waar certificaten bedacht zijn en niet uit eerste hand weet waarom zaken zijn zoals ze zijn, kan ik me wel een voorbeeld voorstellen waarbij die vervaldatum essentieel is.

Zoals je wellicht weet kan elke CA alle certificaten afgeven, zolang ze maar gebruik maken van een door de browsers/clients vertrouwd root-certificaat. Stel je nu eens voor dat ik een domain X heb en er een certificaat voor aanvraag. Ik doe er verder niets mee en laat het domain vervallen. Het domain wordt dan voor een bepaalde tijd in de ijskast gezet. Noch ik, noch iemand anders kan het domain dan registreren. Na die tijd komt het domain weer op de markt, vrij te registreren voor iedereen.

Nu heb jij intresse in domain X en registreert dat domain. Je gaat er vervolgens een website op hosten en gebruikt daarvoor een nieuw aangevraagd certificaat. Mocht mijn certificaat onbeperkte geldigheidsduur hebben, dan kan ik mijn certificaat misbruiken. Natuurlijk is er meer voor nodig, zoals het het manipuleren van DNS, maar toch, de essentie van een certificaat, betrouwbaarheid is dan geschonden.

Natuurlijk zijn er ook methoden om certificaten in te trekken zoals de certificate revocation lists. Echter worden die niet veel toegepast omdat ze een extra stap vereisen bij de validatie van het certificaat. En stel dat elk certificaat een link naar de CRL zou bevatten, dan kun je je ook wel voorstellen wat voor een gigantische lijsten dat gaan worden. En al helemaal als die lijsten niet geschoond kunnen worden door de verlopen certificaten er uiteindelijk uit te gooien.

Maar ookal zou je een CRL gebruiken dan moet jouw certificaat-provider eerst gaan onderzoeken of er al een certificaat bestaat voor domain X. En zo ja, dan moet jouw certificaat-provider eerst met die van mij contact opnemen om mijn certificaat te laten schrappen. En wat... als mijn certificaat-provider failliet is? Dan zou de curator contact moeten opnemen met alle browser-fabrikanten om het root-certificaat ongeldig te verklaren.

Benieuwd naar de chaos die dat oplevert? Zoek dan maar eens op Diginotar. Oké, die werd gehacked in plaats van failliet te gaan, maar het effect was hetzelfde. Van de ene op de andere dag werkte geen van de door Diginotar uitgegeven certificaten meer. De halve Nederlandse digitale overheid lag toen even op zijn rug.

Nu kan het aan mijn beperkte visie liggen, maar een certificaat behoort voor mij gewoon een begin en einddatum te hebben.
Er bestaan naast webservers ook andere toepassingen van certificaten.

Stel je maakt een medisch apparaat (dat niet aan het internet verbonden is, of hoeft te zijn).

Als bedrijf wil je dan een veilige verbinding opzetten om bijvoorbeeld een software update uit te voeren, of als arts wil je de data van het apparaat halen waar de patient mee rond heeft gelopen. Je kunt daartoe elk apparaat voorzien van een eigen certificaat, gekoppeld aan een ingebakken uniek nummer van het apparaat. Het certificaat is getekend door de fabrikant tijdens productie. Nu kun je veilig communiceren zonder bang te zijn voor een man-in-the-middle.

Als je zo'n apparaat 'hackt' (bijvoorbeeld door hem open te schroeven) dan blijft het bij dat ene apparaat - de private key, als je die eruit gepeuterd krijgt, werkt niet op andere apparaten.

Als je nu een "datum" op dit certificaat gaat zetten, dan moet het apparaat ineens weten hoe laat het is (en dat dan ook nog op betrouwbare wijze). En je moet het certificaat, wat tot nog toe in read-only memory kon staat, kunnen aanpassen. Qua veiligheid voegt de "datum" helemaal niets toe - omdat het apparaat in een gesloten omgeving zit, kun je de "datum" naar believen aanpassen. En juist het (remote) kunnen aanpassen van de firmware opent een deur voor hackers.
Jouw voorbeeld schiet zijn doel eerlijk gezegd voorbij. Certificaten voegen een vertrouwenslaag toe op een public-private key infrastructuur. Ze hebben tot doel om vertrouwen te realiseren in een omgeving waar dat vertrouwen niet bestaat; je vertrouwd erop dat de uitgevende CA bepaalde controles heeft toegepast voordat het een certificaat uitgeeft. Controles waardoor jij 'zeker' kunt zijn dat het ondertekende certificaat ook echt behoort bij de persoon/organisatie/apparaat die het certificaat presenteert.

In jouw voorbeeld geef je aan dat de fabrikant tijdens de productie dat certificaat ondertekent, en in dat geval geef ik je gelijk dat de fabrikant certificaten aan kan met oneindige geldigheid. (31 december 9999 vind ik best wel oneindig; ik hoop het niet mee te maken). Maar, dat betekent dat de root-certificate óók diezelfde datum als einddatum moet hebben; immers een certificaat kan nooit een langere geldigheid hebben dan het certificaat wat hem ondertekent. Jouw fabrikant begeeft zich daarmee op glad ijs; wanneer de private-key van het root-certificate ooit uitlekt (of wordt uitgerekend) dan zijn AL hun uitgegeven certificaten in AL hun apparaten nutteloos. Immers, alle certificaten kunnen dan door de aanvaller opnieuw worden uitgegeven.

Toch, ik snap jouw use-case en denk dat een certificaat hier geen toegevoegde waarde heeft. Het is de fabrikant die de apparaten maakt en voorziet van een private-key. Waarom kan de bijbehorende public-key niet in een database worden opgeslagen? Wordt die database gehacked, who cares?! Het zijn slechts public-keys! Een arts kan bij de eerste verbinding met een medisch apparaat de public-key opzoeken en die opslaan voor later. Bij elke volgende verbinding wordt diezelfde public-key gebruikt. Komt die niet overeen? Dan is er iets mis.

Last not least, een apparaat die een certificaat bevat hoeft zelf geen benul van de tijd te hebben. Hooguit om te weten of zijn eigen certificaat nog geldig is. Het is de client die de controle doet. Behalve als je het hebt over bijvoorbeeld Kerberos; maar dan heb je het niet over certificaten maar over tickets met een beperkte lifetime.

Gaan we even terug naar de chromecast dan is het (zoals ik het begrijp) een certificaat wat gebruikt kan worden door apps van derde partijen om te verifiëren dat ze met de juiste chromecast van doen hebben. In dat geval betreft het dus een publiek certificaat. En die wil je gewoon met datum hebben. Immers, beter een fail-close dan een fail-open situatie.

Vervolgens is het aan de software om te kijken wat ze met een verlopen certificaat doen. (Waarschuwen en) alsnog verbinden? Verbinding verbreken? Ik denk dat een app medische app eerder de verbinding zal verbreken terwijl een app als Tiktok eerder zal verbinden. Of... ze laten de encryptie helemaal links liggen en hebben nergens last van.
In het geval dat de fabrikant zelf de devices van een certificaat voorziet is er geen derde partij in de vorm van een CA in het spel - de fabrikant is zijn eigen CA en alles zal dus gestoeld zijn op een self-signed certificaat van de fabrikant. Dat is juist de meest veilige situatie.

Op het internet heb je geen directe relatie, en daar is die constructie met een derde partij CA nodig om "vertrouwen" op te kunnen baseren.

Mijn dagelijkse use case is deze: Als ik een SSH sessie open met een van "mijn" apparaten dan presenteert die mij ook een host key die ik kan verifieren. Ik weet dus ook zeker dat ik met "mijn" apparaat communiceer, zonder iemand ertussen die mee kan kijken. Zonder die "host key" zou een attacker gewoon een SSH service kunnen aanbieden die genoeg op "mijn" apparaat lijkt en daarmee mogelijk allerlei geheimen ontfustelen...
Ja prima, maar SSH gebruikt (standaard) geen certificaten. Kan wel, maar het voegt niets toe.

En zoals ik al met een voorbeeld aangaf, als de CA van de fabrikant gecompromiteerd wordt, zijn alle uitgegeven certificaten waardeloos. Alle beveiliging is in 1 klap weg.

Dus waarom zou je in dat geval dan een certificaat-infrastructuur optuigen? Het maakt je alleen maar kwetsbaarder. Bedenk dat ookal heb je een certificaat, de verbinding nog altijd via een public-private-key pair wordt opgezet. Dus één private key (host-key) per apparaat, en de public-key in een database (of known_hosts). Een certificaat voegt hier niets verder aan toe.
Certificaat zorgt dat die database met public keys niet nodig is. Als je elke dag een paar apparaten de wereld instuurt, moet je die database voortdurend bijwerken. Dat is voor mijzelf geen probleem, maar als anderen hetzelfde vertrouwen willen, hoeven ze alleen maar mijn CA public key te hebben, en die heeft geen update nodig.

Op de dag dat de CA private key uitlekt is het toch game over, met of zonder uiterste houdbaarheid.
Op de dag dat de CA private key uitlekt is het toch game over, met of zonder uiterste houdbaarheid.
Dus daarom voegt een certificaat enkel een extra aanvalsfactor toe.

En over het bijwerken van die database, dat hoeft helemaal niet. Een nieuw apparaat kan zichzelf bij eerste gebruik registreren. Net als bij de host-keys van SSH. Bovendien kan de public-key of de fingerprint ook als bar- of QR-code op het apparaat geprint worden.

En nee, de dag dat een CA private key uitlekt is het niet game-over. Elke iteratie van dat certificaat kan en mag een andere private key hebben. Sterker nog, ook het onderliggende encryptiemechanisme mag anders zijn. Dus stel je geeft op 1 januari van elk jaar een nieuw certificaat uit dan kan het RSA-certificaat voor 2024 vervangen worden door een ED25519-certificaat voor 2025. Als de 2025 key uitlekt dan kan het bijbehorende certificaat worden ingetrokken en opnieuw uitgegeven. Als een client/browser de CRL controleert zal hij weigeren te verbinden. Doet die dat niet dan is in 2026 het probleem sowieso uit de wereld.

Maar ik begin deze discussie een beetje zat te worden. Als jij vind dat certificaten zonder datum veilig zijn, steek dan lekker je kop terug in het zand, zet een root-ca op met als einddatum ergens in 9999 en veel plezier ermee.
Maar nu spreek je over een totaal andere oplossing.

Je geeft het zelf aan, dat je in een gesloten omgeving zit in dit scenario.
Uw eerste stelling trok het algemeen belang van een vervaldatum binnen certificaten in twijfel.

Verhoogde Beveiliging:
1) Een kortere geldigheidsduur betekent dat als een certificaat gecompromitteerd wordt, de schade slechts tijdelijk is. Dit beperkt de tijd waarin aanvallers misbruik kunnen maken van een gestolen of verlopen certificaat.

2) Door certificaten vaker te vernieuwen, wordt het makkelijker om nieuwe cryptografische algoritmes en standaarden snel te implementeren. Dit is belangrijk om bescherming te bieden tegen nieuwe bedreigingen en kwetsbaarheden.
Beheerbaarheid:

3) Certificaten met een beperkte geldigheid zorgen ervoor dat verouderde certificaten sneller worden vervangen, wat helpt bij het minimaliseren van beveiligingsrisico's die ontstaan door vergeten of verwaarloosde certificaten.
Betere Vertrouwen en Controle:

4) Regelmatig vernieuwen zorgt ervoor dat alleen up-to-date certificaten in omloop zijn. Dit versterkt het vertrouwen van gebruikers, aangezien ze weten dat de beveiliging voortdurend wordt bijgewerkt.
Compliance en Regulaties: Veel organisaties moeten voldoen aan industriële en wettelijke normen (zoals PCI-DSS voor betalingen of GDPR voor privacy) die eisen dat certificaten regelmatig worden vernieuwd om compliance te waarborgen.

5) je vermijdt grote revocation lists, die trouwens door andere partijen kunnen genegeerd worden!

Trouwens, maar daar kunnen de experts onder ons misschien eens op reageren, dacht ik dat met elke communicatie die gebruik maakt van certificaten altijd een stukje van de private key achterhaald kan worden via de sessionkey. Hoewel dit momenteel lang duurt, hoeft dat niet zo te blijven. Hoe langer je dus met hetzelfde certificaat werkt, des te groter het gevaar.

Dus in het geval van google ... was het gewoon een nalatigheid om het certificaat niet up-to-date te houden.

*edit: typo

[Reactie gewijzigd door RavensAngel op 10 maart 2025 14:39]

Nogmaals, er zijn andere toepassingen van certificaten dan alleen TLS met een website. Voor websites heb je een third-party CA nodig, met alle problemen van dien, zoals beschreven, en waar een geldigheidslimiet wel helpt (maar geen sluitende oplossing biedt inderdaad).

Als je via een andere weg een certificaat kunt verifieren dan een third-party CA op zijn blauwe ogen vertrouwen, dan is dat sowieso beter.

En uiteindelijk is het bemachtigen van een private key gewoon een kwestie van geld en meedogenloosheid. Voor een bepaald bedrag kun je wel een legertje inhuren die zich met geweld toegang verschaft. Bijvoorbeeld door de juiste mensen te bedreigen en/of ontvoeren.
1) Een kortere geldigheidsduur betekent dat als een certificaat gecompromitteerd wordt, de schade slechts tijdelijk is. Dit beperkt de tijd waarin aanvallers misbruik kunnen maken van een gestolen of verlopen certificaat.
Dit heb ik altijd met afstand het slechtste argument gevonden. De grootste schade wordt altijd aangericht in de eerste paar minuten na de hack. Een bankrekening plunderen duurt hoogstens een paar minuten. En eenmaal binnen in een systeem kan de hacker snel nieuwe backdoors open zetten.
Benieuwd naar de chaos die dat oplevert? Zoek dan maar eens op Diginotar. Oké, die werd gehacked in plaats van failliet te gaan, maar het effect was hetzelfde.
DigiNotar is wel degelijk failliet gegaan, na te zijn gehackt door de Iraanse autoriteiten. Het probleem bij DigiNotar was dat zij hun zaakjes niet op orde hadden, wat je wel mag verwachten van een uitgever van certificaten.

Je voorbeeld waarom een certificaat een einddatum moet hebben is heel juist. Ik was je even voor met twee andere voorbeelden ;) :
Aldy in 'Sommige Chromecast-gebruikers kunnen niets afspelen door verlopen certificaat'
Dat ze uiteindelijk failliet zijn gegaan wist ik, dat was ook onvermijdelijk.
Maar je zegt zelf ook: NA te zijn gehacked.

De hack was de reden om alle certificaten in te trekken, wat weer de oorzaak was van alle chaos. Maar een CA zonder een trusted root certificate is als zwembad zonder water; leeg en nutteloos.
Je weet dat DigiNotar nog steeds in alle browsers staat als uitgever? Dus de rootcertificaten zijn nog wel geldig.

Edit: Correctie. Ze zijn er eindelijk uitgehaald.

[Reactie gewijzigd door Aldy op 10 maart 2025 14:16]

Ja volgens mij was dat op aandringen van de Nederlandse overheid om een beetje tijd te kopen. Hoe dan ook, de chaos was er niet minder om.
Een voordeel van een certificaat met einddatum is, dat de uitgever van het certificaat bij het verlengen of vernieuwen kan controleren of het betreffende bedrijf nog wel bestaat of dat de betreffende persoon nog wel leeft.
Een certificaat met een vervaldatum van 10 jaar op een embedded device als dit, is enkel zodat ze het ding kunnen vervangen binnen afzienbare tijd. Ofwel neem je certificaten van max 1 jaar, ofwel "zonder" einddatum.
Maar dat hier een economische reden kan achter zitten ontken ik niet.

Ik reageer alleen op de opmerking dat het precies een belachelijk concept is om een vervaldatum in certificaten te plaatsen.

Dat Google 10 jaar heeft gebruikt en daar dus besloot om het niet te vernieuwen (bewust of onbewust) staat daar los van.
Vaak zijn certificaten ook maar een drie maanden of zelfs een maand geldig. Dan weet je dus wel dat de tijd beperkt is dat je je kan identificeren met een certificaat.
Als je zo'n device certificaat maar een paar maand geldig maakt, werken devices die een tijdje niet aangesloten zijn aan het internet al heel snel helemaal niet meer, omdat ze dan afhankelijk zijn van updates.

[Reactie gewijzigd door jaapzb op 10 maart 2025 10:49]

Nee dat is onzin.

Bedenk dat een certificaat doorgaans gebruikt wordt bij inkomende verbindingen. Dus een webserver biedt een certificaat aan de client aan om zijn identiteit te bewijzen. Natuurlijk zijn er ook uitgaande (client-)certificaten, waarbij de client zijn identiteit aan de server kan bevestigen, maar die komen een stuk minder voor.

Als ik er voor het gemak even vanuit ga dat die chromecast-devices op een gestripte linux-versie draaien, dan is het heel simpel om bij het booten:
1 - een netwerkverbinding op te zetten
2- te verbinden met een NTP-server om de datum te weten
3 - de geldigheid van de eigen client-certificaat te valideren
4 - indien nodig een nieuw client-certificaat (en evt. nieuwe public/private key) te maken, het eigen client-certificaat te vernieuwen en te laten ondertekenen.

Stappen 1 en 2 gebeuren sowieso bij het booten, stap 3 kan in een fractie van een seconde en stap 4 is afhankelijk van de hardware en random-number-generator en internet; maar zou ook vrij snel kunnen. Zeker als je de random-number-generator vervangt door een geheugentje waarin telkens de waarde van een X aantal willekeurige pixels periodiek wordt opgeslagen of een andere slimme oplossing.

Dus als het certificaat is verlopen doordat het device even stof heeft liggen happen, dan doet hij alleen wat langer over het opstarten.
Stap 4) is best een lastige om veilig te houden bij een geautomatiseerd proces, want hoe controleert de certifcaat-signer dat het signing-request rechtmatig is?

Voor websites is daar 'controle over de webserver danwel ober de DNS registratie achter de domeinnaam' voor bedacht omdat die werken met een 'domain validated' certificaat, maar voor devices is dat nog best een uitdaging om zeker te stellen dat het een device van de fabrikant is die het signing-request doet.
Sowieso zal een device niet zomaar een regulier Lets Encrypt of Verisign certificaat aanvragen.

Wanneer een fabrikant zelf een (root of intermediate) CA heeft dan kan deze het proces zo vorm geven als het maar wil. Bijvoorbeeld door een CSR pas te accepteren nadat dat de device eerst een gegenereerd authenticatietoken moet presenteren. Gegenereerd op basis van unieke eigenschappen en/of een private tekenreeks. Al dan niet ondertekend met de private key van de oude (al dan niet verlopen) certificaat.
Eens, maar 10 jaar is dan wel weer het andere uiterste. Dan moet je er wel aan denken dat de devices na een jaar of 9 een nieuwe ophalen. Verstandiger is dan om eens per jaar een tweejaarlijks certificaat te genereren.
Zeker, ze hadden hier gewoon geen procesje voor waarschijnlijk, of degene die hier over ging zit allang weer ergens anders
Als er iets met een "houdbaarheidsdatum" op je device staat, dan kun je er zeker van zijn dat het apparaat op den duur niet meer werkt, ook al is hij technisch prima in orde.

Als Google nou zegt "ja, nou, na tien jaar ondersteunen we ze niet meer" dan ben je dus mooi bedankt.
Geen problemen mee met de PS3, Wii U en DSI XL
De vorige gens waren echt dummy's, nu heb ik een Google TV met veel reclame, ook al zit ik enkel in de app mode.
Maar wat verwacht je dan ook als je een product koopt van een reclamebedrijf? De core business van Google is reclame (daar halen ze hun inkomsten uit). Geen zoeken, geen streaming, alleen reclame. Alle andere activiteiten zijn puur ter ondersteuning van hun reclame activiteiten, zoals het opbouwen van gebruikersprofielen of het daadwerkelijk tonen ervan (inclusief Android en Chrome). Dus je hebt je verkeerd voor laten lichten toen je die Google TV kocht.
Een gratis chromecast? Ik snap dat je als je niet betaalt er reclame voor krijgt (maps, zoekmachine, docs, enz.) maar voor bepaalde diensten van google kan je betalen en dan verwacht ik een normale dienst. Youtube premium bijvoorbeeld is reclamevrij. Betaal je, dan heb je een normaal product zonder reclame.
Tip: ga niet van de regen in de drup en kies voor een volledige opensource launcher. Geef geen ruimte voor enshittification.

Voorbeeld FLauncher.

[Reactie gewijzigd door The Zep Man op 10 maart 2025 10:49]

Wat een onzin commentaar weer. De ontwikkelaar van Projectivy verdient alle lof.
Ik verdien ook veel op het werk (figuurlijk dus).

Je weet niet wat achter de schermen gebeurt. Dus dat je er iets met wantrouren naar kijkt, is volkomen legit.
De ontwikkelaars van MySQL, OpenOffice.org, ownCloud, XenServer, etc. verdienden ook alle lof, totdat ze dat niet meer deden met die producten. Vanaf dat moment was het goed dat men over kon stappen op een fork.

[Reactie gewijzigd door The Zep Man op 10 maart 2025 14:25]

Heb ik iets gemist? Wat is er gebeurd met OpenOffice?
Ontwikkeling stond effectief op nul. LibreOffice had het stokje overgenomen.

[Reactie gewijzigd door The Zep Man op 10 maart 2025 14:37]

Die alternatieven hebben wel geen voice search, en schakelen doorgaans ook de photos screensaver uit.
Kan van deze daar niet direct info over vinden.
Die alternatieven hebben wel geen voice search, en schakelen doorgaans ook de photos screensaver uit.
I fail to see the problem. Overigens lijkt de screensaver op een Shield TV gewoon te werken met een alternatieve launcher.

[Reactie gewijzigd door The Zep Man op 10 maart 2025 14:42]

Je kan het certificaat inderdaad vernieuwen, maar ik vermoed dat de update service ook geen connecties meer accepteert. Dan wordt het vervangen van bestanden heel lastig!
Classic certificaten tracking. Vaak worden eindcertificaten nog wel bijgehouden op expiration date, maar de im- of rootcertificaten komen meestal van een andere afdeling of externe en dan kijkt niemand er meer naar als de communicatie/tracking niet meer aanwezig is na enkele jaren. Bij veel bedrijven verdwijnt vaak na enkele jaren de ene persoon die er nog op let en dan is het klaar.
Het gaat vooral vaak mis bij projecten waar niemand meer focus op heeft. Deze devices zijn immers door google al lange tijd geleden als end of support aangewezen. Het is op zich nog wel netjes wanneer ze het probleem toch nog verhelpen. Ik ben alleen bang dat er nu een developer geweldig aan het vloeken is dat de makkelijke oplossing niet meer werkt.
Ah ik vroeg me al af waardoor alles via Home Assistant nog wel werkte. Helaas was mn tweede ingeving een factory reset…

Edit: Ok na tijd van IPhone naar 7 maart te hebben gezet kon ik hem weer instellen. Nu maar afwachten dan. Heb een oude TV zonder apps en geen TV abo dus tijd voor een spelletje bij kaarslicht?

[Reactie gewijzigd door teek2 op 10 maart 2025 22:17]

Dank voor deze post.
Mijn Chromecast 2 laat zich ook nergens zien als beschikbaar. Via VLC doet die het wel.
Getver, ik heb mijn CC Audio dus net voordat ik hier las gereset naar fabrieksinstellingen, omdat ik hem na 9 maart onmogelijk nog aan de praat kreeg. Nu krijg ik hem, als ik hem als nieuw apparaat zoek (en vindt) niet meer verbonden en krijg de melding 'kan niet communiceren met je Chromecast audio'....

Weet iemand hier al een fix voor? Of is ie nu echt 'dood'?

Edit: tijd tijdelijk op 6 maart gezet en toen kon ik de fabrieksreset weer afronden, opnieuw verbinden en hangt hij weer in mijn home omgeving. Alleen kan ik dus nog steeds niks casten via reguliere manieren (in mijn geval Spotify)...
Hopen dat de Google update snel komt.

[Reactie gewijzigd door Allewijn op 12 maart 2025 11:07]

Door tijdens het setuppen van je device de datum van je telefoon voor 9 maart zetten lukt het wel en haal je hem uit fabrieksinstellingen.
Zodra je device online is weet hij de exacte datum wel weer en kun je op dit moment (13 maart) nog niet verder.
Onofficiële oplossing om geresette apparaten weer te verbinden: zet de systeemdatum van je telefoon twee dagen terug en doorloop de set-up opnieuw. Dat heeft er bij mij voor gezorgd dat hij weer in Google Home staat en dat hij weer aan m'n netwerk hangt. Casten gaat uiteraard nog niet maar ik hoop dat hij dan gewoon weer werkt als er een update komt.

Credit: bennett2043 op Reddit
Dat is in ieder geval gelukt: echter instellingen en andere device info worden niet weergegeven in de Home App. Ik hoop in ieder geval dat men met een fix komt. Helaas device ook gisteren een reset gegeven.

Ook weer zichtbaar in BubbleUpNp server, echter niet bereikbaar om af te spelen door Google Cast Connection Error: Unknown Error Code (2280)

Met het aanmaken van een OpenHome renderer in BubbleUpNpServer kan ik gelukkig wel casten naar de Chromecast Audio.

[Reactie gewijzigd door prinsvlad op 10 maart 2025 10:59]

Ik had dus mijn Chromecast dus al een factory-reset gegeven. Het probleem is dan dat je dan de Home app niet meer kan gebruiken om de CC weer te verbinden met je WiFi. De gebruikelijke trucjes (airplane mode, oude iOS home app, etc.) lijken niet te werken, sommige oudere apps komen verder, maar uiteindelijk hangt de CC op het verbinden met je WiFi.

Er is echter een oplossing voor. Dit is wel wat minder gebruiksvriendelijk, maar wij zijn immers Tweakers, dus de wat technischere Tweaker moet hier wel uit komen :)

Wanneer de Chromecast (of andere Google device gebruikmakend van de 'Google Home Local API') in setup mode is (na factory reset), dan broadcast het zijn eigen WiFi netwerk, waarmee je kan verbinden. Op de Chromecast draait een webservice waarop je API commands kan sturen. Dit is precies wat de Google Home app doet tijdens device setup, maar wat nu dus mislukt wegens de verlopen certificate.
Je kan dus verbinden met de WiFi van de CC, dan handmatig via cURL de API call afvuren om te verbinden met je WiFi, maar dan met `--insecure` flag om het verlopen certificaat te negeren. Hier komt echter wat cryptografie bij kijken om de access token te berekenen, dus je kan dit niet even met een one-liner doen vanaf de CLI. Gelukkig heeft iemand hier een scriptje voor gemaakt: https://gist.github.com/i...d55658d334e2bc4619d796476
Ik moest het scriptje iets aanpassen (`nodejs` vervangen met `node`), maar daarna werkt het feilloos. Na het scriptje uit te voeren verbind de Chromecast weer met je WiFi. Casten en Google home werkt dan nog steeds niet, maar je bent in ieder geval weer terug naar de status hoe je was voor de factory reset.

Mijn vermoeden is dat Google een update zal uitrollen van Google Home die de verlopen certificate zal negeren, en op die manier dus het instellen van factory reset devices weer mogelijk te maken via de Home app. Daarna zullen we een firmware update uitrollen met bijgewerkt certificaat. Maar tot die tijd kan je het script gebruiken.

Bonus: Wanneer de CC eenmaal verbonden is met je WiFi kan je in je router het IP opzoeken en via dat IP weer diezelfde API bereiken. Je kan via de API dan een reboot+firmware update triggeren, wat je normaal dus via de Home app zou doen. Op dit moment lijkt er nog geen nieuwe firmware te zijn (CC geeft op moment van schrijven een 'network error' nadat de update een tijdje op 0% blijft staan), maar vermoedelijk/hopelijk gaat dit werken wanneer Google een firmware uit gaat rollen.

Het commando om reboot + firmware update uit te voeren is:
curl --insecure --tlsv1.2 --tls-max 1.2 -H "content-type: application/json" -d '{"params":"ota foreground"}' https://{CHROMECAST_IP}:8443/setup/reboot
Hopelijk helpt dit wat ongeduldige Tweakers die (net als mij) de factory reset al hadden uitgevoerd.
Zeer interessantee info!

De tijd terugzetten, zoals 088088 iets verder terug aangaf, werkt en stuk makkelijker ;)
Een post op Reddit met wat meer achtergrond waarom een fix mogelijk lang(er) duurt: https://www.reddit.com/r/..._a_fix_is_taking_so_long/
Ik heb dat bericht gelezen, maar er zit wel extreem veel speculatie in :)

Ik ben het ook zeker niet met hem eens. De Chromecast is een apparaat dat continue met Google-services praat (voor eventuele updates). Ik verwacht dat Google gewoon binnen een paar weken met een update komt.
Hij heeft wel een punt dat die afdelingen natuurlijk al een tijdje zijn opgedoekt, dus dat het (mede) om die reden wat langer duurt.

Z'n onderbouwing 'het bereikt niet iedereen, omdat men hem heeft gefactoryreset, enz.' of dat het risicovol is (als men de update halverwege onderbreekt) is onzin. De Chromecast update zichzelf voordat je hem activeert, en het onderbreken kan altijd al. Het gaat hier ook nog is om de authenticatie-certificaten (dus het certificaat waar de mediasoftware tegenaan authentiseert).

Afhankelijk van hoe Google haar product heeft ontwikkeld is het wel of niet makkelijk om de certificaten te updaten. (in het slechtste geval is het überhaupt niet goed mogelijk als ze het echt heel erg hardcoded erin hebben zitten - en ook dan zijn er mogelijkheden door een ander certificaat het te laten overruelen.)
Inmiddels zijn er verschillende workarounds voor. De 1e (GUI method) werkt hier prima :)
Kan ook weer casten vanaf Chrome (Windows) _/-\o_
Lifesaver :)
Mijn zeurende kids zijn je dankbaar.
Ik heb gisterenavond ook gepuzzeld waarom mijn Chromecast audio's het niet meer deden, gisterenochtend werkte het nog naar behoren.

Nu maar hopen dat dit snel wordt opgelost.

Edit:
@JayStout Google heeft gereageerd: Reddit

[Reactie gewijzigd door JvdBBBB op 10 maart 2025 07:40]

en de reactie van google
Hey all,

We're aware of an emerging issue impacting Chromecast 2nd gen and Chromecast Audio devices and are working on a fix. Do not factory reset your device - we will keep you all updated when the fix rolls out. If you have already factory reset your device, we will provide instructions to set your device back up as soon as possible. Thank you for your patience.
ga dus geen fabrieksreset doen, dat schijnt herstel lastiger te maken als ik het zo lees
Tja, en wat is een van de eerste zaken waar je aan denk als je toestel het niet meer doet, en wat stelt Google zelf ook voor op hun help-pagina's: inderdaad, factory resetten.
Dat heb ik dus uiteraard ook gedaan.
Hier eenzelfde factory reset uitgevoerd… fijn
Nja hier helaas ook factory reset gedaan... Nadien pas gelezen op reddit en nu op tweaker ...

Hopelijk komt dit nog goed.
Argh, soms doet mijn audio chromecast het niet en dat is dus meestal de oplossing. -edit- die link staat er dus.

[Reactie gewijzigd door Aeternum op 10 maart 2025 08:23]

Dat klinkt als veel problemen voor een product, van een gigant, die geld kost.
Volgens mij zijn die producten ook al langer eol, althans ze worden sinds 2019 niet meer nieuw verkocht.
Snap nooit zo waarom dit soort producten zo snel EOL worden. Maar dat past wel een beetje bij de luie weggooi maatschappij.
Zoals beschreven staat in de comments van die reddit post. Kunt datum handmatig terugzetten op je telefoon naar afgelopen zaterdag. Op die manier kan je het instel proces in ieder geval afronden. Casten werkt nog niet.
Helaas werkt dit bij mij niet. Ik krijg de melding dat een andere gebruiker de setup heeft gedaan. En geeft dan aan om fabrieksinstellingen te doen. Wat dan hetzelfde geeft. Maar even afwachten dus.
Ik kreeg opeens de melding dat casten niet mogelijk was. Eerst Chromecast aan en uit. WiFi aan en uit.
Maar ja, na 30 minuten klooien was voor mij de laatste oplossing: een factory reset. Poging tot herinstallatie via Google Home.
Chromecast gevonden, maar meldt dat hij niet kan authenticeren...

Nu maar afwachten waar Google mee komt.

[Reactie gewijzigd door MarvinJames op 10 maart 2025 08:28]

Bedankt voor deze reactie........
Op welke site heb je dit bericht gevonden? Want dan zullen ze via dit platform ook aangeven hoe je dan kan herstellen.
op de genoemde reddit
Same here. Mijn CC audios werkten nog, maar ik ben mijn speakergroep kwijt. En ik maar zoeken hoe dit kwam. Dacht dat het probleem in mijn home assistant zat omdat ik daarin bezig was. 8)7
Je zou zeggen nieuw certificaatje aanmaken, online gooien en klaar :P
Dit is geen certificaat op de webservices van Google, maar een certificaat wat ingebakken is in de firmware van de Chromecast. Er moet dus een firmware update worden uitgerold.

Het probleem is dat je voor de firmware update de Google Home app moet gebruiken, en dat momenteel de Google Home app weigert the communiceren met de Chromecast vanwege het verlopen certificaat in de Chromecast zelf. Een kip-ei probleem dus.

Dus waarschijnlijk zal Google naast de nieuwe firmware ook een update van de Google Home app uit moeten rollen die de verloopdatum van het certificaat negeert (maar alleen voor het cert met dat specifieke serienummer), zodat gebruikers de firmware update kunnen triggeren.

Dit is allemaal niet 123 geregeld.
Probleem is dat de Chromecast dat nieuwe certificaat niet vertrouwd en dus de verbinding zal weigeren.
Fun fact, met het afsluiten van support voor de Chromecast 1 creëerde Google een afvalberg van ongeveer zevenhonderdduizend kilo. Als Chromecast 2 support vervalt, komt daar nog zo'n miljoen kilo bij.

[Reactie gewijzigd door Ablaze op 10 maart 2025 09:00]

Als Chromecast 2 support vervalt, komt daar nog zo'n miljoen kilo bij.
Ik vind het indrukwekkende getallen, maar zoals altijd moet je getallen in perspectief zetten. Als je met een Chromecast je televisie nog slechts twee jaar kunt gebruiken nadat de support voor je smart tv is verlopen, dan heb je waarschijnlijk kilos aan e-waste bespaard.
(...) Als je met een Chromecast je televisie nog slechts twee jaar kunt gebruiken(...)
Ik neem aan dat je minstens twee jaar bedoelt? Een Chromecast kan de levensduur van je televisie inderdaad best een flinke tijd verlengen.
Ja, de verwoording is gek, maar ik bedoel echt slechts. Zelfs als het de levensduur slechts twee jaar verlengt, dan nog...
ja, mijn antieke tv misschien wel 30 jaar😀.
(Die had nog geen hdmi, dus scart-3kleurenkabel en 3kleurenkabel-hdmi er tussen. ik weet niet meer waarom 2 adapters er tussen. of omdat scart-hdmi niet bestaat of omdat ik scart-3kleurenkabel al had)
Niet meer gesupport betekent vooral dat het geen updates meer krijgt, net als vele andere oude Chromecasts. Maar deze apparaatjes werken allemaal nog gewoon, los van het issue uit dit artikel.
Certificaat updates zijn ook updates. Je hebt als gebruiker geen idee of, en waarvoor, er certificaten gebruikt worden in je apparaat, wanneer die aflopen en of dat dan een probleem gaat veroorzaken.

Certificaten zijn letterlijk tijdbommen, zelfs als je apparaat nog volledig ondersteund wordt.

Dit wordt alleen maar erger aangezien we steeds meer certificaten gaan gebruiken, en er een trend is de geldigheid steeds korter te maken. Weer een ding dat gemanaged moet gaan worden, misschien ook gereguleerd om planned obselence te voorkomen.

[Reactie gewijzigd door locke960 op 10 maart 2025 09:22]

CA-cerrificaten worden niet ingekort. Tien jaar is al jaren de standaardtermijn voor een CA. De korte certificaten zijn voor webdiensten zelf, maar daar heb je als client device geen last van. Als je als webdienst je spul onderhand al een keer hebt ingericht voor automatisch vernieuwen van die certificaten, hoef je er als webdienst ook niet meer aan te doen dan één getalletje veranderen zodat de vernieuwcode vaker draait.

Bij oude computers en telefoons kun je simpelweg zo'n certificaat installeren en het web weer op, maar bij Chromecast is daar geen GUI voor dus zit je vast. Er zijn projecten die custom ROMs voor Chromecast bouwen waar men wellicht zonder officiële support straks gebruik van kan maken om dat alsnog voor elkaar te krijgen.

Nu is het bij Chromecasts nog wel zo dat Google regelmatig updates uitbrengt zelfs voorbij de officiële supportperiode, maar bij de meeste andere IoT verwacht ik toch een stuk minder. Alsof die robotstofzuiger van zes jaar terug nog een nieuwe CA root gast krijgen. Het gebrek aan updates en mogelijkheden tot zelfreparatie van de software is het echte probleem bij deze dingen, CA-bundels zijn slechts het eerste signaal dat de gebruiker ontvangt wanneer een fabrikant zijn klanten al jaren eerder in de steek heeft gelaten
De berg pc's die win10 naar win11 niet meer konden en daardoor obsolete werden is flink groter vermoed ik. (En ja dan kan je er linux opzetten en whatever, maar als je win10 pc 9 jaar oud is koop je iets nieuws wat win11 doet)
Het is geen wedstrijd
Of eigenlijk is het wél een wedstrijd, maar dan tussen de e-waste-generators en de Aarde. Ze zijn ruimschoots aan het winnen, dus wie er topscoorder wordt is irrelevant.
Het is geen wedstrijd
Misschien zou het dat wel moeten zijn.
Eigenlijk is dat een teken dat de afvalberg de afgelopen jaren eenstuk minder snel gegroeid is dan voorheen.
Nu kan je klagen dat je 9 jaar oude PC nog steeds goed werkt, maar niet meer de nieuwste versie van Windows kan draaien (terwijl de PC waarschijnlijk van Windows 7 via 8 naar 10 is geüpgradet). Die PC werd 9 jaar geleden waarschijnlijk gekocht omdat een toen drie jaar oude PC niet meer vooruit te branden was.
Ik klaag helemaal niet. Ik gaf aan dat er geen enkele goede reden was om die PC geen up-to-date windows meer te laten draaien. Als windows 10 nog support zou krijgen had ik hem door laten draaien. Als de eis in win11 voor een TPM x.x module optioneel was geweest dan had ik die PC op windows 11 door kunnen laten draaien. Op kantoor en thuis zes PC's, lang niet allemaal 9 jaar oud die geen win11 'aankonden'.
In tegenstelling tot de chromecast met 'gebroken' functionaliteit, kun je met een W10 pc nog prima werken...
Windows 10 doet het nog tot 2028, en daarna kun je er nog iets anders op zetten. Dat de consument liever een hele PC weggooit dan er ChromeOS of iets anders op probeert te zetten, zegt meer van de maatschappij dan dat Microsoft hun systeemeisen na twintig jaar een keer opschroeft.
Dat is alleen veilig met uitgebreide support, de meeste Windows 10 PC’s krijgen updates tot oktober dit jaar. Na die tijd moet je nog voorzichtiger gaan worden als er vulnerabilities worden gevonden die niet meer worden gerepareerd. Maar dat moet je met een bijgewerkte versie helaas ook.
Klopt, maar die is deze keer ook gewoon voor consumenten beschikbaar. Je hoeft niet zoals bij Windows 7 een bedrijf te hebben (of te doen alsof je dat hebt).

Mensen die geen extra support afnemen zijn na oktober inderdaad overgeleverd aan zichzelf. Maar goed, die datum stond ook al tien jaar vast.
Windows 10 stopt deze oktober 2025 met updates. En chromeos draait de software niet die ik gebruik.
Windows 10 is nog (minstens) een jaar langer met goedkope updates te krijgen en de bedrijfsvariant wordt volgens de planning nog drie jaar langer ondersteunt.

Kost je wel extra, omdat de 10 jaar die Microsoft voor Windows 10 heeft aangekondigd in 2015 voorbij zijn, maar de optie is er.
Jammer, al die ewaste.

Ik snap het wel als er een echte reden achter zit zoals bijv. geen H265 of AV1 support. Maar dan moet je alsnog dingen kunnen bekijken die dat niet nodig hebben.
Ik vind ook dat ze daar echt wat mee moeten. De Dell Laptop van mijn vrouw uit ongeveer 2012 doet het voor onze dochter nog prima. Maar officieel draait die geen Windows 11 (dat gaan we natuurlijk wel in de zomervakantie regelen). Heb ook gekeken naar Linux, maar Office werkt daar niet op en de houtjetouwtje oplossingen doen het ook niet werkbaar zeg maar.

Zolang die laptop het gewoon goed doet, gaat die echt niet zomaar weg. Was toen een high-end en is nu ook gewoon nog snel voor alles behalve recente spellen.
Als je er al Windows 10 op hebt staan is het installeren van Windows 11 op een apparaat dat officieel geen Windows 11 ondersteund 9 van de 10x zonder problemen voor elkaar te krijgen.

1: Download de Windows 11 ISO (kies wel dezelfde taal als nu je Windows 10 is, anders behoud hij niet je bestanden en programma's die al geïnstalleerd staan)
2: Dubbelklik op het ISO bestand en kopieer de volledige inhoud naar C:\ESD (ESD map eerst zelf aanmaken)
3: Start command prompt (CMD) of Powershell en voer (of copy/paste) deze regel

C:\ESD\Sources\setupprep.exe /product server

Het lijkt nu of hij een upgrade gaat doen naar Windows Server, maar uiteindelijk upgrade hij gewoon naar Windows 11 Home of Pro (naar de versie die je al had met Windows 10)

[Reactie gewijzigd door Goldwing1973 op 10 maart 2025 09:49]

Voor Microsoft Office zou je kunnen kijken naar de webversie. Niet alle features zitten erin, maar in mijn ervaring zit er genoeg spul in dat je er prima mee kunt werken. Je kunt die zelfs installeren "als app" waardoor je de webversie lokale bestanden kunt openen met een dubbelklik.

Dan is er ook nog onlyoffice is (ook op Windows trouwens) een aardige kloon van Microsoft Office die voor veel mensen ook nog onbekend is.

Als laatste redmiddel voor zo'n laptop kun je nog ChromeOS Flex proberen, zit je wel vast aan Google maar dan heb je alle voordelen van een commercieel onderhouden OS.

Het is een beetje jammer dat Windows tegenwoordig het enige besturingssysteem is dat voor PC's Not ondersteuning heeft. Microsoft heeft zoals sinds Windows 2000 ongeveer in totaal tien jaar aan ondersteuning beloofd en geleverd, maar omdat de consument zich aan Windows heeft vastgebeten blijft er weinig meer over als de termijn die Microsoft beloofde verloopt. Gelukkig dat Microsoft mensen nog een optie bied om langer Windows 10 te blijven gebruiken, al zijn er denk ik maar weinig consumenten die daar voor willen betalen.
Ik gebruik Enterprise LTSC daarvoor. Nog tot 2032 ondersteund *O* . Maar ik heb het voordeel dat ik wat licenties kon krijgen. Die zijn niet makkelijk beschikbaar geloof ik.
Mijn chromecast 1 doet het anders nog prima.
Als je zo gaat rekenen dan geldt dat natuurlijk ook met mobiele telefoons van sommige fabrikanten die maar 2 a 3 jaar ondersteuning krijgen en alle andere elektronica. Deze zijn dan nog bijna 10 jaar in gebruik geweest en is een veel kleiner apparaat.
Maar hebben in die tien jaren minder gebruiksuren dan een telefoon in 3. Je kunt het alle kanten oprekenen :)
Met welk resultaat op de daadwerkelijke afvalberg?
Met die argumentatie kun je goedkope Chinese troep met minder onderdelen hoger schalen dan hoogwaardige duurzame elektronica, omdat ze allebei een keer op de afvalberg belanden, waarbij de goedkope troep minder componenten bevat. Het gaat om toevoegde waarde. Afhankelijk wat het doel is, reken je dat in gebruiksuren of jaren vs grondstofgebruik. Voor een fabrikant is dit ander natuurlijk, want die moet een team of 3 jaar of 10 jaar actief houden voor updates. In dit geval zorgen de updates voor beter verkoop van YT producten en ads en genereert het data voor Google waarmee ze je beter kunnen spammen.
Redenering is niet ongeldig natuurlijk. Kan nog allerlei nuance aan toegevoegd worden, maar het laten verlopen van de mogelijkheid om electronica laten verlopen die op zich nog door zou kunnen werken creeert vroegtijdig afval.
Ligt aan de definitie van vroegtijdig. Dit is vrij simpele hardware die al 10 jaar oud is en nog steeds wordt ondersteund trouwens, er is alleen een issue mee.

Hoelang moet het minimaal ondersteund worden dan? 15 jaar, 20 jaar? Ik vind 10+ jaar al best lang en de ondersteuning loopt ook gewoon door. Bij 10 jaar oude auto's heb je al jaren geen (navigatie)updates meer. Op 10 jaar oude telefoons werken veel apps niet meer.
Zelfs mijn 9 jaar oude laptop, die wat langzamer is misschien maar nog prima werkt. Krijgt geen windows11 update meer vanwege een net te oude cpu (tpm chip zit er gewoon in). Dat is veel meer ewaste.
Subscription expired...

Zelf 2 stuks nog liggen (af en toe gebruik), maar ik zou nog zeker graag deze werkend hebben...

Nu vraag ik mij af wanneer de ChromeCast 4K afloopt?
Deze gebruik ik regelmatig op werk in buitenland.
edit foutje:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 411 (0x19b)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, ST = California, L = Mountain View, O = Google Inc, OU = Cast, CN = Cast Root CA
Validity
Not Before: Jun 21 04:57:51 2019 GMT
Not After : Jun 16 04:57:51 2039 GMT
2039 dus.

Het certificaat voor de CC Ultra verloopt blijkbaar op 12 maart 2026.

[Reactie gewijzigd door oef! op 10 maart 2025 10:35]

Thnx for the info
Iemand ervaringen met de Gen 1 Chromecast?
Ik heb er nog 1 liggen ingesteld op een ander netwerk (gebruik ik 1 keer per jaar voor de vereniging).
Kan ik deze wel gebruiken / resetten?
Ik heb gisteren een 1e generatie Chromecast van mijn dochter gekregen. En die doet het prima!
Mooi, vanavond resetten en in mijn eigen netwerk gooien.
Bedankt!

Edit: Gisteren mijn Gen 1 Chromecast geïnstalleerd en werkt netjes.
Ik kan in ieder geval vooruit tot (als) Google dit fixed.

[Reactie gewijzigd door key op 13 maart 2025 08:36]

Op dit item kan niet meer gereageerd worden.