Month: November 2010

Bring Back TSA Classic

 

At this point very few would expect that you should be able to carry metal items undetected onto a plane, so I don’t have too big a problem with metal detectors at airports. However, society has a general expectation that the image of one’s naked body is private, so we should certainly consider the new scanners a “search” under the Fourth Amendment, requiring some level of probable cause. Is showing up for a flight probable cause for suspicion that you have explosives on you?

Setting aside the question of constitutionality, there seems to be mounting evidence that TSA agents cannot handle the responsibility that this much power brings:

What happens when a terrorist successfully sneaks in bomb materials embedded under the skin? I’d guess the attack would fail for the same reason the underwear bomber’s did: our system already worked. Until all international airports with flights to the U.S. are outfitted with the new scanners and procedures, we still can’t prevent another underwear bomber (he boarded in Amsterdam).

?YouWontSeeMe

 

In beta 11, Opera’s going to hide all “http(s)://”, and also all querystrings (until you focus the addressbar). Opera’s devs are right that users consider them mostly “gibberish”, but I think this change could cause a ton of problems and confusion for people, especially support staff, and there are plenty of sites/apps still out there with URLs based on querystrings. I can see this setting as short-lived.

We need a frontend design tool for live web pages

 

It’s quite frequently that an HTML/CSS designer might want to make changes to a live web page. Maybe she doesn’t have write access, or maybe the fixes needed aren’t worth the start-up cost of copying the page locally and working on it there, or multiple designers want to work up ideas on a given page simultaneously. The “Inspect Element” capabilities of most modern browsers will let you make HTML/CSS changes to a live page, but navigating or refreshing causes those changes to be lost, and they’re hard to keep track of.

Here’s a feature wishlist:

  1. keep track of “Inspect Element” user changes with the ability to save them locally
  2. keep changes in discrete “changesets” that can be re-applied, or saved as a unified patch of the original files, or at least as the modified original files
  3. allow swapping page CSS files with user-controlled CSS files (e.g. file:/// or htttp://localhost/)
  4. allow swapped CSS files to be periodically “refreshed” so the user wouldn’t have to switch between CSS editor and browser.

Firefox’s Stylish extension looks to come close to (3), allowing you to add user styles to a page/site, like Greasemonkey does for Javascript. It doesn’t look like the editing experience is great, though.

You can manually do (3) and use the CSS Reload Every bookmarklet, but it reloads all CSS, which is kinda of jarring.

A bookmarklet could implement (3) and (4) and persist its settings in a cookie.

Other ideas?

Update: Here’s a bookmarklet that let’s you swap CSS files and stores its settings in a cookie for the current page. Next step is for it to allow adding files and controlling the cookie path.

You must enable Javascript! (right-click, add to favorites or bookmarks)

(CSSswap source).

“Buy American”

 

When economies are struggling, protectionism seems well-intentioned: By “buying American” we can go back that golden fantasy age when everything was American-made and everyone had a decent-paying job and could afford the latest luxuries. I have some examples that I hope can convince you that freer trade benefits everyone. It’s not completely intuitive; we commonly think that one person is always screwed in a deal; if it’s good for [insert foreign country], it must be bad for America. Continue reading  

Email Address Munging Still Mitigates Harvesting

 

At least a decade into the use of simple email munging on web pages (my own solution here) there’s a growing consensus—and it seems like common sense with the advancement of the web in general—that this surely can’t still work on modern harvesters. While trying to look up some old research I’d read about this, I came across this January 2010 post by a Project Honey Pot admin:

We’ve run tests on different munging techniques and find that they are still surprisingly effective. We have a page that has a set of differently munged addresses. The ones protected by Javascript have yet to receive a single message. Even simple things like using ASCII character encoding to hide the @ sign, or adding spaces to the addresses, is surprisingly effective at stopping harvesting.

Whether to munge or not is kind of a religious war, but I see this as pretty convincing evidence that munging isn’t obsolete just yet. Of course this or any other single prevention strategy isn’t a “solution”, but mitigation of the inevitable is still arguably worthwhile, especially for people without the luxury of having top notch admins run their mail server.

Using jQuery Before It’s Loaded

 

It’s better to include scripts like jQuery at the end of the BODY, but this makes its methods inaccessible earlier in the page (e.g. inside a WordPress post). What you can do is use a script like the one below to queue DOMReady functions before jQuery loads.

(function (w) {
    if (w.$) // jQuery already loaded, we don't need this script
        return;
    var _funcs = [];
    w.$ = function (f) { // add functions to a queue
        _funcs.push(f);
    };
    w.defer$ = function () { // move the queue to jQuery's DOMReady
        while (f = _funcs.shift())
            $(f);
    };
})(window);

Minified:

Setup

  1. Link to the script in the HEAD or at least before your typical page content area
  2. Link to jQuery at the end of BODY
  3. Below jQuery, include: <script>defer$()</script>

Now in the BODY you can use $(function(){ ... }); to queue up a function as if jQuery were already loaded. And, thanks to the fact that Javascript identifiers are referenced at run-time, you can call any other jQuery functions inside your queued function.

With some modifications you can use this pattern for any library with a similar DOMReady implementation.

Tiny Email Munging Script

 

I’ve seen a lot of these that are bloated/less effective/inaccessible, so I might as well put this out there. It’s simple enough to modify if you’re comfortable with Javascript.

Markup: <a href="mailto:john{@}example{.}org">john{@}example{.}org</a>

(function(){
  var a, i = 0, o = this.onload;
  onload = function(){
    o && o(); // run the old window.onload if existed
    while (a = document.getElementsByTagName("a").item(i++))
      if (0 == a.href.indexOf("mailto:")) {
        a.href = a.href.replace(/[{}]/g, "");
        a.innerHTML = a.innerHTML.replace(/{(.)}/g, "$1");
      }
  };
})();

Minified 234B:

for jQuery 150B: