Afgeschermde Hyves-foto's zichtbaar door bug in kaartenmodule

Foto's van Hyves-gebruikers die van de buitenwereld waren afgeschermd, bleken door een fout in de postkaartenmodule toch toegankelijk. Een gebruiker ontdekte dat hij elke foto als kaart kon selecteren door de url te manipuleren.

Chris Geers, alias tweaker Quinie, ontdekte dat de postkaart-module van Hyves een groot beveiligingslek bevatte. Deze module maakt het mogelijk om een Hyves-foto als postkaart te versturen, in samenwerking met TNT. Door een parameter in de url van de module aan te passen, was het mogelijk om elke Hyves-foto als postkaart te selecteren; ook foto's waarvan een gebruiker niet het recht heeft om ze te zien. Volgens Hyves is de module slechts korte tijd kwetsbaar geweest.

Geers ontdekte dat het bijvoorbeeld mogelijk was foto's te selecteren die enkel voor vrienden zichtbaar zouden moeten zijn, terwijl hij met de eigenaar van de foto's geen vrienden was. "De module controleerde niet of een gebruiker wel het recht had om de foto uit de url als kaart te selecteren", stelt Geers.

Bovendien was het mogelijk om verschillende variabelen die bij de foto hoorden uit te lezen, waaronder de unieke hash van een foto. Daaruit kon de volledige url van de foto worden afgeleid. Dit proces was bovendien te automatiseren, waardoor het mogelijk was om een database met foto's aan te leggen. Als bewijs overhandigde Geers aan Tweakers.net een lijst met zevenhonderd links naar foto's, die hij op deze manier wist te verzamelen.

Hoewel ook verborgen foto's konden worden achterhaald, was het niet mogelijk om specifiek foto's van een bepaalde gebruiker op te vragen. Er kon enkel op de unieke id van een foto worden geselecteerd. Nadat Geers met Hyves contact opnam over het probleem, werd het selecteren van foto's in de kaartjesmodule uit voorzorg uitgeschakeld. Ook werd de ontdekker uitgenodigd bij Hyves om het probleem samen te onderzoeken. Geers is erg te spreken over de reactie van Hyves: "Ze hebben het erg professioneel aangepakt", vindt hij. De links naar foto's die hij had verzameld, werken inmiddels niet meer.

Hyves erkent bij monde van woordvoerder Wouter Glaser dat er enige tijd een lek in de kaartjesmodule heeft gezeten. Glaser doet de kwetsbaarheid af als een 'klein lek', dat maar korte tijd heeft bestaan. "Dit lek is ontstaan na een update", stelt de woordvoerder. "Het is na het melden direct opgelost en was geen groot gevaar voor gebruikers." De Hyves-woordvoerder stelt dat het lek vanzelf aan de orde was gekomen bij een routinecontrole. "Langer dan een dag heeft het niet kunnen bestaan", stelt hij. Dat roept wel de vraag op waarom de beveiliging van de module niet is getest voordat de update werd doorgevoerd.

Volgens woordvoerder Glaser was bovendien 'specifieke technische kennis' vereist om de bug te misbruiken, hoewel er niet veel meer nodig was dan het manipuleren van de url. "Je moet maar net weten dat het openstaat en dat het specifiek op die plek is te misbruiken", stelt Glaser. Momenteel zou de kaartjesmodule weer moeten werken, hoewel het selecteren van een foto uit een album als kaart nog niet mogelijk lijkt te zijn. Volgens Glaser doet Hyves zijn uiterste best om dit soort problemen te voorkomen.

Reacties (80)

[In Search of Sunrise]

Typisch het bestuur achter Hyves weer om het als een kleine bug af te wimpelen en met de drogreden aan komen zetten dat je wel enige technische kennis nodig hebt om het lek te misbruiken. Het geeft aan dat men zelf niet al te veel kaas heeft gegeten van ICT en van ontwikkelingen in de computer wereld niet op de hoogte zijn. Men weet eigenlijk niet hoe ze het lek moeten oplossen en komen dan met zoiets aan zetten.
Telegraaf zou er goed aan doen die hele incompetente bende eruit te gooien en mensen erop te zetten die er wel verstand van hebben.

[Quinie]

Zal ik hier zelf dan maar op reageren met alleen mede te delen dat ik niks meer dan veel kudo's heb voor hyves. Ik geef ze meer vertrouwen dan facebook

[PhilipsFan]

