I am looking at making an application that would make OpenID authentication with desktop clients easy. The rationale is to steal the cookies from the web-browser, so as to avoid having to hard-code authentication to every possible OpenID provider.

Assuming the user has already logged on to the OpenID provider, the application clones the cookies from the default browser, and requests authentication to the desired service with the appropriate OpenID URL.

To make this application usable, I need to know what are the most commonly used web browsers used on Linux, possibly with statistical evidence. I assume that Firefox and Chromium are the two most popular at the moment.

NB: the title of this question was edited in view of the emphasis by respondents on security and standards.

  • 11
    I think you should follow standard and specifications, not browser idiosyncrasies
    – enzotib
    Jan 12, 2012 at 13:05
  • 1
    The most popular are certainly Firefox or a clone, Mozilla Suite/Seamonkey, Chrome or Chromium, Konqueror, Epiphany and Opera. Note that this list is not in order.
    – Sorpigal
    Jan 12, 2012 at 13:13
  • FF and chrome, as you say. FF probably is still most used. Jan 12, 2012 at 13:40
  • @enzotib: could you be explicit please? The current OpenID standards are not desktop application friendly, in fact everywhere on the net you are told to use and embedded browser (which I don't want to do). If I am to offer all possible openID provider logins then I must hard-code authentication requests for each one of them, which too have their idiosyncrasies. Or am I not seeing this right? Jan 12, 2012 at 13:58
  • 1
    I have no recipe and I have no deep knowledge of the argument, but "to steal the cookies from the web-browser" seems an unorthodox method, that I would avoid if possible.
    – enzotib
    Jan 12, 2012 at 14:23

3 Answers 3


"Stealing cookies from the web browser" in order to obtain authentication sounds like exactly the kind of thing malware would get up to in order to gain access to your personal information and login data.

If this approach turns out to work, I recommend you inform each browser's development team about a security hole in their software.

  • Retrieving cookies of a browser like Mozilla though, is a very easy thing to do apparently. I have copied a code sample elsewhere. I don't really see how that is necessarily a bad behaviour: the user logged on to the OpenID provider already, if the user authorises explicitly the use of his cookies, it shouldn't be an issue. I have proposed elsewhere the idea of Centralised Cookie Management to cope with these situations. Jan 12, 2012 at 16:13
  • Were the application to handle authentication directly with the OpenID provider, would it make a difference? The user would also have to provide his username and password to the application, which by all means is worse in terms of security than using a cookie. Isn't it? Jan 12, 2012 at 16:15
  • @neydroydrec That's not worse because your application has the opportunity to store the authentication information in a secure way so that no one else can use it. Something you obviously can't say about browser cookies.
    – bta
    May 5, 2023 at 1:20

Stealing cookies from a web browser is a standard thing when you're writing a scraping script and don't want to deal with some complex website authentication in your script.

Traditionally, browsers stored their cookies in a simple text format inherited by Netscape, the cookies.txt format. Wget has an option --load-cookies to load a file like this.

Modern versions of Firefox and Chrome no longer use this format, but rather an SQLite database. There are extensions to make them dump a cookies.txt file, such as Cookie Exporter and cookie.txt export.

This is all very well for a script for use by technical-minded people, but I wouldn't do this in a general-public application. You are in for a world of hurt figuring out what browser to use (this user has three Firefox profiles and two Chrome profiles, which one should I look at?) and making users of less common browsers angry (Opera, Konqueror, Gecko, …). It's also a big hit on usability, even when it works: you're asking the user to do something in their browser before they can use your application, and not to do something in their browser (logging out of the site or erasing cookies) as long as they keep using your application.

I would still consider the approach reasonable if the target website was very hard to interact with. And even then, I would favor making your application interact with its own browser instance (using its own profile) with a browser automation framework such as Selenium or Watir. For a general OpenID login, I think it's best to invoke a known browser and make it spit out the authentication credentials.


There are a whole lot of ways that this can backfire on you.

While there are ways to get cookies out of a browser, it's not done using any sort of official API. That means it relies on the implementation details of the currently-released version of the software and is subject to change at any time without warning. Your application can and will break at random times as browser internals get redesigned. You likely won't know about these changes in advance, so you'll have angry users breathing down your neck about a completely broken program for however many days or weeks it takes to figure out a workaround. Your entire program will be unfixably broken should browser vendors decide to encrypt their cookie store for security.

Many modern browsers have the notion of multiple profiles. I can log into Edge with my personal account or my work account. How will you know which one to pull cookies from? Would the user expect you to switch accounts in your app when they switch browser profiles? Mixing up work and personal accounts has a long history of ending in disaster for the user. What if I want to use one account in your app and a different one in my browser?

Perhaps most importantly, you're forcing your app's users to use their web browsers in a very specific way that they may not be comfortable with. I (and many other people out there) use private/incognito mode (or a plugin like Cookie AutoDelete) with any websites that require a login. That ensures that no cookies or other login information persists once I close the browser. Your app would require users to use their browser in a way that stores authentication information in an insecure way. People that value security would consider that a non-starter.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .