E così Microsoft, (fatalità giusto due mesi dopo che Apple ha lanciato Snow Leopard, ma non siamo qui per fare uno dei soliti PC vs MAC) annuncia Windows 7…

Anzi! Sarebbe il caso di dire Windows 8, se consideriamo le distribuzioni principali (3.1, 95, 98, 2000, ME, XP, Vista, W7), in ogni caso, sembra che questo Windows 7/8 sia già praticamente pronto, tanto è che Microsoft ha già rilasciato per il download la Release Candidate, anche in Italiano, reperibile –> Qui <–

Se volete cimentarvi nel testing di questo sistema operativo, però state attenti! Avrete tempo di usarlo al suo 100% solo fino al primo maggio 2010, dopodiché, il vostro computer si spegnerà ogni due ore, fino a giungere alla morte e alla morte di croce il 1 giugno, data in cui la Release Candidate si autodistruggerà irrimediabilmente. Il consiglio quindi? Usatelo con attenzione, e non usatelo come OS principale.

Porto ora la vostra attenzione sull’ennesima “innovazione” Microsoft. Ebbene sì, questa nuova release di Windows integrerà un sistema di mini applicazioni dette “Widget”. La cosa è molto stuzzicante, in quanto i Widget spaziano veramente in tutti i campi.

Questo ci va a significare che noi comuni esseri mortali che non abbiamo intenzione di comprare Windows 7 non potremmo mai usare questi Widget? Diciamo “nì”. No perché non ci sarà possibile usufruire della particolare versione del sistema Widget di Microsoft, ma sì, esistono altre piattaforme Widget, probabilmente anche più carine di quella (in beta) di W7.

Ergo? Quali sono queste alternative?

Per Mac e Windows (non-7) potete provare il vaidissimo Konfabulator, progetto esistente in rete già da qualche anno. Offre una varietà veramente gigantesca di programmini, ed è abbastanza leggero.

Su Mac (Da OSX 10.4 in poi) è integrato Dashboard. Premendo F12, oppure il tasto con un contachilometri se avete un portatile, accederete all’ambiente Dashboard. Per scaricare altri Widget è sufficiente collegarsi al sito della Apple.

Linux e gli altri potranno installare l’ambiente KDE, disponibile –> Qui <–. Non dovreste avere problemi nell’installazione, se questo è il vostro primo ambiente Desktop, tuttavia se avete già GNOME, è possibile che i due DE entrino in conflitto, quindi leggete le doc prima di applicare grossi cambiamenti.

Apparentemente, questo è quanto

The Sign Painter

Six Pixels of Separation rues that digital marketing’s infinite shelf life isn’t being made use of properly.

Seth Godin has a Blog post today called, Time Has A Long Tail Too, that highlights perfectly the problems that Advertisers and Marketers are having with the Digital Marketing space. The crux of Godin’s post is about how still, after a few years, the Terry Tate Office Linebacker long-form video commercials for Reebok have an audience (welcome to The Long Tail… where products have an unlimited shelf life… with unlimited shelves). In fact, the one video I clicked over to check out on YouTube – Terry Tate’s World – had 932,933 with 332 comments and 4/5 star rating. The challenge is that when you go to the URL promoted at the end of the Terry Tate video, the site is down. You get a page error.

Why would Reebok not want to capitalize on this audience? How much would it cost to keep the hosting of the Terry Tate page active, and use it to introduce consumers to newer brands and campaigns? The options seem endless, and there’s a captive (and interested) audience with a steady flow of traffic being driven to the site.

Marketing was about one-night stands…

A point, I think, that is particularly pertinent in the case of widgets. You’ve fought tooth and nail to invade the consumer’s desktop. He’s had to download and install something (or perhaps add code to her blog).

Once the campaign’s up, will you let that widget be uninstalled because it became useless, and charm your way back in when your next campaign comes up? Or will you, to use a medical term, “keep the vein open“?

