Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering

TidBITS#731/24-May-04

De deze week opgedoken kwetsbaarheid van de beveiliging is reëel, en reikt tot de kern van Mac OS X. Lees verder voor Adams kijk op het probleem en over hoe je jezelf kunt beschermen en voor de uitleg van Matt Neuburg over hoe het tot stand kwam. Daarna legt Joe Kissell Apple Mails spamfilter uit met een deel uit zijn nieuwe e-boek "Take Control of Spam with Apple Mail" en introduceert Adam Envision: een programma dat de Mac verandert in een internet-fotolijst. In het nieuws: aandacht voor een kleine Apple reorganisatie en de lancering van Office 2004 en SubEthaEdit 2.0. Tot slot: volgende week is er geen editie!

Onderwerpen:

Copyright 2004 TidBITS: Reuse governed by Creative Commons license
<http://www.tidbits.com/terms/> Contact: <editors@tidbits.com>


-> Denk je dat TidBITS interessant is voor <-
-> je vrienden, kennissen, collega's? Geef <-
-> hen de tip zich ook GRATIS te abonneren <-
-> of stuur deze aflevering naar hen door! <-


Deze editie van TidBITS werd gedeeltelijk gesponsord door:


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 USA.

Dit nummer werd uit het Engels vertaald door:

Verder werkten mee:

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


MailBITS/24-May-04

[vertaling: JG]

Geen TidBITS op 31 mei 2004 -- Na het extra lange TidBITS-nummer van deze week, nemen we een week vakantie vanwege Memorial Day, dat samenvalt met de verjaardag van redacteur Jeff Carlson en de dagen die ik zal doorbrengen op de MacDesign conferentie. TidBITS Talk zal onverminderd doorgaan, en kijk op onze thuispagina voor het laatste nieuws dat niet kan wachten (hoewel we hopen op een paar saaie weken). We zijn weer terug met een editie op 7 juni 2004. [ACE]

<http://www.macdesignconference.com/>
<http://www.tidbits.com/>

Microsoft Office 2004 uitgebracht -- Microsoft heeft Office 2004 voor Mac OS X officieel uitgegeven, een aanzienlijke revisie van de bijna alomtegenwoordige suite van productiegereedschappen. We zijn van plan om de veranderingen in Word, Entourage, Excel, en PowerPoint nader te bekijken zodra we de software hebben ontvangen en gezien hebben of de nieuwe kenmerken en verwijderde bugs in de nieuwste editie van elk programma de moeite waard zijn. Nu volstaat het te zeggen dat je het kunt kopen voor $400 (winkelprijs) of $150 (onderwijs); opwaarderingen kosten $240. Individuele producten zijn ook verkrijgbaar als je niet de volledige suite wilt. Je kunt ook een probeerversie downloaden (186 MB) die 30 dagen werkt, maar bedenk wel dat Office 2004 Mac OS X 10.2.8 of hoger vereist. [TJE]

<http://www.microsoft.com/mac/products/office2004/office2004.aspx>
<http://www.microsoft.com/mac/products/office2004/howtobuy/howtobuy.aspx>
<http://www.microsoft.com/mac/default.aspx?pid=office2004td>

SubEthaEdit 2.0 verfijnt samenwerking -- De Coding Monkeys hebben versie 2.0 van SubEthaEdit uitgegeven, hun unieke real-time samenwerkings-tekstbewerker. Deze uitgave voegt verscheidene bewerkingskenmerken toe zoals zoeken en vervangen met reguliere expressies, automatisch voltooien van tekst, een dubbelvenster-weergave, conversie van regeleindes, en alleen-lezen toegang. Het is ook mogelijk andere mensen op je lokale netwerk uit te nodigen naar jouw gedeelde document door middel van Rendezvous. Ontwikkelaarsvriendelijke kenmerken zijn AppleScript en ActionScript syntax-kleuring, en per-modus voorkeuren. SubEthaEdit 2.0 is niet compatibel met versie 1.0, dus iedere medewerker moet de nieuwste versie draaien om documenten te delen. Het programma is een 1.2 MB download, en is gratis voor niet-commercieel gebruik; een commerciële licentie kost $35. [JLC]

<http://www.codingmonkeys.de/subethaedit/>

Apple creëert een nieuwe iPod-divisie -- Om het financiële belang van hun digitale muziekspeler te benadrukken, heeft het bedrijf een nieuwe aparte iPod-divisie gevormd met aan het hoofd vice-president Jon Rubinstein, die voordien Apple hardware engineering beheerde. Ook is er een aparte Macintosh-divisie gecreëerd, met Tim Cook, hoofd wereldwijde verkoop, aan het roer. Sommige deskundigen hebben geprobeerd veel van deze stap te maken, maar voor ons klinkt het als een standaard bedrijfsreorganisatie om de realiteit van de markt van Apple te weerspiegelen. [JLC]

<http://www.reuters.com/newsArticle.jhtml?type=topNews&storyID=5198496>


Maak kennis met de spamfilter van Apple Mail

door Joe Kissell <jk@alt.cc>
[vertaling: MB, LVC, EB, RAW]

Net als de meeste mensen die Apple Mail gebruiken hoopte ik dat de verbeterde filter tegen ongewenste reclame, een veel geprezen voordeel van de upgrade naar Panther, even goed zou zijn als de hype van Apple deed geloven. Na maanden trouw de filter getraind te hebben was ik nog altijd niet echt tevreden met de resultaten. Afgaande op de honderden berichten die ik gelezen heb op de discussiefora van Apple, is mijn ervaring niet uniek. Ik heb, in plaats van te leren leven met ongewenste reclame (of Mail in te ruilen voor een andere applicatie), besloten om het probleem beter te bestuderen. Gewapend met een steeds groter wordende persoonlijke verzameling van vele duizenden spam-berichten experimenteerde ik met de instellingen van Mail betreffende ongewenste reclame, vergeleek het met andere filters, en probeerde ik uit te vinden hoe hij echt werkt - en waarom hij soms niet werkt. Ik kwam erachter dat tenminste sommige problemen te wijten waren aan een misverstand van mijn kant over het ontwerp van de applicatie, dat niet zo vanzelfsprekend is als dat van andere applicaties van Apple.

Ik heb goed nieuws en slecht nieuws. Het goede nieuws is dat de filter voor ongewenste reclame van Mail een betrouwbaar hulpmiddel kan zijn om ongewenste reclame uit je Inkomende Postbus te houden, mits naar behoren geconfigureerd. Het slechte nieuws is dat je, zelfs als de filter voor ongewenste reclame zo goed mogelijk werkt, nog steeds meer ongewenste reclame zult zien dan je zou willen. Gelukkig kunnen andere applicaties en technieken deze tekortkomingen van de filter voor ongewenste reclame compenseren. Je bent in staat betere beslissingen te nemen hoe de filter voor ongewenste reclame te gebruiken (of uit te breiden) als je weet wat er achter de schermen gebeurt.

Ik heb talloze uren van onderzoek en experiment samengebald in mijn nieuwste Take Control e-boek, "Take Control of Spam with Apple Mail", waarvan dit artikel een uittreksel is.

<http://www.tidbits.com/takecontrol/spam-Apple-Mail.html>

Hoe de ongewenste-reclamefilter van Mail werkt. -- De filter tegen ongewenste reclame van Mail heeft twee instellingen: interactief en automatisch. (Je kunt hem ook compleet uitzetten.) Wat er precies bij deze twee instellingen gebeurt kan leken in verwarring brengen. Veel mensen vragen zich in het bijzonder af of de filter door blijft leren als je overstapt naar de automatische instelling. (Dat doet hij inderdaad, hoewel de documentatie van Apple dit feit verhult.) Hier zijn de details.

Als een bericht aankomt, draait Mail een ingebouwde regel - een regel die niet in de Regels-lijst verschijnt. Deze speciale regel voor ongewenste reclame draait pas na alle andere regels; dit om valse positieven te minimaliseren. Maar hij draait niet als een van je andere regels de actie "beëindig evaluatie regels" bevat, en hij is alleen maar relevant als een bepaald bericht niet al door een eerdere regel is verplaatst of gewist.

Je kunt de speciale ongewenste-reclameregel zien door de Reclame-voorkeuren te openen en op de Geavanceerd knop te drukken aan de onderkant van het venster. Afhankelijk van de opties die je kiest controleert deze regel of de verzender van het bericht in je geadresseerdenoverzicht of in je Adresboek staat, en of het Aan: veld van het bericht je volledige naam bevat - aangezien dat bij spam vaak niet het geval is. (Het geadresseerdenoverzicht is een handige aanvulling op de filter voor ongewenste reclame, hoewel er makkelijk onjuiste gegevens in kunnen kruipen, waardoor het contra-productief wordt.) Als het antwoord op een van deze vragen ja luidt, dan stopt de regel en wordt je bericht met rust gelaten. Als alle drie de voorwaarden echter negatief zijn, dan controleert hij nog een laatste voorwaarde: "Bericht is ongewenste reclame." Als deze laatste voorwaarde waar is, dan voert de filter de actie uit die jij specificeert: in de interactieve instelling verandert hij de kleur van het onderwerp van het bericht naar bruin; in de automatische instelling, verplaatst hij het bericht naar je postbus voor ongewenste reclame. (Deze actie is een van de slechts twee verschillen tussen de interactieve instelling en de automatische instelling. Het andere is dat Mail de postbussen voor ongewenste reclame voor al je accounts consolideert onder een enkel Ongewenste reclame icoon in de Postbussenlijst.)

De voorwaarde "Bericht is ongewenste reclame" klinkt nogal mysterieus, maar hij betekent dat de latente semantische analyse filter van Mail (waarover zo meteen meer), als de voorwaarde waar is, aan het bericht een waarde heeft toegekend die hoger is dan zijn arbitraire drempelwaarde voor ongewenste reclame. Je kunt deze drempelwaarde niet veranderen, maar als je het bericht later aanmerkt als Geen ongewenste reclame, dan verlaag je de waarschijnlijkheid dat Mail een vergelijkbaar bericht in de toekomst als spam zal aanmerken.

De Panther-versie van Mail heeft nog een ander criterium voor het controleren op spam: koptekst die door de filter voor ongewenste reclame van de mail-server van je internetaanbieder worden ingevoegd. Veel internetaanbieders gebruiken filters tegen ongewenste reclame die op hun servers staan zoals SpamAssassin of Brightmail. Als zo'n filter een bericht aanmerkt als mogelijk ongewenste reclame, dan voegt het een speciale koptekst toe aan het bericht, zoals X-Spam-Flag. (Deze speciale kopteksten zijn normaal onzichtbaar, maar je kunt ze zien door Weergave > Bericht > Lange kopteksten [Commando-Shift-H] te kiezen.)

