FreePress Blog

This is a review post for the Pyle PSWP20BL MP3 Player I recently purchased for use during lap swimming.

TLDR: It’s good. Make sure the earplugs fit well.

A couple weeks ago I decided to get back into lap swimming. For whatever reason, it seems to be the only regular workout routine that has worked for me historically, but the huge drawback is it’s just so boring. Being able to listen to podcasts or audio books is great for making the time fly during tedious tasks like this, but at least up until now that hasn’t been a good mix with being in the water.

There are a lot of different waterproof MP3 players out there. The price (and I’m sure the quality) varies greatly. I didn’t want to invest a lot without knowing whether they would even work, and these seemed to be an attractive option in that regard – they were only $34.99 when I bought them (about a week ago – they’ve gone up since then).

After reading the Amazon reviews I took a chance on these and I was pleasantly surprised. Of course, the features and user interface aren’t as rich as my preferred media player (the Sansa Clip Zip using the substantially superior open source Rockbox firmware) – quite the opposite in fact – this thing is as bare-bones as it gets. But the basic idea is I’m going to be swimming with it clipped on the back of my goggles, so as long as I can control the volume, pause and skip forward and back without looking that’s all I’m really interested in.

While I normally listen to more podcasts than probably anyone who’s reading this, I decided (at least for now) to see if I can finally make it through the daunting set of Song of Ice and Fire books, so that’s all I’ve listened to using them so far. The simple controls are fine for that, since it’s just listening to each track in order, so I’m never really skipping around.

The big question everyone wants to know with these devices: how do they sound? The answer is it’s not the greatest in terms of audio fidelity (and I highly doubt any waterproof model would be), but in terms of being able to hear (in this case book content) clearly they fit the bill.

In my experience, the most important aspect is making sure the earplugs fit in and seal well. If you’ve got a good seal (no water leaking in), it’s crystal clear. The minute any water gets in, you basically can’t hear at all. Again, I suspect this will be the same for any similar product. They provide four different types of rubber earplugs you can swap out to find the best fit for your ear, but the ones it came set up with initially worked great for me. There are other adjustments you can make to the earpieces, etc. and I highly recommend tweaking them until the fit is perfect, since it’s a deal-breaker if the fit is slightly off.

Update – 2014/09/19

Since this topic has been raised again recently, I thought it might be helpful to update this post with the easiest to understand (not the only) way that iMessage could be “wiretapped” (the term they recently used – “we wouldn’t be able to comply with a wiretap order even if we wanted to”, in reference specifically to iMessage communications). I thought it was worth a short update, since the original post is probably way too long and technical for normal users to read through.

You or a friend may get a new device (either a replacement or an addition) at any time. According to Apple’s own description of what happens, the public encryption keys unique to the new device are provided to other users who want to send that user a message, so that the messages will be received on all the user’s devices, and securely encrypted end-to-end.

Since this key distribution happens automatically and transparently to all the users involved, exclusively via Apple’s servers , the first obvious option for wiretapping is that representatives from a three letter agency go to Apple with some iDevice(s) and say “add these devices on this/these accounts”. From that point forward, the “wiretap” is in effect. (Note that under this model, they would not be able to go back in time to read old messages – it would be a traditional wiretap: from now forward).

Now, there’s probably not an easy/automated way for them to associate a device with an account outside of the normal channels, but it would be naive impossible to believe it’s impossible, and impossible should be the standard for saying “we wouldn’t be able to comply with a wiretap order even if we wanted to”. What I can only assume they “mean” when they say this is that their system as it exists doesn’t support it easily or as an existing feature, but if you don’t believe that someone could go manipulate the database (or whatever) where they store the device-to-user associations to make it happen, you’re fooling yourself. If they’re telling their customers they can’t do it, they’re fooling their customers.

It’s a bit puzzling to me why they would even bother trying to say this, since I really don’t think many users are worried about whether their messages could be wiretapped, but then again most users don’t care that Google can read their mail or search history either. I think in trying to make this into a selling point to contrast Google’s business model (which might be a good strategy), they overstepped into making misleading statements. I think they’d be better off sticking to the facts.

End Update – 2014/09/19

TLDR: Yes

This post is in response to a recent article covering the implementation of the encryption system used in Apple’s iMessage system.

