Just a note for myself about this: Bug 1863246: Copy and Paste context menu entries are sometimes disabled when they should not be
And a workaround lower down, from lexlexlex:
“I noticed that an easy workaround when this happens is to click the address bar to change selection focus, then interact with the page again. After that, the “Copy” entry in the context menu works again without reopening the tab.”
Looks like I’ve failed to mention that alongside the disposable Firefox I’m now using a regular Chrome window for all things Google. That means my Gmail, Google Calendar, Google+, some of my Hangouts use and age-verification requiring YouTube-viewing now happens within that profile.
This has freed me from having to sign in to Google in the disposable Firefox. It was a bit of hassle because of 2FV, but to be honest, I’m sure I could have lived with it; what I think this was more about was the satisfaction from dividing the uses between the two browsers: Google’s browser for the Googly stuff, disposable Firefox for everything else.
I’m still using Android on the mobile side, and prefer to use Chrome there because pretending to gain any privacy from alternatives would be just that, pretense. So the divide on the desktop follows this reasoning, to maintain the strong mental association of Google’s services to Google’s browser. I also picked Chrome proper instead of Chromium for this reason: I don’t see any point in pretending to be safe from Google’s prying eyes when using their services, signed in.
There’s one (perhaps notable) exception among those services: if I use Google to search things, I use Firefox. For me, search benefits from my being signed in mostly only on the mobile (where I do often want to repeat earlier searches to save typing), on the desktop not so much. And on the desktop, searching on Google proper is the exception for me, I usually just use Startpage.
On Chrome’s side (on the desktop), my use is pretty strictly limited to the Google services I listed. That means that any external links within those services I will copy and paste into a Firefox instance. Thankfully, of those services, Hangouts is currently the only one using redirect URLs causing some extra hassle. The same issue is much more severe on Twitter, which goes to irritating lengths to obscure the original addresses behind their stupid shortening service. It’s one of those issues I previously would have fixed simply by installing an add-on, but now have to contemplate whether those links are worth manually decrypting, or even the site worth browsing at all because of the irritation that it causes.
I should also mention that I’ve extended the disposable profile idea to Chrome, so that I can launch a disposable Chrome window (alongside the main profile) from Unity’s launcher. (Unlike Ubuntu’s Chromium package, the Google-provided .desktop for Chrome did not provide this function out of the box.) This is mainly to have a browser with Adobe Flash for the few remaining sites I still occasionally deem worth having it on (I can only think of one off the top of my head).
During this past week (IIRC, could have also been last week) I installed the first two add-ons to my disposable Firefox profile: the first was HTTPS Everywhere (from the EFF), the second was HTTPS By Default. Both installations started out as experiments, but there have been no issues and so I’m going to continue with them for the time being.
HTTPS Everywhere goes slightly against my starting premise of “take sites in as they come, or stop using them if they’re unbearable as such”. But in theory, it shouldn’t influence the end-user experience very much, so I should still feel equally at home in other casual setups I might be using the web on. The add-on should just help to give me slightly better privacy when at home without me having to think about it.
HTTPS By Default, by contrast, does not go against the premise. Although I will be using HTTPS on some sites I’d be using over plain HTTP outside home (due to failing to remember to explicitly request for https://), the purpose here for me is just the opposite: to become aware of sites that fail to present themselves over https, by forcing me to explicitly request them over http://. (The add-on causes such sites to fail hard when requested without a protocol.)
Installing these two add-ons was prompted by my successful deployment of Let’s Encrypt on my own sites, which means I no longer have to make exceptions for them. Those exceptions would have been pretty big as my sites make up a big portion of my web use.
(Sidebar: I didn’t realize it had been such a long while since the last post, but the fact that I had trouble remembering the blog’s name should have been a hint. But for this blog, “no news is good news” basically holds true; it means my setup continues to Just Work.)
I now officially take back any bad suspicions I may have cast over Firefox’s stability in the previous post: after I replaced the temporary profiles hack with properly isolated ephemeral profiles, Firefox has been rock solid. I would even venture so far as to say that it’s now more stable than Chromium was for me back when I still used it, though the comparison is slightly skewed to Firefox’s favor by my removing of Adobe Flash at the time of the switch.
V42 has already been supplanted by V43, and it broke the userChrome tweak I also mentioned in the last post, but in a good way: the irritating, obtrusive full-screen warning pop-up is so much more subtle in V43 that I no longer mind it at all. In fact, I should remove the CSS tweak altogether now that it no longer serves any purpose and, even if it did, doesn’t work.
Another major change that I made that coincided with the switch from Chromium to Firefox was to move from Startpage to Disconnect.me’s Search page. I first became aquainted with the latter when trying out Tor Browser, which defaulted to Disconnect Search. I felt like experimenting with an alternative so I decided to give it a go as my default in regular Firefox too.
Unfortunately Disconnect’s results don’t feel as good as Startpage’s do for me. Disconnect apparently employ some kind of quick filtering which is triggered by an immediate (or -ish) return from a site you’ve picked from the search results listing, hiding or lowering the page/site in question from the search results listing from there on. I found it would often degrade my search results near or entirely to uselessness, as I tend to skip back and forth between the results listing and found pages themselves, and only settle for what I deem the best source after sampling a few of the top results. I obviously can’t do that if my search provider keeps hiding the links I’ve visited from me.
Sometime between the last post and this one Disconnect Search also began to occasionally show remarkably poor results for very basic searches — searches I would then take to Google proper to find that Disconnect had left out a huge portion of raw Google results (I exclusively used Google as Disconnect’s backend). Note that this was not caused by the aforementioned “quick filtering”, as these inferior results would also show up in a fresh, clean Firefox window quite often (that was the first thing I tried when I began to notice these poor results).
Hence I’ve now returned to Startpage as my search provider. It may very well be that Disconnect could be configured to not do the “quick filtering” thing it does, but I can’t be bothered to investigate the possibility, as switching back to Startpage is a much easier route out of this problem while also resolving the “generally poor results compared to Google proper” issue. (Doing an identical search in clean windows of both Disconnect and Startpage only seconds apart clearly showed Startpage’s superiority in this too.)
Firefox 42 came and with it my hitherto working hack of clean profiles became extremely unstable. At least, that’s what I’m hoping the instability is due to and not just that FF 42 is in itself so buggy. (It did use to fall down before also quite easily whenever I started messing around in the console, but with V42 it just kept crashing left and right during regular use.)
So I changed my approach quite drastically in the script: now I’m generating individual temporary profile clone directories from the read-only profile and modifying profiles.ini on the fly. This was actually the way I intended to go about it from the start, but with V<42 I just found that deleting any existing profile (& related cache) directory had little effect on already-running Firefox windows, so I took the shortcut.
Anyway, a couple of hours of Bash-wrangling and I now think I have it working just as before. It remains to be seen whether this actually has any effect on the crashing problem though.
I’ve also done one minor tweak in the read-only profile: I added a userChrome.css file to hide the full screen warning.
@-moz-document url(chrome://browser/content/browser.xul) {#full-screen-warning-container {display: none;}}I know it’s a safety measure but god damn is it annoyingly obtrusive.
Something wicked seems to happen every time I let Firefox update my clean profile and then try to sync it back to my stash. I suspect it’s Owncloud-related (the stash directory is under Owncloud’s sync directory), but anyway, here’s what happens:
~/.mozilla/firefox and start Firefox from the command-line (with -P clean). I let Firefox do its compatibility check thing and close it again.cp -a) the updated profile from ~/.mozilla/firefox to the original stash location. (This is how I created it in the first place.)Like I said, the syncing back is no different from how I originally created the profile, and this issue doesn’t always manifest itself. When it does, I have to use some yet-to-be-pinpointed-exactly combination of cp’s, rsync’s, stoppings and startings of Owncloud to make work as intended.
The irritation this causes naturally correlates with how often Firefox gets updated.
In other, unrelated news, I finally dropped Tor browser from Firefox’s .desktop file. I simply never used it and it only caused me to accidentally launch it when I just wanted a new disposable Firefox.
Fourth day with disposables and it has been much easier to get used to than what I imagined beforehand. It’s pretty much down to just one major issue now: I’d like to be able to open new clean disposables straight from links’ context menu, instead of having to manually open one (through the desktop environment) first and copy & pasting the link.
Firefox deceivingly offers the option of opening links in a new so-called Private window right from the context menu, but when the parent window is already Private, the new window actually inherits the session (cookies and all) which is counter-intuitive. These so-called Private windows only get a true clean start when opened from a non-Private window.
On the surface (in title at least) it looks like what I want is “Per-window Private Browsing“, but that one was apparently implemented ages ago. I couldn’t find bug reports or specifications (drafts or otherwise) matching my use-case precisely.
I could try using the “Open With” extension, but in my preliminary testing I was turned off by how difficult it was to strip its default configuration down to the bare essential of my needs: I just need my one context menu item and not one for every browser installed, and removing those it seems would entail hacking the extension. I’m not gonna bother.
In fact, I’d prefer not using extensions at all for my main profile if possible, to KISS. Having to tweak the environment to the extreme just to feel comfortable is precisely what drove me to explore disposability in the first place, and increasing complexity in implementing this aim would, in reality, go against said aim.
That’s why I’m also resisting the urge to set up a keyboard shortcut for launching new windows. It would mean going right back to having to recreate this environment everywhere else, and feeling uncomfortable without it, whereas my intention is the opposite (to feel at home anywhere with a clean browser).
I have set the profiles I’ve created to be synced via Owncloud, but I intend to recreate this environment only for locations where I spend significant amounts of time (at least days). Elsewhere I mean to just set the main profile to discard everything at shutdown, or to remember to do it myself when changing options is restricted, or when options themselves are disposable.
My other profile, the one with light armoring, has seen no real use so far. It seems to have fallen into a chasm of uselessness between “I want disposability” and “I want the hardest anonymity available”.
Judging by a metering app’s graphs the average CPU and memory usage has fallen dramatically with this new environment, compared to my previous one with a Chromium window with multiple tabs pinned plus a bunch of ephemeral ones at any given time. This could be down to Firefox being lighter on the CPU & RAM, or perhaps utilizing them less effectively, compared to Chromium.
Then again it’s more likely to be just an effect of the fact that I no longer keep all those web apps running when I’m not actually using them. Either way it’s good for the environment and my electric bill.
Today’s ops: set up disposable profiles for Firefox. Chromium has better support for them out-of-the-box (--temp-profile), but I found Firefox’s profile management still comes to me straight from muscle memory despite using Chromium exclusively for years now. I didn’t even try to figure out if Chromium’s default configuration is adjustable, and for practical disposability it would have to be, because the temp profile clumsily always opens two slightly buggy tabs (sometimes the address bar eats the first thing entered into it).
The nice customizability of Firefox instead even lent itself to multiple levels of security: for the default profile I kept most bells and whistles from default configuration, whereas for the second one I installed NoScript, HTTPS Everywhere and Privacy Badger. And beyond those there’s still Tor Browser.
On the negative side, Firefox is still noticeably slower to start than Chromium. It was one of the main reasons for my switch all those years back and they obviously still haven’t caught up, which is a bummer. I was aware of this beforehand though, and the delay isn’t too bad, at least on my i7-3770 and SSD.
Also, as mentioned, ditched flash, finally, and for good, hopefully. Lately I’ve only been putting it off because I still have to support it at my parents’, but since I already upgraded out of the LTS they’re using, I may as well use a VM for reproducing any issues they may still encounter before I upgrade them to the next LTS next summer.
So, Firefox 4/Minefield pulled a fast one on me and instead of looking like it should, which is this:
it somehow, all on its own, ended up looking like this:
As you see, the fancy new menu button has gotten itself on the right end of the tab bar. A subtle change which is trivial to correct using Firefox’s toolbar customization… except the Mozilla engineers in their infinite wisdom have decided that the menu button shan’t be moved.
Great. How the fuck am I supposed to fix this, then, without having to build a new profile from scratch?
Well, the trick is to kill the browser and then edit $YOURPROFILE/localstore.rdf. Find the line that says
currentset="appmenu-toolbar-button,tabbrowser-tabs,tabs-closebutton,alltabs-button,new-tab-button,tabview-button" />but with the “appmenu-toolbar-button” misplaced or even missing entirely. Fix it so that it looks like the code above, with appmenu-toolbar-button first. Save the changes. Now restart the browser and hope for the best!
And no, removing appmenu-toolbar-button altogether won’t get rid of the menu button. It’s just one of the ways to trigger this issue.
Rytmilaatikko-musiikkisoittimessa. Myöhemmin olen purkanut tämän liitoksen valitsemalla työpöydällä olleen MP3-tiedoston Ominaisuudet, ja palauttamalla Avaa ohjelmalla -välilehdellä valinnaksi Elokuvasoittimen.Firefox-selaimeen MrKATin mikseri.net-sivun, ja valitsen kappalelistalta ensimmäisen ladattavaksi painamalla siihen liittyvää Download-linkkiä.~.local/share/applications/defaults.list -tiedoston perusteella. Tämän tiedoston sisältöä ei työpöydältä tehdyn oletussovellusvalinnan yhteydessä ole päivitetty.defaults.list -tiedoston muokattavaksi avaamastani Päätteestä seuraavalla komennolla:gedit ~.local/share/applications/defaults.list
Tekstieditoriin, etsin ja tuhoan siitä seuraavat rivit:.local/share/applications/defaults.list:audio/mpeg=rhythmbox.desktop .local/share/applications/defaults.list:audio/x-mpegurl=rhythmbox.desktop
Kun tämän jälkeen lataan MP3-tiedostoja Firefoxissa, ja se kysyy mitä tiedostolle tehdään, tiedoston avaamiseen käytettävä oletussovellus on Elokuvasoitin.
Lataukset-ikkunan listalta. Silloin se avataan jälleen Rytmilaatikossa, joka on edelleenkin oletussovellus defaults.list -tiedoston mukaan.