Tuesday, September 06, 2011

» FF6/FF7: Re-enable javascript: from urlbar +

Jump a bit for instructions on how to re-enable execution of javascript: urls in Firefox 6.0.1 and 7.0.


So, much to my surprise, javascript: urls stopped working after I upgraded to FF6. I assumed it was a bug, and would be fixed soon enough. After all, "ReferenceError: alert is not defined" couldn't be intentional, right? I mean, javascript:alert(foo.prop); has worked since before javascript was even invented, amirite?

Not so. In bug 527530 it was considered necessary to remove execution of even typed-in javascript: urls in order to circumvent naive users being tricked into running malicious code. Chrome chose to address the social problem with a technical solution also--by disabling execution of drag-dropped and pasted javascript, but not removing the execution of typed-in javascript. Chrome also restores the urlbar after running the script. I have no idea what IE does, but the bug mentioned that it addresses the issue without removing typed javascript url execution.

I tend to think that it's a staple tool used by thousands daily, competing browsers support it, and I can't see a good reason why it shouldn't be available. Counter arguments that it takes fewer keystrokes to launch Web Console or Scratchpad miss the fact that not everyone has incorporated those tools into their workflows. Requiring developers to adopt completely new workflows to use Firefox is a Really Bad Idea(TM), especially if they've been productive with their current workflows for a long time. Further, that's a user interface design concern and shouldn't be rolled into the security concern. And as far as ui design goes, like it or not, besides javascript execution, the urlbar is also used to launch the download manager (from a user perspective, "paste this in your browser to download X" is completely different from "navigate to google"), to view internal information and state (about:*), and to launch the source viewer (view-source:). There are probably more I'm forgetting.

The only compelling argument for removing javscript execution from the urlbar completely is that users may still be tricked into pasting bad scripts, they'll just have to type a letter or two before hitting enter--"Check out the super secret awesome page! Paste this in your browser then press the Home key and type ja and press enter: vascript:badstuff()". Since the hypothetical naive user thinks the urlbar is only for urls, this could be a successful attack vector, but I'm not so sure it would be.

In any case, I'm perfectly fine with having a default-false boolean pref. This allows for developers to enable it, and it mitigates all the security concerns as it requires explicit opt-in. Bug 680302 is tracking adding such a pref.

Fixing Firefox 6.0.1 and 7.0

If you're like me and can't wait to turn urlbar execution of javascript back on, I'm including a backpatch to Firefox 6.0.1 and instructions to apply it.

Note: This is only tested on Linux, but should be identical on Windows and Mac, you'll just have to find where omni.jar is stored on those platforms and find tools un/zip it (it's a PKZIP format file), and to apply universal difference files.

Edit: This process works for FF7 release, you just need to adjust the paths and use something like 10 fuzziness when applying the patch (patch -p0 -F10 < ...).

All platforms

Go to about:config and right click, add a new boolean preference named browser.urlbar.allowInheritPrincipal and set it to true. Shutdown the browser.


mkdir ff6
cd ff6
wget -O ff_urlbar_javascript_pref.diff \
unzip /usr/lib/firefox-6.0.1/omni.jar
patch -p0 < ff_urlbar_javascript_pref.diff
sudo rm /usr/lib/firefox-6.0.1/omni.jar
sudo zip -r /usr/lib/firefox-6.0.1/omni.jar .
cd ..
rm -rf ff6


So first grab the patch: ff_urlbar_javascript_pref.diff

Make a directory and extract omni.jar into it.

Apply the patch (from inside the directory).

Create a new zip archive named omni.jar with the contents of the directory you extracted to, and move this over the original omni.zip. Look inside both before moving yours over the original, to make sure they have the same directory structure.

Restart Fixefox and you're back to being a normal, competent adult. :)

Labels: , , ,

Wednesday, June 22, 2011

» [FIXED] Synergy Flash Fullscreen +