Als een bericht deze koptekst bevat, betekent het dat de spamfilter van jouw internetaanbieder - die geavanceerder kan zijn dan degene die in Mail is ingebouwd - vermoedt dat het bericht spam is. Zolang het hokje Vertrouw kopteksten van internetaanbieder voor ongewenste reclame is aangevinkt in de voorkeuren voor Reclame, dan merkt Mail zulke berichten aan als ongewenste reclame (tenzij ze vrijgesteld zijn om een andere reden, zoals bijvoorbeeld dat ze door iemand in je Adresboek zijn verzonden). Sommige filters tegen ongewenste reclame op de server gebruiken andere kopteksten dan X-Spam-Flag om ongewenste reclame te identificeren. De enige manier om Mail te vertellen dat het moet zoeken naar een andere koptekst is door het voorkeurenbestand handmatig te veranderen; in het e-boek vertel ik precies hoe dat in zijn werk gaat.

Meer over statistisch filteren -- Door de voortdurend evoluerende natuur van spam worden hulpmiddelen voor het filteren van berichten gebaseerd op een vaste lijst van sleutelwoorden, zinsdelen of regels mettertijd steeds minder effectief. Statistische filters verhelpen dit probleem door (in zekere zin) hun eigen regels op te maken als ze je e-mail verwerken. De meest gebruikte statistische spam-filtering methode is Bayesiaanse filtering (te vinden in Eudora, SpamSieve, en SpamAssassin, onder andere).

Apple Mail gebruikt een verwante techniek bekend als Adaptive Latent Semantic Analysis (LSA). Beide methodes berekenen de waarschijnlijkheid dat een bepaal bericht spam is gebaseerd op een analyse van de inhoud van bestaande spam- en niet-spam berichten. En beide methodes worden accurater naarmate ze toegang hebben tot nieuwe voorbeelden van goede en slechte berichten. Hoewel vanuit gebruikersperspectief Bayesiaanse en LSA filters verwant zijn, verschillen ze in enkele belangrijke aspecten.

Bayesiaanse Filters -- Heel eenvoudig gezegd bestaat een Bayesiaanse filter in essentie uit twee lijsten: "goede" woorden en "slechte" woorden. Je bouwt deze lijsten dynamisch op als je de filter gebruikt. Telkens als je zegt dat een bericht spam is, voegt de filter alle woorden in dit bericht toe aan zijn Slechte woordenlijst; telkens als je zegt dat een bericht legitiem is, gaan alle woorden op de Goede woordenlijst. Natuurlijk staan de meeste woorden op beide lijsten, daarom bepaalt de filter de waarschijnlijkheid dat elk woord een spam-indicator is, gebaseerd op de verhouding van het aantal malen dat het voorkomt in de Slechte versus de Goede berichten.

Bij het binnenkomen van een bericht berekent de filter de gemiddelde spam-score van zijn woorden en als deze score een vooraf bepaalde drempelwaarde overschrijdt, wordt het bericht als spam bestempeld. Bayesiaanse filters zijn zeer dynamisch, ze passen zich niet alleen aan, aan het type mail dat elk individu ontvangt (want de een zijn spam is de ander zijn jam) maar evenzeer aan de wijzigende tactieken van de spammers. Hoewel het systeem niet perfect is, betekent het dat als volgende maand een nieuwe oplichterij opduikt voor het verkopen van een bouwproject op Mars, een Bayesiaanse filter zal leren zulke berichten te weren als je handmatig een paar exemplaren als spam aanmerkt. De meeste Bayesiaanse filters houden ook rekening met de kopteksten en andere bericht-attributen om te vermijden dat ze bedrogen worden door lange (maar dikwijls verborgen) passages met gewoon proza.