Inderdaad, iedereen loopt maar te mopperen op Hyves en sinds die Telegraaftoestand heffen velen hun account op. Maar diezelfde mensen zijn dan nog wel op Facebook te vinden. Dat is pas een vieze site! Hyves doet het i.h.a. erg netjes.

[Quinie]

Tja..
Zal nog een keer posten na het lezen van aantal (bovenstaande) reacties. Ik ken de in en out's. Die jongens en meiden bij Hyves doen echt goed hun best. Iedereen laat wel eens een steekje vallen.

Maar wat ik heb gezien al daar geef mij veel vertrouwen in Hyves. Ik kan niet anders zeggen dan top!

En facebook heb ik zo me mening over ik heb ze beide maar doe mij toch maar hyves

[arjankoole]

Ik ken mensen die bij Hyves werken, en op basis van je totaal niet geinformeerde opmerkingen kan ik je verzekeren dat ze er een stuk meer kaas van hebben gegeten dan jij.

Die woordvoerder misschien niet, maar hell, daar is het een woordvoerder voor.

[To_Tall]

aplaus dat je die mensen ken ;-) totaal overbodig maar goed. Ben wel verder met je eens

Je moet wel iets meer kunnen dan linkjes aanklikken. Maar we weten allemaal dat in elke software pakket hoe klein of groot ook bugs in zitten. Techniek gaat zo hard. dat elke dag wel tegen iets anders aan loop.
Zelfs al ben je de perfecte programmeur dan nog kunnen er bugs in je software voorkomen. Al is het maar na een update van je browser of update van de onderliggende architectuur.

[OddesE]

Je hebt kleine bugs en grote architectonische fouten. Om met de bouw te vergelijken: Een missend dakpannetje is een kleine bug, maar als je een torenflat van 100 verdiepingen bouwt op drijfzand zonder funderingen dan heb je het niet over een klein foutje.

Hierboven leg ik uit waarom dit een grote architectonische fout is: De autorisatie zit in de verkeerde laag van de software. Hierdoor kun je de hele controle of iets wel of niet mag gewoon passeren, in dit geval door een linkje aan te passen.

[arjankoole]

aplaus dat je die mensen ken ;-) totaal overbodig maar goed.

Nou nee, het geeft aan dat ik best redelijk kan inschatten wat daar voor mensen rondlopen. Beter dan iemand die alleen afgaat op alleen dit artikel (en het hersenloze geblaat wat sommige mensen in reacties plaatsen)

[Exception]

Ja wat kan ik hier over zeggen. Een beetje programmeur houdt met dit soort dingen toch al rekening zonder er überhaupt over na te denken?

[arjankoole]

Ja wat kan ik hier over zeggen. Een beetje programmeur houdt met dit soort dingen toch al rekening zonder er überhaupt over na te denken?

Rekening: ja, maar bij een enorm complexe applicatie kan er toch nog onverhoopt een bug in kruipen.

[Anoniem: 175233]

Van de beschrijving heb ik anders het gevoel dat er een structurele beveiligingsfout is gemaakt. Het lijkt er namelijk op dat de beveiliging iedere keer opnieuw geimplementeerd moet worden in nieuwe functionaliteit, i.p.v. dat er één functie is, die de beveiliging afhandeld, en die door nieuwe functies gebruikt wordt. En dan vraag je er om dat er dit soort bugs komen.

[OddesE]

Correct er is inderdaad een structurele beveiligingsfout gemaakt: De authorisatie laag zit veel te hoog, namelijk in de view laag.

Als dit een model is van een software applicatie:

---------------------------------------
|............... View laag ............... |
---------------------------------------
|........ Business logic laag.........|
---------------------------------------
|.......... Resources laag ............|
---------------------------------------

