De vooralsnog onaangekondigde AMD Radeon Pro W6800-videokaart krijgt mogelijk 32GB aan GDDR6-geheugen. Dat blijkt uit een vermelding in de database van UserBenchmark. De workstation-gpu krijgt daarnaast naar verwachting een Navi 21-gpu.

De UserBenchmark-vermelding werd opgemerkt door Tom's Hardware. Op die benchmarkwebsite wordt onder andere vermeld dat de videokaart 32GB aan GDDR6-geheugen zou krijgen. Het is niet duidelijk over hoeveel Infinity Cache de gpu beschikt. Naar verwachting krijgt de videokaart verder een Navi 21 XL-gpu, schrijft ook VideoCardz. Er zijn nog geen concrete details bekend over de gebruikte chip.

Volgens UserBenchmark presteert de gpu beter dan de Radeon RX 6800, maar gemiddeld minder goed dan de hoger gepositioneerde RX 6800 XT. Deze resultaten zijn echter nog onbevestigd en dienen dan ook met een korrel zout genomen te worden.

Recentelijk verschenen er al afbeeldingen van een vermeende Radeon Pro-videokaart met Navi 21-gpu op het Chinese forum Chiphell. Die videokaart toont grote gelijkenissen met huidige Radeon Pro-videokaarten van AMD. De videokaart lijkt een blauwe blower-koeler krijgen. Deze videokaart zou echter 16GB geheugen hebben, schreef VideoCardz in april. Het is dan ook onduidelijk of dit dezelfde gpu is.

Het is nog onbekend of en wanneer AMD zijn nieuwe RDNA 2-videokaarten voor workstations aankondigt. Eerder werd al wel ondersteuning voor gpu's met deze architectuur toegevoegd aan macOS, waarbij het gerucht rondging dat Apple binnenkort een nieuwe Mac-computer met Radeon Pro 6000-gpu zou uitbrengen. AMD-ceo Lisa Su houdt op 1 juni een keynote tijdens Computex in Taiwan. Mogelijk toont het bedrijf op die datum nieuwe workstationvideokaarten, hoewel dit nog niet is bevestigd.

Facebook lijkt ondersteuning voor Android-apps voor de Oculus Quest- en Quest 2-VR-headsets te testen. Een YouTube-gebruiker merkte op dat verschillende Android-apps in het Preview Apps-gedeelte van de Oculus Store zijn verschenen.

De test werd als eerste opgemerkt door YouTube-gebruiker TheMysticle, die op Twitter schrijft dat er verschillende apps in de Oculus Store van de Quest 2 worden getoond. Deze verschenen in het Preview Apps-gedeelte van de digitale winkel. Oculus plaatst daar doorgaans apps en games die zich nog in een pre-release-fase bevinden en vaak bedoeld zijn voor bètatests van native apps voor de Quest-headsets, schrijft ook RoadtoVR.

Afbeeldingen van TheMysticle tonen verschillende Android-apps in de Oculus Store, waaronder Spotify, Zoom, TikTok, LinkedIn, ProtonMail en Snapchat, naast Android-games als Among Us en Candy Crush. In het informatiescherm van deze apps zou 'Android Apps For Quest' staan, schrijft de YouTube-gebruiker. In een YouTube-video bevestigt hij dat de apps inmiddels uit de Oculus Store zijn verwijderd.

De chief technical officer van Oculus, voormalig id Software-topman John Carmack, stelde vorig jaar al dat hij graag Android-apps zou laten draaien op de Oculus Quest-headsets. In november schreef hij op Twitter dat hij daarvoor blijft pleiten bij de top van Oculus. Dat deed hij als reactie op een vraag van een Quest 2-gebruiker. Daarbij stelde hij wel dat hij het interne debat over dergelijke ondersteuning 'tot nu toe niet wint'.

De Oculus Quest en Quest 2 zijn stand-alone VR-headsets, die gebruikmaken van een op Android gebaseerd besturingssysteem om apps en games te draaien, zonder dat de headsets daarvoor aangesloten moeten worden op een pc. Daarmee is het mogelijk dat de VR-brillen Android-apps zouden kunnen draaien, hoewel dat nog niet officieel is bevestigd. Facebook, het moederbedrijf van Oculus, heeft nog niet gereageerd op de afbeeldingen en claims van TheMysticle. Tweakers heeft hierover vragen uitstaan bij Facebook en Oculus.

Android-apps in de Oculus Store. Afbeeldingen door TheMysticle op Twitter

