Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering

TidBITS Logo

TidBITS#894, 27 augustus 2007

Stellen we ons bloot aan allerlei kwaadaardige aanvallen op onze gegevens, nu de iPhone en andere apparaten ons op verschillende locaties met het internet verbonden houden? Glenn Fleishman geeft uitleg over "sidejacking", een zwak punt in de manier waarop webverkeer wordt geregeld dat mogelijk schade kan aanrichten, en waarom de gemakkelijkste oplossing hiervoor tegelijk de minst waarschijnlijke is die gebruikt zal worden. Verder verschijnt Adam in deze aflevering met een bespreking van Teleport, een hulpmiddel waarmee gemakkelijk twee machines kunnen worden gedeeld, en kijkt hij naar de herziene versie vam de TidBITS AutoCorrect Dictionary, te gebruiken met Typinator. Hoe krijg je zes ton machinerie voor ononderbroken electriciteitsvoorziening naar de bovenste verdieping van een datacentrum? Glenn doet de top-down oplossing uit de doeken die onze internetprovider digital.forest toepaste. We ronden dit nummer af met nieuws over het verschijnen van Microsoft Office 2004 11.3.7, iPhone 1.0.2, iMovie 7.0.1 en iWeb 2.0.1.
 
Artikelen
 

Deze editie van TidBITS werd gedeeltelijk gesponsord door:
Help TidBITS te ondersteunen door onze sponsors te sponsoren!!

De Nederlandse editie van TidBITS is een letterlijke vertaling van de oorspronkelijke Engelse versie. Daarom is het mogelijk dat een deel van de inhoud niet geldt in bepaalde landen buiten de VS.

Dit nummer werd uit het Engels vertaald door:

Verder werkten mee:

Hoe je ons kunt bereiken kun je lezen op:
<./tidbits-nl/contact.html>


Geen aflevering op 3 september 2007

  door Jeff Carlson <[email protected]>
[vertaling: RH]

Maandag aanstaande is het Labor Day [Dag van de Arbeid - nvdv] in de Verenigde Staten, wat als een lang weekend wordt gevierd. Wij publiceren die dag geen aflevering, hoewel dat niet betekent dat we minder werk verzetten. We zullen van de gelegenheid gebruik maken om aan de infrastructuur van TidBITS te werken en natuurlijk gaan we door met het plaatsen van nieuws en andere interessante artikelen op de TidBITS-website. Onze volgende aflevering zal uitkomen op maandag 10 september. Tot dan!

Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb


iPhone en iLife '08 krijgen updates met foutencorrecties

  door Jeff Carlson <[email protected]>
[vertaling: RH]

Apple heeft onlangs updates voor iPhone en voor twee onderdelen van iLife '08 uitgebracht die vooral niet nader aangeduide foutencorrecties bevatten. iPhone 1.0.2 geeft geen details over wat er veranderd is, behalve dan dat het foutencorrecties betreft, en net als alle andere updates van iPhone is hij alleen via iTunes beschikbaar. iMovie 7.0.1, beschikbaar via Software-update en als losstaande download, levert niet alleen onbekende verbeteringen, maar lost ook een probleem op met het publiceren van filmpjes op .Mac-webgalerieën; de update is een download van 9 MB. Over het publiceren van websites gesproken, iWeb 2.0.1, een download van 12 MB, pakt problemen aan bij het bij de tijd brengen en publiceren van sites die gemaakt zijn met iWeb 1.x.

Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb


AT&T vereenvoudigt iPhone-rekeningen

  door Jeff Carlson <[email protected]>
[vertaling: GS]

Bezitters van een iPhone kregen vorige week goed nieuws van hun provider AT&T met de volgende sms: "AT&T gratis sms: We vereenvoudigen onze papieren rekeningen door het weglaten van de specifieke details. Om details te zien, ga naar att.com/mywireless. Wilt u toch een volledige rekening op papier? Bel 611."

Vorige week schreef Jorg Brown over de krankzinnig gedetailleerde lijst van dataverkeer van AT&T, die rekeningen op enorme lappen papier opleverden (zie "Rekeningen en internationale kwesties bij iPhone-gebruik," 20-08-2007). Deze situatie kreeg ruime aandacht in de pers toen een vrouw een video op YouTube had gezet waarin ze haar zojuist ontvangen rekening van 300 bladzijden liet zien. AT&T had er $10 verzendkosten voor betaald.

De oplossing waarmee AT&T vorige week kwam, was erop wijzen dat bezitters van een iPhone ervoor kunnen kiezen om electronische afrekeningen te ontvangen. Het lijkt erop dat ze inmiddels echt wakker zijn geworden, zodat een volledige afrekening op papier nu alleen op aanvraag beschikbaar is.

Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb


Erlang al meerderjarig

  door Adam C. Engst <[email protected]>
[vertaling: GS]

We bedanken onze vriend Ned Holbrook voor de correctie van de week. In "C4-conferentie verbetert MacHack" (20-08-2007) omschreef ik Erlang als een "nieuwe" taal. Nu blijkt echter dat Erlang rond 1987 reeds bij Ericsson werd gebruikt en daardoor al zo'n 20 jaar oud is, ook al werd het pas in 1998 uitgebracht als open-bronsoftware en het sinds kort meer belangstelling geniet. "Bovendien", zei Ned, "als je deze verbetering leuk vond, zul je misschien ook genieten van 'Erlang: The Movie'." Sla de krijgskunstfilm "Erlang Quan: Basic Applications" niet over: YouTube denkt dat hij ermee te maken heeft. Als nu de audio van de eerste kon worden gesynchroniseerd met de video van de tweede...

Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb


Office 2004 11.3.7 blokkeert kwaadaardige geheugens

  door Adam C. Engst <[email protected]>
[vertaling: OF]

Slechts een maand na de veiligheidsupdate van Microsoft Office 2004 (zie "Microsoft Office 2004 11.3.6 lost veiligheidsproblemen op," 16-07-2007) heeft Microsoft het wéér gedaan, met het vrijgeven van Microsoft Office 2004 for Mac 11.3.7 Update. De 8,5 MB grote update, die je ook rechtstreeks kunt installeren vanuit het Microsoft AutoUpdate hulpgereedschap, moet een lek dichten waarmee een aanvaller "het geheugen van je computer kan overschrijven met kwaadaardige code". Deze 11.3.7 update vereist dat je al de update naar 11.3.6 hebt gedaan, die op zijn beurt weer de update 11.3.5 moet hebben. Gebruik daarom het Microsoft AutoUpdate hulpgereedschap, dat al het zware werk voor je doet.

Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb


DealBITS-verloting: win een exemplaar van Nisus Writer Pro

  door Adam C. Engst <[email protected]>
[vertaling: RAW]

Toen Apple de grote sprong van Mac OS 9 naar Mac OS X maakte, bleven veel geliefde programma's achter, voornamelijk omdat het gewoon te veel moeite was om vreselijk oude code te herschrijven. Het laatste programma waarvoor ik nog Classic draaide was Nisus Writer van Nisus Software, waarin ik macro's had geschreven die een belangrijk onderdeel van het TidBITS-productieproces vormden. We hebben nu een compleet ander systeem, maar het is mooi om te zien hoe Nisus heeft doorgezet om het krachtige Nisus Writer Pro terug te brengen, met zoeken op kenmerken, macro's, woordenlijsten, inhoudsopgaves, indexen, bladwijzers, voorkomen van weduwen en wezen, regelnummering, ondersteuning voor tekst in verschillende talen, stijlen voor lettertekens en alinea's, onderbroken selecties, en nog veel meer. We hebben veel kleine tekstverwerkers voor Mac OS X zien passeren, maar geen daarvan bood dezelfde reeks aan professionele mogelijkheden als Word. Het is dus goed om te zien dat de keuze aan serieuze tekstverwerkers in de Mac-wereld zich uitbreidt.

In de DealBITS-verloting van deze week kun je meedingen voor een van drie exemplaren van Nisus Writer Pro 1.0, ter waarde van 79 dollar. Deelnemers die niet tot onze gelukkige winnaars behoren, krijgen korting op Nisus Writer Pro, dus vergeet niet om je in te schrijven op de DealBITS-pagina. Alle verzamelde informatie valt onder ons uitgebreide privacybeleid. Denk om je spamfilters en andere antispam-systemen, je moet namelijk e-mail van mijn adres kunnen ontvangen om te horen of je gewonnen hebt. Denk er ook aan dat als jij iemand tipt die wint, jij dezelfde prijs ontvangt als dank voor de mond-op-mondreclame.

Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb


Ons gereedschap: Teleport

  door Adam C. Engst <[email protected]>
[vertaling: BA]

Het was de laatste tijd nogal hectisch, met veel gasten over de vloer, de C4-conferentie in Chicago, Tonya en Tristan die op vakantie waren en stapels dingen te doen. Ik realiseerde me dat het moeilijk ging worden om tijd te vinden om mijn MacBook reisklaar te maken (voornamelijk een kwestie van mijn Eudora-map overzetten, zodat ik e-mail op mijn laptop kan lezen in plaats van op de desktop Mac), dus deed ik dat een paar dagen voor vertrek. En sinds ik weer terug ben, heb ik het druk genoeg gehad - en ik had de MacBook een paar keer buitenshuis nodig - om mijn e-mail niet terug te kunnen zetten naar mijn G5. (En ja, ik weet dat ik mijn Eudora-map niet hoef rond te slepen als ik IMAP zou gebruiken, maar met de hoeveelheid e-mail die ik heb opgeslagen en het belang dat e-mail in mijn leven speelt, heb ik me nooit prettig gevoeld bij het idee om geen POP meer te gebruiken.)

Normaal gesproken vind ik het nogal onhandig om op twee computers te werken, aangezien e-mail verreweg mijn voornaamste vorm van communicatie met de buitenwereld is, maar ik geeft over het algemeen voor schrijven, het web gebruiken en software testen de voorkeur aan de G5 met z'n twee 17-inchschermen. Het heen en weer verhuizen van bestanden en gegevens op het klembord is niet erg praktisch met bestandsdeling en een programma voor afstandsbediening, en het gebruik van aparte toetsenborden en aanwijzers onderbreekt mijn gedachtengang. Maar gedurende de laatste paar weken heb ik vertrouwd op een enorm slim en handig, gratis programma dat al deze problemen op een eenvoudige en elegante manier oplost.

Teleport, geschreven door Julien Robert van Abyssoft, laat meerdere Macs een enkel toetsenbord en muis delen over een netwerk. Ik heb mijn MacBook op mijn bureau met daarachter het toetsenbord van mijn G5 en de beeldschermen van de G5 erboven op een plank. Als ik de aanwijzer van de G5 naar de MacBook wil brengen, houd ik de Controltoets ingedrukt en beweeg ik de aanwijzer omlaag, naar de onderkant van het hoofdscherm van de G5. Zonder enige vertraging (zelfs niet over Wi-Fi), zet Teleport de controle van mijn MacBook over naar het toetsenbord en aanwijsapparaat (de RollerMouse Pro van Contour Design) van mijn G5, terwijl de aanwijzer verschijnt aan de bovenkant van het scherm van de MacBook. Elke muisbeweging en aanslag van het G5-toetsenbord en de Rollermouse is daarna gericht op de MacBook en niet op de G5. Terwijl de MacBook wordt bediend, verschijnt op het hoofdscherm van de G5 een doorzichtig venster om aan te geven dat de MacBook bestuurd wordt. Om het toetsenbord en de muis terug te brengen naar de G5, houd ik de Controltoets ingedrukt en beweeg ik de aanwijzer omhoog naar de bovenkant van het MacBook-scherm, zodat de aanwijzer uit de onderkant van het hoofdscherm van de G5 tevoorschijn komt.

De interface van Teleport is minimaal, slechts een icoon in de menubar voor snelle bestandsdeling en deactivatie en een paneel in Systeemvoorkeuren waar je de virtuele plaatsing van de beeldschermen van je Macs kunt regelen. In dat paneel kun je ook vertrouwde gebruikers instellen (je wilt nu eenmaal niet dat zomaar iedereen je Macs op afstand kan bedienen) en een variëteit aan opties die verband houden met schakelen tussen Macs, het overzetten van bestanden en gegevens op het klembord, en meer.

[Zie afbeelding]

Inderdaad, Teleport kan ook bestanden overzetten (gewoon het bestand meeslepen als je de aanwijzer naar de andere machine brengt) en je kunt het zo instellen dat de gegevens op het klembord automatisch meegaan met de aanwijzer. Dus als ik een bijlage via e-mail heb gekregen en ik wil die op mijn G5 zetten, sleep ik hem naar de bovenkant van mijn scherm met Control ingedrukt en laat ik hem vallen op het bureaublad van de G5. Zo ook als ik tekst van Eudora op de MacBook naar BBEdit op de G5 moet verhuizen: ik kopieer de tekst, verhuis de aanwijzer en plak het, moeiteloos.

Andere interessante eigenschappen zijn onder meer mogelijkheid om de gegevensstroom te versleutelen, de mogelijkheid om slapende Macs wakker te maken als je ze wil gaan bedienen, gebruik van de speciale toetsen of te controleren wanneer de klemborddata worden overgebracht, en meer.

Tijdens het intensieve gebruik de laatste weken merkte ik een paar probleempjes op met Teleport. Het duurde even voordat ik de optimale virtuele indeling van de beeldschermen had gevonden, en hoewel ik oorspronkelijk het gebruik van een speciale toets bij het wisselen van scherm wilde vermijden, bemoeilijkte dit het gebruik bij iedere kant van het scherm die ik probeerde. Ook nu, als ik op de allerbovenste pixel van de menubalk klik om een menu te bereiken, is er iets waardoor het huidige venster van de voorgrond verdwijnt en het menu niet opent. (Volgens Julien is dit een bekend probleem en komt het doordat het slepen van bestanden aanstaat.) Eén of twee keer bevroor Teleport terwijl ik de MacBook bediende en moest ik deze in de sluimerstand zetten om de bediening van de G5 terug te krijgen. Toen ik de MacBook daarna wakker maakte, kon ik deze weer prima bedienen. Hoewel de inhoud van het klembord van de ene naar de andere Mac overgezet wordt, vermoed ik dat sommige metadata die identificeren wat voor gegevens er op het klembord staan worden genegeerd, aangezien het plakken van geformatteerde tekst van de ene naar de andere machine soms in vreemd gedrag resulteert. Dit kan er mee te maken hebben dat ik gegevens overbreng tussen een PowerPC-Mac en een Intel-Mac; ik zal binnenkort een nieuwe versie testen om dit uit te vinden. Deze problemen zijn eigenlijk niet meer dan kleine irritaties en hebben geen echte problemen opgeleverd.

Hoewel Julien Teleport onder de naam Abyssoft uitbrengt, werkt hij sinds drieëneenhalf jaar voor Apple, en terwijl dat zijn werk aan Teleport misschien vertraagd heeft, heeft het dat geenszins stilgezet: Julien werkt momenteel aan een versie voor Leopard. Kortom, Teleport werkt vandaag de dag met Panther en Tiger, het is gratis en vreselijk handig voor iedereen die snel met meerdere Macs wil werken. De download weegt 523 KB.

Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb


UPS, ik heb het weer voor elkaar: bits en atomen

  door Glenn Fleishman <[email protected]>
[vertaling: OF]

In het geval je denkt dat het internet alleen een medium van lichtstralen en electriciteit is, zal dit geïllustreerde verhaal je eraan herinneren dat het internet ook vol zit met zware machines (en electriciteit).

Onze aloude co-locatiefaciliteit digital.forest, de lui die onze servers herbergen en van energie, koeling en een connectie voorzien, moest extra maatregelen treffen om hun stroomvoorziening te garanderen. De doorsnee UPS [Uninterruptible Power Supply, een ononderbreekbare stroomvoorziening - nvdv] is zo groot als een schoenendoos of een beetje groter. Ze bevatten accu's en soms een vliegwiel om stroom te kunnen leveren wanneer dat nodig is.

UPS'en zijn onderdeel van een heel systeem dat de stroomvoorziening reguleert en waarbij ook de pieken en dalen in de electriciteit worden afgeschaafd. De grootste UPS die ik ooit bezat was 1400 watt en was in staat om tientallen minuten stoom te leveren aan de servers in het geval van een stroomstoring; hij woog rond de 20 kilo. (De UPS-eenheden bij digital.forest worden weer ondersteund door een dieselgenerator ter grootte van meerdere tanks, die de stroomvoorziening overneemt nog voordat de accu's leeg raken.)

digital.forests nieuwe meervoudige UPS-system weegt in totaal bijna zes ton en kan 180.000 watt leveren. Die grootte en gewicht vereisten dat het personeel eerst een houten maquette maakte om er zeker van te zijn dat ze voldoende ruimte hadden om het apparaat hun datacenter in te krijgen. Vervolgens vroegen de technici zich af, na overleg met de eigenaren van het gebouw, een van de grootste bouwbedrijven voor datacenters ter wereld, of, zelfs als er voldoende ruimte was om de installatie door het gebouw te schuiven, de vloer op bepaalde punten onderweg het gewicht wel zou kunnen dragen.

Waarom dan niet het dak eraf? (Dat is in ieder geval wat inbrekers in een Apple Store onlangs in een nabijgelegen deel van Seattle ook dachten.) Om They Might Be Giants te citeren: "They'll need a crane, they'll need a crane" [ze hebben een kraan nodig - nvdv]. Een deel van het dak weghalen, een nieuwe kap, een paar heftrucks en een kraan en de UPS'en stonden op hun plek.

Het is eenvoudig te vergeten dat het internet niet alleen vertrouwt op etherische bits met gegevens, maar ook op ladingen atomen.

Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb


TidBITS AutoCorrect-woordenboek verbetert Typinator

  door Adam C. Engst <[email protected]>
[vertaling: MSH]

Toen Ergonis Software Typinator 2.0 uitbracht, dat in staat was om typefouten direct te verbeteren en tekstbestanden met daarin fouten en hun verbeteringen te importeren (zie "Typinator wordt twee," 11-06-2007), dacht ik onmiddellijk aan de TidBITS AutoCorrect Dictionary, een gigantische, openbare lijst van onjuist gespelde woorden en hun verbeterde varianten die wij beschikbaar hadden gesteld aan Eudoragebruikers die hun voordeel wilden doen met Eudora's verborgen auto-correctiefunctie (see "Een Eudora Hack die typefouten opmerkt," 04-09-2000). Dat woordenboek, voornamelijk ontworpen door Micah Alpern, maakt dat ik mijn e-mailboodchappen aanzienlijk sneller en gemakkelijk schrijf, aangezien ik iemand van het soort ben dat fouten in berichten corrigeert. Voor anderen die minder precies zijn, zorgt het er ongetwijfeld voor dat hun berichten correcter zullen worden geschreven.

Ik pakte dadelijk een kopie van de TidBITS AutoCorrect Dictionary, verzekerde me ervan dat het in een formaat was dat Typinator kon importeren, en haalde het binnen. Het leek naar behoren te importeren, en Typinator begon onmiddellijk met het corrigeren van meer typefoutjes in al mijn applicaties, maar het klopte niet helemaal. Het bleek dat Typinator instellingen heeft die per woord bepalen hoe de expansie verloopt. Typinator kan de de vervanging in hoofd- of kleine letters schrijven op basis van het hoofdlettergebruik in de fout, maar de standaardinstelling die voor de meeste van mijn geïmporteerde woorden werd gebruikt was onjuist. Veronderstellende dat Ergonis wel wat tovergereedschap zou hebben voor snelle verbetering, zond ik de woordenlijst naar Christoph Reichenberger met de vraag of hij al die woorden snel zou kunnen resetten en de opmerking dat, aangezien wij en Micah met opzet de TidBITS AutoCorrect Dictionary in het publieke domein hadden geplaatst, Ergonis - en ieder ander - de verbeterde lijst mocht publiceren.

Vanzelfsprekend sprong Christoph een gat in de lucht voor de kans om meer dan 2.300 typefouten en hun verbeteringen toe te voegen aan Typinator, en enkele dagen later had ik mijn Typinator-geformatteerde woordenlijst terug. Sindsdien gebruik ik hem altijd, en met enige stelligheid kan ik zeggen dat ik Typinators hulp ernstig zou missen nu ik de mogelijkheid voor auto-correctie heb in elke applicatie die ik gebruik. Typinator produceert een flits en een geluid zodra het een foute spelling herstelt, en dat toont bijzonder duidelijk aan hoe vaak mijn vingers op het toetsenbord slippen.

Als je Typinator 2.0, gebruikt, raad ik je sterk aan om de gratis TidBITS AutoCorrect Dictionary voor Typinator te downloaden. En als je Typinator nog niet gebruikt: Christoph heeft een speciale prijsreductie voor TidBITS-lezers ingesteld als dank voor onze toestemming aan Ergonis om het woordenboek met hun programma mee te leveren. Tot 31 augustus 2007 kun je 25 procent besparen op de normale prijs vanf Typinator van € 19,99 via deze speciale koppeling.

Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb


Sidejacking doorbreekt beveiling van Gmail en andere diensten

  door Glenn Fleishman <[email protected]>
[vertaling: DPF, HV, PAB, JG, TK, PAB]

"Sidejacking" is een nieuw lemma in het woordenboek van netwerkaanvallen. Het gaat hierbij om een methode om een lopende websessie met een dienst op afstand, zoals Gmail, te kapen door het onderscheppen en hergebruiken van de informatie waarmee je je bij die server identificeerde. Een sidejacker kan bijvoorbeeld Gmail-post lezen en versturen, pagina's op MySpace aanpassen en mogelijk je identiteit misbruiken, zodat je collega's en vrienden denken dat je gemeen, gek of crimineel bent. En dat is nog maar het begin.

Deze gegevens kunnen verkregen worden zonder dat daar software voor het kraken van versleutelingscodes voor nodig is, en ze kunnen zelfs onderschept worden wanneer je op een veilige manier op een site ingelogd bent. Er is ook geen toegang tot je computer voor nodig, en het betekent ook niet dat je computer er kwetsbaarder door wordt. Beveiliging tegen sidejacking zou nog wel eens een omslag in het denken kunnen betekenen voor websitebeheerders, gebruikers en fabrikanten van browsers.

Robert Graham, één van de sleutelpersonen bij Errata Security, presenteerde zijn onderzoek op dit gebied op de Black Hat-veiligheidsconferentie die eerder deze maand plaatvond. Kort daarna bracht hij ook een programmaatje uit dat bewijst dat het werkt, met de naam Hamster. Hij kreeg waardering voor het tonen van sidejacking tijdens echte sessies op de conferentie in plaats van een vooraf ingeblikte demo. Hij liet zien hoe hij de controle kon krijgen over een Gmail-sessie en e-mail kon sturen vanaf dat gebruikersaccount met als tekst: "Ik houd van schapen". (Tussen twee haakjes: de andere belangrijke persoon bij Errata is David Maynor.)

Sidejacking schuift als een koevoet tussen de browser en een server, en stelt de inbreker in staat om het slot te laten springen. Hij is dan nog niet meteen in staat om met je internetauto weg te rijden, maar hij kan wel de papieren meenemen zonder een spoor achter te laten.

De presentatie van Graham liet geen details zien over deze onderscheppingsaanval die niet al eerder bekend waren, maar liet wel de gevolgen zien en gaf gereedschap dat het proces kon automatiseren. Hij veranderde het daarmee van een bekende zwakke plek waarvan de ernst onderschat werd, tot een serieus probleem waar zo snel mogelijk een oplossing voor gevonden moet worden.

Naam en wachtwoord alstublieft -- Sidejacking werkt vooral omdat er bij de meeste webgebaseerde diensten een verschil in beveiligingsniveau bestaat tussen de stap waarin je identificatie-informatie geeft (meestal een login of gebruikersnaam gekoppeld aan een wachtwoord) en de sessie die daarop volgt, wanneer je daadwerkelijk verbonden bent. Alleen bij banken en andere sites met verhoogde beveiliging is dat niet het geval.

Normaal gesproken is dit geen probleem op een thuisnetwerk, waar het risico op onderschepping laag tot onbestaand is en de kans dat er gegevens tussen jouw computer en servers op afstand onderschept worden door derden anders dan de overheid vrijwel nul is. Maar het gebruik van publieke Wi-Fi-netwerken, in het bijzonder met handheld-apparaten als de iPhone, doet de kans dat iemand jouw dataverkeer over open Wi-Fi-netwerken volgt flink toenemen.

Veel diensten als webmail vereisen dat je inlogt met een SSL/TLS (Secure Sockets Layer/Transport Layer Security)-sessie. SSL/TLS is in feite een soort rituele dans tussen je browser en server die ervoor zorgt dat die twee een versleutelde verbinding tot stand brengen. (Als je meer wilt weten over hoe SSL/TLS werkt, lees dan het uitgebreide artikel van Chris Pepper, "Communicatie beveiligen met SSL/TLS: een overzicht op hoog niveau," 25-06-2007.)

