a trademark to distinguish network neutral providers

While on vacation last week, I saw a sign in front of a Burger King in New York advertising free wifi.  The sign listed six things you can do with it (downloading songs, chatting, etc.), which left me wondering whether they provide the whole whopping internet or just the selected portions they highlight.

And that got me wondering whether it would make sense to trademark a logo and phrase for distinguishing internet providers that provide unobstructed access to make it easier for users to pick network neutral wifi hotspots at restaurants and hotels, DSL/cable providers, and mobile plans.

Providers licensing the logo could still rate limit, as long as they didn't do so on the basis of site or protocol.  And the trademarked content would be designed to be simple and understandable by non-technical users, like Creative Commons' license logos, TRUSTe's privacy seals, and the feed icon.

I'm not sure what organization would be most suitable for running such a program, but it should be not-for-profit, as Creative Commons, TRUSTe, and Mozilla all are.

Properly implemented, it seems like a program like this would make it a whole lot easier for users to pick providers that don't have frustrating problems caused by access obstructions while putting pressure on providers to provide the whole internet so they can qualify for the program.

Thoughts?

me three

myk@myk:~$ uname -a
Linux myk 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux
myk@myk:~$ history|awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
115 cvs
61 cd
50 ls
33 safari
31 komodo
28 firefox
23 cp
16 ll
12 zip
12 scp
11 mv

proposed changes to Mozdev roadmap

I'm on the board of the Mozdev organization, and we're in the process of reviewing our roadmap for development.

We're a small organization with limited resources, so we can't do everything that would be useful, and it makes sense to leverage the tooling taking place elsewhere in the Mozilla community.

At the same time, I want Mozdev to blaze a trail on the usability and functionality of key services like website development/deployment tools and discussion forums.  And it should be super-easy to set up and manage a project on Mozdev.

So I am proposing that we revise the roadmap to make the following three items the top priorities for the organization:

1. Add one additional revision control system, and deprecate CVS.
   
   The two systems in the running are Subversion and Mercurial, and they each have their advantages.  Subversion's chief advantages are its similarity to CVS and familiarity to some existing project owners, while Mercurial's are its modern design (including support for distributed development) and its momentum in the Mozilla community.
   
   Overall, I think we're better off adding Mercurial, which has the full weight of Mozilla tooling efforts behind it and which is on track to become the most popular system in the Mozilla community (until the next one comes along, anyway).
   
   So I think we should add Mercurial to the site.  But this would not preclude adding Subversion as well at some point if resources became available to deploy and maintain it.
   
   
2. Implement a new website hosting service with simple WYSIWYG wiki publishing and scp/sftp/ftps file upload.
   
   Here we're tackling two constituencies at once: those who just want a simple hosting option where it is easy to create and edit pages, and those who want complete control over the files that make up their site.
   
   The file upload option also addresses the needs of users who generally want the simple approach but occasionally need to upload a file or two (f.e. an image to display on a page in the wiki or a presentation in PDF format).
   
   
3. Automate project creation and management so that project creation requests can be addressed in minutes or hours and users can self-manage their projects.
   
   This item combines the automate project creation process and centralized account management system items from the second and third priority groups, respectively, on the existing roadmap.
   
   I think we should continue to require approval of new project requests from unknown people but no longer require approval of those from known, trusted people like existing project owners, so that trusted people can have a new project up and running in seconds.

There are certainly many other changes that would be beneficial, like integrating forums, feeds, mailing lists, and newsgroups, so users can pick their preferred delivery format and get the same communications as on every other channel.

But these three changes would make a big difference in the usability and functionality of the site, and I think we should make them our top priorities.

Thoughts?

Dynamic Personas - How They Work

The recently released update to the Personas extension includes support for dynamic personas, which are personas that change over time.  Here's a technical overview of the history and present condition of the feature (for a non-technical overview, see the labs blog).

Take One

Original discussions for making personas more dynamic started with the idea of building an API for them to specify a series of background images and when to switch between them.  But the more ideas we had about what personas might want to do, the more complicated this API became.

I wanted something both simpler to scale to more complex functionality and more powerful right off the bat, so I suggested we simply stick iframes behind the browser chrome at the top and bottom of the browser window, let personas load any web content (HTML, SVG, etc.) into them, and let them update themselves as needed ajaxically.

That seemed promising, so I prototyped it by XBL binding the top and bottom chrome into XUL stacks, making their backgrounds transparent, and sticking iframes underneath them.

That worked great until I locked down the iframes with type="content" for security, at which point they were hoisted to the tops of the stacks and covered up the browser chrome.

I asked about this on IRC, and roc pointed me to bug 130078, which won't be fixed in Gecko 1.9.  So I had to find a different solution.

Take Two

The one I hit upon, which is in the latest release, preserves as much of the web content magic of the original solution while still working (safely).  And it still enables personas to change over time, albeit not as rapidly.

The extension creates two iframes in the hidden window, loads the persona content into them (which can still be any web content), takes a snapshot of them using the canvas 2D context's drawWindow method, converts the snapshots to data: URL-encapsulated PNG images using canvas's toDataURL method, and then makes those images the background images for the top and bottom chrome.

Rinse and Repeat

The extension then leaves the persona loaded in the iframes and periodically (once per minute by default) updates the browser chrome with new snapshots.  And occasionally (once per hour by default) it reloads the persona from scratch, although personas are of course free to update themselves more frequently.

Once per minute is obviously not fast enough for animation (like an aquarium with fish swimming around in your toolbar), but it's fast enough for gradual changes, like a panoramic landscape that darkens as the sun sets or a pictorial depiction of the weather report.  And there are plenty of interesting personas for which this update frequency is fast enough.

(Incidentally, one can jack up the frequency with a hidden preference, but doing so is not recommended, since it could impact performance).

Bits and Pieces

When dynamic personas change the background, the optimal foreground color might change too, so the extension sets the foreground (text) color to the one specified on the root element of an HTML dynamic persona.

For example, Heldenhaft's Paderborn, Germany panorama persona is dark at night and light in the daytime, so I adapted some code from an NOAA Sunrise/Sunset Calculator to enable it to determine the status of the sun at its location and set its foreground color appropriately.

And if you want to test out this "any web content" claim, just select Preferences... from the personas menu, press the Custom Persona Editor... button to open the custom persona editor, and enter any URL (f.e. http://www.mozilla.com/) into the Header or Footer fields.  It might not be pretty, but it'll show you a chunk of the page behind the chrome.

Locking it Down

The code is a actually bit more complicated than described above, because the hidden window is an HTML document on Windows and Linux, and HTML iframes can't be locked down with type="content".

So instead of creating those iframes in the hidden window, it creates another iframe in the hidden window that loads a XUL document that contains the two iframes that load the persona content.

Tests like this one (and a version that tests the personas code directly) demonstrate that the content iframes are indeed locked down, so while personas can do anything web content can do in a browser tab, they can't break out of the content jail and access chrome UI or capabilities.

The only thing injected into chrome is static PNG snapshots of web content.

Of course, if you can think of a way around that or another security issue, I and other Personas hackers would be very interested in your thoughts.  To confirm your suspicions, install and test the extension or peruse the code online.