Latente Semantische Analyse in Mail -- Waar Bayesiaanse filters gebaseerd zijn op relatief directe berekeningen van woordfrequentie, gaan LSA filters verder door het identificeren van spam-achtige woorden, zinnen, en berichten gebaseerd op hun gelijkheid in betekenis met tekst die je al als spam geïdentifceerd hebt. In plaats van eenvoudig een gewicht toe te wijzen aan elk individueel woord, zal een LSA filter de algemene context waarin een woord voorkomt, in aanmerking nemen. Bijvoorbeeld: het woord "vergroting," zal, wanneer het voorkomt in een discussie over fotografie, normaal niet een spam-indicator zijn - terwijl hetzelfde woord in de context van cosmetische chirurgie of goedkoop voorgeschreven geneesmiddelen een zeer goede spam-indicator zal zijn. (Nogmaals, dit is een oversimplificatie. Voor meer details over latente semantische analyse, zie deel 2 van Francois Joseph de Kermadec's driedelige reeks "The Fight Against Spam" bij MacDevCenter.)

<http://www.macdevcenter.com/pub/a/mac/2004/05/18/spam_pt2.html>

Net als een Bayesiaanse filter blijft een LSA filter bijleren tijdens gebruik. Dit veronderstelt natuurlijk dat je altijd nauwgezet zijn vergissingen verbetert. In Mail betekent dit alle spam-berichten die de filter mist als ongewenste reclame aanduiden, en alle onjuist geïdentificeerde legitieme berichten als niet-reclame aanduiden.

Op papier lijkt LSA een meer verfijnde techniek die minder waarschijnlijk door slimme spammers doorgeprikt zal worden. In de praktijk echter, laat Mails implementatie van LSA soms te wensen over. In mijn eigen testen leerde het langzamer dan Bayesiaanse filters. Het heeft ook de neiging te voorzichtig te zijn zonder de mogelijkheid de drempelwaarde bij te stellen voor wat het als spam beschouwt. En daar het zoekt naar woordpatronen en niet naar karakterpatronen, kunnen vele overduidelijke spamberichten ongemerkt binnenkomen.

Mail bewaart zijn statistieken van goede- en slechte-berichten-karakteristieken in een enkel bestand: ~/Library/Mail/LSMMap2. (Tussen haakjes, LSM, staat voor "least square method", een wiskundig algoritme gebruikt in latente semantische analyse. Ik wist dat jullie dit wilden weten.) Als dit bestand beschadigd wordt - wat spijtig genoeg tamelijk gemakkelijk kan gebeuren - dan werkt de spam-filtering niet meer naar behoren.

Je kunt het LSMMap2-bestand niet herstellen, maar je kunt het handmatig verwijderen of het opnieuw instellen door op de knop te klikken in Mail's Reclame-voorkeurenpaneel. Zodoende los je de ernstigste spam-problemen op, maar je verwijdert ook al de training van je reclame-filter, dus zal zijn nauwkeurigheid waarschijnlijk heel pover zijn totdat het genoeg legitieme en spam-berichten verwerkt heeft voor de heropbouw van je gegevensbestand.

Hoe kan Mail's ongewenste reclame-statistiekenbestand eigenlijk beschadigd raken? Behalve door de gewone dingen (zoals vastlopers terwijl het bestand is geopend, beschadigingen aan de map, of de computer op onjuiste wijze uitschakelen) kan LSMMap2 soms schade oplopen bij normale bezigheden zoals het bewaren van een bericht of het markeren ervan als ongewenste reclame, als het bericht zelf op een bepaalde manier beschadigd is. Hoewel je beschadigingen niet kunt voorkomen kun je wel stappen ondernemen om herstel eenvoudiger te maken (zie het e-boek voor meer informatie).

Een bericht aanmerken als reclame/geen reclame -- Omdat statistische filters nauwkeuriger worden naarmate je ze langer gebruikt (en omdat spammers steeds nieuwe foefjes leren om ze voor de gek te houden) komt spam soms toch langs het ongewenste reclame-filter en verschijnt dan tussen je gewone post. (Dit heet in jargon "vals negatief".) Je zou zulke berichten gewoon weg kunnen gooien, maar als je dat doet maak je de kans groter dat vergelijkbare berichten er in de toekomst door glippen. In plaats daarvan moet je elk van deze berichten selecteren en handmatig aanmerken als reclame (met Bericht > Markeer als > reclame [commando-shift-J]).

Merk op dat het niet genoeg is een bericht naar je ongewenste-reclamepostbus te verplaatsen; alleen als de reclame-markering aan staat, te zien aan een icoon in de berichtenlijst, beschouwt Mail het bericht als ongewenste reclame. Als je een bericht als ongewenste reclame aanmerkt werk je de statistieken van het filter bij en verwijder je het adres van de afzender uit de geadresseerdenoverzicht als het daarin voorkwam.

Omgekeerd kan Mail een legitiem bericht foutief aanmerken als ongewenste reclame ("vals positief"). Statistische filters kunnen immers alleen maar kansen schatten. Als iemand jou bijvoorbeeld een artikel heeft gestuurd over het soort woorden dat spammers vaak gebruiken is het mogelijk dat dat een hoge score oplevert. (Dit probleem, dat spam-filters overijverig kunnen zijn, is een onuitputtelijke bron van moeilijkheden voor de verzendlijsten van TidBITS en TidBITS Talk.) Je moet zulke berichten dus altijd aanmerken als geen reclame (met bericht > Markeer als > geen reclame) om Mail te vertellen dat ze legitiem zijn.

Verrassend genoeg zorgt het aanmerken van een bericht als geen reclame er tevens voor dat de afzender wordt toegevoegd aan je geadresseerdenoverzicht! Dit zorgt ervoor dat toekomstige berichten van die afzender niet meer als spam zullen worden aangemerkt (aangenomen dat je de standaardinstellingen gebruikt), zoals je misschien wel maar misschien ook niet wilt. Dit is maar een van de vele verrassingen die ik tegenkwam in het ontwerp van het geadresseerdenoverzicht.

Take Control of Spam with Apple Mail -- Ik heb geprobeerd om hier de elementaire werking van Mails filter voor ongewenste reclame uit te leggen, maar in mijn e-boek, het 59 bladzijden tellende "Take Control of Spam with Apple Mail", ga ik veel verder, met gedetailleerde, praktische stappen waarmee Mail-gebruikers spam kunnen elimineren, valse positieven vermijden en problemen met het filter voor ongewenste reclame oplossen. Het e-boek bevat een hoop extra achtergrondinformatie, plus uitgebreide discussies over toe te voegen filters en andere technieken die verder gaan dan de ingebouwde anti-spammogelijkheden van Mail. Ik ben er zeker van dat mijn adviezen je frustratieniveau zullen verlagen en je zullen helpen om minder tijd te verspillen aan de behandeling van ongewenste reclame. "Take Control of Spam with Apple Mail" kost 5 dollar, en net als met alle andere Take Control e-boeken krijgen kopers het recht op kleine updates er gratis bij.

<http://www.tidbits.com/takecontrol/spam-Apple-Mail.html>

[Joe Kissell woont in San Francisco en is schrijver, consulent en Mac-ontwikkelaar. Hij gaf de aftrap voor de Take Control-serie met de bestseller "Take Control of Upgrading to Panther". Zijn website getiteld "Interesting Thing of the Day" komt vanaf 1 juni a.s. weer terug met dagelijkse artikelen.]

<http://www.tidbits.com/takecontrol/panther/upgrading.html>
<http://itotd.com/>


Visualiseer het internet met Envision

door Adam C. Engst <ace@tidbits.com>
[vertaling: EV, MSH]

Een jaar of wat geleden realiseerde ik me dat LCD monitoren zo veel in prijs werden verlaagd dat ik het me kon veroorloven om er een aan de muur te hangen en deze te gebruiken om foto's en andere digitale kunst mee te vertonen. Het bleek dat ik niet de enige was en Alan Oppenheimer van Open Door Networks had een gelijksoortig idee. Alan was verantwoordelijk voor de creatie van AppleTalk toen hij bij Apple werkzaam was en sinds zijn vertrek bij het bedrijf heeft Open Door een aantal gevarieerde netwerk-gerelateerde programma's uitgebracht waaronder ShareWay IP (hetgeen Persoonlijke Bestandsuitwisseling mogelijk maakte via IP in plaats van alleen via AppleTalk), een persoonlijke firewall getiteld DoorStop die gekocht werd door Symantec en veranderd werd in Norton Personal Firewall, een ander hulpprogramma om beter toegangspogingen die gedetecteerd worden door jouw firewall te kunnen begrijpen en erop te kunnen reageren, en verscheidene serverloganalyse-programma's.

Ik vertel dit allemaal om te laten zien hoe Open Doors nieuwste programma - momenteel verkrijgbaar als een gratis openbare bèta versie - een beetje afstand neemt van de wereld van netwerk- en beveiliging-software voor de echte computergek. Envision is in essentie een op internet gebaseerd diashow-programma dat Alan en zijn team begonnen te schrijven om afbeeldingen van het Astronomy Picture of the Day archief op een oude iBook te vertonen. Je wijst Envision naar een website die openbare toegang verleent tot zijn afbeeldingen en het programma gaat het net op, vind de URL's voor de afbeelding en downloadt de afbeeldingen die aan jouw ingestelde criteria van grootte, naam en zo meer voldoen. (Envision wordt geleverd met een selectie van vooraf ingestelde diashows voor musea, valuta, stripverhalen en nog veel meer.) Zodra het afbeeldingen heeft gedownload die passend zijn, vertoont hij deze in een simpele diashow waarbij van dia naar dia wordt gesprongen middels een door de gebruiker ingestelde tijd.

<http://www.opendoor.com/envision/>
<http://antwrp.gsfc.nasa.gov/apod/astropix.html>

Envision is een intrigerend programma voor web browsing zonder voortdurend klikken en ik vond het de moeite waard om te bespreken, zelfs in zijn openbare bèta-fase, omdat Open Door uiterst geïnteresseerd is in terugkoppeling met gebruikers over in welke richting Envision zou moeten gaan en wat nodig is om het beter te laten werken. Ontegenzeggelijk zijn de mogelijkheden nu wat beperkt, soms zelfs opzettelijk: het zal niet voorbij het topniveau van sites kruipen behalve daar van waaraf het startte en het werkt niet met sites die trucs gebruiken zoals rare herverwijzigingen of JavaScript pop-up vensters ten einde gebruikers te beletten afbeeldingen te snel te zien. Ik geef ook de voorkeur aan Mac OS X's foto screen saver, met zijn panning- en zoom-effecten voor het tonen van foto's; gelukkig kun je foto's uit Envisions miniatuurafbeeldingen slepen om ze op schijf te bewaren indien je ze naar Mac OS X's screen saver wilt brengen. Het is aannemelijk dat een toekomstige versie van Envision een optie zal hebben om afbeeldingen in bepaalde mappen op te slaan voor direct gebruik met Mac OS Xs screen saver.

Ook is Envision ongetwijfeld controversieel. Schuinsmarcheerders zullen het gebruiken om stoute plaatjes te downloaden en te bekijken, maar dat was natuurlijk net zo mogelijk met een normale webbrowser. Sommige webmasters zullen bezorgd zijn dat hun banner-advertenties niet met hun plaatjes zullen worden afgebeeld, maar wederom, er zijn webbrowsers en andere gereedschappen die het laden van banner advertenties kunnen voorkomen. En ontwerpers en auteurs van sites zullen er waarschijnlijk hun ontsteltenis over uiten dat gebruikers hun plaatjes niet in de context en met enige ondersteunende tekst zullen zien. Daar staat tegenover dat het dubbelklikken op een foto je onmiddellijk naar zijn oorspronkelijke webpagina brengt en als optie kan Envision de URL van ieder plaatje tonen, een link naar de originele site en zijn onderschrift in een info-veld. (Het onderschrift - geconstrueerd uit de ALT-tag van de afbeelding - kan als optie in Envision op het plaatje zelf verschijnen.) Wie weet, op een dag zullen webmasters misschien zelfs kleine coderingswijzigingen voor Envision gaan maken, zodanig dat hun sites wat makkelijker getoond kunnen worden op wat in wezen een groot digitaal beeldscherm is.

<http://www.opendoor.com/envision/envisionWebmaster.html>

Ondanks de wat ruwe verschijningsvorm van Envision ben ik begonnen met in dealnews te kijken naar goedkope LCD monitoren en te denken over het hoe en waar een dergelijke monitor te plaatsen voor vertoning van niet alleen de duizend digitale foto's die ik genomen heb, maar ook beelden van Envision. Ik denk te beginnen met enkele van die verbazingwekkende ruimte-afbeeldingen van de NASA.

<http://www.dealnews.com/>


URL-gebaseerde kwetsbaarheid van Mac OS X ontdekt

door Adam C. Engst <ace@tidbits.com>
[vertaling: RAW, DPF]

Het is geen paard van Troje, maar een recent onthulde zwakke plek in de beveiliging lijkt een zeer reëel probleem. Het misbruik steunt op onveilige acties die Apple toestaat voor bepaalde URL-schema's (zoals de http, ftp of mailto-stukjes aan het begin van een URL) en maakt het mogelijk dat een kwaadwillend stukje code afgeleverd en stilletjes uitgevoerd wordt, zonder dat de gebruiker doorheeft dat er iets gebeurd is.

Men dacht eerst dat het probleem veroorzaakt werd door slechts twee van deze URL-schema's: disk en help. Als je de mogelijkheid tot het downloaden en automatisch laden van een schijfkopie (die een kwaadwillend AppleScript-script zou kunnen bevatten) combineert met de mogelijkheid om dat AppleScript te draaien (omdat het op een bekende plaats staat) via Help-viewer, heb je een recept voor problemen. Het uitzetten van Safari's optie 'Open "veilige" bestanden na downloaden' in het voorkeurenpaneel Algemeen biedt onvoldoende bescherming (en de zwakke plek is zelfs aanwezig als je sommige andere webbrowsers gebruikt).

<http://secunia.com/advisories/11622/>

Apple reageerde binnen een paar dagen door Security Update 2004-05-24 uit te brengen. Hoewel Apples beschrijving zoals gewoonlijk zeer beknopt was, lijkt het erop dat deze veiligheidsupdate een nieuwe versie van Help-viewer installeert die vermoedelijk de mogelijkheid uitschakelt om Help-viewer AppleScripts te laten uitvoeren die via help-URL's toegestuurd werden. (De veiligheidsupdate bevatte ook een reparatie voor het verwerken van URL's binnen de Terminal voor gebruikers van Mac OS X 10.2 Jaguar; opnieuw gaf Apple geen details.)

