Monthly Archives: February 2011

open(war)

Posted by on February 16, 2011 1 comment

Evil App StoreWe (finally) see the tech industry take critical notice of Apple's closed nature. Most recently over the draconian terms they announced for publisher subscriptions. Of course, I've been self-selecting my articles ever since I heard about Apple's predatory application of the severely closed iOS/iTunes paradigm onto Mac software at large with the Mac App Store. I remember a couple of Apple (one a former employee) buds trying to sell me on it - first extolling the value of a search-able directory of apps with ratings and reviews; less than 5 minutes into the conversation they were complaining about poor App Store search results. Good thing there's an app for that.

This is not totally new. Open source has been fighting the open war (very well) for a while. There are well-known battle plans on both the proprietary side and the open side. Some on both sides want to see their "enemies" destroyed, but some of us think open source has "won" by simply creating and sustaining open products and opportunities - not necessarily destroying proprietary software.

The struggle for Open Web over proprietary Apps is simply an evolution of this struggle of open vs. proprietary. (Personally, I moved from SourceForge.net to Mozilla because I want to be on these new "front lines.") There are signs that the tide may turn in favor of Open Web Apps for Mobile and why not? We saw this already with the victory of the open web over closed networks like AOL, CompuServe, Prodigy, etc.

As much as I'd like to, I'm not predicting the demise of the App Store along the lines of CompuServe & Prodigy. I'm voicing my dissent from the closed status quo and appealing for a more open approach; at least a pro-open perspective. If you're making web apps, build them with open web technologies. Instead of making native mobile apps, make your web apps kick ass on all devices with HTML5, and only go to an App when you really need device-specific features like cameras and accelerometers.

UPDATE: Mobile Europe has a good article on HTML5 & App co-existence.

That's all.

if request.META['HTTP_DNT'] == 1:

Posted by on February 14, 2011 1 comment

SUMO Release Yesterday I sat in on webdev work group - really just a bunch of webdevs sitting in conference room G ("get to da choppa"). I overheard a discussion that showed me the mission of Mozilla permeates the entire organization. Here's an anonymous summary to protect the guilty and innocent:

Dev 1: Check out this 7-line DNT implementation for Site A.
Dev 2: You know the B group is going to hate DNT.
Dev 1: Yeah.
Dev 2: I don't know if it's a battle I want to fight.
Dev 1: It's not what we want - it's what our users want.

It's the same attitude and perspective we had when we first discussed Do-Not-Track at a brown-bag - we should do what our users want. We discussed what Google and Microsoft are implementing, but there are problems with cookie blacklists, as the EFF pointed out. The one I heard most at our brown bag was that NAI "opt out" doesn't specify whether a user opts out of all tracking or only out of the behavioral advertising. The quote I remember from the Mozilla Privacy discussion was: "A Do-Not-Track header is the clearest message a user can send to advertisers that they don't want to be tracked."

It's also the most technically elegant solution. Check the NAI opt-out page with Firecookie and you see the following opt-out cookie: values - TOptOut: 1 (bing, live.com, MSN), optout: 1 (collectivemedia, criteo), id: OPT_OUT (doubleclick), opt: 1 (fetchback), optout: * (invitemedia), qoo: OPT_OUT (quantserve), NETID01: optout and NETOPTOUT: true (revsci), a: cOPT_OUT (rfihub.com), AO: o=1 (yahoo). And that's just from the dozen networks from which I've opted out. The page shows me at least two dozen more networks from which I still need to opt-out. I just did this exercise a couple weeks ago. How often do I need to visit this page to opt out? Where are these new networks coming from?

And a user doesn't have the same cookies between browsers so they have to get the opt-out cookies on every device (think Desktop, phone, tablet, etc. unless they use Firefox Sync of course), and have to get all the new ones on every device too. Google can help you if you clear your cookies - but that's the only issue Keep My Opt-Outs seems to address.

Compare all this with a header:

DNT: 1

It's efficient (6 bytes), decentralized, permanent, extensible (DNT: 2, 3, 4, 'all', 'behavior', etc.) and if it comes down to it - enforceable. It isn't a perfect solution, but I love working at an organization with top-notch engineering talent AND a pervasive focus on the mission to make the web better for everyone. Mozilla FTW.

__init__

Posted by on February 10, 2011 1 comment

I'm embracing a lot of things recently - python, django, my underused programming handle, and now blogging. I liked my old blog, but I didn't have the time nor leeway to post what I was doing all the time. Jay Patel, product manager for MDN, encouraged me to blog about what we're doing there so here I go:

  1.  
  2. from mozilla.webdev import Job
  3.  
  4. class MDN(Job):
  5.     def begin(self):
  6.         from mozilla.webdev.mdn import developer.mozilla.org as devmo
  7.         devmo.enhance(features={
  8.             '0.9.3':'Demo Studio', 
  9.             '0.9.4':'Learn HTML5', 
  10.             '0.9.5':'Single Sign-On'}
  11.         )
  12.  
  13.         from mozilla.webdev.mdn import dekiwiki
  14.         from mozilla.webdev.sumo import Kitsune
  15.         class Kuma(Kitsune):
  16.             pass
  17.         dekiwiki.moveto(Kuma)
  18.  

There are two parallel tracks for MDN - 0.9.x and 1.x.

0.9.x is a track of enhancements to the existing MDN django, dekiwiki, and phpbb systems. In 0.9.3, we're making an HTML5 Demo Studio, somewhat like the Personas Gallery for HTML5 demos. (Duh.) 0.9.3 will also feature many new locales in the django application, and performance improvements for django & dekiwiki. Our MDN staging server showed a YSlow! score increase from 81 to 91 for django; from 79 to __ for dekiwiki. We're still defining the other 0.9.x milestones.

1.x to 2.0 is a large rewrite of MDN moving the wiki docs from dekiwiki to 'kuma' - a clone of 'kitsune' - the django wiki application we use for SUMO. Both are japanese words (a django theme?); 'kitsune' means (demonic shape-shifting) fox and 'kuma' means bear. We might describe Mozilla support users as foxes and Mozilla developers as bears. Dekiwiki is a good wiki platform, but we've run into problems maintaining it, and we want to move all of MDN to django to leverage django libs and features - especially those developed by SUMO and other Mozilla django projects.

I'm mostly working on Kuma now - cloned kitsune and will merge mdn when 0.9.3 is solid. Then we should be able to branch kuma to an 'mdn' branch for the rest of the 0.9.x work and merge each milestone into 'master' with the 1.x work.

At least that's the plan for now. Keep tabs on the MDN wiki page, MDN bugzilla queue, and join us in #mdn to follow our MDN dev activity. We hope to make MDN a premier web dev resource and I think what we're doing now is going to help us get there.