Xiaomi: bug met verkeerde stills op Google Home Hub trof enkele gebruikers

De bug, waarbij gebruikers stills van andere mensen met een Xiaomi Mi Home-camera op een Google Home Hub zagen, trof slechts enkele gebruikers. De functie om de camera te koppelen aan de Google Assistant blijft uitgeschakeld tot de oorzaak compleet is verholpen.

De oorzaak van de bug ligt bij een update van de cache op Tweede Kerstdag, zo zegt een woordvoerder van Xiaomi tegen Tweakers. "Die cache-update was ontworpen om de streamingkwaliteit van de camera te verbeteren." Xiaomi zegt de bug zelf te hebben opgelost, maar werkt nog aan een structurele oplossing die moet voorkomen dat de bug weer voorkomt. Het is onbekend wat die oorzaak is.

De bug trof maar weinig mensen, claimt Xiaomi. Het gaat om een bug van de koppeling tussen de Mi Home Security Camera Basis 1080p met Google Assistant zonder het gebruik van de Mi Home-app. Bovendien moet het bereik van de camera beperkt zijn. "Er waren 1044 gebruikers die de integratie gebruikten en slechts een paar daarvan hebben de camera op een plek staan met beperkt bereik."

De bug kwam vorige week naar buiten toen een Nederlander op Reddit postte. Hij zag stills van de camera's van andere mensen op zijn Home Hub. Google blokkeerde daarop de Assistant-integratie van Xiaomi-apparatuur en dat is nog steeds zo.

Xiaomi-stream op Nest Hub
Afbeelding: reddit-gebruiker /u/Dio-V

Door Arnoud Wokke

Redacteur Tweakers

06-01-2020 • 13:37

21

Reacties (21)

Sorteer op:

Weergave:

Een must-watch video die hierbij aantoont waarom caching voor zo'n problemen kan zorgen: https://www.youtube.com/watch?v=dkSslseq9Y8

Voor statische content is caching uitermate optimaal, maar zodra je dynamische content of account-gerelateerde zaken cached zit je dus met een boel condities die je enorm goed moet afvangen.
Caching is altijd statisch van aard. Dus pre-rendered versie van de website. Daar zitten bijv geen streams bij. Het is vooral een techniek om cpu-load te verminderen op webservers.

Het zou me verbazen moesten mensen hun recordings in een cached folder zitten in het geheugen van de server. Ram is daar te duur voor. Al kan het in theorie wel in een beta-omgeving al is dat niet schaalbaar.

Live Streams cachen kan technisch niet omdat het live is dus het moet over opnames gaan.

Ik lees nu pas dat het over stills gaat. Die cachen ze meestal door de full res ergens om een Amazon server te zetten en dat de tevoren gecomprimeerde en te verkleinen via een amazon server. Ook soort van caching. Om het dan later via een CDN te verdelen, maar dan wel user per user. Dus bandbreedte optimalisatie.

Wat er kan gebeuren is dat bestandsnamen gelijklopen. Bijvoorbeeld in de statische html code laad je Uw persoonlijke foto1.jpg in, dan ziet iedereen foto1.jpg van dat moment die ‘publiek’ beschikbaar is op de CDN. Op een lokaal pad kan het perfect kloppen dat foto1.jpg uw foto1.jps is maar zodra je een publieke CDN er tussenzet om lokaal pad op te vangen dan zie je voor je het weet iemand anders zijn eerste foto of avatar.jpg etc.
Caching is een breed begrip - ik kan me goed voorstellen dat je recente recordings op een SSD cache bewaart. Waarschijnlijk worden beveiligingsbeelden vaker opgevraagd in de week na een incident dan 10 weken later, dus dan zou het zinnig zijn om 1 week aan SSD cache te hebben naast de HDD opslag.

En bij sommige live streams heb je een rewind functie; dat is dan typisch in RAM gecached. Dat kun je gebruiken als je iemand slecht verstaan hebt, en dan heb je typisch dus maar een paar seconde video nodig. Live cachen kan dus best zinnig zijn.
Het is inderdaad vreemd en misschien zelf wel amateuristisch dat dit zo geïmplementeerd is.
Google blokkeerde daarop de Assistant-integratie van Xiaomi-apparatuur en dat is nog steeds zo.
Dat is sinds zaterdag weer terug.
Bij mij werkt het ook weer sinds het weekend.
Inderdaad en dit weet Tweakers ook, hiervan had ik nog helemaal nieuws gesubmit afgelopen zaterdag.
slecht enkele, tja - sinterklaas en de kerstman zijn net geweest, nu schakelen we over op de paashaas...
Het zal me niks verbazen als ze een of andere zwakke hash als filename hebben gebruikt in hun caching laag die al bij vrij snel last heeft van hash-collisions, met als gevolg dat 2 mensen dezelfde hash krijgen uitgedeeld en daardoor elkaars (of de laatst-geuploade) afbeeldingen te zien krijgen.

[Reactie gewijzigd door cappie op 23 juli 2024 03:47]

Met 't risico dat deze reply helemaal kapotge'-1'd wordt: dankjewel :)
Ach maakt mij niet uit. De wereld bestaat uit veel zielige losers die niet beter kunnen dan -1en en disliken.
1044 gebruikers die specifiek de koppeling met Google home zonder de software van Xiaomi zelf ertussen hebben. Dit impliceert dus niet dat in totaal maar 1044 mensen met die beveiligingscamera van Xiaomi werken.
Aanvulling: 1044 mensen gebruiken de camera zonder de Mi Home app. Mi Home is Xiaomi's Google Home-alternatief dat ook weer met Google kan integreren. Ik geloof dat de Mi Home app ook in de meeste Xiaomi-handleidingen te vinden is.

Voor zover ik kan lezen in het bericht werkt die koppeling dus anders dan een directe Google Home-koppeling. Dat zou in elk geval kunnen verklaren waarom er maar zo weinig mensen zouden zijn die een Xiaomi-camera gebruiken met een smart home.
Hoe zie je dit dan.. om de camera te configureren heb je de app al nodig...
Omdat dit een gigantische privacy issue is, je kunt namelijk op die manier heel gemakkelijk de persoonlijke levenssfeer van iemand binnendringen.
Ik begrijp sowieso niet dat je een dergelijke camera wil hebben. Het blijkt maar weer dat je er meer last van hebt en dit is nog een bug waar we van op de hoggte zijn.
Precies! Of het dat 10 gebruikers zijn of 1 miljoen maakt niet uit: een geval als dit MOET gewoon worden gepatched.

Op dit item kan niet meer gereageerd worden.