Niet alle diensten vereisen een versleutelde login, maar ik beveel van harte aan dat je alleen nog maar dat soort verbindingen gebruikt. Je kunt aan twee dingen zien of een site SSL/TLS gebruikt: de URL begint dan met https in plaats van http en je ziet een hangslotpictogram. Sommige sites gebruiken hangsloten in het ontwerp van hun site, vaak naast loginschermen en in navigatiemenu's. Dat betekent natuurlijk niets. Een goede SSL/TLS-verbinding heeft een hangslotpictogram buiten de pagina. In Safari vind je het slotje in de rechterbovenhoek van het venster (let op, het is subtiel), en in Firefox zie je het in zowel het Locatieveld (aan de rechterkant in dat veld) als de rechteronderhoek van het venster.

(Sommige sites die beveiligde logins aanbieden, geven stom genoeg vaak een standaard webpagina voor het invoeren van je gegevens; wanneer je op de login-knop klikt, worden die gegevens naar een beveiligde pagina gestuurd. Dit heeft echter als effect dat je login ook onderschept kan worden op Wi-Fi-hotspots, omdat inbrekers de kans krijgen om je een nep-inlogpagina te presenteren. Verschillende technieken stellen booswichten in staat om een nep hotspot op te zetten of door informatie op een bestaande hotspot te vergiftigen, zodat die eruit ziet als een doorsnee bank- of webwinkelsite. Je kunt echter een beveiligde pagina niet zomaar namaken zonder dat je browser met een waarschuwing komt over een probleem met een certificaat, maar als je een onbeveiligde pagina nabootst, kun je de gebruiker doorverwijzen naar de echte login aan de beveiligde kant, terwijl je hun gegevens ondertussen in handen krijgt.)

Nu komt het lastigste stuk, en waarom sidejacking werkt. Zodra je jezelf hebt geïdentificeerd bij de dienst en die de gegevens over je account heeft opgehaald, wat gebeurt er dan? Wanneer je geen banksite gebruikt, of een andere site die de gehele sessie beveiligt met SSL/TLS, wordt je misschien teruggezet in een onbeveiligde websessie. Het komt allemaal neer op tokens.

Bewijs jezelf met tokens -- Het web heeft van zichzelf geen status. Hiermee bedoel ik dat er geen samenhang is tussen opeenvolgende acties wanneer je van de ene naar de andere pagina klikt op een bepaalde website. Samenhang kan gesimuleerd worden met cookies, een mechanisme waarmee de website je browser vraagt om bepaalde informatie op te slaan zodat bij elk volgend paginabezoek bekend is wie je bent en wat je gedaan hebt, hetzij tijdens een enkele sessie, hetzij weken later. Site-ontwikkelaars kunnen websites ook een speciaal soort webwachtwoord laten vragen dat samenhang tijdens een sessie kan waarborgen, maar daar wordt maar zeer beperkt gebruik van gemaakt, en ik zal duidelijk maken waarom.

Normaal gebeurt er het volgende wanneer je op een website inlogt:

  1. Je bezoekt een beveiligde site, of wordt doorgestuurd naar een beveiligde inlogpagina. (Dit kun je zien omdat er een hangslotpictogram verschijnt in het venster van je browser.)
  2. Vervolgens vul je je gebruikersnaam en wachtwoord in. Sommige websites kunnen daarnaast ook aanvullende informatie vragen om je identiteit te verifiëren.
  3. De programmatuur waar de website op draait bevestigt je identiteit (op voorwaarde dat je de juiste informatie hebt verstrekt), en genereert een 'token', vaak een willekeurige reeks lettertekens, die in een database van de website wordt opgeslagen voor de duur van de sessie.
  4. De webserver stuurt je dit token in een cookie, dat door je browser wordt opgeslagen. (Als je browser deze tokens niet accepteert kun je vrijwel geen enkele website die sessie-samenhang vereist gebruiken. Eén of twee sites - zoals bijvoorbeeld Amazon.com in zijn eerste jaren - herschrijven dynamisch elke link op hun pagina zodat het token hierin opgenomen wordt, zodat browsers die cookies weigeren toch van de site gebruik kunnen maken.)
  5. Bij elk volgend verzoek om een pagina te tonen stuurt je browser het cookie met het token mee, zodat de webserver van de site die je bezoekt weet wat de status van je verbinding is en de juiste informatie kan tonen op de pagina's die je bekijkt.

Na een bepaalde tijd, vaak na slechts 30 minuten zonder activiteiten als het bekijken van nieuwe pagina's, verloopt het token. De webserver kan het cookie voorzien hebben van een levensduur, zodat je browser het cookie verwijdert bij je volgende bezoek aan de website in plaats van het opnieuw te sturen. De server kan het token ook uit zijn eigen database verwijderen, zodat het cookie van je browser geweigerd wordt. Deze twee opties kunnen ook gecombineerd worden.

Tokens kunnen gekoppeld worden aan een IP-adres, om te voorkomen dat tokens geraden worden door ze willekeurig aan te maken. Over het algemeen zijn tokens echter zo lang dat er triljoenen of triljarden mogelijkheden zijn en de kans dat raden werkt verwaarloosbaar is.

Tokens worden onversleuteld verstuurd en gedurende een sessie voor een bepaalde tijd steeds gebruikt, en dat leidt tot de werkwijze bij sidejacking: het onderscheppen en herhalen (hergebruiken) van dezelfde identificatie-informatie als een geïdentificeerde gebruiker.

Tokens creëren mazen in het proces -- Wat Graham liet zien is dat deze tokens niet gekoppeld zijn aan browser-specifieke informatie, en dat dat ook niet kan. Als je tokens onderschept die over een open WiFi-verbinding verstuurd worden, zelfs een abonnee-WiFi-netwerk of een beveiligd netwerk met onbekende gebruikers, dan kun je die tokens hergebruiken in verzoeken aan een webserver die het patroon volgen dat die server verwacht, en zo een volledig geldige sessie met een website opzetten.