Nei nuovi Sistemi Operativi, le varie software-house, compresi gli sviluppatori del mondo open-source, hanno introdotto una novità comune: i Widgets. In pochi, però, conoscono la vera storia di questi mini applicativi tanto utili quanto semplici da programmare. L’idea, infatti, nacque nel 1998 dalla mente di un certo Arlo Rose, il quale, prendendo spunto dalle skin applicabili ai lettori di mp3, pensò di creare un’interfaccia per qualsiasi altra informazione da visualizzare nel desktop. Basandosi sul nome di un programma di skin per l’interfaccia del Mac OS chiamato Kaleidoscope, egli coniò il termine Konfabulator e propose la sua idea agli altri sviluppatori; per quattro lunghi anni nessuno lo appoggiò fin quando un tale Perry Clarke decise di collaborare con lui, interessandosi al progetto. Il 10 febbraio del 2003, i due lanciarono la prima versione shareware di Konfabulator per Mac OS X 10.2 al prezzo di 24,95$; un programma che gestiva i vari “sottoprogrammi” chiamati, appunto, Widgets. Mi ricordo che scaricai la versione di prova e ne rimasi colpito sia per l’estetica che per l’effettiva utilità. Ventuno mesi più tardi uscì la versione per Windows e il 25 luglio del 2005 l’applicazione fu venduta a Yahoo! e divenne freeware. Nel frattempo, il 29 Aprile della stesso anno, veniva messo in vendita il Mac OS X 10.4 Tiger, il quale era il primo Sistema Operativo che includeva una propria rivisitazione della fortunata applicazione Konfabulator, battezzandola con il nome Dashboard. Successivamente uscirono anche le versioni per GNOME (gDesklets) e i Gadgets per Windows Vista nel 2007, chiamati così affinché nessuno potesse dire che erano copiati dal Mac (e chi potrebbe mai dire una cosa del genere!?). Peccato che nelle zone di Redmond nessun sviluppatore del Vista sapeva che in effetti la Apple chiamava i Widgets, durante le fasi beta del Tiger, “Gadget” e solo la versione definitiva riportava il fatidico e definitivo nome di “Widgets”!

La diatriba

Con l’avvento di Mac OS X Tiger si vennero a formare due filoni di pensiero: l’uno definiva la Dashboard una spudorata copia di Konfabulator, l’altro, invece, girava la frittata spiegando che, in effetti, l’idea di base si trovava già nei primi Sistemi Operativi Apple Macintosh del 1984, nei quali vi era una sorta di “collezione” di accessori della scrivania (Desk Accessories, per l’appunto) che includevano funzioni come la calcolatrice e l’orologio. Ebbene, in un suo articolo riguardo il Sistema Operativo Tiger, John Siracusa (gira e rigira sono sempre di origini italiane!) fece chiarezza dimostrando che i creatori di Konfabulator non erano in possesso di alcun brevetto e inoltre i Widgets della Apple presentavano delle differenze sostanziali, prima fra tutte il linguaggio di programmazione (XML e JavaScript per Konfabulator, HTML e CSS con JavaScript per Dashboard) che permetteva all’applicazione per Mac di dialogare bene con il browser Safari. Quando si dice “mettere la parola fine”…

What is Konfabulator? Konfabulator is a JavaScript runtime engine for Windows and Mac OS X that lets you run little files called Widgets that can do pretty much whatever you want them to. Widgets can be alarm clocks, calculators, can tell you your WiFi signal strength, will fetch the latest stock quotes for your preferred symbols, and even give your current local weather. You will need to download the Konfabulator software, and then select the Widget(s) you like. Note: Konfabulator requires Windows XP or 2000, or Mac OS 10.2 or greater — Select whichever download would be the appropriate one for your system.

Use at your own risk!

A few weeks ago, I wrote about the safety of extensions to Web browsers. In the meantime, the landscape of web browsing has changed a lot, at least for developers. Why ? Because of Adobe Air, Microsoft Silverlight and Mozilla Prism, three tools used to put the web on your desktop.

While none of these products is actually new — they are all renamed versions of things that have been hanging out in the air for some time — and none of these products is branded as web browsers, well, that’s exactly what they are. Of course, whenever new browser or browser-like products appear, one of the main questions should be: how safe are they ?

Let’s take a somewhat deeper look.

What is it ?

Air, Silverlight and Prism are branded under many qualifications, from “Ajax desktop integration tools” to “Rich interactive web experience” to “Rich internet applications on the desktop”. In other words, these applications are just web browsers without the buttons. Air is built on top of Adobe Flash and WebKit (the core of Safari and Konqueror), Silverlight is built on top of .Net and — depending on the platform — either Internet Explorer, Firefox or Safari, while Prism is built on top of Gecko (the core of Firefox and Thunderbird). All three products are intended for web developers who want to build desktop applications or to make web pages look and feel like desktop applications.

If this sounds less glamorous than the advertising, it’s perhaps because this kind of things have been around for some time:

• this is the exact premise of Apple’s Dashboard, which has been available for about 2-1/2 years, and is based on Apple’s Safari ;
• before that, this has been the premise of Yahoo! Widgets (née Konfabulator), the inspiration behind Dashboard ;
• before that, this has been one of the driving ideas behind XUL and Gecko themselves, the technology behind Firefox, Thunderbird, Netscape Navigator 6… ;
• still before that, this is quite close to the whole idea of browsers sidebars, as available in just about any browser since at least 2002 ;
• even before that, there was Windows Active Desktop, launched around 1997 and forgotten not much later;
• Windows Active Desktop itself was prompted as a counter-attack to Netscape’s 1996 Constellation / Netcaster — I believe that’s where it all began but I might be wrong.