Apple overwoog in 2015 om alle gebruikers die getroffen waren door de Xcode-malware daarvan op de hoogte te stellen, maar lijkt dat uiteindelijk niet gedaan te hebben. Dat Apple het overwoog, blijkt uit rechtbankdocumenten in de zaak Epic versus Apple.

De rechtbankstukken zijn e-mails tussen verschillende Apple-medewerkers. In dat gesprek wordt overwogen om alle Xcode-slachtoffers, in totaal 128 miljoen gebruikers wereldwijd, op de hoogte te stellen via e-mail. Dit werd niet onmiddellijk gedaan omdat het bericht in veel verschillende talen geschreven zou moeten worden, omdat het systeem om automatisch te vermelden om welke apps het per gebruiker gaat, niet vlekkeloos werkte, en omdat 128 miljoen e-mails versturen ongeveer een week zou duren.

Een Apple-bron van Ars Technica stelt dat zij geen bewijs konden vinden dat die e-mails ooit de deur uit zijn gegaan. De getroffen gebruikers zijn vermoedelijk dus nooit direct gecontacteerd, terwijl dat wel had gekund.

Er is alleen een inmiddels verwijderde post op de Apple-website geplaatst. Die is in het Engels en Chinees; veel van de getroffen apps waren populair in China. De iPhone-maker heeft alleen de 25 meest populaire getroffen apps genoemd, want 'na nummer 25 worden de apps significant minder populair'. Ondanks dat is de consensus onder beveiligingsbedrijven dat het aantal geïnfecteerde apps in de 'vier cijfers' loopt. Gebruikers moesten de apps zelf updaten of verwijderen.

De Xcode-malware zat verstopt in een malafide versie van de Xcode-ide. Die was te halen bij de downloaddienst van Baidu. Dat deden veel Chinese ontwikkelaars omdat de download daar veel sneller zou gaan dan van de servers van Apple. Waarschuwingen over een gebrek aan digitale ondertekening, negeerden ze. De malafide ontwikkelsoftware smokkelde malafide code in de apps waaraan gewerkt werd.

Die apps, voor zaken als instant messaging, internetbankieren, handelen in aandelen, navigatie en gaming, onderschepten systeeminformatie als de taalinstelling, naam en uuid van iPhones en iPads en het netwerktype. De gegevens werden via command-&-control-servers van de criminelen verstuurd. Vervolgens konden de kwaadwillenden notificaties naar smartphones en tablets sturen om gebruikersgegevens te stelen, url's te kapen en het clipboard van de gebruikers uit te lezen. Apple zei destijds dat het 'geen informatie heeft om te suggereren dat de malware is gebruikt om iets kwaadaardigs te doen'.

In de afgelopen dagen kwam de bovenstaande headline langs op meerdere nieuwssites zoals Ars Technica, Engadget, Gizmodo en MacRumors. Op Reddit heeft het nieuws 37.000 upvotes. Zo simpel als de cijfers gebracht worden, zijn ze echter niet, geeft zelfs het analyticsbureau toe.

De grafiek waarop het nieuws wordt gebaseerd, spreekt van het 'percentage actieve mobiele gebruikers in Amerika die app tracking toestaan'. Een overdonderende 96 procent, inmiddels 95 procent, zou 'nee' zeggen tegen tracking in apps, aldus analyticsbedrijf Flurry, dat naar eigen zeggen actief is op meer dan twee miljard apparaten. Zo'n extreem scheve verhouding tussen het 'ja'- en 'nee'-kamp is zeker nieuwswaardig, ware het niet dat de situatie iets complexer is.

Per iOS 14.5 hebben gebruikers de keuze of ze toestemming verlenen om onderworpen te worden aan tracking op hun Apple-apparaat, ten doele van advertenties. Die zaak kunnen ze op meerdere manieren regelen: in het opties-menu alle trackingverzoeken op voorhand afwijzen, of per verzoek van een app een antwoord geven.

De adder onder het gras

Stel nou dat een gebruiker bij de ene app zijn fiat geeft voor tracking en bij de andere niet. En stel dat die twee apps beide analytics van Flurry gebruiken. In de grafiek van het bedrijf zitten alleen maar 'ja'-gebruikers en 'nee'-gebruikers, dus waar komt zo'n geval dan terecht? Deze vraag stelde Tweakers aan Flurry, die verwees naar dezelfde vraag van Seth Berman, Senior Director, Performance Marketing bij Adobe, en Flurry's antwoord daarop.