De reden dat tokens niet verbonden kunnen worden met een individuele browser of gebruiker is dat er geen werkelijke samenhang is tussen cookies, de informatie in die cookies, een browser en zijn omgeving. Het checken van het IP-adres waar een cookie vandaan komt werkt niet omdat veel internet-aanbieders alle uitgaande verkeer omleiden vanaf een enkel IP-adres, of via één of meer proxy-servers. Browserkenmerken, de zogenoemde 'user-agent'-tekst, kunnen eenvoudig nagemaakt worden. Het is mogelijk dat in de toekomst browsers en servers de mogelijkheid bieden om versleutelde cookies te gebruiken in onbeveiligde sessies. Dit zou dan ook gebaseerd kunnen worden op SSL/TLS, maar in plaats van de hele sessie te beveiligen zou dan alleen het cookie versleuteld worden. Dit zou de beveiliging verbeteren zonder veel aanslag te doen op de rekencapaciteit van de server. Zowel servers als browsers zouden hiervoor aangepast moeten worden; voor zover mij bekend wordt hier echter niet aan gewerkt.

Om zelf te ervaren hoe eenvoudig het is om een bestaande sessie te kapen heb ik wat zitten spelen met Ferret en Hamster, de twee programma's die Graham gebruikte; Ferret is al een tijdje verkrijgbaar. Op een virtuele Windows XP machine in Parallels Desktop begon ik met Ferret informatie te verzamelen. Ik bezocht Gmail en nog wat andere sites. Vervolgens opende ik Hamster, dat als een web-proxy werkt en je de verzamelde informatie laat zien. Je kunt ook gewoon het webadres van de site waar je tokens van gekaapt hebt invoeren, waarop Hamster de tokens als cookies naar deze website stuurt. Op die manier kon ik eenvoudig op mijn eigen Gmail-account inloggen.

Om Ferret en Hamster te kunnen bedienen moet je wat van de Windows-commandoregel afweten. Ook moet je enigzins bekend zijn met cookies en proxies. Het ging Graham er niet om om met Hamster en Ferret kant en klare applicaties met een gelikte gebruikers-interface te maken, maar alleen bruikbare voorbeelden om aan te kunnen tonen hoe eenvoudig het is om dit proces te automatiseren.

De fundamentele zwakheid is dat het token/cookie onversleuteld wordt verstuurd, tenzij de hele sessie is beveiligd via SSL/TLS. Waarom gebruiken websites dan niet gewoon SSL/TLS of een andere technologie om je sessie te beveiligen? Dat zit zo:

Serverbelasting en gebruikerservaring leiden tot minder veiligheid -- In een eerste versie van dit artikel stelde ik de vraag: waarom gebruiken websites die vertrouwen op tokens niet gewoon SSL/TLS voor alle pagina's om ze te beschermen? Google's Gmail bijvoorbeeld biedt dit als een optie. In plaats van gmail.com in te typen en doorverwezen te worden naar http://mail.google.com/mail/, kun je ook https://mail.google.com/mail/ intypen en alles wat volgt beveiligd uitvoeren. Gmail is hier wel de uitzondering en zelfs zij bieden deze optie niet standaard aan.

Zoals we hier bij TidBITS vaak doen, liet ik die eerste versie circuleren onder een groep ervaren Macintosh-schrijvers, professionals en informatietechnologie-experts, met de specifieke vraag: waarom is er niet meer SSL/TLS? Het antwoord luidde eenvoudigweg: kosten.

Omdat ik zelf beveiligde servers gedraaid heb, wist ik dat er een extra belasting was in bandbreedte (versleuteling voegt bits toe voor "handshaking" en andere details), vertraging ("latentie", versleuteling en ontsleuteling kost tijd aan beide kanten van de verbinding) en computerbelasting (versleuteling verbruikt processor-cycli).

Wat ik niet wist was dat dat niet zo'n 20 of 50 procent hoger is, maar wel tot 1000 procent of meer kan oplopen als je een website hebt van enige omvang. Bij een kleinere faciliteit, zoals TidBITS, zien we een klein beetje extra kosten, en onze beveiligde pagina's laden voor de gemiddelde gebruiker misschien een klein beetje langzamer dan de onbeveiligde.

Maar als je eenmaal echter een niveau bereikt hebt waar je tienduizenden of zelfs miljoenen bezoekers per uur hebt, nemen de kosten onevenredig toe, zo zeiden mijn collega's. Omdat het aantal SSL/TLS-transacties per seconde dat een bepaalde server kan bedienen veel lager ligt dan het aantal onbeveiligde transacties (misschien tot wel vijf keer minder!), moet een gemiddeld druk bedrijf het aantal servers voor de klanten drastisch uitbreiden om dezelfde responstijd te garanderen en hetzelfde aantal gebruikers te kunnen bedienen.

In het algemeen zijn de SSL/TLS-servers gericht op de klant en geven ze informatieverzoeken via gewone webverbindingen door binnen het lokale netwerk. Dat leidt natuurlijk tot een grotere complexiteit, met veel verschillende beveiligde servers die interne servers om informatie vragen.

Een bedrijf kan als alternatief gespecialiseerde versleutel-hardware toevoegen aan hun servers, daarmee de SSL/TLS-verwerking versnellen en de behoefte aan extra servers verminderen. Dit leidt echter wel tot meer kosten en complexiteit per doos en meer mogelijkheden tot storingen. Het kan ook leiden tot duurdere servers als de huidige dozen niet voldoende kaartsleuven beschikbaar hebben voor de versleutelkaarten.

Elke methode zorgt voor meer stroomverbruik en dus voor meer verbruikskosten. En toegenomen complexiteit betekent dat dingen eerder stuk kunnen gaan en om redenen die niet herleid kunnen worden tot de onderdelen die de storing veroorzaken.

SSL/TLS is ook een nogal grof instrument. Als je je gedrag en gegevens al niet reeds beschermt op open netwerken, geef je er waarschijnlijk niet veel om dat iemand kan zien wat je aan het lezen of bladeren bent. Maar je wil toch niet dat je identiteit gestolen wordt of je accounts misbruikt. Is er niet een manier die niet de SSL/TLS-complexiteit en -kosten met zich meebrengt maar toch tokens beschermt? Jawel, en je zult lachen als je erachter komt waarom deze niet toegepast wordt.

De methode die het beste werkt, wordt vermeden -- Zoals ik al eerder vermeldde bestaat er een speciaal soort webwachtwoord dat op een veilige manier verstuurd kan worden en dat de samenhang kan behouden zoals een token doorgegeven via een cookie. HTTP (Hypertext Transfer Protocol) is de standaard die bepaalt hoe webbrowsers en servers data opvragen en uitwisselen. HTTP-identificatie laat een server een gebruikersnaam en wachtwoord vragen voor toegang. Er zijn zowel basis- (onbeveiligde) als "digest"- (beveiligde) methoden van HTTP-identificatie. (Digest verwijst naar een manier van versleuteling die de verzender laat bevestigen bij de ontvanger dat zij beiden hetzelfde wachtwoord delen zonder dat wachtwoord te onthullen.)