Now, what is true is that this range of tools will make it much easier for web developers to build desktop applications and will bring some long-needed web controls to desktop developers. While none of the technology is actually new, from the user’s point of view, it might still bring something like a revolution, by blurring even more the barriers between the desktop and the network. Or, in other words “The network is the computer.”

At this point, perhaps I should consider mentioning Sun Microsystem’s JavaFX. JavaFX is marketed essentially as Prism, Air or Silverlight, with essentially the same promises (in this case, under the label “Rich Internet Applications”). However, after a few hours of experimenting with JavaFX, the technology seems totally unrelated. Neither superior nor inferior, just unrelated, except by a marketing ploy. In a few words: it’s Java, with an alternative beginner-friendly syntax, but still using Swing and not sporting anything specially Internet. So it’s out of today’s game.

What’s worst it can do ?

Let’s get one thing out of the way: while I’m going to mention now and then what a developer may do with one tool or with another, what I’m interesting in is not the feature-set but the safety of tools. To which tool should you trust your desktop, if any ? Or, taken from the opposite point of view, what’s the worst that Air-, Silverlight- or Prism-applications can do to you and your computer if you use them for your desktop ?

In this survey, I will not take into account the possibility of bugs in Air, Silverlight or Prism themselves. Rather, I will concentrate on malicious or ill-programmed applications for Air/Silverlight/Prism.

Adobe Air

Air’s official documentation and SDK are easy to find on Adobe’s site. Air runs under Windows and MacOS X and a Linux port is under way. Air applications are built with HTML, Flash and CSS (for user interface) and JavaScript / ActionScript with XMLHttpRequest (for interactivity and network communication). To this day, all these technologies are rumored safe for desktop use. Let’s look a bit deeper…

“AIR applications run with the same user privileges as native applications. In general, these privileges allow for broad access to operating system capabilities such as reading and writing files, starting applications, drawing to the screen, communicating with the network, etc. Operating system restrictions that apply to native applications, such as user-specific privileges, equally apply to AIR applications.“

(extract from Air’s documentation)

A few pages further in the documentation, it turns out that the developer may decide to run parts of its application in sandboxes, i.e. without giving them access to the whole operating system, and other parts with all privileges. It is up to the developer to decide how to enforce that security, which parts of the application run in which sandbox, and to make sure that interactions between the sandboxes will not compromise the security of the system.

I haven’t had time to play too much with Air. However, just by reading the documentation, it seems that:

• an Air application can be made to look just like any other application

• a malicious Air application can take control of your session and do just as much harm as any other malicious application, which means a lot if you’re under Windows, a bit less under Mac OS X or Linux ;

• a malicious Air application can pretend to be your password manager, your web browser, or any other application that may be legitimately interested in your passwords or you bank account number, and may record or send these informations to a malicious agent

• if a non-malicious but trivial or well-programmed Air application depends on a website, and this website itself is malicious, perhaps because it has been somehow hijacked, the hijackers could not use this website should not be able to take control of your session

• if a non-malicious but complex and ill-programmed Air application depends on a malicious website, this website can inject code in the application and get that application to run the malicious code, hence again taking control of your session

• a nice Air application may be automatically upgraded to a not-so-nice Air application by a malicious developer or anyone who takes the control of the developer’s website.

Note that Air contains a few interesting techniques to make life harder for people who may wish to inject code in an Air application from a malicious website. That is, the untrusted world may not execute privileged code unless this code has been made explicitly available by so-called “sandbox bridges.” According to the documentation, other manners of injecting code are forbidden (eval, innerHTML…). However, if the documentation is to be trusted, these interdictions are way too limited to keep a decided malicious developer at bay: once some data falls into the hands of untrusted code, the untrusted code seems allowed to modify that data at will, which may include changing the behavior of code if that data contains code. It is probably possible to use automatic checking tools (such as customized JSLint or JSTify) to guarantee that this will not happen.

Bottom line

Unsurprisingly, an AIR application is just as dangerous as any other application. More so, in fact, as the security of the application may additionally depend on the security of a distant website.

In addition, my experience with the community of web developers tells me that, at least in a first time, the future community of Air developers will be interested more in features than in safety and will produce a number of unsafe-but-useful libraries that will have time to spread and be commonly used before their weaknesses are understood. The only thing that could limit this would be a comprehensive library of safe code provided with Air. While Air’s standard library contains a number of interesting features, there seems to be no safe code to give access to unsafe features.

Silverlight