Dan geeft de resources laag toegang tot het filesysteem (met bijvoorbeeld de genoemde foto's er op), de database, web services waar de app gebruik van kan maken e.d. In de business logic laag zitten de algoritmen die de applicatie maken tot wat hij is. Bijvoorbeeld de code om vriendschappen te maken of verbreken, berichten te plaatsen e.d. In de view laag tenslotte zit de code die het venster of de web pagina opbouwt, icoontjes er bij zet, knoppen aan en uit zet e.d.

Autorisatie is de code die controleert of een gebruiker iets mag. Deze code moet zo laag mogelijk zitten, bij voorkeur in de Resources laag. Als jij als ingelogde gebruiker gewoon geen OS permissies hebt op een bepaalde map in het filesysteem bijvoorbeeld, dan kan de applicatie daar gewoon geen fouten meer mee maken. Je mag er niet bij punt. Stop je die controle hoger, in de business logic laag dan heb je meer flexibiliteit, iemand mag er bijvoorbeeld wel bij, maar alleen als hij een 'vriend' is van de gebruiker waar de map van is. Dat is dan specifieke business logic waardoor het wel in de business logic laag moet zitten.

In de view laag hoort echter *nooit* autorisatie plaats te vinden. Autorisatie in de view laag is bijvoorbeeld voorkomen dat je iets kunt door de knop die je daarvoor moet indrukken niet te tonen... of in het geval van een web pagina door geen link te tonen die die actie uitvoert. Wat je doet als je zelf de url gaat zitten aanpassen is effectief de hele view laag passeren. In plaats van dat je 'netjes' op een linkje klikt maak je zelf je eigen link. Doordat deze mensen de beveiliging in de view laag hebben gestopt kun je dus de hele beveiliging passeren. Waarschijnlijk zal men dit oplossen door een extra check in de business logic laag toe te voegen, maar het is natuurlijk de vraag... als deze fout er in zat, hoeveel meer van dit soort fouten er dan in Hyves zitten.

[RubenBentein]

Dit is niet altijd noodzakelijk een fout, dit kan ook een bewuste keuze zijn. Ik kan ook alle afbeeldingen van iedereen op facebook zien, zolang er maar iemand even de juiste url aan mij doorgeeft (http://sphotos.ak.fbcdn.net/...). Je kan inderdaad zeggen dat dit een fout is, maar dit gebeurt nu eenmaal om performantie redenen.

Het is nu eenmaal niet eenvoudig om hiervoor een performante oplossing voor te bedenken (filters voor elke afbeelding, dynamische afbeelding uit database, ...). Dat maakt een volledige "my album with a lot of photos" pagina gigantisch zwaar om te laden. Op zich is een random naam voor een foto al iets, zo dat je op z'n minst geen "http://facebook.com?profile=0123456789&image=1" dingen kan uithalen.

En door de complexiteit van sociale netwerksites, is de authorisatie van een foto minder voor de hand liggend dan je denkt. Mijn vrienden mogen deze foto zien, maar persoon X niet. Persoon Y die niet mijn vriend is wil ik deze foto ook mee delen, en ik wil ook een permalink met een code in voor mensen die geen facebook hebben, zodat ik hun deze link kan doorsturen en ze toch deze foto mogen zien. Je kan dit soort permissies dus niet instellen op filesystem-niveau.

De enige oplossing is dan om ze in de business logica te steken. En business logica (hoe performant ook. Zie http://developers.facebook.com/blog/post/358) is nog altijd pakken zwaarder dan gewoon files aanbieden vanop een file system.

En het feit dat foto's van verschillende plaatsen komen (door jouw geüpload, getagged bij vrienden, getagged in events, ...) maakt het nog eens complexer. Gooi hierbij het feit dat facebook 1.200.000 afbeeldingen per seconde aanbiedt (Bron: fosdem 2010), en deze authorisatie wordt een duur/moeilijk werkje.

Wat ze hier gedaan hebben blijft inderdaad een bug in hun systeem, waarschijnlijk als gevolg van een slechte ontwerpkeuze in hun architectuur. Maar dat schema van de 3 lagen (ook al is het correct) doet het toch wel een eenvoudiger overkomen dan het is. In elk van die lagen zitten er waarschijnlijk nog een aantal extra lagen met elk hun eigen verantwoordelijkheden.

Als je meer wil weten over facebook en hun architectuur, dit was zeker een interessante talk op fosdem: http://ftp.belnet.be/mirr...ntracks/facebook.xvid.avi

[Anoniem: 154505]

Wat is 'performantie' toch een lelijk woord. Volgens mij is het zelfs geen Nederlands. Laten we dat woord vermijden. Gebruik liever 'prestaties'.

[mashell]

Het is een Vlaams woord. De betekenis is ook echt iets anders dan prestaties.

[mashell]

Maar het hoort toch gewoon in de business logic laag? Het is geen view ding, geen resource ding maar is juist de exacte business logic voor het hyves gebeuren. Zoveel mogelijk laag weg stoppen brengt ook grote risico's met zich mee. Immers in die laag is alles vrij mogelijk, eigenlijk moet je daar zo min mogelijk echte applicatie taken leggen. Ik zeg niet dat we het oneens zijn, want in principe zitten we op 1 lijn maar het is altijd een schemer gebied.

[ajakkes]

Ik vind het inderdaad een klein lek. Hoewel verborgen foto's toch vertoont werden door URL manipulatie zijn de gevolgen van het misbruik niet groot.

Er zijn de afgelopen tijd veel vervelendere bugs in sites langsgekomen. Welke minder netjes en minder snel zijn opgelost.

Ik bedoel bijvoorbeeld:
Kasboek
NEM

Hoewel ik de foto's op mijn sociale site alleen voor vrienden toegankelijk heb gemaakt zet ik er geen foto's tussen die anderen die daar veel moeite voor willen doen echt niet mogen zien.

Wat ik wel mis in het artikel is hoe de URL was opgebouwd en hoe deze te manipuleren was. Was het een volgnummer dat verhoogd of verlaagd moest worden of een hash die gegokt moest worden. Was het duidelijk wie de eigenaar van de foto was.

[sjerdo]

Waarschijnlijk door een id achter de volgende url te plaatsen: http://www.hyves.nl/kaartje/?mediaId=
Alleen bij mijn eigen foto's lukt dat ook niet meer

[mashell]

Nee, zonder na te denken krijg je precies dit soort situaties. Nadenken moet altijd, ook als het simpel lijkt..

[Bramboos]

Via de oudere versie van de Hyves app voor Android zat een soortgelijke bug. Ik kon ook foto's zien van anderen die je via je browser niet kon benaderen.

Snel programmeren en bedenken en nieuwe dingen bedenken als Hyves Mobile komt ten goede van de bedoeling: "een profielensite".

Na ook dit gelezen te hebben krijg je wel het gevoel dat Hyves de boel niet echt op orde te hebben...

[Reactie gewijzigd door Bramboos op 26 juli 2024 15:24]

[Nokian95dude]

Is dat wel een officiele app gemaakt door Hyves zelf? Ik denk het niet want die zijn er (nog) niet. In je geeft zelf al aan dat het met een browser niet te benaderen is op je pc dus lijkt me dat t probleem niet is dat Hyves zijn zaken niet op orde heeft. Hebben ze m.i. namelijk wel.

Maar tis eerder de maker van die app die zijn zaken niet op orde heeft...

[Joost]

Is dat wel een officiele app gemaakt door Hyves zelf?

Ja.

[Glashelder]

Juist als het een app van een derde is lijkt het mij dat Hyves zijn zaken niet op orde heeft. Die apps werken met API's en een van die API's is dan lek.

Het zou natuurlijk echt van de zotte zijn als je aan de client kant moet gaan controleren of je bepaalde content wel mag laten zien.

[APAF-1]

Zelfde was tijdje terug zelfs op desktop.

Als iemand (die wel "bevriend" was met persoon x) mij een foto stuurde van persoon x kon ik 'm met de link van de desbetreffende persoon de foto gewoon zien.
Dat terwijl de hele hyves-profiel van persoon x "privé" en alleen voor vrienden was.

Maarja, als je foto's hebt waarvan je niet wilt dat vreemde ze kunnen zien strooi je er toch ook niet mee op straat?

Al publiceren ze m'n foto's in de NY-times, niks te verbergen. Anders staan ze niet op hyves/ andere social-networking-sites

[Tharulerz]

Bij facebook kan je ook gewoon de afbeeldingsbron kopieren en aan eender wie doorgeven, ook mensen die normaal die foto niet mogen zien (omdat ze geen vriend zijn of geen privacy machtiging hebben).

[aerosoul]

Dat kan precies hetzelfde bij hyves. Je kan zelfs alleen de username wijizigen als je in de foto's kijkt. Dan heeft de foto ineens de rechten van die andere user. Heel slap

[Proxy]

Het heeft natuurlijk niets te maken met verberen. Verder zal ik als reactie op je drogreden mijn welbekende drogreden weer eens van stal halen, als je niets te verbergen hebt dan zou je het ook niet erg vinden dat 500 cameraploegen je 24 uur per dag volgen en alles zonder censuur uitzenden op de TV van je oma/moeder/broer.

Of toch wel? Tuurlijk, iedereen heeft wat te verbergen, we zijn geen emotieloze robots.

[Fjerpje]

Ongelooflijk... rr zitten nog wel een paar meer lekken in hyves. Met het omzetten van URL naar IP kan je ook gewoon foto's van anderen zien die dit niet willen.

[ObAt]

Je bedoelt dat je gewoon de Afbeeldings-URL van elke afbeelding kunt kopiëren in elke browser. Daarna kan iedereen gewoon naar de afbeelding navigeren! Z'n link zit er ongeveer zo uit: http://94.100.123.164/113...39416701-1139416800/(knip, hier staan nog wat getalletjes).jpeg

Nog weinig site's hebben hier een oplossing voor gevonden, hetzelfde geld voor video's, de meeste zijn gewoon te downloaden door de broncode te doorzoeken en gewoon direct naar de URL te navigeren .

Inderdaad nogal gevoelige lekken die veelvoudig worden toegepast, er is zelfs al software voor

[vvs-odrs]

Codes omzetten naar Base64.
http://www.greywyvern.com/code/php/binary2base64

Met behulp hiervan worden foto's omgezet in een niet te naderen pad.
Wel is het zo dat de code hierdoor groter wordt en het laden van de pagina zal wellicht iets langer duren, vanwege de grotere kilobyte van de pagina (dan voorheen).

[doxick]

nee, dat zorgt er voor dat ik enkel de webpagina's hoef af te struinen naar de images ipv links naar de images op diezelfde pagina's.

plaatjes worden omgerekend ongeveer 33% groter, dynamische pagina's zijn niet meer te cachen, net zo min als plaatjes dus en uiteindelijk heb je het over een belachelijk grote data increase.

OF je schermt je data gewoon goed af :-)
je kan ook zorgen voor minder auto-ongelukken door auto's te verbannen.. maar is dat praktisch?

[hackerhater]

Er is een makkelijke manier om dit te blokkeren. De weergave via bijvoorbeeld PHP laten lopen en daar controle of die sessie het wel mag zien

En dan de eigenlijke foto's buiten de WWW-root

[Fjerpje]

Volgens mij is het ook wel eenvoudig af te schermen met een .htaccess bestandje.

[PhilipsFan]

Precies, je kunt heel eenvoudig een php-script de authorisatie laten controleren en als het in orde is de foto uit laten spugen. Als het niet goed is spuugt ie een standaard plaatje uit met een foutmelding o.i.d.

[vvs-odrs]

Hyves heeft op dit moment alle mediaId's vervangen door waarde "deleteMediaForm_mediaId".

Zoek het maar op in de broncode bij Hyves als je op een foto pagina zit.
Hiervoor kon je de name="mediaId" opzoeken en kijken wat er bij id="deleteMediaForm_mediaId" stond.

Vervolgens vulde je je gevonden mediaId achter de = teken in.
En voilá je hebt je eigen kaart met een persoonlijke foto van iemand anders bijv. zonder toestemming.

http://www.hyves.nl/kaartje/?mediaId=

Wel jammer dat social networks hun code niet op orde hebben. We mogen verwachten dat onze privacy, waar onze persoonlijke foto's ook onder vallen, goed gewaarborgd worden.

[P_Tingen]

Wel jammer inderdaad, maar voor een deel ook wel begrijpelijk. Sites als Hyves en Facebook beginnen vaak als een geintje, worden dan opgepikt en worden vervolgens gehypet als een dolle. In die mallemolen kan ik mij voorstellen dat de techneuten hun handen vol hebben aan het opschalen van het serverpark en het opkrikken van de prestaties van hun social site.

Als je gemiddeld een paar tientallen bezoekers tegelijkertijd hebt, hoef je je met een beetje server niet druk te maken om efficiente code, want die server kan dat makkelijk aan. Als je site ineens in the picture staat, mensen in hordes je site bezoeken en je servers roodgloeiend staan, dan wordt vaak pijnlijk duidelijk waar de problemen in de code of database zitten. Snel aanpassen om de prestaties op te krikken is dan gewenst, maar in het heetst van de strijd kan ik me voorstellen dat men wel eens een steekje laat vallen op beveiligingsgebied.

En nee, dat hoort niet zo en geen enkele Tweaker hier zou dat overkomen, maar kennelijk wordt Hyves niet door Tweakers gemaakt.

[Anoniem: 372775]

was bovendien 'specifieke technische kennis' vereist om de bug te misbruiken

Volgens mij is het veranderen van de URL één van de allereerste dingen die de gemiddelde scholieren (gem 15 a 16 jaar) die iets meer dan gemiddeld van computers afweten doen.

In ieder geval dat werd er tzt op mijn school 10 jaar geleden wel geprobeerd...
Toen de eerste dynamische pagina's opkwamen.

[Relief2009]

Iets meer afweten can computers is nog steeds <1% van scholieren.

[Anoniem: 366402]

1% van heel veel is nog steeds veel.

[To_Tall]

<1% betekend minderdan 1%

Anyway, Toen MySQL + PHP en dynamic content kwam opdagen was het juist de truuk om verborgen pagina's te bekijken.

Op veel websites was dat dan ook mogelijk dus ja ik denk dat elke scholier wel weet hoe je van bepaalde sites de URL moet kunnen lezen. Zie ook de URL van Tweakers

[THEMAN!!]

Dan heb ik nog een lek gevonden..

Als iemand zijn/haar foto's ook op de google maps (kaart) heeft gezet, maar op zijn/haar profiel heeft verborgen, kan je toch via je eigen profiel zien.. Dit is als je GEEN vrienden ben met hem/haar..

[Reactie gewijzigd door THEMAN!! op 26 juli 2024 15:24]

[Turbo-Puppy]

Lekker belangerijk nieuws.

Gevalletje eigen schuld dikke bult wat mij betreft.
Als je klakkeloos al je info maar op iedere Social Network site gooit dan, weet je dat dit kan gebeuren.

Ik zou veel liever meer informatie willen lezen over de lekken in Internet Explorer hier op Tweakers ...helaas wordt dat nieuws genegeerd.
( in hoeverre een lek in IE nog nieuws is )

[boelensman1]

"De Hyves-woordvoerder stelt dat het lek vanzelf aan de orde was gekomen bij een routinecontrole."
Is het niet logisch dat je na een update een controle doet? Of stelt elke site dat uit tot het einde van de maand?

[Cartman!]

Jammer dat iedereen het hier afdoet als een faal of als dat Hyves meteen weer drama is. Enig idee hoeveel werk het is geweest zo'n site te maken en hoeveel checks daar wel niet bijhoren? Er kan altijd iets falen, dat is gewoon (vrijwel) altijd met software. Ben het met Hyves eens dat het een klein lek was, je moet toevallig maar het id weten van een foto die beschermd is, die kans is zeer klein met 34-bit id's.

[sambalbaj]

inderdaad, uiteraard is elk lek een lek maar ze pakken het wel snel en professioneel op.
En Quinie krijgt nu mooi de credits.

[OddesE]

Je bagatelliseert het probleem.

Stel je voor de koningin moet ergens een tijdje in een gebouw vertoefen. Ze zit in een kamer in het midden van het gebouw en die heeft één deur. Verder heeft het gebouw zelf 3 toegangsdeuren, 1 hoofdingang en 2 zij ingangen (voor personeel.. ok raar gebouw maar goed ) Stel je nu voor dat men *geen* bewaker zet bij de deur die naar de kamer van de koningin zet, maar wel een bewaker bij de hoofdingang.... Iedereen die een zij ingang gebruikt kan zo naar de koningin lopen zonder een keer gecontroleerd te worden! Epic fail dan toch of niet? Nu heeft men een zij ingang ontdekt en dicht gezet maar hoeveel zijn er nog meer? Er had een bewaker naast de kamer van de konigin zelf moeten staan!


. . --------------------
(2). . . . . . . . . . . . .(3)
. . | . . . .----- . . . . .|
. . | . . O .X .|. . . . ..|
. . | . . . . ---- . . . . .|
. . | . . . . . . . . . . . .|
. . | . . . . .B . . . . . .|
. . -------- . ----------
. . . . . . . (1)

X koningin
(1) Hoofdingang
(2) Zij ingang
(3) Zij ingang
B Bewaker
O Ontbrekende bewaker....

[mashell]

Of een onderwijzer die erg duidelijk iets kan uitleggen, daar veel moeite voor doet en daarbij best wel een beetje afdwaalt. Maakt het net wat interessanter allemaal.

[Cartman!]

Ik vind niet dat je een foto op een webomgeving (die je dus bewust zelf erop hebt gezet) kunt vergelijking met de koningin, dat is hele andere orde van grootte als het aankomt op veiligheid. Ik denk dat velen onderschatten hoeveel informatie ze op internet zetten en als er dan door een kleine bug iets achterhaald kan worden schreeuwen ze moord en brand. Als jij die bewuste foto upload ben je je er toch hopelijk bewust van dat het altijd uit kan lekken, op welke manier dan ook. Als iemand een muur opblaast bij het datacentrum en die harddisk mee jat dan was de webbeveiliging top maar hebben ze het op een andere manier verkregen. Tja...kun je Hyves dat echt kwalijk nemen? Ik denk t niet.

Ik praat niet goed dat er bugs in software mogen zitten, maar bovenstaande vergelijking vind ik enorm krom.