Met digest-identificatie kunnen zowel de webserver als de browser de identiteit van de gebruiker doorgeven zonder dat de versleutelde boodschappen die gebruikt worden om de identiteit te bepalen iets opleveren als ze besnuffeld worden. In een goed ontworpen implementatie (en dat zijn ze niet allemaal) hogen de browser en de server een identieke teller op bij ieder doorgegeven verzoek, zodat vorige digests niet opnieuw afgespeeld kunnen worden door een snuffelaar die het digest-equivalent van een token opslaat en later gebruikt.

Dit combineert wel het beste van twee werelden, nietwaar? Waarom wordt het dan niet wijd en zijd gebruikt? Omdat het dialoogvenster voor het inloggen zo afschuwelijk is. Je bent waarschijnlijk wel eens een HTTP-identificatie-dialoog tegengekomen toen je per ongeluk een site bezocht waar je geen toegang toe had, of waarvan je niet wist dat je een wachtwoord nodig had om die site te gebruiken. Het dialoogvenster verschijnt met alleen wat beperkte informatie, zoals een beetje tekst die de site beschrijft die je aan het bezoeken bent. Het vraagt om een gebruikersnaam en wachtwoord, en sommige browsers bieden aan om die geloofsbrieven op te slaan voor een volgend bezoek.

Er is geen enkele manier om het uiterlijk van dat dialoogvenster te veranderen. En telkens als je niet de juiste informatie invult en op OK klikt, verschijnt het venster opnieuw. Als je op Annuleer klikt, verschijnt er een foutmeldingspagina die aangepast kan worden.

Vanaf het allereerste begin besloten webbedrijven dat HTTP-idenficatie gewoon te moeilijk was voor de gemiddelde gebruiker om door te komen. In plaats daarvan gebruikten ze web-gebaseerd inloggen met cookies. Dus oefende niemand druk uit op Apple, Microsoft, Opera, Mozilla en andere browserontwikkelaars en -projecten om de presentatie van het inloggen via HTTP te verbeteren, zoals bijvoorbeeld door JavaScript-haken te gebruiken om controle via een eigen webpagina mogelijk te maken.

Nu is het eigenlijk te laat. Tenzij alle browsers ineens webpagina-gebaseerde HTTP-digest-identificatie zouden ondersteunen, zal geen site er op kunnen bouwen als methode voor inloggen. Dus zitten we vast aan het huidige systeem. Laten we eens kijken naar het risico en daarna naar sommige alternatieve oplossingen.

Risico op sidejacking -- De kans dat een sessie wordt gesidejackt is vrij reëel. Wanneer een sidejacker toegang tot je primaire e-mail via een webmail-account heeft, zou hij naar verschillende sites die jij gebruikt kunnen gaan en aanmelden dat hij zijn "wachtwoord vergeten" is. Domme sites sturen je wachtwoord dan in een e-mail, zodat het in de handen komt van de boef. Slimme sites daarentegen sturen een e-mailbericht met een weblink waarop je moet klikken om daar bijkomende bevestigingsdetails in te voeren die controleren of jij het wachtwoord wel mag opvragen of een nieuw wachtwoord in mag stellen. (Het is je misschien opgevallen dat de meeste banksites en veel webwinkelsites je in het afgelopen jaar gevraagd hebben om hiervoor bijkomende informatie in te voeren. Dat was geen toeval.)

Slimme webwinkelsites staan niet toe dat je je leveringsadres verandert of een opgeslagen kredietkaartnummer opvraagt zonder een nieuwe identificatie, zodat je daar veilig zit. Bij Amazon.com, bijvoorbeeld, krijg je een nieuwe, beveiligde inlogsessie telkens wanneer je voorbij de kassa gaat, en zodra de identificatie opnieuw is uitgevoerd, is de sessie volledig beveiligd door SSL/TLS zodat lokale snuffelaars niet achter de details kunnen komen.

Sidejackers kunnen geen Amazon.com-paswoord achterhalen, zodat een boosdoener ook geen artikelen op jouw kosten naar zijn adres kan laten verzenden. Hij zou echter wel spullen naar jou kunnen laten sturen via het 1-Click bestelsysteem. Eens je in een bepaalde browser bent ingelogd in 1-Click, blijf je ingelogd en hoef je je niet opnieuw te identificeren. In een verweggestopte hulppagina waarschuwt Amazon dat je 1-Click best niet geactiveerd laat na gebruik van een "publieke terminal" (wat een oubollige terminologie) om iets te bestellen. Maar sidejacking zou Amazon er wel eens kunnen toe aanzetten om de implementatie van 1-Click te herzien.

Ook goed om te weten is dat Amazon je in een beveiligde of onbeveiligde sessie nooit je kredietkaartnummer terugstuurt. De beveiligingen van andere sites lopen sterk uiteen, maar sites die kredietkaarten aanvaarden zouden het nummer nooit mogen terugsturen. Ik herinner me nog een incident in de korte periode dat ik bij Amazon.com werkte eind 1996, toen een bekende technologiebons en vaste klant van Amazon er zich over beklaagde dat wanneer hij een fout in zijn kredietkaartnummer maakte, hij op de volgende pagina opnieuw het volledige nummer moest invoeren. Jeff Bezos benadrukte met klem dat dit geen fout was maar een met opzet aangebrachte eigenschap. Hij en de rest van het management stonden veel verder dan andere sites op het vlak van beveiliging tegen in-transitdiefstal van kaartnummers.

Sites met minder intelligente ontwikkelaars en beheerders zullen gemakkelijker kunnen worden gekraakt door middel van sidejacking. Graham en anderen hebben geopperd dat met het wijdverspreid gebruik van sociale networking-sites zoals MySpace een sidejacker een virus zou kunnen verspreiden naar een groot aantal mensen met een tool dat het opnemen van MySpace-tokens automatiseert, bestaande pagina's opvraagt, en deze pagina's weer online zet met de aanvallen ingebouwd.

