Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering

TidBITS#818, 27 februari 2006

Zijn de recente zwakke plekken in de beveiliging van Mac OS X het werk van geniale crackers of eerder tekortkomingen van Mac OS X wat betreft het koppelen van programma's en documenten? Geoff Duncan bekijkt het recente beveiligingslek in Safari en Matt Neuburg legt uit hoe we hierin terecht zijn gekomen. Verder bespreekt Adam in dit nummer iPhoto 6, geeft hij ons het laatste nieuws over voormalig Macintosh-evangelist Guy Kawasaki en kijkt hij kort naar Apples aankondiging van het miljardste via iTunes verkochte nummer.

Onderwerpen:

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


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.


Deze editie van TidBITS werd gedeeltelijk gesponsord door:

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, 27 februari 2006

[vertaling: PAB]

Verslag van Apples speciale evenement -- Het nummer van deze week verschijnt een dag voor Apples media-evenement op 28 februari 2006 en hoewel we kunnen blijven voorspellen totdat onze toetsenborden het onder de druk begeven, doen we in plaats daarvan het verstandige: we verslaan de aankondigingen van Steve Jobs in een ExtraBITS direct volgend op de gebeurtenissen. [JLC]

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


iTunes Music Store gaat over de grens van 1 miljard verkochte nummers

door Adam C. Engst <ace@tidbits.com>
[vertaling: HM]

Als ik Cupertino weer eens bezoek, kijk ik of Apple een McDonalds-bord die het aantal verkochte hamburgers vermeld heeft overgenomen om te adverteren hoeveel iTunes-nummers er zijn verkocht in de iTunes Music Store. Als zoiets deze maand had bestaan, zou het een extra cijfer hebben moeten toevoegen op 23 februari 2006, toen verkocht de iTunes Music Store het miljardste liedje (dat is een Amerikaans biljoen, geen Brits biljoen, al zul je dat waarschijnlijk al begrepen hebben).

<http://www.apple.com/pr/library/2006/feb/23itms.html>
<http://www.askoxford.com/asktheexperts/faq/aboutwords/billion>

Het miljardste nummer was "Speed of Sound" van Coldplays X&Y album, gekocht door Alex Ostrovsky uit West Bloomfield, Michigan. Door op het juiste moment op de "koopknop" in iTunes te drukken, won Alex een 20-inch iMac, 10 vijfde-generatie iPods, en een geschenkbon van $10.000 voor de iTunes Music Store (Ik heb het beeld voor me van een man die een geschenkbon voor de iTunes Music Store krijgt zo groot als een plaat triplex). Apple heeft ook een leerstoel opgericht aan de Juilliard School of Music in Alex' naam om de miljardste verkoop te herdenken.

Apples mijlpaal is dubbel interessant omdat ze normaal gesproken informatie bevatten over de verkochte artikelen in de iTunes Music Store (Wikipedia verzamelt blijkbaar veel van deze gegevens, hoewel het ook interessant zou zijn om verkoopgrafieken te zien). Bijvoorbeeld, iTunes Music Store verkocht 15 miljoen video's en bevat momenteel ruwweg;

<http://en.wikipedia.org/wiki/ITunes_Music_Store>


Guy Kawasaki is terug!

door Adam C. Engst <ace@tidbits.com>
[vertaling: JG]

Terwijl de Macintosh door de jaren gerijpt is, zijn sommige mensen verder getrokken, en de Mac-wereld is er armer door geworden. Maar een bekend gezicht van vroeger is weer terug: ex Apple-evangelist Guy Kawasaki. Guy is directeur van het Garage Technology Ventures venture-capitalfonds, en hij toonde overal op de Macworld Expo in San Francisco, FilmLoop. Het was enorm leuk om hem weer terug in de Macintosh-gemeenschap te zien, en dankzij de blog tegen het eind van 2005, denk ik dat hij weer een publiek figuur zal worden.

<http://blog.guykawasaki.com/>

Zoals we van Guy kunnen verwachten is dit niet 'Just Another Blog' (de ondertitel is "Blogger. zn. Iemand die niets te zeggen heeft, die schrijft voor iemand die niets te doen heeft." Au!). Het blog van Guy is in plaats daarvan gevuld met het soort praktische wijsheid dat we kennen van zijn boeken sinds "The Macintosh Way". Zijn recentere boeken hebben vanzelfsprekend een beetje meer het oogpunt van de durfkapitalist (vandaar de titels: "The Art of the Start", "Rules for Revolutionaries", "Selling the Dream", en "How to Drive Your Competition Crazy"). Maar ze zijn amusant, vol inzicht, en nuttig voor bijna iedereen die een nieuw project gaat beginnen, een presentatie gaat geven, of die probeert op te vallen. De artikelen op het blog van Guy hebben precies dezelfde kwaliteiten, en het blog-formaat is misschien wel een effectievere presentatiemethode voor sommige van zijn ideeën, omdat ze in regelmatige kleine stukjes komen. Hoeveel ik ook van de boeken van Guy hou, als ik ze lees word ik heel erg enthousiast over zijn ideeën, maar ik begraaf me dan in een project, en ik kom er nooit toe het af te maken. Misschien zullen de constante duwtjes in de rug van zijn blog me eindelijk eens iets af laten maken.

(En als je nieuw bent in de Macintosh-wereld en geen flauw idee hebt wie Guy Kawasaki is, pak dan een exemplaar van "The Macintosh Way" en lees het - tweedehands exemplaren zijn ongeveer $5 op Amazon en het blog heeft links naar al zijn boeken.)

Een gebied waar Guy al heel lang in uitmunt is het bouwen van een gemeenschap. Hij was altijd een enorme voorstander van gebruikersgroepen binnen Apple, en inderdaad, ik kletste met hem tussen onze lezingen door bij de User Group University (de aanwezigen waren allemaal gebruikersgroepsleiders) de dag voor Macworld Expo in San Francisco. Ik was net klaar met mijn praatjes - samen met Chris Breen en Bob LeVitus - over hoe gebruikersgroepen zichzelf nieuw leven in kunnen blazen en relevant kunnen blijven, dus het was bijzonder interessant om het recente artikel van Guy over gemeenschap bouwen te zien. Uitstekende punten, en het commentaar is ook de moeite waard voor iedereen die geïntereseerd is in gebruikersgroepen of in het samenbrengen van mensen. [ACE]

<http://blog.guykawasaki.com/2006/02/the_art_of_crea.html>


Belangrijk beveiligingslek in Safari ontdekt

door Geoff Duncan <geoff@tidbits.com>
[vertaling: MSH]

Er is een potentieel veiligheidslek in Apples Safari ontdekt. Dit zou aanvallers in staat kunnen stellen om willekeurige Unix shellscripts los te laten op machines van een gebruiker, door eenvoudigweg een link op een website te volgen. Apple moet nog commentaar geven of een reparatie uitgeven, maar ondertussen dringen we er bij Safarigebruikers op aan om de optie "Open 'veilige' bestanden na het downloaden" in het algemene deel van de Safari Voorkeuren buiten werking te stellen. (Feitelijk hebben we deze optie al sinds mei 2005 aanbevolen, toen een zwakke plek betreffende Dashboard widgets werd ontdekt).

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

Oorzaak van het lek betreft de wijze waarop Mac OS X vaststelt welk programma bestanden van een bepaald type start. Onder Mac OS 9 werden applicaties geassocieerd met bestanden door vierletterige "creator codes", die in de resource fork van het bestand zaten; onder Mac OS X worden applicaties met bestanden gelieerd via een mysterieuzer systeem, met metadata en de extensie van een bestand. Door de naam te veranderen van een Unix shellscript tot een "veilige" extensie (zoals .pdf, .jpg, etc.), het instellen van de 'executable bit' van het bestand en het comprimeren van het script met het Zip archiveringsgereedschap, zal Safari het script zonder blikken of blozen downloaden, decomprimeren, aannemend dat het script "veilig" is, en zal het dan zonder meer doorgeven aan de Terminal applicatie van Mac OS X om het uit te voeren. Een aanvaller zou een dergelijk script zo gemakkelijk kunnen toepassen om de thuismap van een gebruiker te vernietigen, de computerconfiguratie te beschadigen, of persoonlijke data te verkrijgen. (Voor meer informatie, zie Matt Neuburgs "Of Files, Forks, en FUD" elders in dit nummer.)

Safari is de enige webbrowser waarvan bekend is dat hij hiervoor gevoelig is, maar het is mogelijk dat andere programma's ook voor zulke aanvallen kwetsbaar zijn . De Camino en Firefox browsers zijn hier niet gevoelig voor.

Het Deense beveiligingsbedrijf Secunia noemt de tekortkoming "uiterst kritiek", en publiceerde een onschuldig voorbeeld van het lek, zodat gebruikers hun systeem hierop kunnen testen. Heise Online geeft een andere demonstratie.

<http://secunia.com/advisories/18963>
<http://secunia.com/mac_os_x_command_execution_vulnerability_test/>
<http://www.heise.de/security/dienste/browsercheck/demos/safari/Heise.jpg.zip>

Gebruikers zouden ook zichzelf kunnen beschermen door de Terminal applicatie weg te halen van zijn standaardplaats in Programma's > Hulpprogramma's. (Echter, door dat te doen zou je toekomstige systeem updaters in de war kunnen brengen, gebruikers moeten zich herinneren om het terug te plaatsen voordat ze nieuwe software installeren.)

Standaard is de Safari-optie "Open 'veilige' bestanden na downloaden" niet actief op nieuwe Mac OS X 10.4.5 installaties. veel gebruikers zijn dus standaard hiertegen beveiligd. Echter, alleen maar Mac OS X 10.4.5 gebruiken is geen veiligheidsgarantie: we zagen bevestigd dat systemen die naar Mac OS 10.4.5 vanaf eerdere versies werden opgewaardeerd toch de Safari "Open 'veilige' bestanden na downloaden" optie actief lieten. Dus, controleer veiligheidshalve dat de optie op jouw systeem uit staat, ongeacht welke Mac OS X versie je gebruikt.


Over bestanden, forks, en FUD

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

Als evenwichtige en rationele lezer van TidBITS heb je vast niet toegegeven aan de golf van angst, onzekerheid, en twijfel die ons deze week overspoelde vanwege de recente soort Mac OS X-beveiligingsproblemen (zie Geoff Duncans "Belangrijk beveiligingslek in Safari ontdekt", elders in deze aflevering voor meer informatie). Zoals wel te verwachten was, hebben de massamedia alle zin voor historisch perspectief en technische details overboord gegooid in hun "verslaggeving" om plaats te maken voor schreeuwerige koppen met evenveel inhoud als onduidelijk gebrul ("Mac OS X heeft virussen!"). En dan zijn er natuurlijk ook nog de onvermijdelijke paniekzaaiende persberichten van ondernemingen die dergelijke berichten niet zonder enig eigenbelang verspreiden. Hier laten we de hype achterwege en bekijken we alleen de feiten.

Sesam open u -- Deze feiten draaien voornamelijk rond hoe documenten en applicaties in Mac OS X met elkaar worden geassocieerd. Wanneer je een document in de Finder bekijkt, heeft het een pictogram van de applicatie die het opent. Wanneer je dubbelklikt op het document, wordt die applicatie opgestart en het document geopend. Hoe blijft deze associatie behouden?

In de dagen van Mac OS 9 en eerder, had het antwoord te maken met metadata die op een onzichtbare manier in het bestandensysteem waren opgeslagen en in een onzichtbare database werden opgezocht. Vanaf Mac OS X is Apple begonnen met deze architectuur te vervangen door die vervelende kleine bestandsextensies die - onzichtbaar of niet - na een punt in de bestandsnaam staan, samen met een ingewikkelde reeks strategieën voor het opsporen van de geassocieerde applicatie.

<http://db.tidbits.com/getbits.acgi?tbart=05415>
<http://db.tidbits.com/getbits.acgi?tbart=06584>
<http://arstechnica.com/reviews/os/metadata.ars/8>

Op deze manier heeft Apple een elegante methode voor associaties tussen documenten en applicaties, een manier die goed werkte (nu ja, toch vrij goed want een probleem met de associatie kon je oplossen door het "bureaublad opnieuw op te bouwen") en onzichtbaar was voor de gebruiker te vervangen door een lelijk en vaak onvoorspelbaar systeem waarbij het type van het bestand in de bestandsnaam wordt opgenomen, en dat alleen maar omdat andere besturingssystemen dat zo doen. Alleen hebben ze niet helemaal komaf gemaakt met de eerdere methode, maar we zitten nu met een ongemakkelijke Jekyll-en-Hyde-combinatie. Een bestand van voor Mac OS X heeft immers misschien geen extensie, zodat bestanden tegenwoordig type/creator-metadata, een extensie, of beide kunnen hebben.

Maar dat is nog niet alles. Neem nu bijvoorbeeld het probleem van een generiek bestandstype zoals .pdf. Zowel Preview als Adobe Reader kunnen een .pdf-bestand openen - met welke applicatie moet dit specifieke bestand nu worden geopend? Jij, de gebruiker, kunt die vraag eenmalig beantwoorden door het bestand op het pictogram van de gewenste applicatie in het Dock of de Finder te slepen. Maar wat als je het bestand aan de ene of de andere applicatie wilt toewijzen, zodat het bij dubbelklikken in de Finder altijd met die applicatie wordt geopend?

Om redenen die ik niet helemaal begrijp, gebruikt Mac OS X niet de type/creator-metadata voor deze situatie. In plaats daarvan heeft Apple een plek in de resource-fork - de 'usro'-resource - voorzien waarin de aangepaste bestandsassociatie van de gebruiker wordt opgeslagen. In het venstermenu 'Open met' in het dialoogvenster 'Toon info' in de Finder stel je dan eigenlijk de 'usro'-resource van het bestand in. Een bestand kan met alle drie voorkomen: zowel een 'usro'-resource als een metadata-creatorcode als een extensie van de bestandsnaam.

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

Hoe werkt het veiligheidslek nu precies? -- Het blijkt nu dat deze informatie kan worden misbruikt om een conflict te genereren. Een dergelijk conflict ligt aan de basis van de huidige reeks beveiligingsrisico's. Wanneer je het demonstratiebestand van Heise downloadt en decomprimeert, krijg je een tekstbestand met shellscript-opdrachten, maar het bestand heeft een .jpg-extensie en een foute 'usro'-resource. De extensie bepaalt het pictogram van het document (op mijn machine is dat een JPEG-pictogram afkomstig van Preview), terwijl de 'usro'-resource het bestand met een andere applicatie (Terminal) associeert. In het dialoogvenster 'Toon info' in de Finder kun je zien dat het eigenlijk een Terminal-document is.

<http://www.heise.de/security/dienste/browsercheck/demos/safari/Heise.jpg.zip>

Het feit dat deze inconsistentie mogelijk is, is waarschijnlijk een bug in het systeem. In theorie moet het systeem kunnen detecteren dat de 'usro'-resource ongeldig is. Wanneer ik het creator-toewijzingsmechanisme van de gebruiker test, zie ik dat het bestand, behalve een 'usro'-resource ook een 'icns'-resource krijgt met het label "Binding Override" en die waarschijnlijk het documentpictogram van de nieuw toegewezen creator is. Het JPEG-pictogram van GraphicConverter verschilt bijvoorbeeld van dat van Preview. Maar Terminal heeft geen JPEG-pictogram omdat het geen JPEG-bestanden opent. En bovendien heeft dit beveiligingsrisico Terminal nodig om het bestand niet als JPEG, maar als tekst te behandelen. Het Heise-bestand heeft dan ook geen 'icns'-resource, wat bij het systeem bellen zou moeten doen rinkelen.

Zip en onzin -- Het feit dat er een .zip bestand mee gemoeid is, dat op je computer uitgepakt moet worden om het probleemdocument te genereren is niet van belang. Natuurlijk wordt het document uitgepakt door of StuffIt Expander of BOMArchiveHelper van Apple, maar deze programma's spelen geen belangrijke rol in het verhaal. Ze doen immers niet meer dan het correct reproduceren van het bestand wat ze in handen gekregen hebben. Het is bovendien waar dat het .zipbestand intern een speciaal formaat heeft; maar dat geldt voor willekeurig welk bestand met een resource fork.

De rol van Safari in het hele verhaal moet ook niet overdreven worden. Het is waar dat de optie van Safari ("Open 'veilige' bestanden na downloaden" standaard ingeschakeld is (wat eigenlijk niet zo zou moeten zijn, om heel veel redenen), het gedownloade bestand twee keer zal openen. De eerste keer om het uit te pakken, en de tweede keer om het bestand te openen omdat Safari denkt dat het om een veilig .jpgbestand gaat. Dit wijkt echter niet af wat jijzelf met het bestand zou doen in de Finder, als je zou denken dat het een veilig bestand is (en waarom zou je dat niet?).

Verder moeten we opmerken dat Mail van Apple aan hetzelfde probleem lijdt als de Finder. Wanneer je het bestand als een e-mail-bijlage zou hebben ontvangen, toont Mail je een JPEG-icoon (samen met de .jpg-extensie), maar zal het het bestand openen in de Terminal als je er op zou dubbelklikken.

Als laatste wordt her en der beweerd dat het zou gaan om een zogenaamde executable - het is echter een shellscript, en de schrijfrechten zijn zo ingesteld dat het script meteen gaat lopen wanneer de Terminal het opent. Dat dit kan is niet nieuw, ieder tekstbestand met een .command-extensie en uitvoerrechten zal gestart worden door de Terminal wanneer er op gedubbelklikt wordt, en dat is altijd zo geweest. Of dit zou moeten of niet is een andere discussie, waarop ik later terug kom. Het is ook niet nieuw dat een executable doorgegeven kan worden als een gecomprimeerd bestand; anders zou je immers geen programma's kunnen comprimeren. Sommigen beweren dat een deel van het probleem zit in het feit dat het bestand geen "shebang"-regel heeft, maar dat is niet waar; het werkt ook wanneer die er wel geweest zou zijn.

Conclusies -- Mijn conclusie bestaat uit twee delen: en allebei leiden tot de aanname dat computerbestanden zoals Iago zegt over mensen, "zouden moeten zijn wat ze lijken, of niet zijn, mochten ze niets lijken".

Allereerst is het systeem dat Mac OS X gebruikt om documenten aan programma's toe te wijzen, nooit helemaal volwassen geworden en nu blijkt dat er een belangrijke bug in zit. Apple moet die eruit halen, en goed ook, zodat een bestand altijd lijkt op wat het is.

Ten tweede is een executable, van welke soort dan ook - of het nu een Cocoa application bundle is of een uitvoerbaar shellscript - een heel bijzonder soort bestand, en dat moet ook zichtbaar zijn. Gegevens die je kunt lezen en code die je kunt uitvoeren zijn beide bestanden, maar verschillen wel op cruciale punten; executables moeten er dus uitzien (en zich gedragen als) zodanig. Ieder bestand dat kan werken als code moet op een opvallende manier "gemerkt" worden. Het helpt wellicht ook dat wanneer je een bestand voor de eerste keer uitvoert, je met een opvallend bericht geconfronteerd wordt. Apple heeft iets dergelijks ingevoerd na het URL scheme-drama, maar dat ging niet ver genoeg. Het gaat hier om een bericht dat getoond wordt bij de eerste keer uitvoeren van een programma na het dubbelklikken van een document dat hierbij hoort, maar niet na het dubbelklikken van de executable zelf, terwijl het echte probleem is dat het programma zelf - zoals nu blijkt - een executable is. Pas als Apple dit oplost, zal de wereld een veiliger plaats zijn.


iPhoto 6: goed, maar niet grensverleggend

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

Er zijn weinig programma's waarmee ik zo vertrouwd ben als met iPhoto. Dit is te danken aan mijn jaarlijkse analyse van de mogelijkheden tijdens het schrijven van mijn boek "iPhoto for Mac OS X: Visual QuickStart Guide". Het is dan ook altijd boeiend te zien wat Steve Jobs demonstreert bij de onthulling van een nieuwe versie. Dat deed hij ook bij de introductie van iPhoto 6 op de recentste MacWorld Expo in San Francisco. Maar ik kan niet alleen nauwelijks wachten om de nieuwe mogelijkheden uit te proberen, ik ben ook enorm nieuwsgierig of Apple een oplossing gevonden heeft voor enkele lang slepende ergernissen in iPhoto. In de laatste edities werd er weinig aan die ergernissen gedaan, maar iPhoto 6 ruimt er vier van uit de weg. Twee andere zijn spijtig genoeg over het hoofd gezien en er zijn ook nieuwe ergernissen in de plaats gekomen. Maar laat ons eerst eens kijken naar de nieuwe mogelijkheden die iPhoto 6 op het vlak van beeldbewerking en bestandsdeling te bieden heeft.

<http://www.apple.com/ilife/iphoto/>

Bewerkingsuitbreidingen -- In iPhoto waren er totnogtoe drie manieren om foto's te bewerken: in het weergavescherm, in een apart scherm en in een extern beeldbewerkingsprogramma als Photoshop Elements. Daar komt nu nog een vierde methode bij waarbij de interface van iPhoto volledig verdwijnt. Daardoor wordt het mogelijk om het volledige schermoppervlak te benutten en de foto op de maximale resolutie weer te geven. Bovenaan het scherm verschijnt een balk met miniatuurweergaves en onderaan een gereedschapsbalk. Beide verdwijnen, net als het Dock, automatisch als je Dock verbergen hebt ingeschakeld. De mogelijkheid om het volledige schermoppervlak te gebruiken voor het bewerken van foto's komt erg van pas omdat de andere besturingselementen heel wat nuttige ruimte opslorpten. Bij de in iPhoto ingebouwde mogelijkheid om foto's in een apart venster te bewerken, werd noch de grootte noch de plaats van de foto onthouden. Je kunt iPhoto trouwens zo instellen dat de foto in deze modus wordt geopend als je er op dubbelklikt.

Werken in de volledige modus houdt wel een aantal veranderingen in aan de gebruikelijke interface. Als je bijvoorbeeld op de infoknop drukt, verschijnt er een transparent infopaneel (want er is geen plaats voor een normaal infoscherm). En als je inzoomt, dan verschijnt er een transparant navigatiepaneel om je te helpen met scrollen, want er zijn ook geen navigatiebalken (maar met een scrollwiel kun je nog altijd naar boven en beneden scrollen; naar links of rechts scrollen doe je door de Shift-toets ingedrukt te houden). Het belangrijkste nadeel van de volledige modus is voor mij dat het langer duurt om over te schakelen; op mijn dual 1 GHz Power Mac G4 duurt het ongeveer 4 seconden voordat ik een foto kan bewerken terwijl dat in het weergavescherm maar 2 seconden duurt. En als je twee beeldschermen naast elkaar gebruikt en je per ongeluk buiten de volledige modus klikt, keert iPhoto zonder wijzigingen op te slaan onmiddellijk terug naar de organisatiemodus.

iPhoto 6 heeft nog altijd het zelfde Bewerk-paneel als iPhoto 5 maar er komt een nieuw Effecten-paneel bij met zes knoppen met nieuwe effecten, naast de bestaande zwart/wit- en sepia-effecten en een negende knop om terug te keren naar het origineel. Het Antiek-effect lijkt erg op het Sepia-effect, maar is eleganter en een beetje minder verzadigd. De knoppen om kleuren te vervagen of te versterken lijken ongeveer net zo te werken als de schuifbalk om de verzadiging aan te passen in het Bewerk-paneel. De drie knoppen op de onderste rij tot slot, leggen een ovaal masker over de afbeelding, waarbij de foto in het midden doorschijnt. Door de Mat-knop te gebruiken krijg je een wit masker, met Vignet krijg je een zwart masker en met Randen Vervagen vervaagt de foto onder het masker. Behalve op de knoppen Zwart/wit, Sepia en Origineel kun je meerdere keren klikken om het effect in meer of mindere mate aan te brengen. Je kunt de verschillende effecten ook samen gebruiken; je kunt een foto bijvoorbeeld sepia maken, de kleur vervagen en het Vignet-masker aanbrengen. Ik kan nog niet zeggen of ik de nieuwe effecten ook werkelijk ga gebruiken, maar het is een beetje raar dat Apple deze effecten niet in Photo Booth heeft geïntegreerd. En ik zou het ook leuk vinden als iemand uitzocht hoe alle Mac OS X Core Image-effecten toegankelijk kunnen worden gemaakt in iPhoto - het gratis ImageTricks van BeLight Sortware maakt ze als een apart programma beschikbaar.

<http://www.belightsoft.com/products/imagetricks/overview.php>

Al deze transparante panelen zorgen voor een nieuwe ergernis. Ze blijven in de weg zitten, ook al zijn ze doorzichtig. Voor opslag is een tweede beeldscherm dan ook zeker welkom. Als de foto's op een tweede scherm zijn geplaatst, onthoudt iPhoto tijdens de sessie hun positie. Tussen de lanceringen van het Effecten- en het Bewerk-paneel gaat iPhoto hier wel in de mist.

Bij het werken met een volledig schermoppervlak is er nog iets dat erg welkom is: je kunt in een keer acht foto's met elkaar vergelijken. Als je de Vergelijk-knop aanklikt als je al in de volledige modus zit, toont iPhoto de huidige en de volgende foto zij aan zij in hun hoogst mogelijke resolutie. Maar als je in de organisatiemodus tot acht foto's selecteert en dan op de knop drukt om de volledige modus in te schakelen, worden alle acht foto's zo groot mogelijk op het beeldscherm vertoont. Je kunt dan ook op een ervan klikken en met de pijltjestoetsen naar de volgende of de vorige foto gaan; nog interessanter is het dat je al de bewerkingsopdrachten op alle foto's kunt toepassen of de huidige zelfs verwijderen door op de Verwijder-knop te drukken. Het vergelijken van foto's wordt dus een leuke manier om door je foto's te bladeren na het importeren. Zo zie je ook welke de moeite waard zijn om te behouden; dat geldt zeker als je de functie op je camera gebruikt om meerdere foto's snel achter elkaar te nemen om zo snelle actieshots te maken.

Omdat het leuk is om te delen -- Het andere waar iPhoto beduidend beter in geworden is, zijn de mogelijkheden om te delen. De fotoboeken, iPhotos top-functie van het begin af aan, zijn verbeterd met nieuwe thema's, hogere kwaliteit afdrukken en lagere prijzen. Je kunt ook op de knop "Speel af" klikken bij het maken van een boek om de foto's te laten zien als diavoorstelling. Maar echt gaaf zijn de twee nieuwe afdrukmogelijkheden kaarten en kalenders. Beide worden op vergelijkbare wijze opgemaakt als een boek.

Kaarten zijn er in twee soorten: gevouwen wenskaarten en briefkaarten. Wenskaarten hebben een afbeelding aan de voorkant en tekst op één binnenkant. Briefkaarten kunnen een afbeelding aan de voorkant hebben en op de achterkant of een tekstblok, of de standaard lijntjes voor adres en postzegel. Ze zijn zo eenvoudig te maken als je zou verwachten, omdat de enige opties de te gebruiken afbeelding, de tekst die je opgeeft en een lettertype naar keuze (als je tenminste een andere wil als de standaard). Verschillende ontwerpen en achtergronden zijn voor beide soorten beschikbaar. De prijzen variëren tussen $1 en $2 per kaart, afhankelijk van de kaartsoort en het bestelde aantal.

Kalenders zijn flexibeler, samen met de gebruikelijke overvloed aan thema's en pagina-ontwerpen binnen elk thema, afhankelijk van het aantal foto's die te zien zijn. Verder kun je ook naar elke dag foto's slepen, waardoor je bijvoorbeeld eenvoudig elke verjaardag met een portret van de jarige kunt versieren. Je kunt zelfs de fototitel als onderschrift toevoegen, maar je moet een naastliggende dag gebruiken voor de tekst, die kan niet over de foto zelf heen getoond worden. Je kunt ook elke tekst die je wilt, toevoegen aan een specifieke dag. iPhoto kan kalenders maken van tussen de 12 en 24 maanden, nationale feestdagen van meer dan 30 landen toevoegen (helaas van slechts een land, je kunt dus niet de feestdagen van zowel de Verenigde Staten als Australië tonen), kalenders van iCal importeren (via deze omweg kun je misschien toch feestdagen van verschillende landen tonen) en verjaardagen vanuit het Adresboek importeren. De kalenders zien er prachtig uit en kosten $20 voor 12 maanden, elke maand extra kost $1,50.

Steve Jobs besteedde veel aandacht aan iPhotos nieuwe photocast-functie in zijn Macworld Expo-presentatie en het is ook een interessante functie. Het basisdoel is iPhoto-gebruikers in staat te stellen foto's te delen (via een .Mac-abonnement) met mensen die of iPhoto 6 gebruiken, of een RSS-lezer die met foto's kan omgaan (zoals Safari). Photocasts moeten beginnen vanuit een normaal album, geen slim album, maar je kunt ze automatisch laten bijwerken als het album verandert. Photocasts kunnen voor iedereen toegankelijk zijn, of alleen voor degene die je een toegangsnaam en wachtwoord gegeven hebt. Het lijkt er niet op dat Apple publiekelijk toegankelijke photocasts in een of ander overzicht publiceert, dus realistisch gezien is het onwaarschijnlijk dat iemand de URL van een photocast achterhaalt als die hem niet door iemand verteld wordt.

Hoewel ik niet echt aanhanger ben van de populaire fotosite Flickr (waar vinden mensen de tijd om foto's te bekijken van willekeurige internetburgers?), hebben anderen zich ingespannen om Flickr RSS-feeds te laten verschijnen in iPhoto (kies "Archief > Abonneer op photocast…" en plak de URL in). Eerlijk gezegd lijkt de verbinding tussen de twee nog steeds slecht, maar bekijk onderstaande sites voor proxy-diensten die iPhoto voorzien van meer dan 10 afbeeldingen tegelijk en de grootst mogelijke foto's op Flickr gebaseerd op gebruikersnaam, sets en tags (Photocastr werkte in mijn testen het beste).

<http://photocastr.com/>
<http://snosrap.com/photocast/>
<http://phlikr.3xi.org/>

Photocast-albums zijn gewoon erg raar. Je kunt er niet in zoeken, of de foto's bewerken en nog vreemder, je kunt geen foto uit een photocast-album naar je bibliotheek verslepen. Maar, je kunt de foto wel naar een normaal album verplaatsen of het in een kalender of boek gebruiken en als je dat eenmaal gedaan hebt, kun je de foto ook bewerken. Maar de foto verschijnt nog steeds niet in je bibliotheek. De enige manier om photocast-foto's in je bibliotheek te krijgen is het weggooien van je photocast-album. iPhoto bewaart alle foto's die je hebt "gebruikt" en vraagt je de rest te bewaren door ze op dat moment te importeren in je bibliotheek (het verwijderen van photocast-albums crashte iPhoto 6.0.1 ongeveer een op de twee keer bij mij). Het is afwachten hoe populair photocasten binnen iPhoto 6 zal worden.

Andere veranderingen in de manier waarop je foto's kunt delen met iPhoto zijn onder andere de vervanging van de .Mac HomePage-integratie met een verbinding naar iWeb en een optie "Zoom en snij uit" bij het maken van afdrukken op standaardafmetingen (in wezen zorgt deze optie voor het maken van de noodzakelijke uitsnede om een foto in de juiste beeldverhouding te krijgen).

Irritaties: echt en ingebeeld, opgelost en nog bestaand -- Doordat Apple niet in staat lijkt om toch in het oog springende problemen met iPhoto op te lossen, begin ik tegenwoordig bijna aan mijn eigen beoordelingsvermogen te twijfelen: ben ik de enige die denkt dat deze irritaties de moeite van het repareren waard zijn? Blijkbaar is er niet hard genoeg geroepen om Apple in actie te laten schieten, vooral omdat ik de indruk heb dat geen enkele van deze problemen bepaald subtiel of moeilijk op te lossen is.

Het schokkendst is nog wel dat iPhoto 6 je nog steeds dwingt om de namen van foto's en filmrollen te veranderen in het Titelveld van het Infopaneel. Ik verbaas me er al die jaren nog steeds over dat het iPhoto-team niet van de Finder schijnt te kunnen leren dat het veel logischer en gemakkelijker zou zijn als je de titel van de foto of filmrol direct zou kunnen dubbelklikken en de naam ter plaatse zou kunnen veranderen, net als in de Finder en overal elders in de Macintosh-interface.

Ik kan er ook nog steeds niet over uit dat niemand bij Apple er blijkbaar de noodzaak van inziet om iPhoto krachtiger te maken dan het hulpprogramma Fotolader dat met OS X meegeleverd wordt, tenminste als het gaat om een selectie van foto's van een camera te importeren in plaats van allemaal tegelijk. Fotolader heeft al selectieve import sinds de jonge jaren van Mac OS X, dus waarom heeft iPhoto na vijf jaar deze zo voor de hand liggende eigenschap nog steeds niet in huis? (En nu we het toch over Fotolader hebben, zou het niet logisch zijn om iPhoto de controle te geven over de voorkeursinstelling die aangeeft welk programma er geopend moet worden bij het aansluiten van een camera, in plaats van mensen te dwingen om Fotolader te openen om deze instelling te veranderen?)

Om wat positieve punten te noemen: Apple heeft toch een aantal zeer onnodige irritaties weggewerkt. De opvallendste is een voorkeursinstelling in het Geavanceerd-paneel in het Voorkeurenvenster van iPhoto waarmee je foto's in iPhoto kunt importeren vanaf je harde schijf zonder dat de originelen van deze foto's naar je iPhoto Library-map gekopieerd worden. Sinds iPhoto 1.0 wordt er al geklaagd over de manier waarop iPhoto geïmporteerde foto's overnam, en nu, vijf jaar later, heeft Apple eindelijk toegegeven. Het is misschien wel zo dat relatief weinig serieuze iPhoto-gebruikers er in geslaagd zijn om het verzet vol te houden en een aparte mapstructuur in de Finder voor originele foto's te onderhouden. Daardoor is de nieuwe eigenschap een halfslachtige concessie, maar wel eentje die, daar ben ik zeker van, door sommigen enorm op prijs zal worden gesteld. Eén opmerking: hoewel originele foto's in hun originele mappen blijven, worden gewijzigde foto's binnen de iPhoto Libraryhiërarchie opgeslagen.

Ook de manier waarop iPhoto bestanden op schijf bewaart, is veranderd. Velen waren niet te spreken over de jaar-maand-dag-mapstructuur die voorgaande versies van iPhoto gebruikten, dus in iPhoto 6 heeft Apple de structuur afgevlakt. Nu zijn er drie mappen op het eerste niveau in de iPhoto Librarymap: Original (voor originele foto's), Modified (voor bewerkte foto's) en Data (voor verkleinde weergaven). Binnen elke van deze mappen zitten mappen voor elk jaar, met daarin mappen voor elke filmrol die de naam van die filmrol dragen (foto's binnen de filmrolmappen houden hun originele namen: titels die binnen iPhoto werden toegekend bestaan alleen binnen iPhoto). De oude hiërarchie wordt door iPhoto 6 vernietigt na het updaten van je iPhoto Library naar de nieuwe indeling. Maar in de verschillende upgrades die ik heb uitgevoerd, sloeg het programma een aantal foto's over en bood het aan om ze te "repareren" na het voltooien van de rest van de upgrade. Je moet dit aanbod aannemen, wand in mijn bibliotheek van 10.000 foto's zaten er ongeveer 50 die reparatie nodig hadden, en zo'n 35 daarvan waren geen dubbele (zoek handmatig op bestandsnaam met het zoekveld van iPhoto).

Nog een veel voorkomende klacht was dat iPhoto contactafdrukken van fotovellen kon maken, maar geen mogelijkheid had om de titels erbij te zetten, waardoor deze contactvellen vrijwel geheel onbruikbaar waren voor de traditionele functies van contactafdrukken. Dat is nu opgelost: een aankruisvak zet de titels aan en uit en je kunt het lettertype kiezen.

De laatste, maar zeker niet de minste verandering is de reparatie die Apple invoerde voor een andere opvallende fout bij het invoeren van tekst in albums. Hoewel iPhoto vanaf de eerste dag een Cocoa-programma is geweest en het altijd de ingebouwde spellingscontrole van Mac OS X heeft ondersteund, heeft de Controleer spelling tijdens typen-optie altijd uitgestaan en als je hem aanzette tijdens het invoeren van tekst in een album, zette hij zichzelf zeer irritant altijd weer uit zo gauw je van bladzijde veranderde of de albumweergave verliet. Dit is niet langer het geval: Controleer spelling tijdens typen staat nu standaard aan, zoals het hoort, en werkt overal waar je tekst invoert, in albums, kaarten en kalenders.

Moet ik opwaarderen? Steeds als ik een nieuwe versie van iPhoto bespreek, behandel ik de vraag of de verbeteringen al of niet de opwaardering naar de nieuwste versie van iLife waard zijn. iPhoto 6 bevat voldoende verbeteringen en nieuwe eigenschappen die waardevol zijn voor iedereen die iPhoto ook maar enigszins serieus gebruikt, zeker als je ook in een van de andere iLife '06-applicaties geïnteresseerd bent. Maar als je geen foto's bewerkt in iPhoto en je niet van plan bent om fotoboeken, kaarten of kalenders te bestellen, zijn de nieuwe eigenschappen van iPhoto 6 op zich wellicht geen 80 dollar waard; daarvoor is iPhoto 6 niet echt wezenlijk verschillend van iPhoto 5.


Take Control-nieuws, 27 februari 2006

door Adam C. Engst <ace@tidbits.com>

"Take Control of Podcasting on the Mac" met GarageBand 3 -- Podcasting veroverde 2005, maar mensen realiseerden zich al snel dat het moeilijker was dan het leek. Daarom hebben we vorig jaar "Take Control of Podcasting on the Mac" uitgebracht en daarom heeft Apple, niet echt verrassend, een hoop nieuwe podcasting-mogelijkheden in GarageBand 3 toegevoegd. Maar als je Apples iLife programma;s gebruikt dan weet je, de documentatie is spaarzaam, daarom zijn we blij dat Andy Affleck "Take Control of Podcasting on the Mac" heeft bijgewerkt met info over het gebruik van GarageBand 2 of 3 voor het maken van een podcast. Het e-boek behandelt natuurlijk nog steeds Rogue Amoebas Audio Hijack Pro, (en je krijgt $3 korting op het programma), en het bespreekt SoundStudio 3. Ook nieuw in deze update is informatie over het toevoegen van hoofdstukken aan een podcast. De update is gratis voor de mensen die versie 1.0 kochten; klik op de 'Check for Updates'-knop op de voorpagina van jouw exemplaar. Voor mensen die willen beginnen met podcasting, "Take Control of Podcasting on the Mac" kost $10 en het helpt je GarageBand 3 tot het uiterste te gebruiken.

<http://www.takecontrolbooks.com/podcasting-mac.html?14@@!pt=TRK-0029-TB818-TCNEWS>


Recente onderwerpen in TidBITS Talk, 27 februari 2006

van de TidBITS-redactie <editors@tidbits.com>
[vertaling: DPF]

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

De eerste URL van elke thread-beschrijving verwijst naar de traditionele TidBITS Talk interface; de tweede URL verwijst naar dezelfde discussie op onze Web Crossing-server. Die heeft een ander uiterlijk en is mogelijk sneller.

DVD audio into iTunes? Hoe neem je een snipper geluid direct van een DVD op? Lees verder om de verschillende methodes te leren. (6 berichten)

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

SMS Text Messaging Costs -- Sommige mensen in de VS betalen meer om een tekstbericht te versturen dan om een gesprek te voeren vanaf hun mobiel. Is dit ook zo in de rest van de wereld? (8 berichten)

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

iPod nano as external storage device for beige G3 Macs running OS 9.2.2? Is het mogelijk om een iPod nano te gebruiken als een USB opslagapparaat voor twee Macs die niet Mac OS X draaien? (2 berichten)

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

Mac OS X 10.4.5 Fixes PowerBook Stuttering -- Verstopt in de details van de recentste Mac OS X Tiger update is een oplossing voor het storende probleem waarbij input door feedback gestoord werd. (2 berichten)

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

Are Input Managers the Work of the Devil? Het artikel van Matt Neuburg vorige week over het nieuwe gevaar voor de Mac, Leap-A malware leidt tot discussie over de reikwijdte van het probleem. (6 berichten)

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

Shell script exploit -- TidBITS-lezers kijken naar het nieuwste veiligheidslek en bespreken of andere browsers dit probleem ook kennen. (16 berichten)

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


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