Disclaimer: This post is only going to cover the purely technical answer to the question of whether Apple could read / intercept iMessages (assuming that the description in the article is accurate). This means the post isn’t about how I don’t like Apple very much (which I grant is true); I think I’ve done a pretty great job recently of not bashing Apple (I rarely post or even RT stuff about them), and that’s not what this is meant to be. It also isn’t about whether similar messaging systems from other companies are any more secure – most aren’t, but GPG email (for example) is. Please, if you want to comment on this post, let’s keep it on topic to this specific technical issue and the answer to the question in the post title.

Also, to be fair to the original author of the article, I don’t know whether it was even meant to answer that question, although it does neglect to mention what I’m covering here and in doing so may give a false impression that the answer is “no”. The article could just be trying to convey the technical details of how it works, and they did a great job of that.

The question of whether Apple could intercept is primarily being discussed due to recent concerns about the NSA forcing companies like Apple to do this sort of thing and also keep quiet about it. The response to that concern (by some) has been to try to claim that this system is impervious to that threat because Apple themselves couldn’t do it even if they wanted to, and that’s the part that unfortunately just ins’t true.

The Basics

The post actually does a pretty great job of explaining the concept of public key cryptography, and how it’s used by the iMessage system. In this post, I’m going to take for granted that the article is an accurate representation of how iMessage works.

Here’s a quick illustration of the basic example, why it seems secure, and eventually why it isn’t. [And please excuse the crude drawings - don't want to spend all day on this].

User A wants to send an encrypted message to User B, via a messaging system that’s owned by Company X. Both users have a set of public / private key pairs, and the great thing about that type of system is that as long as both users have the public key of the other user, they can send encrypted messages to each other that Company X cannot read.

Using only User B’s public key, User A can create an encrypted message, and then send it  through Company X to User B. Since X does not have User B’s private key, X cannot decrypt the message.

Seems great, right? Of course! If it were as simple as that, the answer to whether X can read or intercept is (at this point) “no”.

The Critical Question

What this simple picture doesn’t take into account is the question of how did User A get the public key for User B? Again, assuming the article is correct, it says:

“When someone starts an iMessage conversation with you, they fetch your public key(s) from Apple’s servers.”

Uh oh. This is game over for the question of whether Company X (Apple) can read / intercept. Here’s exactly how they could do it:

User A: “I want to send an encrypted message to B. X, can you give me B’s public key?”

X creates key pairs C and D. X gives public key C to A and tells A it’s public key B. X also gives public key D to B and tells B that it’s public key A.

User A encrypts a message using the key X told it was public B, and sends it through Company X’s system.

The obvious flaw here is that A and B both can only (in this system as described in the article) obtain the public keys by asking Company X to give them to them. Given that, there’s nothing stopping X from giving A & B keys that it actually controls both ends of behind the scenes, and A & B have no way of seeing that that’s what happened.

Of course, if you’re only concerned with whether other parties can read / intercept, and you don’t care that X could, that’s all fine. But the question this post is answering then has to be answered with a “yes”, which means (especially for a US company) that someone like the NSA could at any time compel X to do what is illustrated above and to not talk about it – and it would all be transparent to the users.

How It Could Be Better

It would actually be pretty simple for Company X to give the users a way to avoid this vulnerability. If X gave A & B the option to generate and directly exchange keys with each other without that exchange going through X in any way, the problem described in the above illustration would be eliminated. Users could transfer the keys in person, or via any other channel they trust that X doesn’t control.

I’d love to see Apple (and other companies with similar messaging systems) do this. I doubt they will, but if they do I will definitely update this post and give them huge kudos.

Anyone who sees “RSS” in the title of this post and understands what it means is probably familiar with Google Reader, and is also probably aware that it finally got shut down this month. So now what?

I switched over to Feedly a while before the shutdown, but I honestly haven’t really been using it enough to give it a proper review yet. However, I already know it’s not an ideal solution for me (for one primary reason, which I spend most of the text below covering), so I thought I’d put together a few thoughts on what a perfect world would look like to me when it comes to apps and services used to consume RSS.

My ideal system would be composed of 2 distinct parts or aspects:

1. Aggregation / Sync Service

This means something running somewhere that is consolidating all of your feeds as well as your state information (read items, shared posts, etc.) that has a good external facing API for other user interfaces to build on top of.

Although not as visible, this was arguably the more important aspect of Google Reader, and the thing that caused the most pain when it went away. Sure, GR had its own web UI and official mobile apps, but it also served as the back end for many other 3rd party reader clients who had the rug yanked out from under them along with the direct users and had to scramble to build their own back end or move to support others.

Which brings me to *my* most important requirement for this piece: it should be open source, free (as in freedom) software. It could also be hosted as a paid or free service (which is how most non-tech people would choose to use it), but it’s important that if whoever is primarily behind it decides to make any number of moves for any reason that infringe on the value users originally found in the service, someone else can pick up the ball and run with it, or users can even host it themselves.

2. UIs that work with that service

Whether the provider of #1 also puts together a great web UI and/or mobile apps on top of the service is not too important to me. In fact, I’d almost rather they didn’t, just because that would probably make sure they are focusing on providing a great API as their only “user interface”. If they do that right, there will be plenty of room for lots of other players to build great apps and UIs (free and paid) that use it, again giving users the freedom of choosing among many options in case one ever fails.

Closing thoughts

GR used to be even better when it also had a lot of the social features they removed (sharing & comments) in their initial attempt to push users to G+, but that’s a whole other rant – as well as a service that could be provided as an add-on by either party described above or even a third service player that inter-operates with them.

The funny thing is that the ideal system I described above is pretty much what Google Reader was before it went away.

Ultimately, I thinking making sure that #1 is free software / open source is actually the best way to make sure that users and app partners can’t be burned in the same way that Reader burned them / us.

Some people are gravitating towards paid solutions as an option for mitigating this concern, with the idea that it’s more likely to stick around if it’s paying for itself / making someone money, particularly as the primary or exclusive focus of the business. While I’m all for paid services and there is some merit to that argument, I think it’s just not as strong a protection as free software offers, because it ultimately does not address the true problem, which is lock-in that the service provider can choose to make the same “bad” choices Google did at any time. It leaves users and 3rd parties vulnerable in the exact same way as they were under GR.

Case in point: Google’s Reader did not go away because it wasn’t making money, nor because the company behind it couldn’t afford to keep it up. It went away purely and simply because Google decided they wanted it to. We can speculate on their motivations (still probably mostly having to do with pushing G+), but those ultimately don’t matter, because the real problem is lock-in depending on a sole provider with no easy way to replace them. *Any* company, if they are the sole provider of a service, can leave users and 3rd party apps out in the cold this way, either for their own business interests, or because they ran out of money, or any of the many other potential reasons, but the result is the same.

It’s unfortunate that all the offerings I’ve looked at so far (please point out others) seem to be clinging to this closed source, single provider model, which is just a recipe for the exact same lock-inproblem we had in Reader. I’d love to see a product surface that meets this need and really takes off, becoming the basis for many sustainable businesses while still remaining free at its core. There are many examples of this approach succeeding, with WordPress probably being the most obvious.

Of course, this whole post is simply my opinion, and is based on the particular weight I give in my own considerations to aspects I value in software. Many people weigh or value those aspects differently, or are not even aware of them at all which makes it difficult to give them any weight in consideration, so YMMV and all other appropriate disclaimers…

UPDATE – 2013/7/3 20:35 – Edited to replace “lock-in” references to better, less loaded terminology

For most of human history, the general public (aka: the “average user”) was unable to read or write for themselves. In many cases their interests were not well served by yielding that advantage to the relatively few who could.

Computers are an increasingly important part of life in our modern world, and the time where it was OK to be “computer illiterate” is behind us. Not that those who struggle with technology should be judged – on the contrary, we should encourage them to not sell *themselves* (and their own capacity for learning) short with statements like “it’s too hard” or “I’m just not a computer person”. Nonsense.

OK, it might not be that extreme, but I have recently been trying out a new desk configuration.

Being a software developer, the majority of my working time is spent in front of a computer. To be honest, since it’s something I enjoy learning about and doing (not just because I “have to” for work), a decent chunk of my leisure / hobby time involves computer use of some sort as well.

This brings us to ergonomics. Regardless of how much time you’re going to use your computer, it’s in your best interest to take care of your body while doing so – specifically avoiding the long-term damage that can come simply from neglecting things like good posture.

Until a couple weeks ago, I was sticking pretty closely to the image on the right. OK, maybe not sitting up quite that straight 100% of the time, but still, that was the goal

Recently a few social networking posts got me thinking again about a concept I’d read about before: the standing desk (as seen on the left in the above image). You can do your own web searching for all the info on the benefits of standing rather than sitting down all day. Long story short, I thought it was interesting enough to check out.

The huge downside that has deterred me from exploring this further before is that a lot of the recommendations involve either buying a standing-only desk (replacement) or a convertible contraption capable of supporting both standing and sitting. While there are some cheap, DYI options (at least for the standing-only variety), some of these things can get really pricey.

Inspiration struck me when I noticed that a dresser already situated right next to my desk just happens to be the perfect height for me to very quickly achieve the position shown in the left image above – merely by moving my keyboard and mouse up to the dresser surface, and setting the monitor atop a platform raised to the appropriate height.

For the last couple weeks I’ve been trying out this setup – alternating between sitting and standing for either one or two Pomodoros at a time, and I’ve found it to be a refreshing change. I think I feel more focused during the standing sessions, and while I think it might be a bit too much to fully switch over to it, I may try to gradually adjust the balance away from 50/50, in favor of standing.

One other thing it’s great for – sometimes prior to working or during breaks I’ll exercise. Yeah, again, not as much as I should / plan to, but I’m getting better. Anyway… the point is that after doing so, standing is a good alternative to covering my chair with a towel to avoid getting it sweaty.

In summary, I recommend giving some variation of the standing desk a try. Even if you don’t though, take note of the posture image above whether you’re sitting or standing. It may seem complex at first glance, but really it’s just a few straight lines and 90 degree angles. Your body will thank you later.

The tempest around the recent Carrier IQ “spyware” issue serves as an important example of a key advantage of an open platform like Android, as compared to a closed source, locked system alternative (of course, we’ll use iOS as the example of the latter).

To be clear, before we begin, my point is *not* about the degree of “bad” that’s present in the various CIQ implementations. Let me clearly say that I acknowledge that (assuming you trust their statements on the matter, and I’m not arguing those here), Apple allowed the use of CIQ in the past in a much more limited capacity than some of the other cases, and it claims that it is even more limited in later releases. That’s great. Wonderful. Not what I’m talking about here, though.

The point I *am* making is that I don’t want to have to take the word of the carrier or the device maker on issues like this. All of them came out with similar statements denying the degree to which the “bad stuff” happened. Some were proven to be lying. Some may have been telling the truth. Doesn’t make much difference to me in this scenario.

My point is that you can take any instance of something like this and evaluate an important question. In order to avoid confusing the issue with the irrelevant details of the CIQ case, let’s (for the purposes of the rest of this post) substitute a different, totally fictional and hypothetical but similar discovery.

Let’s say it comes out in January that HTC, Motorola, and Apple all made deals with “DJR” (fictional) software in the past, and they all (to varying degrees) stored and shared some extra information you’d rather they didn’t.

The most important question (IMHO) if I’m a customer using a device where something like this has been discovered is “what can I do about it?”

If I’m an Android user, there are several answers to that question. I could buy a different phone (since I have many to choose from) from a different carrier / manufacturer who hasn’t made the particular poor choice that I have a problem with. Or I could install an open source, custom ROM on the device I have now. This may (in some cases) void my warranty, but it’s at least an option that I can consider.

On the other hand, if I’m using a system like Apple’s iOS, I have nowhere to turn. There are no other iOS devices (not made by Apple) to choose from if I don’t like what Apple has decided to do on the one I have. I certainly can’t install some alternative “distribution” of iOS, since those don’t exist. Even if the source were open (or obtained by other means) and it was technically possible for someone to build an alternative *full* iOS ROM (as opposed to simply jailbreaking the stock Apple one, which doesn’t solve problems like this), it would be illegal for it to ever be distributed since the people doing so would be violating Apple’s copyrights in doing so.

Rather, the only real choice I would have as an Apple customer would be the decision of whether I’m willing to just accept it or whether it’s a big enough deal for me to leave them over.

That last point is the one that really hit me with this, and I think it provides some degree of insight into why some people who are really into Apple are so reluctant to ever admit that they’ve done anything “wrong” or negative, in any situation. Perhaps it’s because they know deep down that if they do acknowledge anything of that sort but continue to use Apple products anyway, they are effectively saying “and I’m willing to live with that because I want to use iOS and there’s nothing else I can do about it”.

Ultimately, that’s the point I’m making here. One of the benefits of a free / open platform is not being boxed in to those kinds of all-or-nothing choices.