Steam gebruikt verouderde Chromium-browser

Steam maakt gebruik van de opensourceversie van Googles Chrome-browser, Chromium. Daarvoor gebruikt Steam de voorlaatste stabiele versie van de browser, nummer 47, die uit het bèta-kanaal kwam op 1 december 2015. De huidige stabiele versie is nummer 48.

Dit zou kunnen leiden tot mogelijke kwetsbaarheden schrijft Ghacks, vooral omdat Steam Chromium niet in een sandbox laat draaien, getuige het --no-sandbox-commando. Door de browser in een sandbox te laten draaien, worden gebruikers beter beschermd. De ontdekking dat Chromium niet in sandbox-mode draait en een verouderde versie is, werd gemeld op de officiële GitHub-pagina van Valve door GitHub-gebruiker ekaris.

Valve is niet de enige die de opensourcebrowser Chromium gebruikt voor zijn dienst. De browser wordt door veel bedrijven gebruikt om een eigen browserimplementatie te maken. Het probleem is dat die browsers vaak niet in de pas lopen met de meest recente stabiele versie van de browser. Onlangs is Googles beveiligingsteam begonnen met het analyseren van browsers gebaseerd op Chromium en browserextensies.

Het ontdekte onder andere dat antivirusbedrijf Avast de browser verkeerd gebruikte, waarbij het voor aanvallers mogelijk was alle bestanden op een systeem te lezen als gebruikers op een bepaalde link klikten. Ook de op 'veiligheid, snelheid en privacy' gerichte browser van Comodo genaamd Chromodo had bijvoorbeeld veel veiligheidsproblemen.

Nummer 48 is de laatste stabiele versie van Chromium en is sinds 20 januari 2016 beschikbaar. In de versie zijn verschillende bugs geplet ten opzichte van nummer 47, waaronder cve-2016-1612 met een fout in de Google V8-renderengine en kwetsbaarheid cve-2016-1613 voor de pdf-implementatie PDFium. Versie 49 van de browser is momenteel in bèta en komt waarschijnlijk in de week van 8 maart in het stabiele kanaal. Versie 50 bevindt zich nog in de dev-channel en hoeft niet voor de week van 19 april in stable verwacht te worden.

Recentelijk vertelde een chef van de NSA aan Wired dat Steam een geliefde vector is om in te breken op apparaten die werknemers meenemen naar kantoor. Of dat door de browser komt of door games met ondeugdelijke beveiliging, vertelt het verhaal niet.

Reacties (71)

[CH4OS]

Steam maakt gebruik van de opensourceversie van Googles Chrome-browser, Chromium. Daarvoor gebruikt Steam de voorlaatste stabiele versie van de browser, nummer 47, die uit het bèta-kanaal kwam op 1 december 2015. De huidige stabiele versie is nummer 48.

Het is natuurlijk de vraag of de code waarop Steam zijn embedded Chromium gebaseerd is op hetzelfde patchlevel zit als de Chromium browser zelf. Het zou mij niet verbazen als Steam hier een eigen fork voor gebruikt, Als dat het geval is, dan is het nog maar de vraag in hoeverre die fork bij is qua patchlevel ten opzichte van de broncode bij Google.

Je kunt dus niet er zomaar van uit gaan dat Chromium binnen Steam is gebaseerd op Chromium van Google zélf. Ook omdat Steam zijn eigen schil over Chromium heeft en Chromium binnen Steam akelig beperkt is, om een voorbeeld te noemen. Wellicht zitten er bijvoorbeeld backports of andere beperkingen in, waardoor Chromium binnen Steam hier niet vatbaar voor is en je dus een wat uitgeklede versie hebt van Chromium.

Een versienummer alleen zegt dus nog maar weinig. De webbrowser binnen Steam is in elk geval sterk beperkt en zeker niet gelijk aan Chromium op de desktop zelf. Het nieuwsartikel is daardoor naar mijn idee dus gebaseerd op een voorbarige aanname.

Steam heeft zelf ook een beta client, wat is het versienummer van Chromium daar? Wellicht zit er dus een update van Chromium in de pijplijn bij Steam.

Al met al lijkt het er dus naar mijn idee best op, dat dit nieuwsartikel voornamelijk is gebaseerd op aannames die wellicht niet eens kloppen.

[Reactie gewijzigd door CH4OS op 22 juli 2024 19:08]

[letatcest]