Helaas voor eenieder die er mee te maken heeft, was Apples oplossing slechts een pleister op wat nu lijkt op een veel uitgebreider en diepgaander probleem, dat Matt Neuburg elders in deze aflevering zal uitleggen. Het volstaat te zeggen dat de bezorgdheid over Help-viewer slechts een speciaal geval was van een algehele zwakte, die draait om de mogelijkheid voor een aanvaller om een schijfkopie openbaar te maken met een kwaadwillend programma dat een speciaal URL-schema aanmeldt. Als een gebruiker op de koppeling klikt (die natuurlijk vermomd is als iets anders), wordt de schijfkopie gedownload, geladen en het speciale URL-schema wordt aangemeld bij Mac OS X. De server die de URL leverde, wacht een tijdje (totdat de schijfkopie geladen en het URL-schema aangemeld is) en stuurt de gebruiker dan automatisch door naar een andere URL die het zojuist aangemelde schema gebruikt. Die URL geeft Mac OS X de opdracht om de kwaadaardige applicatie te starten. En dan is het hek van de dam, natuurlijk. Complimenten aan TidBITS Talk-lezer Sander Tekelenburg, die een duidelijke webpagina maakte die deze gang van zaken uitlegt.

<http://secunia.com/advisories/11689/>
<http://www.euronet.nl/~tekelenb/playground/security/URLschemes/>
<http://db.tidbits.com/getbits.acgi?tlkthrd=2233>

