Tag: chrome

RealPlayer/RealDownloader poses as Firefox running on 64-bit Linux and sends HEAD and GET requests

I recently noticed some strange HTTP logs where a resource would be requested twice with two different User-Agent headers. In one case, the first request suggested the client was running Chrome on Windows, while the second request indicated that it was coming from Firefox on Linux. This didn’t make a lot of sense, so I did some digging.

The culprit turns out to be RealPlayer (and previously RealDownloader, a separate application that now seems to be abandoned). RealPlayer places an overlay over supported browsers (Internet Explorer, Firefox and Chrome and possibly others) that allows the user to save videos from web pages. It doesn’t seem to be a browser plugin as such – it runs in its own process and sends HTTP requests independently of the browser.

RealPlayer browser overlay

The software just happens to set the User-Agent header to something like Firefox running on 64-bit Linux. I sacrificed a virtual machine and installed all manner of RealPlayer software to try and reproduce this behaviour, and the latest version sends requests like the following:

My browser’s actual User-Agent header is:

Based on this blog post and this Yahoo! Answers question, the following User-Agent header was used by an earlier version of the software:

The Gecko build date and Firefox version number (but not the ‘rv’ token!) have been bumped up, but everything else (including the weird trailing ‘Chrome’ identifier) are the same.

Migrating from Opera to Chrome

I’ve used Opera as my primary web browser since the year 2005. It’s never looked quite at home on Windows and its tiny market share means it’s lucky to ever be included on a website’s list of ‘supported browsers’, but still I preferred it over Internet Explorer, Firefox and later Chrome. I valued the user interface for nearly always being extremely responsive (much more so than the other browsers, in my experience), even when I had more than 100 tabs open, which somehow manages to happen quite often. Features like mouse gestures and an RSS reader are available out of the box – other browsers require a lot of extensions before they come close to reaching the level of functionality that’s built-in to Opera.

Opera (the company) announced in February this year that Opera (the browser) would be moving from the Presto engine to the Google Chromium implementation of WebKit (it was later revealed that in fact both Google and Opera will be using a new engine called ‘Blink’, forked from WebKit). An early version of Opera 15, the first version to be built around Chromium, was released this week, so of course I was keen to try it out. Regrettably, most of what I loved about Opera is gone – no RSS, no customisable mouse gestures, basically no UI customisation, no sidebar (handy for RSS, downloads and window/tab management), no separate search box, no MDI (multiple document interface), no private tabs (rather than windows) and probably other features that I’ve forgotten. On one hand, I’m disappointed that my favourite browser has changed for the worse. On the other hand, this gives me a reason to switch to a better-supported browser.

I’ve never really cared too much for Firefox, so Google Chrome seemed the obvious choice. Benchmarks would suggest Firefox’s engine is getting ever faster, but the UI has never been quite responsive enough for my liking. This is quite possibly unfair prejudice on my part.

Chrome is certainly not perfect, buy with the help of extensions, it’s a pretty good replacement for Opera. That said, I don’t see any particular advantages over Opera, other than perhaps the benefit of knowing that your browser is being developed by a tech giant and will almost certainly be supported by nearly every website.

Here’s what I don’t like, and the steps I’ve taken to mitigate each issue:

  1. No mouse gesture support. The Smooth Gestures extension is decent, and it’s certainly much easier to setup gestures than it is in the old Opera settings dialog. You can tell it’s not a native part of the browser, though, as gestures only work when drawn within a page (not on the tab bar or address bar, for example), and they don’t work at all on the new tab page, settings page or Chrome Web Store pages.
  2. No MRU tab ordering. I’m really missing Opera’s most recently used ordering of tabs (the same ordering that Windows uses for windows), and I’m quite shocked that in 2013 Chrome doesn’t have an option to enable this. Partially resolved by the ‘Tab to the next’ extension, but it’s far from ideal. The (Shift+)Ctrl+Tab shortcut is almost useless.
  3. No RSS reader. I’ve started using Feedly, since Google Reader is apparently about to be shut down. It seems pretty good – I just need to get used to the keyboard shortcuts.
  4. No support for POST searches. I find this one a bit baffling – there’s no support for creating a search shortcut that requires the POST verb (I personally need this for WWWJDIC). I happened to have already written a simple script to ‘translate’ GET requests to POST requests (the usage being something like post.php?url=encodedurl&args=encodedpostargs). My POST searches go via my server now, but it’s a reasonable compromise.

Surprisingly – given its multi-process architecture – Chrome doesn’t seem to handle lots of tabs being open at once as well as Opera did, but it’s not terrible. Flash seems to be crashing more in Chrome, which doesn’t make a lot of sense to me, as I thought it was the same plugin. Tabs take up more horizontal width than seems necessary, and I don’t really like that they go to the very top of the window when maximised (makes it difficult to grab the window border).

I’ll give Opera 15 another shot when it is out of beta – by then it might be closer in functionality to Opera 12.15 – but for now Chrome doesn’t seem like a bad alternative, even with its various flaws.