Als je naar het plaatje kijkt, zie je dat ze gebruikmaken van het Chromium Embedded Framework, dat onderhouden wordt door het Web Engine Team van Adobe. Om verwarring te voorkomen, hebben we de verwijzing daarnaar uiteindelijk niet in het verhaal gestopt.

De builds van CEF lopen, voor zover ons bekend, achter. De huidige Chromium 48-build die in de dev-channel van CEF staat, is ook niet de allerlaatste die in stable Chrome(ium)-versies zit (zie: https://cefbuilds.com/ )

Goolge baseert zich officieel op het Chromium opensourceproject. Dat die twee dicht met elkaar verweven zijn, dat is een ander verhaal.

Veel andere berichtgeving stelt dat de stabiele desktopversie van Chrome ondertussen op 50 zit, maar dat is volledig onwaar.

Steam is in dit geval eerder de hoge boom en daarom hangen er ook nog wat andere gebruikers van CEF aan. Het laat zien dat het 'zomaar' implementeren van opensourceprojecten niet per se leidt tot veilige versies, als je je niet aan de update-cycle houdt. Maar hoe die precies loopt bij Valve kunnen we hier niet zien.

Webbrowsing binnen Steam is volgens mij niet heel erg beperkt verder. Helaas zit ik niet in het bèta-programma van Steam.

[CH4OS]

De builds van CEF lopen, voor zover ons bekend, achter. De huidige Chromium 48-build die in de dev-channel van CEF staat, is ook niet de allerlaatste die in stable Chrome(ium)-versies zit (zie: https://cefbuilds.com/ )

Met andere woorden; mogelijk dus óók vatbaar al zouden ze CEF updaten.

Welke versie van CEF heeft Steam momenteel in diens beta versie van de Steam Client? Wellicht ligt er dus een update voor in het verschiet. Daarnaast is de build ook niet zo héél oud, dus zo raar vind ik het niet dat versie 47 nog gebruikt wordt. Wel vervelend van de 2 critical CVE's, maar meer dan dat is het niet tot zeker is dat CEF er ook last van heeft.

Webbrowsing binnen Steam is volgens mij niet heel erg beperkt verder. Helaas zit ik niet in het bèta-programma van Steam.

Chromium in Steam wordt echter niet alleen gebruikt voor het webbrowsen vanuit Steam. Steam is zover ik weet, een schil over Chromium heen. Vandaar dat ik verwacht dat Steam / Valve een fork gebruikt van CEF. Blijkbaar met dezelfde versioning, maar ook dat hoeft dan natuurlijk niets meer te zeggen. Dat Chromium er last van heeft, wil natuurlijk niet per se zeggen dat de embedded variant er ook last van heeft.

Sorry, maar het blijven dus aannames naar mijn idee, die hier echter wel als feit gebracht worden.

[Reactie gewijzigd door CH4OS op 22 juli 2024 19:08]

[MrFax]

Ah ja maar dat veranderd alles... Ze willen verwarring voorkomen maar nu doen ze het tegenovergestelde

Ik dacht dat dit tweakers.net was, en nieuwsartikelen niet voor elke oog leesbaar/te begrijpen was.

[Uncle Mel]

Ook in de bètaversie van Steam wordt deze versie van Chromium gebruikt

[MrFax]

Dit is wel een feit omdat in steam changelogs altijd de precieze versie nummers van stabiele Chromium versies staan. CMIIW maar Valve merged Chromium gewoon upstream

[Reactie gewijzigd door MrFax op 22 juli 2024 19:08]

[CH4OS]

Ah oke. Maar dan nog kunnen ze er wel bijvoorbeeld backports er in hebben gedaan. Naast dat Chromium in Steam best dichtgetimmerd is, denk ik dat de kans klein is dat met de Chromium in Steam dingen misbruikt kunnen worden.

[Blokker_1999]

Dit is eigenlijk non nieuws. Bij het lezen van de titel en het woord verouderd dacht ik even dat een versie van meer dan een jaar oud gebruikt word. Om dan te lezen dat ze met een versie zitten die slechts enkele weken ouder is dan de recentste versie moet ik eigenlijk zeggen dat het omgekeerde mij meer zou verbazen.

Je wil in Steam (of elk ander project) geen onstabiele versie hebben. Je moet dus eerst wachten op een stabiele build/release van de browser waarna je pas kan beginnen aan het testen van de embedded versie voor je eigen software. Dat kost tijd en je zal dus altijd achterlopen.

[Verwijderd]

Ik had inderdaad ook zo'n gedacht bij het lezen van de titel . Ik vraag me wel af waarom ze de browser in no-sandbox mode draaien als dat onveiliger is. Wat zou hier de mogelijke reden van zijn?

[defixje]

Misschien om eigen content te kunnen injecteren op manieren die normaal in sandbox mode niet mogelijk zijn.

[R4gnax]

Misschien om eigen content te kunnen injecteren op manieren die normaal in sandbox mode niet mogelijk zijn.

Zoals? Ook met de sandbox aan kun je nl. gewoon je eigen host objects ontsluiten voor gebruik door JS in de browser via je eigen bindings. Dat is vziw nou net iets wat CEF makkelijker maakt.

Ik denk eerder dat het uitzetten v/d sandbox te maken heeft met process-injection van de Steam overlay in een draaiende game en het openen van de browser in de overlay.

[Rob Coops]

No sandbox draait waarschijnlijk omdat men bijvoorbeeld een "plug-in" heeft draaien die bij onderdelen van de computer moet kunnen komen waar je in sandbox mode geen toegang toe hebt. Ik vermoed dat bijvoorbeeld de doorvoer snelheid en of het automatisch downloaden en patchen van games een reden zouden kunnen zijn dat je niet in sandbox mode kan draaien.

[MrFax]

En daarom is het beter om een versie van een browser platform te nemen dat een extended life cycle heeft, en dat heeft Chromium niet, waardoor er in oudere majore versies van Chromium geen security issues gefixt wordt en je dus altijd de kans hebt dat een nieuwe versie je platform breekt.

Je moet dus dan een keuze maken:

1) op tijd updaten en een (best wel grote) kans hebben op problemen
2) een versie achterlopen om langer te kunnen testen.

Als de Steam platform breekt is dat natuurlijk een veel(let op: veel) groter probleem voor Valve dan een aantal geinfecteerde pc's.

Misschien is het voor Valve een beter en veiligere keuze om af te stappen van Chromium en op alternatieven als WebCore over te stappen, of om zelf security patches te mergen.

Edit: Dit was als reactie op de hoofd-thread bedoelt... oeps. Mobiele site

[Reactie gewijzigd door MrFax op 22 juli 2024 19:08]

[Loller1]

Een andere oplossing zou zijn om gewoon de build-in webview van het OS te gebruiken, EdgeHTML op Windows 10, Webkit op OS X, en whatever de webview is op Linux distro's.

[MrFax]

Dat deed Steam since de release ervan, maar dat gaf vaak problemen en de performance liet te wensen over en waarschijnlijk had Valve features nodig die de built-in viewer niet had.

Since de release van de moderne Edge zou dit natuurlijk wel weer kunnen maar dat is nu al veels te laat.

[Reactie gewijzigd door MrFax op 22 juli 2024 19:08]

[Verwijderd]

1 december is de laatste versie uit het betá-kanaal gekomen. Die versie is dus al 2 maanden stabiel. Sowieso vraag ik me af wat Steam moet testen aangezien ze gewoon linken naar hun eigen website die in elke hedendaagse browser goed werkt.

[EwanO]

Steam heeft ook een ingame browser waarin je alle websites kan bezoeken

[henkdejong]

1 december is de huidig gebruikte versie uit beta gekomen. De enige versie die daarna uit beta is gekomen is van 20 januari. Steam loopt dus 3 weken achter op het moment. Mogelijk dat het beta kanaal van de Steam client al wel deze nieuwe versie bevat.

[CAPSLOCK2000]

Dit is eigenlijk non nieuws. Bij het lezen van de titel en het woord verouderd dacht ik even dat een versie van meer dan een jaar oud gebruikt word. Om dan te lezen dat ze met een versie zitten die slechts enkele weken ouder is dan de recentste versie moet ik eigenlijk zeggen dat het omgekeerde mij meer zou verbazen.

Dat was ook mijn verwachting, op een bepaalde manier laat het zien hoe groot het probleem is. Software wordt steeds complexer en er komen steeds meer lagen bij. Iedere volgende laag moet wachten op onderhoud en ontwikkeling in de vorige lagen.