Zonder op wat voor manier dan ook de ernst van deze zwakke plek af te zwakken, is het toch belangrijk om een paar dingen duidelijk te maken. Dit is geen Trojaans paard, het is geen virus, en hoewel verscheidene mensen bewijzen dat het werkt openbaar hebben gemaakt, ken ik geen enkel geval van bestaande kwaadaardige software die deze techniek gebruikt.

Ik ben er zeker van dat Apple als een gek bezig is om met een oplossing te komen; tot die tijd lijkt het beste advies voor standaardgebruikers te zijn (behalve goede back-ups maken!) om Paranoid Android te downloaden en te installeren, een gratis hulpprogramma dat ontwikkeld werd door Unsanity. Na installatie houdt Paranoid Android de wacht en bij onbekende URL-schema's laat het een waarschuwingsdialoog zien waarmee je de actie kunt annuleren voordat je Mac aangetast kan worden. Unsanity en John Harris verdienen de hoogste lof voor het ontwikkelen en gratis ter beschikking stellen van Paranoid Android. Als je meer wilt weten over hoe Paranoid Android werkt, kun je Jasons uitleg lezen via de tweede koppeling hieronder.

<http://www.unsanity.com/haxies/pa/>
<http://www.unsanity.com/haxies/pa/whitepaper/>

Sommige mensen ergeren zich aan de techniek die Paranoid Android gebruikt (die dezelfde is als de andere Haxies van Unsanity); ik denk dat je of het advies van John Gruber moet volgen op zijn Daring Fireball site zodat je Paranoid Android niet langer nodig hebt of het moet beschouwen als een tijdelijke oplossing totdat Apple een oplossing uitbrengt. John beveelt het gebruik van RCDefaultApp van Rubicode aan voor het aanpakken van eventueel gevaarlijke URL handlers. Een andere suggestie is Little Snitch van Objective Development; dit gereedschap kan je waarschuwen voor verdacht gedrag.

<http://daringfireball.net/2004/05/help_viewer_security_update/>
<http://www.rubicode.com/Software/RCDefaultApp/>
<http://www.obdev.at/products/littlesnitch/>

Het is de moeite waard om je voortdurend te realiseren dat iedere actie op je computer mogelijk onveilig is; een bug in een verder volledig acceptabel programma zou misbruikt kunnen worden door kwaadwillende software. Hoewel er geen reden is om volledig paranoïde te worden is het wel verstandig om na te gaan waar je bestanden vandaan downloadt of op welke link je klikt. Het belangrijkste is nog wel te onthouden dat het uitvoeren van regelmatige back-ups waarbij je meerdere versies van veranderde documenten bewaart je voor de gevolgen van een aanval beschermt, zonder dat het al te veel moeite kost.