Silverlight’s official documentation is lacking and the SDK contains strictly nothing to read. That is, there seems to be more than enough tutorials to help people get started, but technical issues seem mostly non-covered, possibly because people who are expected to understand anything too technical are also presumed to be proficient with .Net and to start digging on .Net. Consequently, the informations presented here have been gathered from around Microsoft’s Developer Library and Shawn Farkas’s blog — Shawn Farkas is one of the developers of Silverlight.

Silverlight runs under Windows and MacOS X, in addition to which there’s an on-going open-source cross-platform port known as Moonlight. Silverlight applications are built with HTML, XAML and CSS (for user interface) and C#, JavaScript or any other .Net language (for interactivity and network communications). Again, all these technologies are rumored safe for desktop use. Let’s look a bit deeper.

From Shawn Farkas’ explanations:

“All applications written for Silverlight are security transparent. This means that they cannot:

• Contain unverifiable code
• Call native code directly

Silverlight applications can access public methods exposed by platform assemblies which are either:

• Security transparent (neither the defining type nor the method has any security attributes)
• Security safe critical (the method has a SecuritySafeCriticalAttribute)

Silverlight applications may contain types which derive from:

• Other types defined in the application
• Unsealed, public, security transparent types and interfaces defined by the platform

Silverlight applications may contain types which override virtual methods and implements interface methods which are:

• Defined in the application itself
• Defined by the platform and are transparent or safe critical”

What this seems to mean is that a Silverlight application may never proceed with any operation that isn’t considered as safe by whoever introduced that operation in the first place. Taken to its logical conclusion, this would mean that no Silverlight application could ever read or modify an arbitrary file. Unfortunately, this is not believable — especially from Microsoft — as this policy would make Silverlight much safer but also much poorer in terms of features than the competition. Therefore, I understand the description to mean that most Silverlight applications will, in fact, be composed of two things: an “application written for Silverlight” (the equivalent of the Air sandboxed code, as seen above) and some code “defined by the platform” (the equivalent or privileged code).

From this conclusion, let’s deduce a few facts:

• a Silverlight application can be made to look just like any other application
• a malicious Silverlight application can take control of your session and do just as much harm as any other malicious application, which means a lot since you’re under Windows ;
• a malicious Silverlight application can pretend to be your password manager, your web browser, or any other application that may be legitimately interested in your passwords or you bank account number, and may record or send these informations to a malicious agent
• if a non-malicious Silverlight application depends on a website, and this website itself is malicious, perhaps because it has been somehow hijacked, or because your network connection has been hijacked, the hijackers could not use this website should not be able to take control of your session (more details on this later)
• if a non-malicious but ill-programmed Silverlight application depends on a website, and this website itself is malicious, it seems that the hijackers could trick your Silverlight application into pretending to be your password manager, etc. (more on this later)
• a nice Silverlight application may be automatically upgraded to a not-so-nice Silverlight application by a malicious developer or anyone who takes the control of the developer’s website.

Again, from Shawn Farkas’s explanations:

“Silverlight applications [...] may only call transparent or safe critical APIs exposed from the platform.”

Among other things, this means, unsurprisingly, that privileged code may be made available for use by untrusted code in much the same way as in Air. The big difference is that it seems impossible for the untrusted code to modify privileged code to execute code containing operations considered unsafe. It still seems that ill-programmed applications could be hijacked by a website into executing code considered safe, though, although with much more difficulty than in Air.

Note the keyword: considered. While it’s nearly certain that any operation that will modify a file on your hard drive is considered unsafe, it seems pretty sure than operation that will only open a new window will be considered safe. Guess what I can do just by opening a new window ? Yes, as usual, I can masquerade as your password manager or your bank account manager, take over your passwords and send them to whoever is behind this.

Bottom line

Unsurprisingly, a Silverlight application is just as dangerous as any other application. Less so than an Air application, despite the complexity of the technologies driving Silverlight, but still more than a regular desktop application, as the security of the application may additionally depend on the security of a distant website.

Silverlight developers do start with two additional advantages, though:

• the safe library provided for them is quite vast, which should limit the appearance of unsafe libraries wrt Air or Prism;
• you have to try slightly harder than in Air if you want to write an unsafe library usable by unprivileged code — it’s still more streamlined than in Prism, though.

Prism

Prism isn’t officially available yet, however preview releases are easy to find for Windows, Linux and MacOS X. The MacOS X version is obsolete but should be brought up-to-date any day now. There is little documentation available for the moment, although most of the documentation meant for extension developers could be used for developing Prism applications (known for the moment as “Webapp bundles”). Prism webapps are developed using JavaScript and CSS only. Everything else resides on the website.

For this section, I’ve both worked with the documentation of Prism and discussed with Mark Finkle, his main developer. As these discussions gave me a few hints of where Prism is heading, I’m going to subdivide this section between the situation as it is in the current preview release and what it’s going to be when Prism reaches 1.0.

