There is no such thing as perfect security. And in practice, the time resourced needed for hardening a server are an additional limitation for the security level you can reach. That's why I searched for adequate security principles to guide us when securing a web server. Here's my proposal, feel free to discuss.

To develop a meaningful set of principles, we have to start with a risk assessment. My set of principles is for what I consider a "typical webserver" (presenting publicly accessible information, enabling private messaging, maybe containing secret sourcecode of SaaS applications, secret but not sensitive custoemr data connected to these SaaS apps, and maybe paywall-protected downloads.)

So we develop the security principles for the this worst-case damage: "Combined financial and worktime loss equivalent to a one-month." This also includes financial losses by fines and charges resulting from leaked data. The leaking of paywall-protected downloads, with or without an integrated licencing mechanism, is not considered a financial loss here because they're "leaked" to a paying customer anyway.

My current proposal for security principles is this – feel free to discuss:

  1. Limit damage by proper access rights when non-root access is compromised.
  2. Do not even try to limit damage for a case of compromised root access. It would only complicate day-to-day work, and all user data is compromised anyway. So if other passwords are also compromised or not is not of much additional importance, so we won't care about key-stretching, salting etc. in that context. Only to detect root logins.
  3. Care to detect root access immediately.
  4. Assume that the server, before starting the hardening, is an uncompromised setup. Everything else would mean to completely re-setup the server, to get rid of root kits etc..
  5. Harden against everything but high-profile hackers. The server is to be hardened against automatic attacks of botnet operators, against (D)DoS attacks, and against targeted attacks of moderately sophisticated hackers (who use known tools and techniques remotely and at most 10 days of work). Do not try to secure against high-profile hackers who might use new ingenious combinations of tools and techniques, zero-day exploits, and a lot of time and energy. This also means, do not try to secure against attack types that require physical proximity or physical access to either the server or a server user's location – these are highly unlikely to happen for servers that contain only moderately valuable information.
    This protects against the ubiquitous dangers of the web, and against low-profile targeted hacking attempts against sites hosted on the server (as they could be executed by personal enemies or competitors of customers hosting their site there). But this also means, it could be broken by high-profile hackers (which will only happen if the server contains valuable data of course).
  6. Do not store high-value data on the server. The server should withstand 10 person days worth of high-profile hacker attacks, but might break with some bad luck at an undetermined point afterwards. Everybody using the server (including customers, if it's a commercial webhost) should know about that security level, and based on that they should decide what kind of data to entrust the server with. Some simple rules for that:
  • Don't store something that could cause bigger damage than shown in the risk profile above. For example, do not store Bitcoins worth more than a few thousand USD.
  • If you have to store high-value data, decrease its value by the mode of storing it, if possible. For example, store your company's SaaS application not as plaintext source, but obfuscated.
  • Do not store information on these servers that might lead to a criminal conviction. This esp. refers to sensitive e-mails, which should not be stored permanently in IMAP except in encrypted form. Not storing such information on a server in unencrypted form is advisable anyway, as the biggest danger to such information is not hackers but law enforcement agents.

First, to diagnose whether the whole screen does not work or just not the backlight, you can do this:

  1. Power up the phone, it will vibrate shortly to acknowledge that it starts.
  2. Wait for 2 minutes to let the phone finish booting, so you can be sure there "should be" something on the screen.
  3. Use a flashlight in a somewhat darkened room and light directly on the screen, by placing the flashlight head on the glas. If only the backlight does not work, you should see a dim screen image around the flashlight head now.
  4. If this did not work, try some other spot and make sure only little light escapes from the flashlight that does not go into the screen. Finding a spot that shows white on the display will work best for this, as this means the light can go through the whole display into the light dispersing mat behind it, disperse like normal display background light, and emerge from a larger area around the flashlight head.

[TODO: Find out how to test the screen backlight of a display unit.]

[TODO: Find out if the screen backlight (probably LEDs of a display unit can be replaced while keeping the screen.]

Procedure to exchange the screen:


There is an interesting discussion about typical failures of the screen replacement procedure. Mostly a gap between display and phone case at the upper edge of the display.

You can, but potentially only in the GSM (2G) network (then, you would get only GPRS / EDGE data connections, no UMTS (3G) ones).

To make sure you can use a North American smartphone also in Europe, you have to look at what frequency bands are supported by the phone, and what frequency bands are in use by the phone networks in your country. Here's an overview:

Frequency GSM
North American networks: T-Mobile USA [source] x x x x     x   x  
North American networks: AT&T USA [source] x x x x x       x  
European networks [source] x x x x   x   x   x
HTC Sensation Z710e [source]
T-Mobile version ("Sensation 4G")
x x x x   x x     x
HTC Sensation Z710a [source]
international version, Bell version, Telstra version
x x x x x       x x
HTC Sensation XE Z715e [source, source, source] x x x x   x x     x
HTC Sensation XE Z715a [source]
Telstra version, Vodafone Australia version
x x x x x       x x
HTC Desire HD                    
HTC Desire                    

Effect for Europeans: you can use all of the HTC Sensation / Sensation XE variants in European networks.

Sometimes, the models for the North American and European market carry different names. For example, the "HTC Sensation 4G" is the name given to the HTC Sensation by T-Mobile for launching it in the U.S.. The hardware is just the Z710e version, and it is supported by CyanogenMod 10 (at least) [example].

This is the index for all the open content (licensed CC-BY 3.0) knowledge base articles of my little phone repair and modding business called "Freedom Fones".

Hope it's useful! Please report errors and inaccuracies.

Maintenance: Model specific manuals

These manuals link to other model-specific articles that are not listed here.

There are some more model-specific articles for models that don't have a manual yet:

Maintenance: General articles

These are also partially linked to in the above manuals, but are relevant for many more phone models.


This collects articles about productive and privacy-enabled usage of Android, not tied to any phone model.


Chunks of knowledge that have to be sorted into the above or new articles.

  • Creating backups. Boot into 4EXT Recovery and choose to do a backup from the menu option for it. It will backup everything that's not on the SD card (so, system partition and apps) to the SD card.
  • Hard reset procedure.
  • Legality in Europe. "The Free Software Foundation Europe argues that it is legal to root or flash any device. According to the European Directive 1999/44/CE, replacing the original operating system with another does not void the statutory warranty that covers the hardware of the device for two years unless the seller can prove that the modification caused the defect."
  • Spare part source: spare parts and tools for many HTC phones (also others).
  • Checking a MD5 sum in command line (note that you have to place exactly two spaces after the MD5 hash for this to work):
    echo "fefbcf7a411df7df31fea65417d92f36  filename.ext" | md5sum –check
  • Spare parts source:
  • Spare parts source in Germany:–ersatzteile.php
  • HTC Desire HD disassembly with photos (no video):
  • headset hardware repair when the buttons do not work:
  • Spare parts source:
  • Spare parts and tools source:

This is my way of installing it, on an Ubuntu Linux 12.04 host.

  1. Make sure you meet the installation requirements of Drupal 7 (as per its INSTALL.txt). The simplest set of alternatives:
    • Apache 2.0 or greater
    • PHP 5.2.4 or greater
    • MySQL 5.0.15 or greater
  2. Create a directory where you want your Drupal installation to reside. It does not have to be below your /var/www/ document root, we'll sort that out.
  3. Switch to the directory you just created and create an empty local git repository in it by calling: git init. The repository is created in ./.git/.
  4. Download the latest version for Drupal 7 from the Drupal Commons project website. In my case it was the 7.x-3.x-dev pre-release version dating 2012-12-21.
  5. Unpack the Drupal Commons package into your git repo directory:
    tar -xzf ../commons-7.x-3.x-dev-core.tar.gz
    mv commons-7.x-3.x-dev/* commons-7.x-3.x-dev/.gitignore commons-7.x-3.x-dev/.htaccess .
    rmdir commons-7.x-3.x-dev/
  6. Do an initial git commit:
    git add .
    git commit -m "Initial commit: Drupal 7 Social Commons 3.x."
  7. Install Drush locally. With Ubuntu multiverse repos enabled, execute:
    sudo apt-get install drush drush-make
  8. Create the working Drupal site with Drush. Enter the directory of your Drupal installation and execute:
    drush site-install standard --db-url=mysql://dbuser:dbpassword@localhost:port/dbname --db-su=root-user --db-su-pw=root-password --site-name="Your Site Name"
    In there, replace root-user with your MySQL superuser user name (normally admin) and root-password with its password. Giving that information enables Drush to create the database you want to use for teh Drupal installation and gave via dbuser, dbpassword, port and dbname.
  9. Do another git commit:
    git add .
    git commit -m "After drush site-install."
  10. Make the Drupal 7 site accessible on your local Apache webserver.
    sudo vi /etc/apache2/sites-available/your-site-name
    Add the following content and save it:


    <VirtualHost *:80>
            ServerAdmin webmaster@localhost

            DocumentRoot /home/user/path/to/your/site
            ServerName your-site-name.localdomain

            <Directory /home/user/path/to/your/site/>
                    Options Indexes FollowSymLinks MultiViews
                    AllowOverride All
                    Order allow,deny
                    allow from all

            ErrorLog ${APACHE_LOG_DIR}/error.log

            # Possible values include: debug, info, notice, warn, error, crit,
            # alert, emerg.
            LogLevel warn

            CustomLog ${APACHE_LOG_DIR}/access.log combined


    Then execute, to enable this site:
    cd /etc/apache2/sites-enabled/;
    sudo ln -s ../sites-available/edgeryders ../sites-enabled/001-edgerydersRestart your Apache:

  11. Add name resultion for your new site. In this case, we simply use the hosts file. Just add the following line to /etc/hosts, in accordance to the domain name you chose for the Apache configuration above: your-site-name.localdomain
  12. Make sure mod_rewrite is enabled in your Apache webserver. (It is expected by Drupal 7 by default, and if not loaded, all POST forms will not work but with no error message, so even login will not work then. See Drupal issue 932636.) To enable it, execute:
    cd /etc/apache2/mods-enabled
    sudo ln -s ../mods-available/rewrite.load .
  13. Restart your Apache webserver:
    sudo service apache2 restart
  14. Reset your Drupal admin user's password (since I could not find out which one Drush uses when creating that user):
    drush user-password admin --password="some-password"
  15. Access your site and log in as user "admin" with the password you have just set. Just access this URL, in accordance to how you configured your domain name in your Apache config:


If you have admin access to the software that generates the RSS feed, you have a lot of options as detailed here. If you don't have that admin access, or want an easier solution, the only working ones that I found are in this list.

Working and probably working solutions:

  • Feedburner. It is proposed that one can onvert a simple RSS feed into one that has PubSubHubbub enabled in it by feeding it through [source1source2]. This normally works. With one exception: If the feed uses HTTPS (and only that; as done by for example), this triggers a longstanding bug in Feedburner, namely "Received HTTP error code 400 while fetching source feed." [source1source2].
  • This seems to be one of the best Feedburner alternatives. (I did no make exactly sure though that they do indeed add PubSubHubbub when processing one feed into another one.) The drawback is, it always costs money. However it costs money only for the publisher, not for the subscribers, and you pay only 1.49 USD monthly for any number of RSS subscribers if you do not have e-mail subscribers.
  • Self-hosted PuSH hub with polling. There are free software PubSubHubbub hubs you can run on your server. Hopefully one included polling – start searching here. However, compared to the lightweight utilities "RSS to" and "feed2omb" (see above), this seems like overkill. Except you want PuSH feeds anyway.

​Partially working and non-working solutions:

  • and Guzzle Ayup!. It is possible to create both a free publisher and subscriber account at superfeedr and Guzzle Ayup!, which results in a RSS feed with PubSubHubbub enabled [source]. However, subscribers to this feed have to use a username and password, and pay for getting notifications. This is a problem, as such a fee is only acceptable for big subscribers like a social network app operator. For normal users (or the SubMirror plugin for auto-posting RSS entries), this is not a viable solution.
  • Open PuSH hub with polling. If you find a gratis PubSubHubbub hub with pollling, that would work. It is like the solution above, just that accessing the feed does not need climbing over a paywall. I did not find such a service though, maybe you have more luck.
  • Zapier. Does not work: You can create a RSS-to-RSS zap there, but the target RSS has no added PubSubHubbub support. So cannot subscribe to it. Also it is a HTTPS feed as well, so we can't route it through Feedburner to add the PubSubHubbub …
  • IFTT. Does not work: With them, it is not possible to create a "RSS to RSS" chain at all. Somebody tell 'em.


Auto-posting your activity from the N-1 social network as Twitter and status updates. It is not required to post all and every activity, but the most meaningful part would be to post the N-1 "wire posts", which are Twitter-like short status updates within N-1.

N-1 wire posts to Twitter

Access your N-1 wire posts as RSS feed and use a web service that posts RSS to your Twitter / account. Step by step:

  1. Log into your account, click in the main menu on "The Wire", then on the tab "Mine". The page's URL will look like
  2. In the right area of the page, you see an RSS icon for this very page (that is, your own wire posts). Copy its link location; that will be an URL looking like:
  3. Choose a web service that can post RSS entries to social networks, according to your needs:

    • IFTTT – The most powerful variant, but also more complex. Allows rule-based connections between (currently) 59 channels, including Twitter and many other social networking stuff, but missing [source].
    • Twitterfeed – With them, you can post your RSS entries to Twitter, Facebook and Linkedin [source].
    • – You can post your RSS feed (and other sources) to Facebook, Twitter, LinkedIn, Tumblr and, according to my own test.
  4. Use your above RSS URL and configure your web service of choice to post your RSS entries to Twitter.

Note that this solution is not fast because it is polling-based. If you use IFTTT for example, the polling period is 15 minutes. The N-1 RSS feed does not have PuSH support, so you cannot use the IFTTT Quick Triggers or similar mechanisms to get instant updates.

N-1 wire posts to

Alternative 1 (best): Sync to Twitter

The only working solution that I found was getting your N-1 wire posts over to Twitter as indicated above, then syncing your account with your Twitter account with's "Settings -> Twitter" feature.

Alternative 2: Self-hosted utility

There are at least two utilities you can run on your own server to poll any RSS feed and publish its entries to (via its API):

Alternative 3: Adding PuSH to the RSS feed, feeding to mirroring

This would normally be a straighforward solution like this: (Note that the first two steps are the same as in the Twitter solution.)

  1. Log into your account, click in the main menu on "The Wire", then on the tab "Mine". The page's URL will look like
  2. In the right area of the page, you see an RSS icon for this very page (that is, your own wire posts). Copy its link location; that will be an URL looking like:
  3. Log in to your account.
  4. Navigate to "Settings -> Mirroring -> RSS or Atom feed"
  5. Enter your RSS feed URL that you determined above, click "Add feed".

However, at this point you get "Internet Server Error: Could not subscribe to feed." from even though the RSS feed is working, publicly accessible and has a post in it. This is because expects the feed to support PubSubHubbub [source1source2], which the feed does not support.

So what you have to do is adding PubSubHubbub to your RSS feed without admin access. It's technically possible, but in this particular case quite an effort because the feeds use HTTPS only (which is not compatible with feedburning the feeds to add PuSH). See my linked post for details.

Other Activity to Twitter /

Currently not possible.

Long story: Your N-1 wire posts RSS feed is publicly accessible (as of 2012-12-23). That's why the IFTTT / Twitterfeed / services could be used on it. Interestingly, all other RSS feeds for other types of activity are password protected, they only work if you are logged in. That is, they are inaccessible for web services like IFTTT and Twitterfeed. (Even worse, a proper N-1 RSS URL like will always show your own activity regardless of what user name you put in.)

Now there is one tool called Zapier that can access password-protected RSS feeds and create unprotected feeds from them (or directly push the message to Twitter – not to services like however). I did not try this, however I assume that this refers to Basic HTTP authentication, while your required N-1 login is something else. Probably won't work so.

So we better care to get the bugs fixed in the N-1 software so that all public content is also available in RSS feeds without the need to log in. (A friend of mine reported these issues 2012-12-23, so they might be fixed soon.)