Ten slotte: hoewel Apple zich ongetwijfeld bewust is van de ernst van de zaak, is het wel een soort van praktijktest. Na een wat onstabiel begin lijkt de beveiligingsgroep van Apple goed werk te hebben verricht bij de minder gevaarlijke lekken, die meestal te maken hadden met de Unix gereedschappen die bij Mac OS X geleverd worden. Het gaat hier echter om een totaal nieuw geval, een Mac OS X-specifiek gevaar dat alleen maar kan bestaan door de ontwerpkeuzes die Apple gemaakt heeft. Nog zorgwekkender is het feit dat het probleem niet door Apple zelf is ontdekt, en niet is opgelost voordat iemand anders het kon ontdekken. Dat impliceert dat de beveiligingsgroep van Apple achter de feiten aanloopt; ik zou willen dat op zijn minst een deel van de functie-omschrijving van het team gewijd zou zijn aan het voortdurend testen van Mac OS X en de bijgeleverde programma's om voortdurend de eventuele kwetsbaarheid na te gaan.


URL-gebaseerde kwetsbaarheid van Mac OS X uitgelegd

door Matt Neuburg <matt@tidbits.com>
[vertaling: DPF, GH]

Wat is dan precies de oorzaak van deze kwetsbaarheid van Mac OS X? Het is allemaal een beetje verwarrend, en misschien haal ik wat details door elkaar, maar hieronder volgt mijn beschrijving van de situatie.

Wanneer je een document in de Finder dubbelklikt wordt zoals je weet, het programma gestart dat "eigenaar" is van dat document om dat document te openen. Wanneer je bijvoorbeeld een Word-document dubbelklikt zal Word gestart worden. Dit vereist dat je computer iets weet over "types documenten" en dat de computer een verband kan leggen tussen een bepaald documenttype en een bepaald programma. Voordat Mac OS X verscheen werd deze relatie gelegd door vierletterige creator codes die in de meta-informatie van een bestand verstopt zaten (de "desktop database"). Onder Mac OS X echter, werd hiervoor een volledig nieuwe manier geïntroduceerd door een systeem met de naam Launch Services. Apple documenteert de hele situatie op onderstaande pagina van de ontwikkelaarsdocumentatie van Launch Services.

<http://developer.apple.com/documentation/Carbon/Conceptual/LaunchServicesConcepts/LSCConcepts/chapter_2_section_4.html>

Het volgende is het belangrijkste deel van die documentatie. Naast het oude systeem van vierletterige codes heeft Apple een nieuw systeem geïntroduceerd om de compatibiliteit met andere systemen te verhogen, de bestandsextensie. Dit is een code van meerdere karakters aan het eind van iedere bestandsnaam die een idee moet geven van het soort document waar we mee van doen hebben. Tegelijkertijd werd een derde manier geïntroduceerd, namelijk een URL schema. Een programma kan het systeem hierbij vertellen dat het in staat is om meerdere soorten documenten te openen en zorgt er hiermee voor dat het systeem een bericht kan sturen aan dat programma wanneer het zo'n document tegenkomt.

Ik weet eigenlijk niet waarom Apple dit gedaan heeft. Misschien deels omdat Apple een probleem lijkt te hebben met te beslissen hoe een bestand gespecificeerd moet worden. In Cocoa bijvoorbeeld wordt een bestand gespecificeerd door of een padnaam of als een URL; over het geheel genomen lijkt Mac OS X te proberen om het onderscheid tussen een bestand en een URL te laten verdwijnen. Vanuit een bepaald perspectief heeft dit voordelen, omdat het betekent dat de programmeur hetzelfde commando kan gebruiken voor het openen van een document op een andere machine via http als voor het openen van een lokaal tekstbestand. Belangrijk is in ieder geval om te begrijpen dat onder Mac OS X een URL in feite een manier is om een bestand te specificeren, net zoals een padnaam dat is.

Er zijn meerdere manieren waarop het systeem bewust kan worden van een programma en van het feit dat een programma op een schema kan reageren. Zoals in de eerste paragraaf van de documentatie staat vereist dit niet dat je het programma ook daadwerkelijk start. Alleen al het kopiëren van een bestand naar je harde schijf is genoeg. Dit lijkt een verstandige ontwerpbeslissing, omdat je niet eerst Word wil openen om in staat te zijn Word-documenten te kunnen dubbelklikken. Je wilt dat de gebruiker die bestanden meteen kan dubbelklikken, zelfs wanneer Word nog nooit gedraaid heeft op die machine.

Tot hier geen enkel probleem. Maar ga nu eens na, met dit alles in gedachten, wat er gebeurt als je over het web surft in Safari en op een link klikt. Bijvoorbeeld als je op een mailto-URL in een webpagina klikt moet er iets gebeuren. Iets moet daarom het mailto URL-schema koppelen aan jouw standaard e-mail client. Lang geleden, in de slechte oude tijd, had Apple geen oplossing voor dit probleem. Maar uiteindelijk kwam er een derde-partij oplossing op het toneel, genaamd Internet Config, en Apple nam het later over en bouwde het in het Mac OS in.

<http://db.tidbits.com/getbits.acgi?tbart=01718>

Oplettende lezertjes herinneren zich dat ik net nog zei dat een programma nu eenvoudig kan verklaren dat het de "eigenaar" is van een bepaald URL-schema, net zoals het kan stellen dat het de "eigenaar" is van een bepaald documenttype. Dat wordt nog eens onderstreept door deze pagina in Apples documentatie voor ontwikkelaars.