On my media computer I use synergy to remote control it from my desktop. There was one big drawback -- every time I switched to the primary screen, the flash video would exit fullscreen on the secondary screen. So I either had to watch the video non-fullscreen or go to the physical mouse of the secondary box and hit the fullscreen button and then not switch to the secondary until the video was over. Yeah, that wasn't going to work.

I googled around and apparently synergy unfocuses the active window when the mouse leaves the screen. The Windows GUI lets you set an option to enable or disable this behavior. Given that I haven't used Windows as my primary OS in like 6 years, that doesn't help me. I assumed there would be a config option, but couldn't find it in the synergy docs, or anywhere else for that matter. Went to the source code to patch it and after following it a bit, found preserveFocus in CConfig.cpp (this is synergy+, not sure about any other flavor).

It does exactly what it sounds like. Added it to the second screen in the server config, and presto, flash stays fullscreen. Yay.

And, of course, now that I know what to search for, I immediately found the bug report where this option was added for Linux. Just wanted to document this feature in case anybody else needs it.

Labels: , , ,

Wednesday, April 06, 2011

» Thunderbird won't open links +

So after a recent system update (Arch Linux, cause it's the best, obviously. Duh, Winning), Thunderbird refused to open links in email bodies.

I would be like, "Please Mr. email client, open my links" and it would say "No, eff you, rawr-rawr-rawr" and then poop this on the error console:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIExternalProtocolService.loadUrl]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://communicator/content/contentAreaClick.js :: openLinkExternally :: line 188" data: no]

Apparently, my default browser somehow got set to an explicit path for Firefox 3.6. When I upgraded to FF4, that obviously broke.

Followed the article linked below and everything works again. Yay!


Labels: ,

Wednesday, July 21, 2010

» Getting USB speakers working in Gnome +

So I just got a set of Insignia USB speakers (NS-2908). Wanted to use them as my default speakers, but still have the option of using the internal sound card. Got it working and thought someone else might find it useful. This assumes you're using a new-ish version of gnome.

You'll want to set the Internal Audio profile to "Off" in the pulseaudio volume control application, under the Configuration tab.

You'll want to edit the preferences of the volume control applet to point to the correct default device and channel.

Next part is the tricky part.

You'll want to run:

cat /proc/asound/cards

Find the number of your USB speakers. In my case, it's card 2:

 2 [default        ]: USB-Audio - USB Audio DAC   
Burr-Brown from TI USB Audio DAC at usb-0000:00:04.0-6 [...]

Now you'll need to edit the gconf keys gnome uses to set the mixer device for youe multimedia keys (yes, when you have fancy volume buttons on your speakers that trigger the mm keys, you want it to work!). So in my case I want to default submixer of the second alsa device:

gconftool-2 --set -t string /desktop/gnome/sound/default_mixer_device 'alsamixer:hw:2'

And I want only the PCM channel to be controlled (you may want Master, or Front, or multiple channels):

gconftool-2 --set -t list --list-type=string /desktop/gnome/sound/default_mixer_tracks '[PCM]'

The cool thing about this, is that it falls back to the default device. So when the USB speakers are unplugged and I'm using the internal sound card, it still Just Works with the mm keys on my keyboard. Nice.

And for good measure, I threw this in my ~/.asoundrc:

pcm.!default front:default

You'll need to look at the output of aplay -L to get the right values for your speakers. Or, if you have pulseaudio set up as your default device, you can just skip this step.


Labels: , ,

Tuesday, February 23, 2010

» Dark Glass theme with DroidMod v1.0 - White Clock +

The DroidMod Team (formerly of sholes.info) relased a new ROM (--one of the best availible, I might add). The only "problem" with the ROM is that it does not include the ability to select the Smoked Glass theme when applying it. This is not so much a problem as a design decision.

The Metamorph application, available on the Market, lets you apply all manner of themes to your device, uncluding the "Dark Glass" theme previously included in the SholesMod ROM. Thus, the new ROM opts to exclude theme support directly, and just let users apply whatever theme they like via Metamorph.

That's fine, and Metamorph is an awesome application. However, there is a minor hang-up. AdamZ's Smoked Glass metamorph themes do not include a hacked services.jar, so you have a black statusbar clock, and the XML files in framework-res don't change all of the foreground text colors to white for notifications.

So, here is a simple Metamorph theme that adds a services.jar and framework-res.apk with white clock and notifications (just used colorChangev3.jar on them). Should work with any theme on any 2.0 or 2.0.1 ROM. :)

  1. Install the Smoked Glass theme located here (the "Glass Theme Only - No Blue" is the closest to the one previously included in SholesMod).
  2. Install the "White Clock Notifications" theme from here
  3. ???
  4. PROFIT!

Happy droiding. :)

Labels: , , , ,

Monday, February 15, 2010

» Clear Android Market Search History +

So, I wanted to clear the search history that displays in the Market app when you open the search bar. It seems that from a quick googling many people would like to do the same thing. I found a way that seems to work, but it requires root access.

I figured the Market app probably stores the search history in some type of standard database, rather than in a compressed or encrypted container, so I just grep'd /data for a unique history item (foobarbazbozbiz) that I searched for in the Market for specifically this purpose:

grep -r foobarbazbozbiz *

It looks like /data/data/com.android.vending/databases/suggestions.db is where the history is stored. And yes, this is just an SQLite3 database. I tried removing the file, but the Market app still shows the same history. Hmmm. Maybe the Market app is still running in the background and holds an open handle to the database? (In Linux, the kernel Android runs on, when a reference to a file is held in memory, the file can be deleted from disk, but it is not actually removed until all the references to it are released--see here).

So I tried killing the Market app:

Menu -> Settings -> Applications -> Manage Applications -> Menu -> Filter -> All -> Market -> Force Stop

That worked. :)

I haven't found any other apps that use the database, but there may be some that do. So far, my phone hasn't exploded, but YMMV.

Ps. Maybe my first Android app will be a "Clear Market Search History" app (looks like the SearchRecentSuggestions class might be helpful; or I'll just do it quick and dirty with the File I/O APIs ;)).

Labels: , ,

Thursday, November 19, 2009

» Ad-blocking with Polipo +

Polipo is a fast local proxy that does on-disk caching (by default, at least). Privoxy is another local proxy, with a focus on privacy and ad-blocking. Due to the nature and purpose of Privoxy, it has to buffer portions of the page (to check for content it should block) before serving it to the browser. This makes it a bit slower than Polipo. You could always use Polipo in front of Privoxy (see here, middle of the page), but that is a bit much if you don't need fancy filtering and simply want a domain/regex blocklist.

You could build up the blocklist yourself, by hand, but that would be a pain. Instead, we'll just convert an adblock filterset to a format that Polipo can understand. Since Polipo is blocking by matching the URL only, we don't have the same fine-grained control as Adblock rules, but I personally don't require that level of control.

Firstly, grab an adblock filterset (e.g., easylist.txt). Next, grab either adblock2polipo.py (python) or adblock2polipo.rb (ruby). Then run whichever script you downloaded with the filerset file as the first parameter. The script will dump the re-written rules to the console so they can be inspected or be redirected to the file polipo uses to load its blocking rules from (~/.polipo-forbidden or /etc/polipo/forbidden on *nix systems). Restart Polipo and the new blocking rules should take effect.

PS. If you're like me, you'd rather have Polipo serve up a blank page for blocked URLs rather than a 403 error page. To accomplish this you need to edit the Polipo config file and add a forbiddenUrl option pointing to an empty image, such as this one. One good option for this is the following: make sure localDocumentRoot is either set to a real path (such as /usr/share/polipo/www) or commented out completely. Then create an empty file in that directory:

sudo wget -O /usr/share/polipo/www/empty.gif \

Then point forbiddenUrl to Restart Polipo. That's it. :)

NB. Firefox users will need to add port 8123 to the allowed ports list, or they'll get an equally annoying error message from Firefox instead of a blank page. To do this, you need to open about:config in a new tab/window. Right-click and go to New->String, and for the property name put network.security.ports.banned.override, and for the value put 8123. It should work properly after that.

Labels: , ,