Android

Manually Update Time Zone Data on Android 10

Tuesday, October 31, 2023 

One of the updates that stops when your carrier decides you have to buy a new phone to keep their profits up is the time zone data, which means as regions decide they will or won’t continue using standard time and will switch permanently to lazy people time (or not), time zone calculations start to fail, which can be awfully annoying when it causes you to miss flights or meetings.  It is probably something you’ll want to keep up to date.  Unfortunately, this requires root access to your phone because… profits depend on the velocity by which first world money is converted to e-waste to poison third world children.  Yay.

Root requires reflashing your device, which means wiping all your data and apps and reinstalling them, so easier to do on a new phone than backing up and restoring and re-configuring all your apps.  Sooner or later your vendor will stop supporting your device  in an attempt to get you to throw it away and buy a new one and you’ll have to root it to keep it up to date and secure so you might as well do it now, void their stupid warranty, and take control of your device.

You should also take a moment to write your elected representatives and demand that they take civil action against this crap.  Lets take a short rant break, shall we?

Planned obsolescence, death by security flaws, and vendor locks should be prosecuted, not just as illegal profiteering but as environmental crimes for needlessly flooding the world with e-waste. If you own a device you have the right to use it as you like and any entity that by omission or obfuscation of reasonable information needed to keep that device operational is depriving legitimate owners of rightful value. Willfully obstructing security updates, knowing full well the risks implied, is coercive if not extortion. Actively blocking the provision of third party services intended to mitigate these harms through barratry and legal extortion should be prosecuted aggressively. Everyone who has purchased a phone that has been intentionally and unfairly life-limited by non-replaceable batteries, intimidation of repair services, manipulation of the spare parts market, or restrictions or obfuscation of security updates is due refund of the value thus denied plus penalties.

Ah, that feels better, no?

Assuming you have a rooted phone, adb installed on your computer, and your TZ data is out of date, lets get it fixed, shall we?  The problem is that TZ data comes from IANA, from here actually, and is versioned in a form like 2023c, the current as of now. That’s lovely but the format they provide is not compatible with android and needs to be transformed.  Google seems to have some tools for this in the FOSS branch of Android, but it seems a little useless without a virtual environment, a PITA. But the good folks at LineageOS (yay, FOSS!!!) maintain their version of the tool with the thus created output data in their git, which we can use for all android devices (it seems).  The files we need are in this directory: note that these are 2023a, but 2023c is identical to 2023a, reverting some changes made in 2023b because, I don’t know, the whole mess about getting up an hour earlier or later being some traumatic experience when it happens twice a year is catastrophic for people’s sense of well being, but when they get up at different times on days off than on work days, that doesn’t count or something. OMG.  so drama.  people. sometimes it hurts to be associated with them as a species. Not that I care, but stop messing around and just pick one. So many rant triggers in this whole mess.

Anyway, proceeding with the assumption your device is rooted and you have adb installed on your computer, the files needed are:

tzdata        a binary file that if you view with a text editor should start with: tzdata2023a
tzlookup.xml  an xml file that should (nearly) start with: <timezones ianaversion="2023a">
tz_version    a simple text file that should have one line: 003.001|2023a|001

Download the compressed .tgz archive of the output_data directory from here by clicking on the [tgz] text at the top right

You should get a .tgz archive, from which you want to extract:

  • tzlookup.xml from the android folder
  • tzdata from the iana folder
  • tz_version from the version folder

Here’s the tricky bit, you gotta get these files to the right places. So I mounted my android on my computer and created a folder TZData in Downloads and copied the files there, this resolved to /data/media/0/Download/TZdata/ on my device.  While you’re there, make a folder like oldTZ in the same place for backup.  Everything else is done by command line via adb.