Het heeft ook te maken met hoe we software beheren. De standaard is om een applicatie te verschepen samen met alle ondersteunende software. Als een applicatie gebruik maakt van bibliotheken en componenten zoals Chromium dan is het gebruikelijk dat die applicatie zelf een kopie van Chromium bevat en deze ook zelf bijwerkt (of niet). Bij een beetje grote applicatie gaat het al snel om tientallen of honderden componeten.
Nog vervelender is dat iedere applicatie z'n eigen verzameling componenten heeft die afzonderlijk beheerd moeten worden. Zo kan het zijn dat je tientallen kopietjes van populaire componenten hebt, eentje voor iedere applicatie die er gebruik van maakt.

Vanuit het oogpunt van de veiligheid zou het mooier zijn als je die componenten centraal installeert en beheert. In plaats van dat iedere applicatie alles zelf moet doen kun je dan ook een centrale updater gebruiken.
Tot op zekere hoogte bestaat dat al, Windows (of elk ander OS) is zo'n verzameling centraal beheerde componenten met een gemeenschappelijke updater. Als er een bug in Windows wordt gefixed dan profiteren alle applicaties mee.

Onder Windows is er een scherpe grens tussen OS en applicaties en die bestaat ook voor de updater. Daardoor moeten de meeste applicaties nog steeds bijna alles zelf doen.
Google heeft voor Android een hybride oplossing bedacht via de Google Play Services. Het OS is in praktijk haast niet te updaten (om redenen die nu even niet relevant zijn) maar via de Play Services kunnen ze toch nog een paar belangrijke componenten updaten.

Onder Linux (je zat er al op te wachten) is het model anders. Daar is er wel een centrale updater en de meeste ontwikkelaars zijn daar aan gewend en houden er rekening mee. Het is heel gewoon om volledig op het OS te vertrouwen om alle componenten aan te leveren die je applicatie nodig heeft in plaats van zelf alles in te bakkken. Daardoor is het veel makkelijker om bugs in één keer voor het hele systeem te repareren. Het systeem heeft natuurlijk ook nadelen, anders was de hele wereld al overgestapt, maar vanuit security oogpunt is het onovertroffen.

[Baserk]

Wat betreft linux; je zit wel met WebKitGTK+ 2.8.5 op bijv. meest recente Ubuntu 15.10.
Lees hierover 'On webkit security'.link

[Brent]

Het is zeker een stuk minder ernstig dan het titel misschien doet vermoeden, maar evengoed is de ontdekking dat standaard --no-sandbox-commando aanstaat een serieus onveilige vector die er niet zou moeten zijn. Ook Valve moet scherp blijven, en daar hoort soms zo'n extern onderzoek bij.

[aadje93]

ik vermoed dat er no-sandbox inzit gezien het gedeelte voor betalingen, dat gaat via de steam browser echter moet de client wachten tot de betaling gedaan is alvorens hij verder kan.

*Al weet ik niet in hoeverre chromium verweven is in steam*

[Cilph]

Zijn we ons nou echt druk aan het maken om embedded browsers uit December 2015, die één versie achterlopen?

[BasilFX]

Ja, stiekem wel. Zie hier: https://www.cvedetails.co...opec-1/Google-Chrome.html

Daar zijn al twee exploits voor een Chrome 47/Chromium, met een score 10.0. Beide exploits in december geregistreerd.

EDIT: Merk overigens op dat eerste (CVE-2015-6792) een exploit beschrijft in hetzelfde versienummer als in de screenshot.

[Reactie gewijzigd door BasilFX op 22 juli 2024 19:08]

[CH4OS]

Echter is er voor Chromium Embedded Framework (CEF) een totaal andere source beschikbaar, die dus mogelijk géén last heeft van de genoemde CVE's van Google Chrome. Dat dezelfde versioning aangehouden wordt, zegt niets over de code zelf. Er kunnen dan nog altijd backports in zitten, waardoor CEF niet vatbaar is voor de genoemde CVE's of zelfs de gewraakte code niet eens bezit, omdat het dus een totaal andere sourcecode is.

[latka]

Ja, in theorie wel. In de praktijk geloof ik dat niet echt. Bugs worden niet per ongeluk gefixed en backporten is werk wat je kunt vermijden door sneller vooruit te gaan. Ik denk dat ze besparen op het backporten en niet snel genoeg vooruitgaan. Dat source niet 100% overeenkomt zal best. Behalve dat er echt geen andere V8 JS engine in zit. Met zo'n groot stuk software als een browser tegenwoordig is, is de kans dat je de bugs meeneemt wel heel erg groot geworden.

[Verwijderd]

Voor mensen die er zin in hebben kunnen hier lezen hoe Chromium en CEF (Chromium Embedded Framework) zich tot elkaar verhouden: http://blogs.adobe.com/we...omium-embedded-framework/ en https://bitbucket.org/chromiumembedded/cef/wiki/Architecture .

[Reactie gewijzigd door Verwijderd op 22 juli 2024 19:08]

[himlims_]

Jah; dat een $usertje een oude browser gebruikt is niet zon ramp.

Maar wanneer Steam/Valve een systeem aan de consument aanbiedt, waarmee betalingen worden verricht en persoonlijke data wordt opgeslagen wat bovendien door vele Tweakers hier wordt gebruikt is zeker nieuwswaardig.

Maar of het terecht is dat we nu allemaal 'boos' naar steam wijzen ...

Steam's using the most up-to-date non-dev-branch CEF build (see https://cefbuilds.com), the problem is that CEF is lagging behind mainline Chromium. Really the only way to correct this would be to bring CEF into being a first-class part of the Chromium project, but without the backing of Google that's really unlikely to happen..
[bron]

[CH4OS]

Tja, aan de andere kant, er zijn dus ook builds van Google Chrome en Chromium geweest met hetzelfde buildnummer. De exploits hebben dus (wellicht) ook in die browsers gezeten.

Al is dit denk ik waar je op doelt, maar dacht, kaart het voor de zekerheid even aan.

[Giesber]

Zijn we ons nou echt druk aan het maken om embedded browsers uit December 2015, die één versie achterlopen?

Een beetje. Je zou kunnen zeggen dat het meevalt dat ze maar een maand achterlopen, maar daarmee kan je uiteraard wel een maand langer de deur open zetten voor virussen en malware. En als Google een nieuwe versie uitbrengt, wordt het meestal ook gemakkelijker om de kwetsbaarheden in de oudere versies uit te buiten. Deze kunnen dan bekend gemaakt worden. Vandaar is het niet zo raadzaam om zomaar een maandje achter te lopen met patches.

Ik maak mij meer zorgen over het feit dat ze security features zoals de sandbox uitzetten. Als ze dan al een niet gepatcht lek hebben kan het ook nog eens gemakkelijker schade veroorzaken.

[Verwijderd]

Achterlopen en geen container gebruiken wel. Je gaat dan volledig uit van de beveiligingsmaatregelen op de PC van de gamer. Op zichzelf als je achterloopt maar de container is actief dan is er al een hoop minder aan de hand.

[phochs]

Mee eens, was ook mijn eerste gedachte.
Is dit nieuwswaardig?

[loki504]

Ja het is nieuwswaardig. Alleen tweakers plakt er een clickbait titel aan vast. En mensen lezen alleen de titel en gaan in /nerdrage mode.