"Als een gebruiker bij de ene app voor de opt-in gaat en bij de andere voor de opt-out, beschouwen we dat als twee apparaten: een opt-in-apparaat en een opt-out-apparaat", verklaart Flurry. Een gebruiker kan er dus ook daadwerkelijk een zijn in de grafiek, maar ook twee, of misschien wel drie of meer. Dat lijkt een min of meer acceptabele oplossing voor een zaak met dit niveau van complexiteit. Het probleem zit hem er dan echter in dat de kop van de grafiek, 'percentage gebruikers dat tracking toestaat' dus niet klopt. Dat moet eerder iets zijn als 'percentage instemmende antwoorden op tracking requests in iOS 14.5'.

Met de kennis van wat de kop van de grafiek zou moeten zijn, rijst meteen de vraag hoeveel gebruikers het dan écht om gaat. Bovendien zou je voor een beter beeld meer informatie moeten hebben: hoeveel gebruikers antwoordden alleen maar 'nee', hoeveel 'ja' en hoeveel 'een mengsel van beide'? En hoe ziet dat mengsel van beide er dan uit en hoe groot is het? Deze informatie zou het moeilijker maken om een simpel en duidelijk nieuwsartikel naar buiten te brengen, want het wordt meteen tien keer zo complex, maar de informatie is wel betrouwbaarder.

Seth Berman, de man van Adobe, tekent het protest al aan: "Je zou kunnen overwegen om die methode te noteren en niet naar de cijfers refereren als 'percentage gebruikers'. Flurry is in deze zaak een prominente bron voor mensen, maar de data wordt al misbruikt". Ook stipt hij aan dat er tot iOS-versie 14.5.1 een bug was waarbij de system-level-setting onder bepaalde omstandigheden niet goed werd doorgevoerd.

Cijfers hebben beperkte waarde, maar zijn niet waardeloos

Hoewel er dus zeker iets aan te merken valt op de grafiek-headline van Flurry, de headlines van die nieuwssites en de Redditpost met 37.000 upvotes, neemt het niet weg dat deze zeer vroege cijfers een grof beeld schetsen van een situatie die niet positief is voor partijen die gebruikers willen tracken.

De cijfers van Flurry zijn echter niet allemaal dubieus. Het bedrijf noteert ook hoeveel van de gebruikers die het volgt, de tracking in de systeeminstellingen uitschakelt en dus automatisch iedere app een 'nee' geeft. Wereldwijd heeft vijf procent van de 5,3 miljoen gebruikers aangegeven nooit gevolgd te willen worden en in de VS is dat drie procent van de 2,5 miljoen gebruikers. Die cijfers zijn van afgelopen vrijdag.

Google gaat het straks mogelijk makkelijker maken om met third-party controllers op Stadia te spelen met de Chromecast Ultra. Nu kan dat ook al met 'Tandem Mode', maar het bezit van een Stadia-controller is daarbij nog verplicht.

In de bestaande Tandem Mode kunnen spelers die op Stadia gamen op de Chromecast Ultra hun third-party-controller via usb aansluiten op hun Stadia-controller. Hoewel je de Stadia-controller daarbij niet direct gebruikt voor de bediening, is hij nog wel vereist.

9to5Google heeft in versie 3.15 van de Android-app verwijzingen gevonden naar een nieuwe bridge mode waarin je je telefoon kan zetten. Daarin kan ook je telefoon dienen als de controller, met de knoppen zichtbaar op het touchscreen. In het verlengde daarvan is het echter ook mogelijk om een third-party-controller aan te sluiten op de telefoon, waarvan de input vervolgens naar Stadia gaat. Het is nog niet duidelijk of de controller via usb-kabel met de telefoon verbonden moet worden of dat een bluetooth-verbinding ook volstaat.

Verwijzingen naar de functies zitten in een nu verkrijgbare versie van de app, maar de functie werkt nog niet. Naast deze feature wordt ook gesproken over Stadia-volume regelen met je telefoon, integratie met Google Contacts om medespelers makkelijker te vinden en een sneltoets voor het activeren van de screen reader, die tekst opleest voor slechtzienden.

Google Stadia is nog niet beschikbaar voor de nieuwste versie van de Chromecast, uitgerust met Google TV. Het is wel mogelijk om de .apk over te zetten naar de nieuwe Chromecast en die daar te installeren. 9to5Google vond in april al wel verwijzingen naar Google TV-ondersteuning in de Stadia-app.