(comments are demarked with "#", the prompt is assumed)
# get shell on your device
adb shell
# get root, if this fails, you don't have root, bummer, you don't really own your device.
su root
# verify your tz data is where mine was, if so copypasta should be safe.
find / -name tzdata 2>/dev/null
#output for me looks like some are symlinks
/apex/com.android.tzdata/etc/tz/tzdata
/apex/com.android.tzdata@290000000/etc/tz/tzdata
/apex/com.android.runtime/etc/tz/tzdata
/apex/com.android.runtime@1/etc/tz/tzdata
/system/apex/com.android.runtime.release/etc/tz/tzdata
/system/apex/com.android.tzdata/etc/tz/tzdata
/system/usr/share/zoneinfo/tzdata
# did ya get the same or close enough to figure out what to do next? good.
# Backup your old stuff
cp /system/apex/com.android.tzdata/etc/tz/* /data/media/0/Download/oldTZ
# your directories are read only, so you need to fix that, scary but reversible
mount -o rw,remount /
mount -o rw,remount /apex/com.android.tzdata
mount -o rw,remount /apex/com.android.runtime
# copy the new files over the old files, the last location is legacy and doesn't
# seem to have a copy of tzlookup.xml, so we don't put a new one there, but check
ls /system/usr/share/zoneinfo
# only tzdata and tz_version?  Good.
cp /data/media/0/Download/TZdata/* /apex/com.android.tzdata/etc/tz
cp /data/media/0/Download/TZdata/* /apex/com.android.runtime/etc/tz
cp /data/media/0/Download/TZdata/* /system/apex/com.android.tzdata/etc/tz
cp /data/media/0/Download/TZdata/tz_version /system/usr/share/zoneinfo
cp /data/media/0/Download/TZdata/tzdata /system/usr/share/zoneinfo
# all done, now we just gotta read-only those directories again
mount -o ro,remount /
mount -o ro,remount /apex/com.android.tzdata
mount -o ro,remount /apex/com.android.runtime
# and why not reboot from the command line?
reboot

That was fairly painless once you know what to do and have root, no?  it worked for me, my phone rebooted and the time zone database appears to be updated.  YMMV, hopefully not the reboot successfully part but bricking a phone is a risk because, you know, profits.  After that tz file surgery I created a new event in a US time zone that recently changed their daylight savings to pacify the crazies and it seemed to work as expected.

Posted at 18:25:30 GMT-0700

Category: Cell phonesGeopostHowToLinuxTechnology

A sad loss for security

Monday, July 20, 2015 

Whisper systems wrote the very useful TextSecure app for Android. It had a great feature of encrypting text messages, a standard communication modality in much of the world and one I rely on often. I have previously suggested it is a good tool.

The last “update” removed the ability to establish new encrypted chats over SMS and, it appears, the next will remove the function entirely. For me, this change substantially reduces the utility of the app.

Reading their arguments for doing so, I find myself disagreeing with their justifications. I understand there was some complexity in establishing encrypted SMS, but frankly initiating a one-time key exchange was about as easy as encrypted communication gets. That iOS users can’t play along is pretty irrelevant: iOS isn’t exactly the platform for secure communications anyway, you carry iOS devices when you want to impress people with your brand awareness, not get things done. That people occasionally end up with a conversation that is half-encrypted seems annoying but hardly all that problematic. The person that uninstalled the app will try to send messages in the clear, not the person who is still running it and a partial session. I can see the annoyance, but not any security leak.

I think the final result is somewhat dangerous. The first incarnation used SMS as the starting point, and once a secure communications were established, if available, coms moved transparently to the data channel. If not, it stayed with SMS. As I work in a place where data service is frequently disabled, this was the most reliable non-voice communication protocol.

Now SMS is unencrypted and data-mode communication is encrypted. You have to remember which is which and that is dangerous.

If they don’t restore encrypted SMS functionality, I will switch back to the standard SMS app, which is insecure SMS only and so not confusing and use chat secure or xabber for encrypted data communications so the difference is clear. You’re probably going to run a jabber-based chat tool anyway chat secure’s Tor integration makes it a better choice for data-mode chat while text secure no longer does anything particularly useful over the default app for SMS-mode nor anything particularly unique for data mode.

Posted at 00:53:41 GMT-0700

Category: Cell phonesSecurity

What’s Right About PGP

Thursday, August 14, 2014 

Occasionally you find the crankypants commentary about the “problems” with PGP. These commentaries are invariably written by people who fail to recognize the use modality that PGP is meant to address.

PGP is a cryptographic tool that is, genuinely, annoying to use in most current implementations (though I find the APG extension to the K9 mail app on the android as easy or easier to use than the former Enigmail implementation for Thunderbird, since replaced by a less fully featured native implementation.)  The purpose of PGP is to encrypt the contents of mail messages sent between correspondents.  Characteristics of these messages are that they have more than ephemeral value (you might need to reference them again in the future) and that the correspondents are not attempting to hide the fact that they correspond.

It is intrinsic to the capabilities of the tool that it does not serve to hide with whom you are communicating (there are tools for doing this, but they involve additional complexity) and all messages encrypted with a single key can be decrypted with that key. As such keys are typically protected by a password the user must remember. It is a sufficiently accurate simplification of the process to consider the messages themselves protected by a password that the owner of the messages must remember and might possibly be forced to divulge as the fundamental limit on the security of the messages so protected. There are different tools for different purposes that exchange ephemeral keys that the user doesn’t ever know, aren’t protected by a mnemonic password, and therefore can never be forced to divulge).

These rants against PGP annoy me because PGP is an excellent tool that is marred by minor usability problems. Energy expended on ignorantly dismissing the tool is energy that could be better spent improving it.  By far the most important use cases for the vast majority of users that have any real reason to consider cryptography are only addressed by PGP.  I make such a claim based on the following:

  • Most business and important correspondence is conducted by email and despite the hyperventilation of some ignorant children, will remain so for the foreseeable future.
  • Important correspondence, more or less by definition, has a useful shelf life of more than one read and generally serves as a durable (and legally admissible) record.
  • There are people who have legitimate reasons to obfuscate their correspondents: email, even PGP encrypted email, is not a suitable tool for this task.
  • There are people who have legitimate reason to communicate messages that must not be permanently recorded and for which either the value of the communication is ephemeral or the risk is so great that destroying the archive is a reasonable trade-off: email, even with PGP, is not a suitable tool for this task.
  • There’s some noise in the rant about not being sufficient to protect against NSA targeted intercept or thwarting NSA data archiving, which makes an implicit claim that the author has some solution that might provide such protection to end users. I consider such claims tantamount to homicide.  If someone is targeted by state-level surveillance, they can’t use a Turing-complete device (any computer device) to communicate information that puts them at risk; any suggestion to the contrary is dangerous misinformation.

Current implementations of PGP have flaws:

  • For some reason, mail clients still don’t prompt for the import or generation of PGP keys whenever a new account is set up.  That’s somewhat pathetic.
  • For some reason, address books integrated into mail clients don’t have a field for the public key of the associate.  This is a bizarre omission that necessitates add-on key management plug-ins that just make the process more complicated.
  • It is somewhat complicated by IMAP, but no client stores encrypted messages locally in unencrypted form (by default, Thunderbird can do this now), which makes them difficult to search and reduces their value as an archival record.  This has trivial security value: your storage device is, of course, encrypted or exposing your email should your device be lost is likely to be the least of your problems.

PGP is, despite these shortcomings, one of the most important cryptographic tools available.

Awesome properties of PGP keys no other cryptographic system can touch

PGP keys are (like all cryptographic keys in use by any system) long strings of seemingly random data.  The more seemingly random, the better.  They are, by that very nature, nonmnemonic.  Public key cryptosystems, like PGP, have an awesome, incredibly useful characteristic that you can publish your public key (a long, random string of numbers) and someone you’ve never met can encrypt a message using that public key and only your private key can decrypt it: a random stranger can initiate crytopgraphically secure communication spontaneously.

Conversely, you can “sign” data with your “private key” and anyone can verify that you signed it by decrypting it with your public key (or more precisely a short mathematical summary of your message).  This is so secure, it is a federally accepted signature mechanism.

There’s a hypothesized attack called a Man In The Middle attack (often abbreviated “MITM”) that exploits the fact these keys aren’t really human readable (you can, but they’re so long you won’t) whereby an attacker (traditionally the much maligned Eve) intercepts messages between two parties (traditionally the secretive Alice and Bob), pretending to be Bob whilst communicating with Alice and pretending to be Alice whilst communicating with Bob.  By substituting her keys for Alice’s and Bob’s, both Bob and Alice inadvertently send messages that Eve can decrypt and she “simply” forwards Bob’s to Alice using Alice’s public key and vice versa so they decrypt as expected, despite coming from the evil Eve.

Eve must, however, be able to intercept all of Alice and Bob’s communication or her attack may be discovered when the keys change, which is not practical in the real world on an ongoing basis (but, ironically, is easier with ephemeral keys). Pretending to be someone famous is easier and could be more valuable as people you don’t know might send you unsolicited private correspondence intended for the famous person: the cure is widely disseminating key “fingerprints” to make the discovery of false keys very hard to prevent.  And if you expect people to blindly send you high-priority information with your public key, you have an obligation to mitigate the risk of a false recipient.

Occasionally it is hypothesized that this attack compromises the utility of PGP; it is a shortcoming of all cryptographic systems that the keys are not human readable if they are even marginally secure.  It is intrinsic to a public key infrastructure that the public keys must be exchanged.  It is therefore axiomatic that a PKI-based cryptographic system will be predicated on mechanisms to exchange nonmnemonic key information. And hidden key exchange, as implemented by OTR or other ephemeral key systems makes MITM attacks harder to detect.

While it is true that elliptic curve PKI algorithms achieve equivalent security with shorter keys, they are still far too long to be mnemonic.  One might nominally equivalence a 4k RSA key with a 0.5k elliptic curve key, a non-trivial factor of 8 reduction with some significance to algorithmic efficiency, but no practical difference in human readability.  Migrating to elliptic curves is on the roadmap for PGP (with GPG 2.1, now in beta) and should be expedited.

PGP Key management is a little annoying

Actually, it  isn’t so much PGP that makes this true, but rather the fact that mail clients haven’t integrated PGP into the client.  That Gmail and Yahoo mail will soon be integrating PGP into their mail clients is a huge step in the right direction even if integrating encryption into a webmail client is kind of pointless since the user is already clearly utterly unconcerned with privacy at all if they’re gifting Google or Yahoo their correspondence.  Why people who should know better still use Gmail is a mystery to me.  When people who care about data security use a gmail address it is like passing the temperance preacher passed out drunk in the gutter.  With every single message sent.  Even so, this is a step in the right direction by some good people at Google.

It is tragic that Mozilla has back-burnered Thunderbird, but on the plus side they don’t screw up the interface with pointless changes to justify otherwise irrelevant UX designers as does every idiotic change in Firefox with each release.  Hopefully the remaining community will rally around full integration of PGP following the astonishingly ironic lead of the privacy exploiting industry.

If keys were integrated into address books in every client and every corporate LDAP server, it would go a long way toward solving the valid annoyances with PGP key management; however, in my experience key management is never the sticking point, it is either key generation or the hassle of trying to deal with data rendered opaque and nearly useless by residual encryption of the data once it has reached me.

Forward Secrecy has a place.  It isn’t email.

A complaint levied against PGP that proves beyond any doubt that the complainant doesn’t understand the use case of PGP is that it doesn’t incorporate forward secrecy.  Forward secrecy is a consequence of a cryptosystem that negotiates a new key for each message thread which is not shared with the users and which the system doesn’t store.  By doing this, the correspondents cannot be forced to reveal the keys to decrypt the contents of stored or captured messages since they don’t know them.  Which also means they can’t access the contents of their stored messages because they’re encrypted with keys they don’t know.  You can’t read your own messages.  There are messaging modalities where such a “feature” isn’t crippling, but email isn’t one of them; sexting perhaps, but not email.

Indeed, the biggest, most annoying, most discouraging problem with PGP is that clients do not insert the unencrypted message into the local message store after decrypting it.  This forces the user to decrypt the message again each time they need to reference it, if they can ever find it again.  One of the problems with this is you can’t search encrypted messages without decrypting them.  No open source client I’m aware of has faced this debilitating failure of use awareness, though Symantec’s PGP desktop does (so it is solvable).  Being naive about message use wouldn’t have been surprising for the first few months of GPG’s general use, but that this failure persists after decades is somewhat shocking and frustrating.  It is my belief that the geekiness of most PGP interfaces has so limited use that most people (myself included) aren’t crippled by not being able to find PGP encrypted mail because we get so little of it.  If even a small percentage of our mail was encrypted, not ever being able to find it again would be a disaster and we’d stop using encryption.

This is really annoying because messages have the frequently intolerable drawbacks of being ephemeral without the cryptographic value of forward secrecy.

Email is normally used as a messaging modality of record.  It is the way in which we exchange contemplative comments and data that exceeds a sentence or so.  This capability remains important to almost all collaborative efforts and reducing messaging complexity to chat bubbles cripples cognitive complexity.  The record thus created has archival value and is a fundamental requirement in many environments.  Maximizing the availability, searchability, and ease of recall of this archive is essential.  Indeed, even short form communication (“chat” in various forms), which is typically amenable to forward secrecy because of the generally low content value thus communicated, should have the option of PGP encryption instead of just OTR in order to create a secure but archival communications channel.

A modest proposal

I’ve been using PGP since the mid 1990s.  I have a key from early correspondence on PGP from 1997 and mine is from 1998.  Yet while I have about 2,967 contacts in my address book I have only 139 keys in my GPG keyring.  An adoption rate of 4.7% for encrypted email isn’t exactly a wild success.  I don’t think the problems are challenging and while I very much appreciate the emergence of cryptographically secure communications modalities such as OTR for chat and ZRTP for voice, I’ve been waiting for decades for easy-to-use secure email.  And yet, when people ask me to help them set up encrypted email, I generally tell them it is complicated, I’m willing to help them out, but they probably won’t end up using it.  Over the years, a few relatively easy to fix issues have retarded even my own use:

  • The fact that users have to find and install a somewhat complex plugin to handle encryption is daunting to the vast majority of users.  Enigmail is complicated enough that it is unusable without in-person walk-through support for most users.  Even phone support doesn’t get most people through setup. Basic GPG key generation and management should be built into the mail client.  Every time one sets up a new account, you should have to opt out of setting up a public key and there’s no reason for any options by default other than entering a password to protect the private key.
  • Key fields should be built into the address book of every mail client by default.  Any mail client that doesn’t support a public key field should be shamed and ridiculed.  That’s all of them until Gmail releases end-to-end as a default feature, though that may never happen as that breaks Google’s advertising model.  Remember, Google pays all their developers and buys them all lunch solely by selling your private data to advertisers.  That is their entire business model. They do not consider this “evil,” but you might.
  • I have no idea why my received encrypted mail is stored encrypted on my encrypted hard disk along with hundreds of thousands of unencrypted messages and tens of thousands of unencrypted documents.  Like any sensible person who takes a digital device out of the house (or leaves it unprotected in the house), I encrypt my local storage to protect those messages and documents from theft and exploitation.  My encrypted email messages are merely data cruft I can’t make much use of since I can’t search for them.  That’s idiotic and cripples the most important use modality of email: the persistent record. Any mail client should permanently decrypt the local message store unless the user specifically requests a message be stored encrypted, an option that should be the same for a message that arrived encrypted or unencrypted as the client could encrypt mail with the user’s public key on arrival without requiring a password or access to the private key.
  • Once we solve the client storage failure and make encrypted email useful for something other than sending attachments (which you can save, ZOMG, in unencrypted form) and feeling clever for having gotten the magic decoder ring to work, then it would make sense to modify mail servers to encrypt all unencrypted incoming mail with the user’s public key, which mitigates a huge risk in having a mail server accessible on the internet: that the historical store of data there contained is remotely compromised.  This protects data at rest (data which is often, but not assuredly, already protected in transit by encrypted transport protocols using ephemeral keys with forward security.)  End-to-End encryption using shared public keys is still optimal, but leaving the mail store unencrypted at rest is an easily solved at rest security failure while protection in transit is largely solved (and would be quickly if gmail bounced any SMTP connection not protected by TLS 1.2+.)

Fixing the obvious usability flaws in encrypted email are fairly easy.  Public key cryptography in the form of PGP/GPG is an incredibly powerful and tremendously useful tool that has been hindered in uptake by limitations of perception and by overly stringent use cases that have created onerous limitations.  Adjusting the use model to match requirements would make PGP far more useful and far easier to convince people to use.

Phil Zimmerman’s essay “why I wrote PGP” applies today as much as it did in 1991:

What if everyone believed that law-abiding citizens should use postcards for their mail? If a nonconformist tried to assert his privacy by using an envelope for his mail, it would draw suspicion. Perhaps the authorities would open his mail to see what he’s hiding.

It has been more than 30 years and never has the need for universally encrypted mail been more obvious.  It is time to integrate PGP into all mail clients.

 

Posted at 14:39:09 GMT-0700

Category: FreeBSDLinuxTechnology

Xabber now uses Orbot: OTR+Tor

Sunday, November 3, 2013 

As of Sept 30 2013, Xabber added Orbot support. This is a huge win for chat security. (Gibberbot has done this for a long time, but it isn’t as user-friendly or pretty as Xabber and it is hard to convince people to use it).

The combination of Xabber and Orbot solves the three most critical problems in chat privacy: obscuring what you say via message encryption, obscuring who you’re talking to via transport encryption, and obscuring what servers to subpoena for at least the last information by onion routing. OTR solves the first and Tor fixes the last two (SSL solves the middle one too, though Tor has a fairly secure SSL ciphersuite, who knows what that random SSL-enabled chat server uses – “none?”)

There’s a fly in the ointment of all this crypto: we’ve recently learned a few entirely predictable (and predicted) things about how communications are monitored:

1) All communications are captured and stored indefinitely. Nothing is ephemeral; neither a phone conversation nor an email, nor the web sites you visit. It is all stored and indexed should somebody sometime in the future decide that your actions are immoral or illegal or insidious or insufficiently respectful this record may be used to prove your guilt or otherwise tag you for punishment; who knows what clever future algorithms will be used in concert with big data and cloud services to identify and segregate the optimal scapegoat population for whatever political crises is thus most expediently deflected. Therefore, when you encrypt a conversation it has to be safe not just against current cryptanalytic attacks, but against those that might emerge before the sins of the present are sufficiently in the past to exceed the limitations of whatever entity is enforcing whatever rules. A lifetime is probably a safe bet. YMMV.

2) Those that specialize in snooping at the national scale have tools that aren’t available to the academic community and there are cryptanalytic attacks of unknown efficacy against some or all of the current cryptographic protocols. I heard someone who should know better poo poo the idea that the NSA might have better cryptographers than the commercial world because the commercial world pays better, as if the obsessive brilliance that defines a world-class cryptographer is motivated by remuneration. Not.

But you can still do better than nothing while understanding that a vulnerability to the NSA isn’t likely to be an issue for many, though if PRISM access is already being disseminated downstream to the DEA, it is only a matter of time before politically affiliated hate groups are trolling emails looking for evidence of moral turpitude with which to tar the unfaithful. Any complacency that might be engendered by not being a terrorist may be short lived. Enjoy it while it lasts.

And thus (assuming you have an Android device) you can download Xabber and Orbot. Xabber supports real OTR, not the fake-we-stole-your-acronym-for-our-marketing-good-luck-suing-us “OTR” (they did, but that link is gone now) that Google hugger-muggers and caromshotts you into believing your chats are ephemeral with (of course they and all their intelligence and commercial data mining partners store your chats, they just make it harder for your SO to read your flirty transgressions). Real OTR is a fairly strong, cryptographically secured protocol that transparently and securely negotiates a cryptographic key to secure each chat, which you never know and which is lost forever when the chat is over. There’s no open community way to recover your chat (that is, the NSA might be able to but we can’t). Sure, your chat partner can screen shot or copy-pasta the chat, but if you trust the person you’re chatting with and you aren’t a target of the NSA or DEA, your chat is probably secure.

But there’s still a flaw. You’re probably using Google. So anyone can just go to Google and ask them who you were chatting with, for how long, and about how many words you exchanged. The content is lost, but there’s a lot of meta-data there to play with.

So don’t use gchat if you care about that. It isn’t that hard to set up a chat server.

But maybe you’re a little concerned that your ISP not know who you’re chatting with. Given that your ISP (at the local or national level) might have a bluecoat device and could easily be man-in-the-middling every user on their network simultaneously, you might have reason to doubt Google’s SSL connection. While OTR still protects the content of your chat, an inexpensive bluecoat device renders the meta information visible to whoever along your coms path has bought one. This is where Tor comes in. While Google will still know (you’re still using Google even after they lied to you about PRISM and said, in court, that nobody using Gmail has any reasonable expectation of privacy?) your ISP (commercial or national) is going to have a very hard time figuring out that you’re even talking to Google, let alone with whom. Even the fact that you’re using chat is obscured.

So give Xabber a try. Check out Orbot, the effortless way to run it over Tor. And look into alternatives to cloud providers for everything you do.

Posted at 08:50:47 GMT-0700

Category: FreeBSDSelf-publishingTechnology

Iraq Blocked For Many Android Apps

Sunday, March 3, 2013 

I’m not sure who decides what apps are blocked on a country by country basis, but an awful lot of apps are blocked in Iraq and it seems like more and more.

iraq_blocked_play_viber.JPG

OTT apps like Whatsapp and Viber sort of make sense. These apps are at war with the carriers, who claim the app is making money somehow on the backs of the carriers*, and they seem to be largely blocked from install in Iraq. One would imagine that was Asiacell’s doing, but I changed SIMs and that didn’t help.

Iraq_blocked_whatsapp.JPG

But then I noticed that weird apps like Angry Birds are not allowed in Iraq—apps that makes no sense for a carrier to block.  The advertising model actually works and ad-supported apps show (some) relevant, regional ads, as they should, in theory generating at least some revenue for the developers. Part of the problem may be that there’s no way for in-app payments to be processed out of Iraq and therefore developers of even “freemium” apps may choose to block their apps in the country reasoning that if they can’t make money, why let people use the app?

Iraq_blocked_angry_birds.JPG

If so, it seems short sighted: ultimately payment processing will be worked out and even if it isn’t, Iraqis are allowed to travel to countries where in-app payments do work. Establishing a beachhead in the market, even without revenue seems prudent. Blocking users who represent neither revenue nor cost seems arbitrarily punitive.

* The carrier’s business should be to transport bits agnostically.  They have no business caring what we do with our bits; no bit costs more than any other bit to carry.  If they can’t figure out how to make money carrying bits, they have no business being in the bit carrying business. When they whine about a business like WhatsApp or Viber or Free Conference Call or Skype or Google hurting their profits what they really mean is that these new businesses have obviated a parasitic business that was profitable due to a de facto monopoly over what people could do with their bit carrying business.

If the bit carriers were competent application layer developers, they’d have developed their own versions of these “OTT” applications.  But they’re not competent developers and so they have not and they’ve squandered the expertise and market control they once had and are now crying that they can’t even make the core bit carrying business work. This should not inspire sympathy or legislative support.
Dear telco, I will pay you a fair market price for carrying my bits.  You have no right to worry about what bits I choose to send after I’ve paid my bit toll.  If you can’t do that, we the people have every right to build our own information highways collectively without you.  And we probably should anyway.

Posted at 05:29:54 GMT-0700

Category: Cell phonesPlacesPoliticsTechnology

Otterboxes for the iPhone and Galaxy S3

Tuesday, January 8, 2013 

There are two things I always do with a new digital device, get a good screen protector and a good case. (And the biggest memory card that will fit).

The screen protector is pretty easy: I’ve used both Zagg and Armor Suit and prefer the Armor Suit, but not by much. Both work really well and I have an Armor Suit on my Motorola Razr V9x (still the best basic cell phone I’ve ever owned) that has lived in my pocket for many, many years without a scratch visible on the outer screen.

For cases I lived with an (almost iconic) yellow Defender case for my Blackberry Bold 9000 for about 5 years.  It was awesome, indestructible, and fit the belt holder perfectly.  Alas, it was no match for a random late night cab ride and early flight out of Dubai–can’t defend against that, can ya? Well, it lasted about 5 years, so no complaints. I contacted Otterbox to see if I could get a replacement silicone bit and they checked and only had 2 belt holsters left in stock from the entire product line.  They mailed me those for free. Thanks Otterbox! (One did come in handy eventually.)

I got an iPod from United and, of course, got an Otterbox for it; one of the Commuter series.  With a polycarbonate outer shell protecting the critical corners, and that backed underneath by a few mm of soft silicone, the iPod is extremely well protected.  This is a well-engineered protection model, far better than just a layer of silicone. (Update 2023: I still use this United 1M mile award iPod)

A corner drop tends to generate very high localized pressure where the corner tries to merge with the hard surface it is being dropped on. Having the polycarbonate outer shell distributes that pressure load over the silicone underneath it resulting in a broad, gentile distribution of the impact load and minimizing the risk of localized overpressure which would crack plastic or glass.

Conversely, simple silicone sleeves without the polycarbonate layer, while adding critical padding and being fairly effective in most cases, can’t distribute the impact load nearly so effectively.  This should not matter too much for a surface-to-surface drop where the impact force is distributed over the whole back or even an edge of the phone, but in a corner drop the silicone can be effectively mushed out of the way as the hard surface attempts touch delicate plastic or glass in a tragic romance.

This outer shell is what distinguishes the Commuter series from Otter’s lower-cost silicone-only Impact series cases, as well as the host of cheap silicone sleeves on the market.

otterbox_iPhone-vs-Galaxy_S_3.jpg

I replaced the Blackberry with a Samsung Galaxy S3 and got a Commuter case for it.  The case is very nice, not too big, but Otterbox did something very, very wrong.  They rotated the polycarbonate tabs 45 degrees, covering the edges and not the corners.  Why Otter, why? The case is still quite nice and it is the nicest looking and most comfortable I’ve found, but this is an odd engineering mistake.  They talk about the “layers of protection” as a key selling point for their more expensive Commuter and Defender series, yet leave the most fragile corners protected by only a single layer.  As protection goes, it is no better than the Impact since the corners are all that really matters.

The polycarbonate shell does serve to anchor the access flaps closed, which is an improvement over the iPod case, but this could easily have been achieved with a few well-placed polycarbonate fingers reaching around the case without making it difficult to assemble (too many fingers wrapping around the device make it impossible to snap the device into the polycarbonate shell).

Further, the textured silicone edges on the iPod case are actually really nice to hold, far more comfortable and slip-resistant than the polycarbonate edges of the S3 case (and make the iPod less likely to drop than the S3 as well).  As an additional bonus, the iPod version exposes some textured silicone on the back surface making the case somewhat non-slip, while the S3 case is all polycarbonate on the back. Without some non-slip silicone on the back, the likelihood that the enclosed device will slip off a sloped surface and onto a hard floor or into a toilet or sink is much greater. While the case makes a disaster far less likely for the former eventuality, it is not waterproof.

While the Android OS just crushes iOS, and the availability of Android-specific tools and applications, particularly for security and encryption, makes it the best choice for a mobile device right now (though security, at least, is even less of a concern with a Blackberry – that’s the one thing Rim still has going for it – that and efficient use of data), Otterbox really could have done a better job with the case.   Hopefully the S4 case will get it right.


 

Update

It has been almost 2 years and I’ve been carrying the Otterbox-protected S3 more or less continuously since in a relatively active and somewhat unforgiving environment, not that anyone’s pocket or purse would fail to meet that definition.  A few issues emerged:

  • The rubber flap covering the USB port, which you need to access at least twice a day for charging, tore off very early on;
  • I change SIMS a few times a month and the case doesn’t really like being taken on and off and eventually cracked in two places, but it still holds together;
  • The unprotected silicone covering the corners began to deteriorate fairly quickly, as I predicted, and one corner has disintegrated completely, leaving that most fragile of impact points unprotected.

Failed corner of the otterbox case

I’d probably buy another – two years is a pretty good life (but not as good as the 5 my blackberry gave me.  I still miss that phone).  I wish Otterbox would focus on protecting the corners, not the edges. The iPod case, far less heavily used but equally traveled shows no wear on the corners at all and provides the same protection it did two years ago.  It is a better design.

Update 2023, ten years later

The S3 is long gone and the case with it.  It was already disintegrating starting with the exposed corners I didn’t like when I got it back in 2012.  The iPod case?  Still on that iPod which is still working.  More than 2 million miles, just on United iron, and still going strong.

Posted at 12:36:41 GMT-0700

Category: Cell phonesNeutralphotoReviewsTechnology