Today

“Webapp bundles, as defined today, can and usually do include a JS (webapp.js) which runs with system privileges. This should be removed, so that starting a webapp bundle does not imply handing over your machine and all the data on it to whoever created or modified the bundle. Ideally, webapp bundles should not be able to do more than a normal webapp can, just run in a slightly different UI (no menu etc.) and in their own process.“

(source: Prism’s documentation)

In the current state, it seems that:

• a Prism application cannot be made to look just like any other application
• a malicious Prism application may take control of your session and do just as much harm as any other malicious application, which means a lot if you’re under Windows, a bit less under Mac OS X or Linux;
• a malicious Prism application cannot pretend to be your password manager, your web browser, or any other application that may be legitimately interested in your passwords or you bank account number
• if a non-malicious but trivial or well-programmed Prism application depends on a website, and this website itself is malicious, perhaps because it has been somehow hijacked, the hijackers could not use this website to take control of your session
• if a non-malicious but complex and ill-programmed Prism application depends on a malicious website, this website can inject code in the application and get that application to run the malicious code, hence taking control of your session
• a nice Prism application cannot be automatically upgraded to a not-so-nice Prism application by a malicious developer or anyone who takes the control of the developer’s website.

It is possible to make privileged code (the part of the Prism application that gets installed on your hard drive) communicate with untrusted code (the part of the Prism application that resides on the distant server) through messages — the mechanism looks cleaner, less accident-prone and easier to check automatically than in Air but ultimately equivalent. If the data sent between these codes contains code itself, it may be overwritten at will by malicious unprivileged code, which can result in the Prism application, if it’s poorly programmed, being fully hijacked.

Today’s bottom line

Unsurprisingly, a Prism application is just as dangerous as an Air application. Here, also, my experience with the community of web developers tells me that we are going to see unsafe libraries being required for a number of applications, hence opening wide doors for applications hijacking.

As of today, Prism applications suffer from :

• a small library of safe tools ;
• a large library of unsafe tools ;
• the fact that it’s very easy to write unsafe code — well, just as easy as in Air and much more than Silverlight.

As far as security is concerned, the result ends up slightly worse off than Air. However, the story doesn’t stop here.

Tomorrow

Prism is evolving a lot. In particular, Mark Finkle insists that, while there is only little security for the current prototype, the upcoming versions will change the situation completely. In fact, there’s a huge difference between the aims of Air, Silverlight and Prism — while that difference is not visible yet, it should become evident with the next prototypes. To summarize, Silverlight and Air are full programming platforms, which means that they attempt to provide developers with all the tools to write any application — with all the unsafety it implies. On the other hand, Prism is a super-bookmark that lets you use a web application in a convenient way, without the clutter of the browser’s user interface. While Silverlight could be conceivably used to write the next Windows Update or Microsoft Word and Air could be conceivably used to write the next Adobe Reader or Acrobat Pro, Prism does not need and does not want such power, rather being designed for the next Google Mail, Google Office or aMSN — the examples come from me, by the way, so don’t try to read Mark Finkle’s mind from this blog entry.

“we want the web application (written in web content) to handle as much as possible – using open web technologies“

(IRC conversation with Mark Finkle — I promise I’m going to stop quoting him)

Technically, this means that Prism applications will lose access to XPCom. The direct consequence will be that web applications should be exactly as safe as the corresponding version of Firefox. Possibly somewhat safer, actually, due to the fact that Prism will be lighter than Firefox.

What follows is the result of a discussion, so don’t take it for guaranteed. From what I gather, in the future :

• a Prism application cannot look just like any other application
• a malicious Prism application cannot take control of your session ;
• a malicious Prism application cannot pretend to be your password manager, your web browser, or any other application that may be legitimately interested in your passwords or you bank account number ;
• a malicious website can theoretically inject code into Prism — but not without the help of Prism ;
• a nice Prism application cannot be automatically upgraded to a not-so-nice Prism application by a malicious developer or anyone who takes the control of the developer’s website.

Privileged code can read and write unprivileged code, working essentially as a pre-processor or, say, GreaseMonkey. There is still a possibility to use this mechanism to inject code from the website to the Prism application, but that looks impossible to do by accident — that is, unless the Prism application has been designed specifically to accept injection, there is little a malicious website could do. It looks quite possible to write a customized JSLint or a JSTify module to automatically detect Prism applications specifically designed to accept injection and reject them.

In other words, out of the box, Prism applications should be completely safe. The price of this safety being that the most complex Air or Silverlight applications will be richer in terms of desktop-side features than Prism. This won’t prevent Prism developers from writing a tool comparable to, say, Microsoft Office, or an application used by your local tax office, but it will prevent them from writing a tool to index files on your hard drive or to edit videos.

Note that Prism itself will support an extension mechanism, which has the potential to change everything in terms of security and features. That is, Prism extensions, just like Firefox extensions, are a mechanism that will allow adding arbitrary features to the whole platform, including anything unsafe. I’ve already discussed the danger of Firefox extensions in a previous blog entry, so I’m not going to repeat myself here. If extensions are taken into account, the safety of Prism is as bad as that of Air or Silverlight. The good point is that, by opposition to what happens in Air or Silverlight, Prism extensions will be clearly separated from Prism applications: the install mechanism will be different and will warn the user about potential dangers of extensions.

Tomorrow’s bottom line

A Prism application that doesn’t rely on extensions should be absolutely safe. The fact that Prism somewhat discourages the installation of extensions is a good point but it may not end up being sufficient to prevent the web developer community from developing a whole bunch of unsafe libraries, eventually leading to a situation equivalent to that of Air.

Dashboard

As I mentioned, before the three stars of the day, there was Dashboard. Dashboard is available for Mac OS X only and comes bundled with the operating system. Dashboard applications, or “widgets”, are developed using HTML and CSS (for the interface), JavaScript and — although that’s not widely known — Objective-C, AppleScript, plus the Unix command-line (for the interactivity). There is some documentation on Apple’s website, but nothing precise on security.

While HTML, CSS and JavaScript are expected to be safe, Objective-C, AppleScript or Unix commands give Dashboard widgets the ability to do just about anything.

• a Dashboard widget cannot be made to look just like any other application, as it resides on a different layer
• a malicious Dashboard widget can take control of your session and do just as much harm as any other malicious application ;
• a malicious Dashboard widget cannot pretend to be your password manager, your web browser, or any other application that may be legitimately interested in your passwords or you bank account number, and may record or send these informations to a malicious agent
• I haven’t been able to assert if a distant website may hijack an ill-programmed Dashboard widget.

Every code in Dashboard is privileged. There is no security involved.

Konfabulator

Last review of this list, Konfabulator, sorry, Yahoo! Widgets (let’s just call it Y!W, even if it starts sounding religious). Y!W, the immediate predecessor of Dashboard, is available for Windows and MacOS X. Y!W applications (or “widgets”) are developed using HTML and CSS (for the user interface) and JavaScript and — that’s not widely known — any external command (for interactivity).

While HTML, CSS and JavaScript are expected to be safe, commands give Y!H widgets the ability to do just about anything. In addition, this particular version of JavaScript has access to a rather comprehensive unsafe library.

• a Y!H widget can be made to look just like any other application
• a malicious Y!H widget can take control of your session and do just as much harm as any other malicious application ;
• a malicious Y!H widget can pretend to be your password manager, your web browser, or any other application that may be legitimately interested in your passwords or you bank account number, and may record or send these informations to a malicious agent
• I haven’t been able to assert if a distant website may hijack an ill-programmed Y!H widget.

Every code in Y!H is privileged. There is no security involved.

So, should you ?

The question asked in the beginning of this post was whether you could trust your desktop to Air, Silverlight or Prism. Before judging, let’s summarize:

• A randomly downloaded Air application can do anything and masquerade as any other application.
• An Air application you trust could still be hijacked and could be dangerous even if does not contain privileged code.
• A randomly downloaded Silverlight application can do anything and masquerade as any other application.
• A Silverlight application you trust could still be hijacked, although with more difficulty than Air, and could be dangerous, although less so than an Air application.
• A current Prism application can do anything but can’t masquerade as any other application.
• A current Prism application you trust could theoretically be hijacked, although with more difficulty than Air, and could be dangerous, just as Air.
• A future Prism application will only be able to do browser stuff and won’t be able to masquerade as any other application.
• A future Prism application will be nearly impossible to hijack and won’t be dangerous even if hijacked.
• A Prism extension, on the other hand, is just as dangerous as a Silverlight or Air application.
• A randomly downloaded Dashboard widget can do anything but can’t masquerade as any other application.
• A randomly downloaded Yahoo! widget can do anything and can masquerade as any other application.

In other words, at the moment, everything is unsafe.

Now, if you’re the kind of user who doesn’t care about security/only downloads applications from sites you trust very much/is pretty sure that the developers of a given application are both honest and careful, any of these technologies should be acceptable for you and you probably ought to go for the most feature-rich. Silverlight and Dashboard will be the most feature-rich respectively for Windows and MacOS X, while Linux users will be happy with either the current version of Prism, the future versions of Prism with extensions or the equally unsafe gDesklets or SuperKaramba.

If, on the other hand, you’re the kind of user who considers that the Net is a wild place with a few malicious people and lots would-be developers who ought to learn one or two things about security before disseminating their creations, and if you are willing to pass the opportunity to see something cool if it means keeping your system safer, you should stick with future Prism web applications, without extensions. Or, if you can manage to check every Air/Silverlight application and reject those that contain privileged code, you should be ok.

This last comment is not benign, mind you. It’s only a matter of time before tools appear that check Firefox/Prism extensions/Air/Silverlight privileged code and reject anything that doesn’t comply with the way you want your computer to behave. I’m working on what could serve as the base layers of such a tool for extensions and Air, anti-virus writers are bound to do the same thing for Silverlight.

Últimament he estat usant prou Konfabulator (serà perque m’he acostumat al Dashboard del Mac OS X).
Per als no-iniciats, es tracta d’un segon escriptori anomentat Konsposé on posem widgets (miniaplicacions) que fan tarees molt concretes. Jo tinc posades algunes: una que em diu el temps a Alzira, una que simula uns post-it’s, un calendari i un amb la llista de coses a fer.
Es poden baixar molts widgets desde el propi programa, hi ha per totes les classes (visors de temperatura, comptes enrere per a presentacions d’Apple, etc.).
Jo abans usava el Google Desktop Search, que en compte de widgets són gadgets, però entre que l’index que feia no m’agradava gens (realment no l’usava) i no tenies la flexibilitat suficient per posar les coses on tu volies, em vaig decidir canviar.

No, this is not a spoiler posting. I’m pondering what other of the hidden features might leap out at us. What they might (or hopefully, might not) be. The role of Apple’s Developers and how that could change in the near future based on things like Google Gears. The real gem of my screed is at the very end.

Please, consider adding the gwhiz blog to your RSS feed reading. Thanks!

First up? Everyone’s favorite (and hopefully, first) non-Apple app they run to when they buy a new Mac… QuickSilver. Apple has this quirky habit of glomming onto other people’s REALLY good ideas and making them, well, their own. I’m specifcally calling to mind things like Watson (aka Apple’s Sherlock), Konfabulator (aka Widgets) or VirtueDesktop (aka Leopard Spaces). I’m sure there are more which are not top of mind. I can only hope Apple doesn’t do to Black Tree’s QuickSilver or Delicious Monster what they’ve done to these other of their innovative developers.

Have to plead ignorance here… Do Sun, Microsoft or Linux pull these kinds of stunts with their OS builds? Swiping from their developers I mean…

The flip side of that is Apple does do right by some of their developers. CoverFlow for instance. Which seems to be taking more and more prominent positioning in their lineup with the new CoverFlow powered Finder.

Second up – Open Sourcing. When Apple’s not being strongly influenced by the innovations of others (pat on back, nicely politely put) they’re doing some MARVELOUS stuff with open source bedrock. CalDAV. Mongrel. SquirrelMail. Ruby. Java. Blojsom. Some of the Teams components in Leopard Server we’ve been told in the public forum are based on lots of open source goodness. So, please, despite all my dissing on Apple this week… I can diss my own family. Someone else pulls that crap and I’m all over them I LOVE Apple. I simply want to see them do right by their developers. I recall someone suggesting Apple’s coming up short in this regard (must look at my CoComment threads - yep, it was The Scobleizer). I happen to think that’s spot on the money.

Which brings me to the third and final point. I’ve been an Apple Developer since I left Apple in 1994. Before that I was firmly in the camp of Apple’s internal developers as one of their “Systems Engineers” (what a GREAT job during such a DARK period… jogs self back to present). Ahem. We were secretive then and that was under Spindler and Amelio. I can only imagine how things have changed under Mr. We Will NEVER Do A Video Ipod. That’s all good and fine and I can certainly appreciate the mystique that promotes. Still, when you’re a developer and you’re trying to build the next best thing to page swapping… well, secrets kinda crimp your style.

This is one of the dirty little secrets of the Mac developer community. We have to route around Apple. Read another way, we have to route around the damage. On the one hand they say they love their developers. And, to a degree I believe them. But, then they do things that don’t match up with their declaration of love. The big example I wave around is probably the most important. I’m not the worlds best coder. I’m largely self-taught. Once upon a time I was among the first hundred or so Newton Messagepad developers. Even then (much as today) there has not been a place for Apple’s Developers to swap experience outside of the WWDC meeting. (EDIT: appears I didn’t finish out the thought… Apple is putting their developers in a position to go akimbo to their NDAs by talking outside of channels)

Why, in this day and age, can’t Apple break off a nice little chunk of their Web Crossing Forum software and make a petri dish for us? That way the conversation is contained in a hermetically sealed space. Apple can control the inning and outing of information. And, most importantly, we developers can discuss stuff like Leopard’s upcoming features under the watchful eye of Apple (but we both know I was thinking Mordor). I want to become a better developer. I want to hire people who share their coding talents with others (net “givers”, not net “takers”).

Anyway… I’m looking at Leopard (OSX in general) imagining all it can become and the pace at which it could get there. Apple’s not doing the platform any favors and they risk losing fine and innovative developers like Mark at ClamXav (and aspiring ones like me) who are expanding the utility of the platform more out of a sense of cause and community than anything. Hopefully, Apple swings closer to the middle for the sake of the platform rather than hang out in the relative safety of the cloister in Cupertino.

One more thing (ouch!)… IF Apple’s approach to developing for the iPhone is really (and I’m skeptical) centered on web deployable apps AND Google’s Gears is emerging as the take-your-web-apps-offline king of the heap AND Google and Apple are deep under the sheets THEN don’t you think it is reasonable to expect some day things like the iPhone and OSX even will no longer require an installed app? Think about that one and get back to me.

I never really liked Yahoo, I just tolerated it. And was saddened when they acquired Konfabulator (now with an ultra lame name : Yahoo Widget Engine) and Flickr. I was a Google flag waver.

Then my iTools (uh – I mean, DotMac) account expired due to my refusal of paying $99 a year. My Macs started getting out of sync…

At the same time I’ve been somewhat playing with the Yahoolized version of Konfabulator, then they released what to me looks like a NeXT Dock for your widgets – with the widgets now fully tied in with Yahoo such as the Day Planner with Yahoo Calendar, Notepad and the Flickr Widget that allows you to upload pics directly into your Flickr account, I decided to give them a second chance.

I resurrected an old yahoo account that has premium services left over from when I had Yahoo SBC DSL to tie everything in and get the full experience. Together with disposable email addresses (premium option), I must say I’m really starting to enjoy it again.

I simply install Konfabulator (Yahoo Widget Engine, sorry – I refuse to call it by that super-lame name!) and the Yahoo Toolbar on my Firefox Browser on all my computers – Mac or PC and have instant access to my schedule, notes, contacts, etc.

I only wish I would have chosen a better base name for my disposable email addresses before it locked me down to it (you can only change it once).

The only real problem I see is with Yahoo’s latest implementation of Mail – it hides advanced features, such as the ability to use disposable email addresses (only available with a premium account), having to switch back to the older version of mail.

Want to build your brand cross-platiform but having trouble getting it to happen online? Widgets just may be your answer.

And it’s cost-effective, too.

The Jointblog has been a longtime fan of widgets since first discovering Konfabulator in 2004 (later purchased by Yahoo! a year ago). With the release of Window’s new Vista platform, PC users will get a whole new array of widget options (also known as “gadgets”) for the desktop which will pull more Internet activity off of web browsers and onto these customized mini-applications.

Widgets were one of several great additions for Mac’s OS X system, epecially for its Dashboard advancements for 10.3 and 10.4 in the last year (expect even more once Leopard 10.5 and the new iPhone are released this summer).

And Google already has invested deeply into widgets, too.

In addition, as WiFi and WiMax helps make the web more accessible with mobile devices and cellphones, widgets will be the key killer app to make the web tolerable to use when mobile.

It’s the perfect bridge technology bringing “old” media into the new media world.

Business 2.0 said “suddenly everything’s coming up widgets.” In November, Newsweek proclaimed 2007 to be the Year of the Widget and we couldn’t agree more. Last month, West Coast wireless carrier AllTel previewed its new widget-handy cellphone tools and received rave reviews for it at January’s CES.

Most powerfully, these widgets create focused user experiences giving exactly desired content immediately, on-demand, 24/7, when the user wants it.

For content owners, it also provides an advertising opportunity that can be built right into the widget app.

It’s the media trend the Jointblog continues anticipating to grow in significance.

The big question: will traditional media sources such a radio, TV, newspapers and magazines be too slow to notice or will they see the low-cost, ease-of-use opportunity in time?

If radio could figure out its DRM and AFTRA issues, it could create the perfect bridge to build fast online tuning. For example, RadioSherpa’s radio badges.

What’s going on with your radio station this week? On your morning show? Latest contests and promotions? How about for your market’s entire cluster of radio stations? It can all be done on one widget you build. Auomatically, through RSS and other feeders.

Nice and easy. For you. And, more importantly, for your listeners’ digital online needs.

Good follow-up article: What’s Up With Widgets?

For a quick review of why widgets matter now, here’s a 2-minute YouTube/Engadget clip explaining the immediate value of widgets and why you should consider offering customized widgets for your own users to use, install and even embed into their blogs and websites (which, if done, can serve as a free form of marketing for you):