Het melden is niet heel erg.(zolang het maar niet te kosten gaat van belangrijkers nieuws.

[Anoniem: 463321]

Ik ben het met je eerste zin eens maar ik heb het artikel wel gelezen en sluit me bij Cilph aan dat het niet gekker moet worden. Cilph kan net als phochs, ik en wellicht anderen pas tot de conclusie komen dat dit toch wel wat overtrokken is als het artikel gelezen is. Er wordt namelijk een link gelegd tussen titel en inhoud. Dat we overgaan in nerdrage mode slaat dan ook nergens op.

[latka]

Als microsoft een know CVE niet binnen 20 minuten met een patch oplost is het een probleem want.... Als Valve software released met known issues/security exploits is het goed?? Natuurlijk is er een probleem. Maar m.i. een ander probleem dan het artikel beschrijft: als Google zo nodig een bughunt doet omdat iedereen en zijn moeder Chrome verkeerd embed is er iets mis met hoe chrome ge-released wordt. Blijkbaar is een default chrome install (met autoudate etc.) niet bruikbaar om te embedden. Waarom niet dan? Dat doet MS als sinsds mensenheugenis met IE en iedereen kan die control embedden/gebruiken en krijgt de patches gratis. Waarom lukt dat niet met Chrome?

[Herko_ter_Horst]

Inderdaad, het is niet alsof ze IE 6 embedded hebben, of zo...

[hcQd]

Chromium is open source, het is hierdoor heel simpel om te zien welke bugs geplet zijn en is het makkelijker om aanvalsvectoren te ontdekken voor oudere versies.

[Loller1]

Wel ja, er zitten verschillende ongepatchte kwetsbaarheden in Chromium 47 wat zeer zeker een veiligheidsrisico inhoud. Maakt niet uit dat hij nog maar 2 maanden oud is. Oudere IEs (9/10) en Firefox ESRs zijn belangen na niet zo kwetsbaar als een Chromium-based browser die 1 maand achterloopt.

[KoploperMau]

Ik vind van wel. Vergeet niet dat Steam een groot, veelgebruikt platform is dat ook nog eens veel gebruikers heeft. Het kleinste foutje kan veel gebruikers treffen, en Steam update zo vaak, dan kan dit ook wel geüpdatet worden. Dus ja, we moeten ons hier druk om maken. Steam cq Valve moet gewoon zijn zaakjes op orde hebben.

[CAPSLOCK2000]

Ik snap heel goed waar je opmerking vandaan komt maar mijn reactie is "he he, eindelijk, het werd tijd". Uit jouw reactie en die van velen anderen blijkt duidelijk wat we het heel normaal vinden om maandenlang met grote beveiligingsgaten rond te lopen.

We hebben het hier niet over een stel junkies die inbreken en fietsen stelen en vijf jaar nodig hebben om een nieuw type slot open te maken. We hebben het over alle hackers van de wereld die direct of indirect alle computers in de wereld aanvallen. Iedere consument en iedere bedrijf met een computer op internet neemt deel aan die strijd, of je dat nu wil of niet. Je hoeft geen intersesant doel te zijn, iedere computer op internet is op zichzelf al interessant.
99% van de aanvallers zijn kruimeldiefjes die niks aanrichten maar die 1% aan professionele hackers en botnetbeheerders zijn het probleem. Die wachten geen half jaar om een lek uit te buiten, die komen direct in actie.

Beveiliging zoals het installeren van patches is voor de meeste mensen een maandelijkse activiteit, op z'n best, zat mensen die minder dan eens per jaar onderhoud plegen. Een modern systeem installeert gelukkig zelf patches maar dat is typisch eens in de maand het patchen van een bug duurt ook al snel een maand. Met een beetje pech moet je dus twee a drie maanden wachten voor een fout is verholpen. De hackers wachten niet zo lang, die gaan direct aan de slag. Moderne Linux-distributies brengen een paar keer per dag patches uit maar zelfs dat is in sommige gevallen te traag. Ik verwacht niet dat dit in de nabije toekomst anders gaat worden. De wereld gaat steeds sneller en we moeten dus ook steeds vaker gaan patchen. Eens per minuut zou mooi zijn

[SuperDre]

De interne browser wordt voornamelijk gebruikt voor de store zelf en eigenlijk niet voor andere zaken, dus ik zie hier sowieso niet echt een probleem in, tenzij de store gehackt zou worden en dan malafide code hier injecteert..

[R4gnax]

De interne browser wordt voornamelijk gebruikt voor de store zelf en eigenlijk niet voor andere zaken, dus ik zie hier sowieso niet echt een probleem in, tenzij de store gehackt zou worden en dan malafide code hier injecteert..

De interne browser wordt ook gebruikt in de Steam overlay. Dat maakt het draaien zonder sandbox uitermate gevaarlijk. Kwestie van een gebruiker die een keer via die embedded browser naar een walkthrough of guide gaat zoeken buiten Steam en waarbij een malafide advertentie zijn/haar pad kruist en je hebt de poppen aan het dansen.

[Reactie gewijzigd door R4gnax op 22 juli 2024 19:08]

[Soggney]

Indien dat zo is, lijkt het me wel best om geen Steam te draaien op bedrijfshardware.
Wel jammer dat Steam Chromium niet in een sandbox laat draaien. Weet iemand waarom ze daarvoor kiezen?

[Wailing_Banshee]

Is alleen het installeren van Steam al voldoende? Of moet je er ook gebruik van maken? In dat laatste geval, wie maakt er nou gebruik van die browser! Ik gebruik gewoon mijn tablet als ik iets moet opzoeken als ik aan het spelen ben (heb ik tenminste ook al mijn snelkoppelingen, etc)

[jLing]

Steam Store etc gaat ook via deze browser.

[Verwijderd]

En die is in de praktijk mega langzaam/laggy vergeleken met de browser. Ik browse zelf dan nagenoeg nooit via die interne browser van Steam. Geef mij maar gewoon store.steampowered.com

[Wailing_Banshee]

Goed punt, had ik niet aan gedacht... Ach, gewoon geen spelletjes kopen op kantoor en er is niets aan de hand

[Jaahp]

Maar wat moeten we dan op werk doen?

[shades]

Steam verkoopt niet alleen games maar ook applicaties. Ik kan me voorstellen dat daar diverse applicaties tussen zitten die je kunnen helpen bij het uitvoeren van je dagelijkse werkzaamheden..
(ik heb zelf deze http://store.steampowered...7260/?snr=1_7_7_151_150_1)

[Reactie gewijzigd door shades op 22 juli 2024 19:08]

[Jaahp]

Ik denk niet dat veel mensen in het bedrijfsleven onironisch de Steam browser gebruiken om hun werk uit te voeren...

[SkyStreaker]

Goed. Echter, alles wat je in steam "browsed" is toch alleen de shops e.d. op Steam zelf? Hoe kan je daar precies de kwaadwillende uithangen?

[proatjeboksem]

Dat was ook mijn eerste gedachte. of kun je de browser ook voor andere doeleinden gebruiken?
Weer websites oid?

en Je zou met DNS spoofing oid ervoor kunnen zorgen dat de steambox naar een website-met-kwade-bedoelingen gaat, ipv de steam app/gamestore, maargoed.

[Verwijderd]

Je kunt er in principe overal mee rondbrowsen, maar dat zal niet zo vaak gebeuren, dus ik denk ook dat het geen enorm beveiligingsrisico is

[PdeBie]

Nee hoor, ik gebruik het ook om bijvoorbeeld een walkthrough op Google op te zoeken als ik ergens in een game vast zit.

[R4gnax]

Nee hoor, ik gebruik het ook om bijvoorbeeld een walkthrough op Google op te zoeken als ik ergens in een game vast zit.

En dat is, gok ik, waarom de sandbox uit staat. De proces-injectie voor de Steam overlay-versie v/d browser speelt wss. niet samen met Chromium's sandbox.

[dmantione]

Start de Big Picture-mode, kies dan voor "web" en hij functioneert als browser voor algemeen gebruik.

[PerfectionVR]

Simpelweg hun eigen fork mergen kan al een stuk werk zijn maar daarna ook nog al hun systemen en paginas testen lijkt mij wel het ergste. Wellicht moeten ze ook extensief gaan testen met de in-game overlay waar de browser ook in gebruikt word.
Dit heeft in het verleden ook wel eens problemen opgeleverd ik heb er de laatste jaar(en) steeds meer stabiliteits problemen mee gehad.

Als ik bijvoorbeeld een match counter-strike bezig ben met een team dan ga ik niet zitten alt-tabben. Dan gebruik ik gewoon de in-game overlay om wat te youtuben, ff snell tussendoor een smoke angle te leren, etc etc.

Waarschijnlijk is dit gewoon gepubliceerd om wat druk achter Valve te zetten. Pun intended?

[rbr320]

Het artikel linkt alleen naar het issue op GitHub waarin is gemeld dat de browser verouderd is, maar het niet draaien in een sandbox van de browser is gemeld in dit issue: https://github.com/ValveSoftware/steam-for-linux/issues/4293

[Finraziel]

Als Steam Chromium gebruikt, dan vraag ik me toch af wat ze er nog meer mee doen waardoor het zo traag wordt als dikke ...
Ik gebruik meestal gewoon maar chrome om Steam zaken te bekijken (de store, guides, friend activity en zo), dat is vele malen sneller. Als het eigenlijk praktisch dezelfde software is... vreemd.

[Jeldert]

Iets zegt me dat we dit soort problemen nog veel vaker gaan zien met de opkomst van container-technieken als Docker.

[Herko_ter_Horst]

Die moet je ff uitleggen. Welke problemen en wat heeft het embedden van een browser in een desktop app te maken met (Docker) containers?

[Soldaatje]

Docker containers moeten ook geupdate worden, dat gaat niet vanzelf automatisch.
Gevolg is dat er veel oude software kan blijven draaien in productieomgevingen.

[dmantione]

Het ironische is juist dat men vaak precies om die reden Docker (en andere virtualisatiemiddelen) inzet: Door virtualisatie is de container hardwareonafhankelijk en inzetbaar op meerdere machines, waardoor het een black box wordt: Eenmaal inrichten en nooit meer aan prutsen.