<http://developer.apple.com/documentation/Carbon/Conceptual/LaunchServicesConcepts/LSCIntro/chapter_1_section_1.html>

Met andere woorden, Apple heeft in Mac OS X's Launch Services twee zeer verschillende mechanismes van het classic Mac OS in elkaar geschoven: de Desktop Manager (die documenten koppelt aan programma's) en Internet Config (dat URL-schema's koppelt aan programma's). Dat klinkt allemaal heel redelijk, omdat we in beide gevallen iets gebruiken (een document of een URL-schema) om een programma op te starten, maar de twee noties zijn slechts gedeeltelijk parallel. Het ligt niet voor de hand dat de verzameling URL-schema's onbeperkt uitbreidbaar is. Op een e-mailadres klikken dat een mailto-link is en daarmee Mail starten, is één ding, maar op een link klikken en daarmee Help Viewer of Script Editor starten, of een verborgen programma waar je nog nooit van gehoord had een schijfkopiebestand laten downloaden en activeren is heel andere koek.

Het eind van het liedje is dat als ik kwaad wil, en het me lukt je mijn kwaadaardige programma te laten downloaden en aan Mac OS X bekend te maken, ik in staat ben om jou, door middel van een gewone webpagina, dat programma een bericht te laten sturen waardoor het actief wordt en zijn slechte daad gaat verrichten. Mijn kwaadaardige programma vertelt het systeem dat het reageert op het "duvel://" URL-schema, en als het mij dan lukt je op een "duvel://"-link te laten klikken, zal mijn programma starten. En zoals Adam in zijn artikel elders in deze aflevering uitlegt, begint het bedrog pas goed als ik kans zie een een-tweetje te maken zonder dat je doorhebt wat er is gebeurd. Door middel van een pagina die een doorverwijzing (redirect) of zelfs frames bevat kan ik je browser per saldo twee URL's na elkaar laten bezoeken: de eerste gebruikt een techniek zoals het disk URL-schema om het programma naar je harde schijf te downloaden en bekend te maken aan je besturingssysteem, de tweede gebruikt mijn "duvel://"-protocol waardoor Mac OS X het zal opstarten.

Als de bovenstaande bespreking op hoofdlijnen klopt, dan is het probleem waar we voor staan behoorlijk diep geworteld. Deel van de moeilijkheden is, natuurlijk, dat URL-schema's (zoals disk) ervoor kunnen zorgen dat een programma op je machine verschijnt voordat je weet wat er gebeurt; maar een ander deel van de moeilijkheden is dat alleen al een URL in een web-browser voldoende kan zijn om dat programma te starten. Daarom is het onmogelijk je tegen dit soort aanvallen te beschermen door alleen maar bepaalde afzonderlijke schema's te blokkeren, want het aantal mogelijke schema's is oneindig. Daarom is Paranoid Android van Unsanity een effectieve patch: het waarschuwt de gebruiker voor alle onbekende schema's die kunnen zijn aangemeld door een kwaadwillend programma, in plaats van zich te richten op bepaalde bekende schema's. Maar als ik het bij het juiste eind heb met mijn idee dat het probleem zijn wortel heeft in het opnemen van de functionaliteit van Internet Config in Launch Services, dan is het denkbaar dat Apple, om dit gat te dichten, het ontwerp van Mac OS X op een zo fundamenteel niveau moet aanpassen dat hierdoor bepaalde mogelijkheden waar we aan gewend zijn geraakt, verloren gaan.

<http://www.unsanity.com/haxies/pa/>


Recente onderwerpen in TidBITS Talk/24-May-04

door TidBITS Staff <editors@tidbits.com>
[vertaling: GH]

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

De tweede URL onder iedere discussiebeschrijving verwijst naar onze Web Crossing server, die veel sneller is, maar nog niet het door ons gewenste ontwerp voert.

<http://emperor.tidbits.com/TidBITS/Talk/>

Mac Browser Security Hole -- Lezers bespreken de realiteit van het recent gerapporteerde gat in de beveiliging van Mac OS X, en wat je er aan moet doen. (4 berichten)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2233>
<http://emperor.tidbits.com/TidBITS/Talk/99/>

New AppleScript Trojan Horse -- Moeten we de persoon die een Trojaans paard schrijft boos aankijken, of degenen die dit feit publiceren en daarmee anderen aanmoedigen hetzelfde te doen? (8 berichten)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2236>
<http://emperor.tidbits.com/TidBITS/Talk/98/>

Thoughts about WriteRight -- Lezers dragen hun ideeën en meningen aan over een ideale Mac tekstverwerker. (31 berichten)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2235>
<http://emperor.tidbits.com/TidBITS/Talk/101/>

Discussing Mellel -- Luister mee naar een gesprek over Mellel tussen Adam en de directeur van het bedrijf dat de tekstverwerker maakt. (5 berichten)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2237>
<http://emperor.tidbits.com/TidBITS/Talk/102/>

Problems with Disc Labeling -- Nadat we schreven over het uitbrengen van disclabel 2.0, wijst een lezer op de problemen die het gevolg kunnen zijn van het plakken van etiketten op cd's en dvd's. (4 berichten)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2234>
<http://emperor.tidbits.com/TidBITS/Talk/100/>


Niet-winstgevende en niet-commerciële publicaties en Websites mogen artikels overnemen of een HTML link maken als de bron duidelijk en volledig vermeld wordt. Anderen gelieve ons te contacteren. We garanderen de precisie van de artikels niet. Caveat lector. Publicatie-, product- en firmanamen kunnen gedeponeerde merken zijn van hun ondernemingen.

Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering