François Nonnenmacher (EN)

The Content Management System of my dreams (part 3) — Static Site Generators with a side of toml/yaml soup

2023-02-08T02:48:17Z

Previously on: The trouble with dynamic publishing.
Upcoming next: Let's dream!

Reinventing the wheel

Those same developers who dismissed static publishing as out, were starting to feel le vent du boulet. More and more people were coming to bother them about pesky cache and performance issues. They suddenly re-discovered the benefits of serving static files.

Very quickly, the traditional “Hello World!” first exercice when playing with a new language turned into writing your own static site generator, crunching Markdown files because HTML is still out for some reason (after all, we are talking about people who never use a rich text editor, live in a code editor and see no problem generating HTML and CSS with JavaScript, there is some logic here).

But they stopped at “here are some markdown files with fancy front matter, mix that with a few templates accompagnied with a toml/yaml soup and voilà, problem solved!”

This is why we now have a gazillion Static Site Generators made by developers, for their own benefit (et encore), as an exercize to learn new languages.

Markdown-eating Static Site Generators are a niche inside a niche.
They are not about managing content. They are about turning files in a directory tree of files into the a similar hierarchy of files ready to serve, with very little possibilities of developping a more complex one besides iterating along taxonomies.
This is the familiar setting for a developper. Not so much for everyone else. This is also why the SSG-powered sites lying around are mostly software or API documentations made by developers for other developers.

And then comes another layer above that.

Because SSGs are, to make an understatement, not made for content editors, here comes a flurry of web frontends that try to hide Markdown (if you're lucky to have a WYSIWYG preview), show the metadata in a decent way into form fields (with the extra benefit of some validation which you don't have if you edit the source directly), and isolate the rest of us of the jargon and complexity of git (no normal person would naturally understand “commit, MR, merge” as “save, ask for review, publish”, nor should they have to).

And that market is in a sorry state. Just look at the Front ends to Hugo. All are abandonned, not supported, or too complex to integrate for too few advantages to bother. And the commercial alternatives have pretty much all opted for the Very Bad Idea™ of forcing one to put themselves and their content into the hands of an external company somewhere in this fuzzy cloud.

I'll let you read this and picture yourself learning one day that you cannot edit your own web site anymore.

A Very Bad Idea™, indeed.

The best tool I have found so far is a plugin for VS Code. There is no escaping the Mordor furnaces SSGs were born into. I could swear it is a conspiracy to turn everybody into a git-loving developer (this one will cost me some karma points :-)

Some light at the end of the tunnel?

I see some recent progress with people who understand that content management is for content editors who need a content management system that allows them to do way more than organizing text files and a few images in folders, and that publishing content on the web is something different, that can be separated from the CMS (or at least intelligently articulated together). For example, a CMS might benefit from using a database, while the published site has no need for it.

And these content editors want to be able to manage their taxonomies, media, menus, styles, specialized blocks, semantic content, accessibility, forms, URLs, SEO, publishing process, moderation etc. as well as search and manipulate them in a web browser, anywhere, anytime. Some even want a Rich Text editor experience (how dare they?). And all this without having to pay for a specialized developer constantly on call anytime they add a new content type. For the most part of the life of their sites, they might sometimes need to work with web designers on styles and layout, again without having to add a developer in the loop at each time.

As I mentionned in the first part, Movable Type has been doing this since 2000, and even offers the ability to publish both static and dynamic pages on the same site. Unplug the database and MT, the site works just fine with a simple web server.

Enough for the snarky rant. Let's dream a little!

(To be continued…)

Previously on: The trouble with dynamic publishing.
Upcoming next: Lets dream!

The Content Management System of my dreams (part 4) — Lets dream!

2023-02-08T02:07:48Z

Previously on: Static Site Generators with a side of toml/yaml soup.

If you have read this whole series and reached this last episode of The Content Management System of my dreams, I thank you! If not, while they provide some background of the sorry state of current Content Managment Systems and Static Sites Generators, they are not a mandatory reading if you are just looking for the specifications of what would be the best CMS ever (at least in my dreams).

Now…

Lets dream!

TL;DR: The Content Management System of my dreams allows easy web content management for editors, easy theming for designers, and publishing the best performing websites using the least amount of human and hardware ressources as possible.

The ultimate CMS specifications

This CMS:

is open source and can be self-hosted (I'd prefer it free, freemium even for extra value added outside this list, commercial license is OK)
runs self-hosted on Linux
is architecturally separated from the web server, it makes no assumption regarding the web server and its concerns, it does not serve public-facing content unless asked to (like handling comments or searches). It does not take down the site with it for serving a file
produces files on a disk and an easy and fast way to publish those on the web. Whether those files are “static” or “dynamic” is not a concern of the CMS but of the web server
has a UI and UX tailored for non-technical users (content contributors, editors and non-specialized web designers)
offers a Rich Text and WYSIWYG editor that hides the underlying markup (both HTML and Mardown as a minimum), supports semantic and accessible content, and provides site-defined validation of metadata and content (e.g. allow/disallow use of certain HTML tags and attributes)
allows to manage everything from a web browser, including site design, templates, content types, taxonomies, metadata and validation rules, system configuration. File management on disk with a text editor is a nice to have, not a requirement
provides fine grained custom roles and permissions management for users processes (e.g. for content editing: contribution, moderation, publication etc.)
handles versionning of changes with rollback (using git is good provided it is completly transparent for the non technical end users)
provides a human readable journal of all actions (at a minimum of any change to any data)
provides search and replace capability for any textual file managed by it (this includes templates)
provides a search engine for the website or means to plug in any external search engine
allows customization or its interface, behavior and template features via configuration or plugins
provides architectural security by forbiding a template designer or an external plugin to bypass the content management layer
provides theming capability
has top notch internationalization support (supporting Russian is a good Litmus test) that handles source changes nicely and actually helps translators
is easy to upgrade without the risk of breaking things
has no mandatory dependancy to an external service (providing a plugins market is fine, as long as not using it does not restrict any feature)
forces no specific database engine (e.g. if it requires a database, I want to have the choice between Postgres and MySQL)
provides a complete API (at minimum a Data API to manage content)
provides backup and restore facilities for everything it stores (content, templates, configuration etc.)
has a fast and smart template architecture that knows where and when to regenerate files according to what content is changed. It does not force blind full rebuilds for a single change. It provides template caching and inclusions for easier templating and faster rebuilds

In story form:

What I want	CMS requirements	Story
Manage any kind of files the way I want	Make no assumptions on the types of files and directory structure	While the CMS allows me to manage files, it is not involved in serving those on the web. Whether I want the CMS to generate HTML, PDF, PHP, text etc. this is not its concern. However I want to organise those files on disk, basically my site structure, is my business.
Allow me to freely use any valid URL, with my own schemas and validations	Make no assumptions on the site structure and URLs. The CMS routes have no bearing on the website routes.	I want to be able to define the entirety of the site URLs without unnecessary constraints from the CMS. OK: check that URLs are unique Not OK: force me to use a specific way of generating a list, or serving multilanguages sites Viewed another way: if I move from another CMS, the new site can work with the same exact URLs (unless technically impossible because the previous CMS has specific URLs).
My site must work^(*) behind just a web server, even if the CMS is down or if I want a strict separation between both	Have no role in serving public content, unless specifically used for	The CMS can be totally separated from the website if required. It does not serve content unless I decide to use a dynamic call to it (like the result of a search). It does not impose any constraint on the public site web server (typically WordPress and CMS rules in .htaccess files are out). (*) Losing some CMS-provided capability (like search) is acceptable as long as I chose to use them.
I can manage any number of sites, independant or related, from the same dashboard	Related sites can be grouped hierarchically	Provide the means to nest related sites and a cascade for templates to simplify site design (e.g. if a template does not exist in the child site, defer to the parent template, or a system-wide one).
I can change the site layout, design, content types, custom fields etc. without needing a code developer	Everyday changes require zero development	All content and design concerns can be managed through the CMS. Editors and designers can use the web UI to do anything they need. A CMS developer should never be needed during the normal life of the website, except when it makes sense (e.g. developing a plugin).
I can manage any custom data and generate any kind of files with it	Provide custom content types, taxonomies, fields etc., and a template engine capable of generating anything from the data	Make no assumption whatsoever about the generated files. Provide a template engine that takes custom data and generate files according to a custom routing: indexes, individual files, lists of files with custom URLs and custom facets derived from custom data.

Wait, is this only a dream?

It is not only feasible, it has been available for decades.

Movable Type has been providing pretty much all these features since 2000. The only things it does not do in the laundry list above are: being open source, being usable by anyone, I18n support, no specific database engine (it forces use of MySQL). Those do not qualify as dreams.

If you are reading this as a CMS software editor and do not know Movable Type and its architecture, you are missing something big. Trust me. If your software lacks one key thing from what MT is capable of, especially its really well thought architecture, you are missing something.

So why not use Movable Type?

I still do for a few sites. I could still do when it is the perfect match. But the trouble with MT boils down to its editor, Six Apart, a Japanese company that does not help its alien community to expand its usage outside Japan (where it still enjoys the lyon share of the CMS local market). I used to do its French translation, but they stopped asking me to. The only reasonnably up to date documentation is in Japanase and has not been updated in English for quite a while (one becomes tired of reading it through Google Translate). One simply cannot use it without existing knowledge of MT or of Japanese. Six Apart is thriving in Japan, where it enjoys a whooping 88% market share, and is pretty much non existent anywhere else.
It is their business decision, and our loss.

Additional thoughts and advice for CMS developers

Please stop plaguing the world with yet another SSG or “Your CMS in the cloud” horror. Companies are already fighting against bad web agencies that capture their sites to hold them captive. Thinking that you can grab their entire site, content included, as a way to make money migth be a business plan, I call it a Bad Business Folly (both for clients and yourself, this is not a sustainable business).

A requirement could be that the files are managed, under the hood, in a git repository. This would take care of several features: auditable versioning, logs, staging and publishing via a CI, and a lot of other things (not the least this being a possible mandatory requirement for a company). What you absolutely have to do, is provide a user-friendly web UI and experience that isolates the CMS users from git jargon. They want to see “save” not “commit”, “publish” not “merge”, they don't want to hear about a “repository”. We all want to be able to use the best tools for our jobs, those being very different depending on roles. If you are developing a CMS, your real users are not other developers.

Providing a native application for content editors would be very nice to have. It might even be paid-for as a source of revenue for the product development.

Speed matters. In short, the CMS will be doing all the generation of content, server-side (generating content from the client side is a big no-no for me). Be very careful about the performance of rendering a complex site holding hundreds of thousands objects (this is a real world site, which MT takes many hours to process).

Comments

You can join the conversation either on Mastodon or on Twitter.

The Content Management System of my Dreams (part 2) — The trouble with dynamic publishing

2023-02-07T07:09:57Z

Previously on: A little bit of history.
Next in this series: Static Site Generators with a side of toml/yaml soup.

The trouble with dynamic publishing

PHP, Personal Home Page, popularized dynamic publishing. It gave way to blog engines, such as b2, b2evolution, Dotclear. Speaking of history, Movable Type was the number one blog engine loved by geeks and non geeks alike, and the few developers that would not burst in flames in front of Perl like sun-bathing vampires. When Six Apart made a brusque U-turn in killing the Open Source version of MT to pursue questionnable commercial ventures (because it was already well known that it is easier to make money out of other people's content rather than selling a CMS), a certain Matt Mullenweg saw the uproar of the community, took an opportunity by forking b2/cafelog and rebranded it as WordPress. The crowd of bloggers took the bait and followed in droves. In one fell swoop Movable Type faded in history and WordPress took over the world.

Web developers got so enamored with instantaneous “dynamic publishing” that the thought of having to click one more button and wait more than a few seconds to see a code change became unbearable. It would waste their time and by some twisted reasoning they decided that static publishing was old school and dynamic publishing was soooo in.
If it's good for them, it must be good for everyone else, right?

This is why most “dynamic sites” will make a hundred calls to a database just to display one page to one visitor, even if its content never changes. Think about it this way: for each page view you are assembling the whole following scene along with summoning actors, the sea and some clouds for style, instead of just showing a print:

“Ah! But you are doing it wrong! Just put a cache in front of it. Problem solved!”

And there you have two problems. If you need an external cache in front of your CMS, you are doing it wrong.
Cache is one of the most difficult problems in IT. Its invalidation certainly is. If the cache is added in front of the CMS, rather than being managed by the CMS itself (like MT does), you now have two different systems that need more development and maintenance work to handle changes. Your site just became more costly and more difficult to manage.

I have a concrete example of this point. A site is generating its home page dynamically. Because of performance issues (it can take more than 10 seconds to generate the page) an external cache has been added in front of the site. Now the site has a cache invalidation issue that prevents a small promotion block to update when a new item is added in the CMS. The adopted solution consists of throwing an ugly truck of javascript at the visitor's browser and have it make a call to an API to fetch the last two promotions. Yes, this is a “dynamic” site that requires a double request and three computations from two servers and the browser, for each view (at least for the latter when the web server cache works, I won't even talk about caching the API server response). I reckon that this site is wasting at least 10 times the energy and money that is reasonable. And of course absolutely nothing can be done on it, beyond content edition, without a highly specialized developer and a complex deployment process.

Another obvious auto-inflicted problem are performance issues, which are almost always offset by throwing more horsepower in front of the slow carriage. On the Internet, nobody knows we are entertaining a whole menagerie to serve you this page.

At a time where we all must seriously think about our ecological impact and energy use, it is not ok to not take a step back and question every architectural decision that needlessly multiply servers and computing cycles when we should know, and do, better. Lazyness is half-jokingly said to be good in development. This is not funny when it turns into self-centered decisions like switching to a dynamic system because a developer or a content editor does not care to wait while rebuilding a page. A few seconds saved for one person turn into a fantastic waste of time, money and energy for everyone else.

I am serious about these aspects. There are concerning reports, most of them totally out of whack, pointing fingers at the Internet sector for its ecological waste. Let alone suicidal (literally), it would be absolutely hypocritical to dismiss them by cherry-picking where those reports are wrong (that's easy) while we are conveniently forgetting about the ecological impact of some of our decisions. We are responsible, and at some point in the near future, we will be held responsible for our footprint in the climate disaster.

“But I need a dynamic site!”

Do you, really?

Think very hard about that word. What exactly is dynamic on your home page? Are you speaking about that Top News thingy? How often do they change? Are you doing this to satisfy yourself (some content editors have the same proclivity than developers to throw a tantrum because their new content does not appear instantaneously on the site)? Is this a business requirement or a real need of your users?

Of course you might need dynamic pages, for example on backoffice sites, profile pages, pages that are unique to one user. But an outstanding majority of pages floating in the cloud do not need to be recalculated for each view. Even if they contain information that changes sometimes, especially if those information are not unique to any visitor.
And if you do need some dynamic pages, nothing prevents you to publish the rest as static files, especially for the most visited pages of your site.

Here is an easy check point: if your pages show the same content to all visitors then you do not need a dynamic site, regardless of the frequency of its changes.

There is an ironic turn at this point in history. Stay tuned…

Previously on: A little bit of history.
Next in this series: Static Site Generators with a side of toml/yaml soup.

The Content Management System of my Dreams (part 1) — A little bit of history

2023-02-07T04:37:26Z

The world needs more static sites but does not need yet another SSG munching Markdown files.

Each and every time I encounter a new CMS I cry and want to design a new one. No wonder why there is a flurry of half-baked “off-the-shelf” CMS and even more custom ones out there.

Most tech people do not understand the sweet spot between designing and editing a web site, its content management, static vs dynamic publishing, and all their users real needs. Or even who are the real users of the end product.

A little history about a forgotten jewel

In 2001 — that's 22 years ago, about a bazillion years in web time — a tiny two-people company named Six Apart, announced and published Movable Type. It was a blog engine that, from the start, allowed one to publish any number of blogs, related or not down to their domain names, with a 100% web UI that allowed designers, contributors, editors and site visitors to do what they each wanted to do.

Designers could create and manage all templates using a browser. The template markup (MTML) would prevent, by design, obvious security issues by simply not allowing anything outside what it was designed to do: display content — whatever it is, it did not care if it is HTML, PDF, PHP and whatnot — in the site style.
It did not prevent one to extend the application logic, using either a scripting language of their choosing, or developing plugins that would expose new MTML tags.
It introduced a very powerful concept: the ability to publish anything as files, with a template logic allowing to generate index pages (like the home page), listings (e.g. a page listing blog entries, lists generated through custom rules such as tags, categories, date-based archives etc.), and custom shared templates you could use directly in other templates and computed in-place or just once and included either via an internal cache or via Apache and PHP includes.
Cherry on the cake, it included a very smart internal cache system that would allow the designer to tell MT exactly when and where to refresh files. This particular ability, which about no CMS gets right 22 years later, would allow MT to publish a blog in 100% static HTML files with visitors comments added on the fly by republishing only the strict minimum of pages (obviously the commented blog post, along with any page impacted by it, like a page displaying the latest comments or their number).

Yes, 22 years ago we had a CMS that would allow dynamic content on a static site. And even if it needed a database for content management, it would not for serving content. You could shut down your database server, the site would continue to work just fine if no new content needed to be published. If you had to face a spam attack throught comments, you could just disable one file and your site would still work, just without new comments while waiting for the wave to pass.

You know what? Movable Type is still alive and kicking today. Albeit in Japanese and developed by a company that used to care about editors outside Japan.
I have been using it from day one of this blog (né Year II before LLM). I have tried a few times to play with a new CMS only to go back to MT.
I have built several sites, one of them growing over a million PV per day on a single small web server that did not need any upgrade for years, another one that has quite a complex set of content and sustained years of attempts by WordPress lovers to replace it, only for them to come to love MT at the end, each and every time.

Next in this series: The trouble with dynamic publishing.

Steve Jobs

2011-10-09T00:13:01Z

"Remembering that I’ll be dead soon is the most important tool I’ve ever encountered to help me make the big choices in life. Because almost everything — all external expectations, all pride, all fear of embarrassment or failure — these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart." - Steve Jobs

Steve Jobs was stubborn, but less than the statistics on pancreatic cancer. He died at 56, at the pinnacle of an extraordinary and way too short career, after having fought till his last breath.

Through Apple, he marked my professional life more than anybody else in the technology industry. I'm not just an “Apple fanboy” since 1985. After I finally could touch and buy a Macintosh in France, I had the chance to know Apple from the inside and share, with extraordinary people, a vision of informatics for humans, for “the rest of us”, that is radically different from the one that was imposed on the business world.

My first contact with Apple predates my love-at-first-sight of the Macintosh. Among our neighbors in Orsay was Giancarlo Zanni, then CEO Apple France. I played with his daughters, my brothers were interns at Apple. At 14 year-old I was hooked by “l'informatique” but I couldn't legally work.

Many years later, in 1997, after a professional reconversion that drove me back to my first technological love affair, I landed an internship at Apple Europe, then got Apple as a client during my first adventure as a freelance. Steve Jobs had just returned to Apple (he was paid by Apple to buy Apple back, as we half joked at the time) and Apple had a product catalog shock-full of 15,000 references. He handsomely turned around a company that was 15 days from bankruptcy, a company the entire IT industry was laughing at. That this industry and many others aren't laughing anymore at Apple now is quite an understatement.

I have had the chance to see Steve Jobs in person on stage at several occasions, in Paris, in Cupertino, in San Francisco; those were even better experiences than seeing him on videos. Some are dismissive of his use of superlatives and his “reality distortion field”, but he really had a larger than life presence and gold in his hands: a vision and the means to make it come true. For one Steve Jobs, how many uncharismatic CEOs are out there bragging about grand ideas that will never see the light because they do not have a fucking clue about what the company they're managing is doing?

Apple's marketing is a wet dream for many marketing folks, who have some difficulty realizing (or admitting) that it's all about good design of good products that sell themselves. The recipe Jobs imposed when he came back in 1997 of not announcing a product before it ships, and especially to only design things that do “just what's needed and just well”, is an absolute departure from the old methods of competitors: empty announcements of vaporware, obese products plagued by plethoric features lists (the strict equivalent of the pissing contest among geeks).

For the past 25 years, all my personal computers have been made by Apple, and I didn't have to depend on IBM or Microsoft. I'm confident this will continue for years to come, considering the recent developments in personal computing and the choices ordinary people make when they're free to chose their own tools. This is the second time Apple has to run without Steve Jobs, definitely this time, but contrary to the Sculley-Amelio era, the company is prepared and stronger than ever.

I've read comments of people who are astonished by the reactions to the death of Steve Jobs. Those public manifestations coming from ordinary people around the world are concrete proofs that he influenced his epoch. Not getting that is just a display of ignorance.

While I am confident on a professional level about what Apple is preparing next, I am personally sad about Steve Jobs' death, sad for his family, and probably a bit nostalgic of a past era, a page that has been turned too suddenly and too soon. I do not ask you to comprehend that, just to respect this sadness.

Your privacy on MOTOBLUR by Motorola

2011-06-22T07:56:04Z

After the Nokia Ovi Store carelessness, it's now Motorola who's allowing strangers to get access to your private information on their MOTOBLUR portal. Exactly like Nokia, Motorola does not bother to validate the email address you enter on your profile, and sends a welcome message straight to that address:

Bonjour Francois,
Félicitations! Vous avez créé avec succès votre compte MOTOBLURMC! Nous vous écrivons donc pour vous souhaiter la bienvenue dans notre grande famille. Vous êtes maintenant prêt(e) à vous connecter à MOTOBLUR et à profiter d’une vie sociale branchée.

(Pardon their French, it's Motorola Canada.)

In this case, since it was my own address and it serves as the account ID, I was able to request a password change and access the account:

An almost complete profile with phone number, phone IMEI, access to contacts, phone location and the ability to wipe the phone remotely!

Since Motorola does not provide any way to delete the account I'm not going to do anything beyond changing the password and opting out from the Motorola marketing spam that's now arriving in my mailbox (thanks Francois!). The poor schmuck might just have made a typo on the email address, and it's Motorola's entire fault to send out the keys to their client's profile without the simple step of verifying it actually belongs to the right person.

How to resume a broken ADC download

2011-03-13T12:54:03Z

(I'm documenting this trick for myself to remember, but it can be useful for others…)

Apple, on its Apple Developer Connection site, has a bad habit of not providing small or separate SDK downloads for iOS or Mac OS X development. This means, for example, that I have to download a 4.3GB bundle for Xcode 4 and iOS SDK 4.3 to get one of those. Problem: I'm living on a small island where the local postal-and-telecommunications monopoly is better at finding ways to milk everybody to death rather than providing a fast, stable and affordable internet connection as part of its public service duties, so it's simply impossible to download gigabytes of data without being disconnected at least once. The fact is that I've never been able to download anything on ADC without fail.

Thanks to the Unix roots of Mac OS X, we have curl to the rescue. Here's how to resume a failed download on ADC:

Let's say you have started to download the file xcode_4_and_ios_sdk_4.3__final.dmg but the download has been interrupted. Usually, Safari will happily pretend that the download has completed, but the DMG archive won't load. If you check the file size, it's less than it should be.
Check the Finder Info for that file and look in the More Info panel where it comes from. There will probably be several URLs (because of redirections), take the first one. For me it's http://adcdownload.apple.com/Developer_Tools/‌xcode_4_and_ios_sdk_4.3__final/xcode_4_and_ios_sdk_4.3__final.dmg
Connect to ADC to reauthenticate
In the web inspector on the ADC page, go to Storage then Cookies and note the ADCDownloadAuth cookie and its content. In curl parlance, this will translate into something like: -b "ADCDownloadAuth=;"
And finally, in Terminal — assuming you are in the same path as the download file, get there or give the full path to the -o file option — both the -C - and the -o file options will tell curl to resume the download exactly where it stopped, and the --retry 100 will automatically retry up to 100 times in case it fails again (so it'll work unattended):

curl -b "ADCDownloadAuth=;" -C - --retry 100 -o xcode_4_and_ios_sdk_4.3__final.dmg http://adcdownload.apple.com/Developer_Tools/‌xcode_4_and_ios_sdk_4.3__final/xcode_4_and_ios_sdk_4.3__final.dmg

Et voilà !

P.S. My CSS overflow rule cuts the long lines above so I've used a zero-width space to force line breaks, but you should get the gist.
P.S. 2: Added the --retry 100 option to let curl automatically resume the download in case it fails again.
P.S. 3: Just found this script from Michael Tyson which automates all the manual steps above (won't retry automatically, though it's easy to modify it). Very handy!

WTF is this ‘myEventWatcherDiv’ doing in my web?

2011-03-11T12:39:35Z

All of a sudden I started to find the following line in most of the web pages I was browsing, including ones I made where I'm sure I didn't place that code:

I googled and binged and yahooed the whole interwebs but couldn't find any explanation. Then I searched my browser plugins directory and found the culprit: wpa.safariextension which is part of the DivX Inc. plugins galore installed with DivX for Mac.

Since these DivX plugins do not bring any value, but on the contrary bring very bad memories from the RealPlayer era of shoddy tactics (“Click here to get a better video experience" my ass!), you can safely trash them and be done with this cruft.

You're welcome.

Your privacy on Nokia Ovi Store

2011-02-25T19:10:13Z

My friend Adam Greenfield recently complained about the over-engineering culture at Nokia:

I was given an NFC phone, and told to tap it against the item I wanted from the vending machine. This is what happened next: the vending machine teeped, and the phone teeped, and six or seven seconds later a notification popped up on its screen. It was an incoming text message, which had been sent by the vending machine at the moment I tapped my phone against it. I had to respond “Y” to this text to complete the transaction. The experience was clumsy and joyless and not in any conceivable way an improvement over pumping coins into the soda machine just the way I did quarters into Defender at the age of twelve.

It’s not that the NFC-based, phone-to-object interaction didn’t work. Of course it did: it had been engineered perfectly. But what it hadn’t been was designed. Those responsible for imagining the interaction apparently wanted to protect users against the (edge case!) contingency of someone making off with their phones and running up a huge vending-machine tab.

Today, I found out that the Nokia Ovi Store team could actually learn a few things about privacy and security from their engineers.

Yesterday, I received the following email on one of my personal addresses (name changed to protect the guy who used my email address to register):

Date: Thu, 24 Feb 2011 12:18:17 +0000 (UTC)
From: Nokia account
To: francois_@…
Subject: Welcome to your Nokia account

Hello Francoisxyz, and welcome aboard!

To experience the full suite of Ovi services, all you need to do is visit http://www.ovi.com. Alternatively, if you would like to update your Nokia account details, please visit https://account.nokia.com.

Please verify your email address by clicking the link below:

https://account.nokia.com/acct/verifyEmail?id=_____&lang=en

If clicking the link does not work, copy and paste the URL in a new browser window instead.

Thank you for joining and we hope you enjoy using Nokia services.
All the best,
Your friends at Nokia
http://www.ovi.com

Someone had used my email address to register on Ovi. The confirmation email looked quite standard and I ignored it, thinking that the registration wouldn't go through without my confirmation. (I receive a certain number of similar emails, I guess it's the price to pay for being among the first to grab my first name on popular services.)

Then today, I received this from NokiaMusic-no-reply@nokia.com:

Welcome to Music
Hi Francoisxyz,

Welcome to Ovi, the place to discover and download new music. Make sure you put this email somewhere safe because you'll need it in case you forget your Nokia account username - Francoisxyz. You won't be able to log into Music or any of the other Ovi services without it.

Your music, your way

There are millions of tracks from today's top artists and the legends of yesteryear on Ovi, spanning everything from dance to classical to rock. It's easy to get started - you can search for specific tracks, albums and artists or simply click through the genres, charts and playlists to see what's hot. If you want to know more about exploring music on Ovi, check out our help and troubleshooting page.
We're glad to have you with us.

What. The. F…! I immediately requested a password reset, which was nicely delivered to (you guessed it) my email address, and logged in to account.nokia.com to delete this profile. What I discovered at this point is that the profile was already filled in with the guy's real name, mobile phone number, country of residence, and various other personal information (I noted he likes being spammed since he authorized Nokia to send him any promotional info by both email and SMS). It took me about 10 seconds to find his Facebook profile and remind him that he should be a bit more careful when (ab)using someone else's email address.

As for Nokia, especially for a platform that wants to compete with the Apple App Store, this is appalling. Anyone who has a vague idea about security and privacy would not design a process where one can complete a registration process with a fake email address or worse, in this case someone else's address with the obvious risk — that I just illustrated — that personal information might be passed to a stranger.

If these examples are typical of the way Nokia designs things nowadays, I'm not betting on the wedding with Microsoft to stop that platform from burning.

Now let's see how long it takes for Nokia, which I'm sure cares about their customers privacy, to fix that security issue in their registration process…

[Update 28 Feb. 2011] I'm not sure whether the Nokia folks really understand the problem. Case in point, this tweet from @NokiaHelps:

@ubiquitic Account registration is verified either by email or tel. no. depending on selection during account registration. ^JR

I've proved above that Nokia does NOT verify the email address, no matter what they say. And verification by phone number does not alleviate the problem if, when the registrant has entered someone else's email address by mistake, the later receives the acknowledgment emails I have received and which allowed me to gain access to — and delete — an account that didn't belong to me.

Let me summarize the problem for short attention-span marketing/support folks:

If someone enters a wrong email address in their Nokia profile, anyone receiving the “confirmation” emails from Nokia will be able to highjack the account.

Is that clearer ?

Internal inconsistency

2011-02-03T12:22:32Z

Seen a minute ago from the Mac App Store, while updating an application:

What the heck, Apple? If you are trying to confuse your users with modal dialogs written by robots à la Microsoft, then yes I do see one internal inconsistency here.

Melody 1.0 Beta 1 is here

2010-11-03T08:51:31Z

The Open Melody Software Group has just released Melody 1.0 for beta testing.

If you are using MTOS 4, and/or MTOS/MT 5 do not suit your needs, you should keep an eye on Melody.

101010

2010-10-11T05:53:34Z

42.

(Yes, I know, it's the geek inside me who forced me.)

P.S. And Ubuntu managed to release 10.10 on 10.10.10. No small feat, and with the obligatory compliment to Douglas Adams.

Why Movable Type?

2010-09-30T12:54:53Z

On my professional blog I have started a series of articles to explain why Movable Type is an excellent choice as both a CMS and a blog engine.

Google AdSense pearl

2010-09-30T12:38:28Z

The joy of Google AdSense:

(As seen on the Angry Drunk feed, no permalink alas.)

On Apple Safari's use of justified text in Reader

2010-06-10T15:44:00Z

On my professional blog, a take on Apple Safari's use of justified text in Reader.