Contactinformatie op een site die e-mailaddressen bevat staat ook bloot aan sidejacking. Toen ik met Ferret en Hamster mijn Gmail-sessie kaapte, merkte ik in de nuttige informatie die Hamster had onderschept dat mijn volledige lijst met e-mailadressen voor mijn Gmail-contacten ertussen stond - dat is informatie die Google doorgeeft zodat een e-mailadres of naam onmiddellijk kan worden aangevuld via JavaScript zodra je begint te typen.

De kans dat je wordt gesidejackt hangt volledig af van de locatie. Als niemand ooit sidejacking-software draait wanneer je Wi-Fi gebruikt op een openbare plaats, of als je zelden publieke Wi-Fi-hotspots gebruikt, lopen je data (en je identiteit) weinig gevaar. Maar met geautomatiseerde programmaatjes en de wind mee - identiteitsdiefstal of virusverspreiding via e-mail - wordt die kans veel groter. Om het even welke populaire hotspot kan het slachtoffer worden van sidejacking. De visie van Adam Engst hierover van enkele jaren geleden in "De noodzaak van draadloze veiligheid: drie maal L" (05-04-2004), blijft een goede studie.

Jezelf beschermen tegen de sidejacker -- Sidejacking kun je op drie manieren voorkomen:

Bescherm websites tegen de sidejacker -- Hoe kan een website zijn gedrag veranderen om zijn gebruikers te helpen in de beveiliging tegen sidejacking? De website kan SSL/TLS vereisen voor alle verbindingen. Zoals hierboven al gesteld is, kan dat kostbaar worden, maar het is wel uiterst veilig. Veel systemen die te maken hebben met betalingen en beheer van rekeningen (zoals onze partner eSellerate, die de bestellingen en betalingen van onze Take Control-boeken afhandelt) kiezen ervoor alles te versleutelen.

Iets realistischer zou een site tokens aan elkaar kunnen knopen en in de gaten houden of er pogingen zijn om tokens te onderscheppen en hergebruiken. Hier zijn mijn ideeën hierover, die ik zal implementeren in alle toekomstige ontwerpen die samenhang behouden middels tokens.

Ten eerste kan een server tokens aan elkaar koppelen door een nieuwe token te leveren en bij te werken elke keer als een gebruiker een pagina opvraagt. Tokens kunnen een levensduur hebben die maar zo lang is als de tijd die de nieuwe token nodig heeft om gebruikt te worden. Een in tijd beperkte token kan een paar pagina's meegaan, maar zodra een nieuwe token gegenereerd is, verloopt de oude. Dit vermindert de kans aanzienlijk dat je sessie wordt gesidejackt. Uitloggen aanmoedigen om een token te verwijderen aan het einde van een sessie is ook een goed idee. Als de sidejacker je sessie niet volgt en niet constant zijn token aanpast, wordt hij dan buitengesloten. Dit zorgt voor wat extra processorbelasting op de databaseservers, maar niets uitzonderlijks. Het is in wezen een armeluisversie van de HTTP-digest-identificatie, maar het zou kunnen werken.

Ten tweede, wanneer een token gebruikt wordt door wat overkomt als een andere browser of als verlopen tokens constant gebruikt worden, kan een gebruiker in een actieve sessie gewaarschuwd worden. "Hé", zeg je ze de volgende keer dat ze een pagina laden, "het ziet er vanuit onze kant uit alsof iemand probeert uw sessie te kapen. Zit u op een openbaar netwerk? U kunt misschien beter nu uitloggen en uw sessie later vervolgen. Ondertussen kunt u hier wat lezen over beveiliging." Dit kan resulteren in valse meldingen, maar het is een mogelijke strategie.

Uiteindelijk is het web nog steeds een open middel om gegevens uit te wisselen. Als je geen versleuteling gebruikt om je identiteit te versterken, dan kan een identiteit iets worden dat gemakkelijk gestolen wordt.

Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb


Recente onderwerpen in TidBITS Talk, 20 augustus 2007

  van de TidBITS-redactie <[email protected]>
[vertaling: RH]

[De discussies waarnaar verwezen wordt zijn in het Engels, daarom hebben we de titels niet vertaald - Tb-NL.]

iMovie '08 impressions, library size problems -- iMovie '08 laat nu je hele videobibliotheek zien, net zoals iPhoto je bibliotheek van digitale afbeeldingen opslaat. Maar dat leidt tot een enorme videoverzameling. Kan het bronmateriaal worden gecomprimeerd of is het beter om de bibliotheek op uitwendige harde schijven op te slaan? (9 berichten)

Any Good Books on AirPort Express -- Een lezer zoekt een publicatie die dieper graaft in Apples AirPort Express dan bijvoorbeeld Glenn Fleishmans "Take Control of Your AirPort Network". (6 berichten)

TidBITS AutoCorrect Dictionary Enhances Typinator -- Adams artikel over het TidBITS AutoCorrect-woordenboek leidt tot discussie over soortgelijke, automatisch corrigerende programma's zoals TypeIt4Me, TextExpander en SpellCatcher X. (9 berichten)

Tools We Use: Teleport -- Lezers wijzen op een meer recente ontwikkeling van dit gereedschap en op een vergelijkbaar programma. (3 berichten)

iPhone issue? Zijn de pennetjes in de stekker van de iPhone anders dan die van iPods, zodat een oplader voor in de auto de telefoon zou kunnen beschadigen? (9 berichten)

Mail not using default browser? Apple Mail lijkt toch de voorkeur aan Safari te geven, hoewel de standaardbrowser van een lezer op Firefox is ingesteld. Andere programma's, zoals iCal, lijken hetzelfde te doen. (6 berichten)

iPhone update oddness? Een lezer constateert dat de laatste update van iPhone niet aardig is voor hacks op de iPhone en dat zijn iPhone daardoor in zijn originele toestand werd teruggebracht. (4 berichten)

Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb


Dit is TidBITS, een gratis wekelijkse technologie-nieuwsbrief met recent nieuws, bekwame analyse, en grondige besprekingen voor de Macintosh- en internet-gemeenschappen. Geef het gerust door aan je vrienden; beter nog, vraag of ze een abonnement willen nemen!
Niet-winstgevende en niet-commerciële publicaties en websites mogen artikelen overnemen of een link maken als de bron duidelijk en volledig vermeld wordt. Anderen gelieve ons te contacteren. We kunnen de precisie van de artikelen niet garanderen. Caveat lector. Publicatie-, product- en firmanamen kunnen gedeponeerde merken zijn van hun ondernemingen.
Copyright 2007 TidBITS; reuse governed by this Creative Commons License.

Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering