Blogs

Liferea 1.10.11 Released

This is a new maintenance release.

The Changes:

    * Fixes Github #53: Doesn't automatically update feed name and favicon
      for new feed (reported by asl97)
    * Fixes Github #67: Missing dist files for documentation
      (patch by Mikel Olasagasti)
    * Fixes Javascript links not opening in new browser tabs

    * Updated French translation (Guillaume Bernard)
    * Updated Hebrew translation (Genghis Khan)

Linux Desktop Feed Reader Usage Declining?

When working on your open source pet project there is always the ego boost of asking yourself how popular is this thing that we are building. Who is using it? Why is there no feedback. Or why are there suddenly so many bug reports? So what is the amount of users of Liferea and other feed readers and how is it changing?

Popcon

Well for Debian and Ubuntu there is the famous popularity contest which tracks installation and usage count per package. Let's look into the statistics over the years. Note that while the Debian graph is official from the Debian popcon.debian.org, the Ubuntu graph is from lesbonscomptes.com/upopcon as Ubuntu itself doesn't provide a graphs. Also the Ubuntu graph only covers the time from 2010 to now, while the Debian graph dates back to 2004.

Liferea and Akregator

The two widely used feed readers under Debian/Ubuntu are Liferea (GTK) and Akregator (KDE). While it is possible that more people use Thunderbird or Firefox for feed reading it cannot be measured using popcon as there is no dedicated package for Thunderbird nor Firefox that could indicate the feed reading habits of their users. So we can only look at the standalone feed reader packages.

Debian

Ubuntu

The graphs indicate a decline from up to over 4000+ users on each distributions which seems to have been peak usage to recently roughly over 1k Debian users and 700 Ubuntu users. Interesting is the difference on Debian with until 2014 more Liferea users vs. Ubuntu which always had more Akregator users.

Other Market Shares

Of course there are several other news readers for Debian and Ubuntu. Note that Ubuntu has RSSOwl which Debian hasn't. Snownews isn't listed in the Debian graph anymore as it was dropped with Wheezy.

Debian

Ubuntu

All other feed readers on Ubuntu count roughly 250+ votes in 2010 and roughly 80 in 2014.

Installation Base

Usage is falling. Well there are mobile devices and the reduced visibility of syndication techniques in the browser (we do not have the feed button in the browser location bar anymore)... So people might just not install feed readers anymore. Is this the case? Let's limit the analysis just on Liferea and Akregator.

Debian

On Debian the install base of Liferea is rapidly declining as it is not in the default desktop selection, while Akregator installations still grow maybe due to the kde-pim integration.

Ubuntu

A different situation on Ubuntu. Both feed readers are in the default desktop packages of their respective desktop environments. So installations seem to scale linearly upwards along with the growth of Ubuntu installations. Update: Jeff Fortin hinted on only Akregator being in a default package selection on Ubuntu. This makes the linear growth of the Liferea install base strange.

It looks bleak... Checking the baseline!

Well let do some verification of the results to be sure popcon can be trusted. Let's have a look at a basic Debian package needed during installation like "debianutils" which users do not unselect and which is automatically used. And let's also add a basic GNOME package like "gnome-session" which always will be used if GNOME is used.

Here are the Ubuntu popcon results for both

It looks (most obvious with "debian-utils") that there was a 50% reduction of the popcon votes in over 2013. Please note that the staircase steps in all the Ubuntu curves do probably indicate there are only 2 samples in the given time range! I guess the decline was rather continuous as can be found in the Debian curve. When checking the installations at the same time there is no drop. So some mechanic in the popcon voting counting could have changed. I found no hints online why this is the case so far.

Conclusion

At this point I think the results are too confusing to actually read much into it. I believe all graphs indicate a decline of the feed reader usage over the years, especially after the peak in 2010, and at the same time the graphs indicate changes in the vote counting with differences in Ubuntu and Debian.

Liferea 1.11.0 - New Unstable Line

This is the first release of the new unstable release line. This release line focusses on code maintainability and this sometimes means removing features (like the very desktop environment dependant tray icon and popup notification features). On the other hand it extends support for online accounts with support for InoReader and Reedah. It also introduces label (folder) support for TinyTinyRSS subscriptions.

Change Details

    * Added experimental InoReader support
    * Added experimental Reedah support

    * Fixes SF #1123: Mistakenly claims "TinyTinyRSS source is not self-updating"
      (reported by Dominik Grafenhoher)
    * Fixes SF #1119: Crash on font resize at startup.
      (reported by David Smith)
    * Fixes #1056, #1089, #1098: Honor preferences when opening links
      (patch by Daniel Seither)
    * Fixes #1117: Selecting last unread item in reduced feed list jumps to next feed
      (reported by Bruce Guenter)
    * Fixes missing "Via" metadata type
      (patch by Rich Coe)
    * Fixes incorrect new count reset handling in item_state.c and 
      some of the node source implementations.
    * Fixes SF #1096: missing installation of liferea.convert file
      (reported by stqn) 
    * Fixes SF #1135: liferea-add-feed doesn't process feed:https//
      (patch by Kevin Walke)
    * Fixes SF #1137, #1142: startup race with LifereaHtmlView
      (reported by Yanko Kaneti)
    * Fixes Github #13: Parsing errors not visible with dark themes
      (reported by Steve Kelly)
    * Fixes Github #29: Do not use bold text for feeds/folders with unread items
      in the leftmost treeview (repored by Jeff Fortin)
    * Fixes SF #1141: Liferea does not update feeds with TinyTinyRSS
      (reported by Dominik Grafenhofer, denk_mal, Fabian Henze)
    * Fixes SF #1150: subscription prop/source: not all fields and
      buttons visible (reported by David Smith)
    * Fixes Github #26: RTL comments appear incorrectly
      (reported by yaconf)
    * Fixes Github #27: Images do not autosize to fit the available space
      (reported by Jeff Fortin)
    * Fixes Github #34: Add TinyTinyRSS Enclosure Support
      (reported by Adrixan)
    * Fixes Github #43: "Any of the following" search condition doesn't work
      (reported by Jeff Fortin)
    * Fixes Github #49: Some dialogs scrolling areas do not request enough height
      (reported by Jeff Fortin)
    * Fixes Github #53: Doesn't automatically update feed name and favicon
      for new feed (reported by asl97)
    * Patch SF #224: Update to new libxml2 buffer API
      (Simon Kagedal Reimer)
    * Patch SF #209: Avoid copying list in itemset_merge_items
      (kaloyan)
    * Make Liferea use ETags and send If-None-Match
      (patch by Chris Siebenmann)
    * Support NOCONFIGURE for RPM builds
      (Charles A Edwards)

    * Rename README to README.md
    * Removing libindicate support (to be added as plugin maybe)
    * Removing libnotify support (to be added as plugin maybe)
    * Removing build in tray icon support
    * Added tray icon plugin
    * Added category/folder support for TheOldReader
    * Added folder auto-removal for TinyTinyRSS & TheOldReader

    * Updated README on plugin contribution
    * Updated Arabic translation (Khaled Hosny)

Finally please note that this is an unstable release and might have quite some bugs.

So please help testing!

Download

You can download the release on Github:
https://github.com/lwindolf/liferea/releases/tag/v1.11.0

Liferea: git master now has TinyTinyRSS podcast support

If you use TinyTinyRSS synchronization and care about podcast try git master (upcoming 1.11.0 unstable release) to also fetch podcasts!

Continuous Liferea git master builds with Travis CI

Today I set up Travis for Liferea git master. This should reduce mistakes like forgetting to add files or dependencies as well as testing compilation with LLVM.

I also converted the README to Markdown syntax and the new README.md now has a Liferea screenshot and a Travis build status badge looking like this:

Liferea Project Moved to Github

Today I closed the ticket tracker at Sourceforge the last remaining project tool there. Several maintainers and users already started using the new one at Github. Please also do!

If I set everything correctly the SF bugs should stay readable for everyone. You just cannot edit them anymore. I plan to close all of them with appriopriate results. In any case if you mind please reopen at Github:

https://github.com/lwindolf/liferea

Moving to Github simplifies my workflow a lot (especially the auto-linking of tickets by commits with ticket id) and less time will be spend on maintaining the tickets and more on the code and the actual issues to solve.

Also feel invited to make many many pull requests!

Invisible Tray Icon in Ubuntu Unity 14.04

If you are using Ubuntu Unity as desktop environment and after upgrading to Ubuntu 14.04 the tray icon disappears please workaround by running:

gsettings set com.canonical.Unity.Panel systray-whitelist "['all']"

TheOldReader Categories Support in Liferea git master

Git master now features categories support when subscribing to theoldreader.com accounts. As TheOldReader allows only level of folders nested folders are not possible. Still this allows to organize the feeds neatly. If you already have a subscription don't worry your feeds will be automatically reorganized without loosing any items.

The TheOldReader category support will be first included in release 1.11.0

How Common Are HTTP Security Headers Really?

A recent issue of the German iX magazin featured an article on improving end user security by enabling HTTP security headers

  • X-XSS-Protection,
  • X-Content-Type-Options MIME type sniffing,
  • Content-Security-Policy,
  • X-Frame-Options,
  • and HSTS Strict-Transport-Security.

The article gave the impression of all of them quite common and a good DevOps being unreasonable not implementing them immediately if the application supports them without problems.

This lead me to check my monthly domain scan results of April 2014 on who is actually using which header on their main pages. Results as always limited to top 200 Alexa sites and all larger German websites.

Usage of X-XSS-Protection

Header visible for only 14 of 245 (5%) of the scanned websites. As 2 are just disabling the setting it is only 4% of the websites enabling it.

Website Header
www.adcash.com X-XSS-Protection: 1; mode=block
www.badoo.com X-XSS-Protection: 1; mode=block
www.blogger.com X-XSS-Protection: 1; mode=block
www.blogspot.com X-XSS-Protection: 1; mode=block
www.facebook.com X-XSS-Protection: 0
www.feedburner.com X-XSS-Protection: 1; mode=block
www.github.com X-XSS-Protection: 1; mode=block
www.google.de X-XSS-Protection: 1; mode=block
www.live.com X-XSS-Protection: 0
www.meinestadt.de X-XSS-Protection: 1; mode=block
www.openstreetmap.org X-XSS-Protection: 1; mode=block
www.tape.tv X-XSS-Protection: 1; mode=block
www.xing.de X-XSS-Protection: 1; mode=block; report=https://www.xing.com/tools/xss_reporter
www.youtube.de X-XSS-Protection: 1; mode=block; report=https://www.google.com/appserve/security-bugs/log/youtube

Usage of X-Content-Type-Options

Here 15 of 245 websites (6%) enable the option.

Website Header
www.blogger.com X-Content-Type-Options: nosniff
www.blogspot.com X-Content-Type-Options: nosniff
www.deutschepost.de X-Content-Type-Options: NOSNIFF
www.facebook.com X-Content-Type-Options: nosniff
www.feedburner.com X-Content-Type-Options: nosniff
www.github.com X-Content-Type-Options: nosniff
www.linkedin.com X-Content-Type-Options: nosniff
www.live.com X-Content-Type-Options: nosniff
www.meinestadt.de X-Content-Type-Options: nosniff
www.openstreetmap.org X-Content-Type-Options: nosniff
www.spotify.com X-Content-Type-Options: nosniff
www.tape.tv X-Content-Type-Options: nosniff
www.wikihow.com X-Content-Type-Options: nosniff
www.wikipedia.org X-Content-Type-Options: nosniff
www.youtube.de X-Content-Type-Options: nosniff

Usage of Content-Security-Policy

Actually only 1 website in the top 200 Alexa ranked websites uses CSP and this lonely site is github. The problem with CSP obviously being the necessity to have a clear structure for the origin domains of the site elements. And the less advertisments and tracking pixels you have the easier it becomes...

Website Header
www.github.com Content-Security-Policy: default-src *; script-src https://github.global.ssl.fastly.net https://ssl.google-analytics.com https://collector-cdn.github.com; style-src 'self' 'unsafe-inline' 'unsafe-eval' https://github.global.ssl.fastly.net; object-src https://github.global.ssl.fastly.net

Usage of X-Frame-Options

The X-Frame-Options header is currently delivered by 43 of 245 websites (17%).

Website Header
www.adcash.com X-Frame-Options: SAMEORIGIN
www.adf.ly X-Frame-Options: SAMEORIGIN
www.avg.com X-Frame-Options: SAMEORIGIN
www.badoo.com X-Frame-Options: DENY
www.battle.net X-Frame-Options: SAMEORIGIN
www.blogger.com X-Frame-Options: SAMEORIGIN
www.blogspot.com X-Frame-Options: SAMEORIGIN
www.dailymotion.com X-Frame-Options: deny
www.deutschepost.de X-Frame-Options: SAMEORIGIN
www.ebay.de X-Frame-Options: SAMEORIGIN
www.facebook.com X-Frame-Options: DENY
www.feedburner.com X-Frame-Options: SAMEORIGIN
www.github.com X-Frame-Options: deny
www.gmx.de X-Frame-Options: deny
www.gmx.net X-Frame-Options: deny
www.google.de X-Frame-Options: SAMEORIGIN
www.groupon.de X-Frame-Options: SAMEORIGIN
www.imdb.com X-Frame-Options: SAMEORIGIN
www.indeed.com X-Frame-Options: SAMEORIGIN
www.instagram.com X-Frame-Options: SAMEORIGIN
www.java.com X-Frame-Options: SAMEORIGIN
www.linkedin.com X-Frame-Options: SAMEORIGIN
www.live.com X-Frame-Options: deny
www.mail.ru X-Frame-Options: SAMEORIGIN
www.mozilla.org X-Frame-Options: DENY
www.netflix.com X-Frame-Options: SAMEORIGIN
www.openstreetmap.org X-Frame-Options: SAMEORIGIN
www.oracle.com X-Frame-Options: SAMEORIGIN
www.paypal.com X-Frame-Options: SAMEORIGIN
www.pingdom.com X-Frame-Options: SAMEORIGIN
www.skype.com X-Frame-Options: SAMEORIGIN
www.skype.de X-Frame-Options: SAMEORIGIN
www.softpedia.com X-Frame-Options: SAMEORIGIN
www.soundcloud.com X-Frame-Options: SAMEORIGIN
www.sourceforge.net X-Frame-Options: SAMEORIGIN
www.spotify.com X-Frame-Options: SAMEORIGIN
www.stackoverflow.com X-Frame-Options: SAMEORIGIN
www.tape.tv X-Frame-Options: SAMEORIGIN
www.web.de X-Frame-Options: deny
www.wikihow.com X-Frame-Options: SAMEORIGIN
www.wordpress.com X-Frame-Options: SAMEORIGIN
www.yandex.ru X-Frame-Options: DENY
www.youtube.de X-Frame-Options: SAMEORIGIN

Usage of HSTS Strict-Transport-Security

HSTS headers can only be found on a few front pages (8 of 245). Maybe it is visible more on the login pages and is avoided on front pages for performance reasons, maybe not. That would require further analysis. What can be said is only some larger technology leaders are brave enough to use it on the front page:

Website Header
www.blogger.com Strict-Transport-Security: max-age=10893354; includeSubDomains
www.blogspot.com Strict-Transport-Security: max-age=10893354; includeSubDomains
www.facebook.com Strict-Transport-Security: max-age=2592000
www.feedburner.com Strict-Transport-Security: max-age=10893354; includeSubDomains
www.github.com Strict-Transport-Security: max-age=31536000
www.paypal.com Strict-Transport-Security: max-age=14400
www.spotify.com Strict-Transport-Security: max-age=31536000
www.upjers.com Strict-Transport-Security: max-age=47336400

Conclusion

Security headers are not wide-spread on website front pages at least. Most used is the X-Frame-Option header to prevent clickjacking. Next following is X-Content-Type-Options to prevent MIME sniffing. Both of course are easy to implement as they most probably do not change your websites behaviour. I'd expect to see more HSTS on bank and other online payment service websites, but it might well be that the headers appear only on subsequent redirects when logging in, which this scan doesn't do. With CSP being the hardest to implement, as you need to have complete control over all domain usage by application content and partner content you embed, it is no wonder that only Github.com has implemented it. For me it is an indication how clean their web application actually is.

Liferea Bug Tracker Switching to Github

Dear maintainers and contributing end users,

I plan to switch the bug tracker from SourceForge to Github to the end of the month (31.05.2014) to further simplify the workflow of maintaining Liferea. As a benefit at Github I'll maintain milestones with due dates and assigned issues. The Github bug tracker is already in use by some users. Feel free to use it right now.

Nothing Gets Lost!

I won't ignore the old tickets, they will just become invisible. I promise to process all important SF tickets. I believe you will still get mail notifications on state changes. For the maintainers: if you still need to access the tickets I we can find a solution (admin user role...). I know this pains you guys probably the most and don't want to mess up your valuable work more than absolutely necessary.

If you are in any doubt please drop a short mail on the mailing list or just recreate all the tickets at Github: https://github.com/lwindolf/liferea/issues?milestone=2&state=open

The Future

I plan to entirely stop using the Sourceforge tools in favour of Github. Sourceforge is just not very useable. Code formatting looks funny all the time. One needs to edit tickets to change state. Also the commit correlation with tickets in Github is just a killer feature for me.

For the future I also hope to invite more contributions via Github forking and merging. By also switching more code to Python plugins I can imagine some more users crossing the barrier, that coding in C is, and contribute.

Syndicate content