Category: Tech

Nexus 7: The Tablet I Didn’t Know I Wanted

~ Steve ~ 1 Comment

When it became obvious I was going to be getting a tablet a number of years ago I knew exactly what I wanted. It had to be 10-ish”, Android based and have a keyboard dock. My reasoning for the dock was so I could get some “real work done” in a pinch and that would require some decently fast typing I wasn’t sure I could do with my thumbs. At the time I went with the Asus Transformer and, I have to admit, liked the device a lot. I also learned that what I thought I wanted in a tablet was not totally accurate.

Break it down

10 > 7

There was a few reasons I thought that a 10″ tablet would be much better than a 7″. The first being that there would be more screen to view. That means more widgets, bigger videos, more room to enjoy games, etc.. While I get most of my comics in physical form the thought of reading a comic on a 7″ screen seemed unnecessarily frustrating. The next reason was due to what, at the time, was a sizable screen on a phone. I had this thought that a 7″ wasn’t a drastic enough difference from my phones screen size. Lastly, I had the mindset that the 7″ tablets are the 10″ tablets cheaper versions. It sort of makes sense. In other areas of tech the smaller version has less space/power/upgrades/something.

Android!

I wanted an Android based device. I had just mourned a move from WebOS to an Android phone. I liked the Android phone quite a bit and figured it would do well in tablet form. The more open nature of Android was a big factor as I much rather use open of Free. Add to that I could use the same apps and it was a no brainer. Of course having many of my other friends walking around with Android devices didn’t hurt either.

Get things done

When I said “get real work done” what I really mean is not simple nor short. “Real work” constituted things that I didn’t see as being very easy to do with a soft keyboard. Not impossible, but not an enjoyable experience. For instance writing a blog post or going through some code would be work while responding to an email or reading a book wouldn’t.

Where I went wrong

10 != 7

10″ and 7″ really are in different categories as Ava from HeelsAndTech points out. What I slowly started to figure out was that portability was a huge want for me when it comes to tablet usage. Of course a 10″ is portable but a 7″ is easier to keep with you day after day. Keeping a 10″ tablet with me day after day was like keeping a very light textbook along. A 7″ tablet is similar to carrying a light paperback.

Android?

Nope, spot on with this one.

Work

But way off here. I usually don’t think of myself as a consumer but somewhere in between producer and consumer. I’m creating code, writing documents, editing images, recording music, etc… My faulty assumption was that I would want to do most of these things from my tablet. In reality I grabbed the tablet when I wanted to read the feeds without being tied to a desk or watch a movie on a treadmill (probably not the safest thing…). These were times when I was done creating for the moment and ready to walk away from the desk.

But I wasn’t unhappy

My Transformer didn’t cause any problems. It had great battery life. It’s screen was nice. But something happened that inched me over the line: seemingly no official word on the original Transformer getting Jelly Bean, the newest version of Android. It is true I could root the device and throw another ROM on there but when it comes to my tablet I want to keep it simple. It got me thinking more about if it was already time to replace my Transformer with another device which had a better chance for a longer life span.

Nexus 7

I waited a little bit and it wasn’t long that I started to see friends slowly getting their hands on Nexus 7‘s and still liking them weeks after purchase. It got me thinking about if an official Google device would likely get better lifespan than 3rd party devices which rebuild, add on and push their own ROM’s out. After a coworker brought Nexus 7 over so I could test out the tablet I was pretty much sold.

So far it hasn’t been perfect but total perfection is not what I was expecting. The issues have been minor and I believe are more on the server side than client side. For instance I was looking at Google Play Magazines and it was stuck trying to log in.

In general it’s a solid and speedy device with a good feel. I’m glad I picked one up when I did.

Update

The issue I had with Google Play Magazines I also had with Google Currents. This seems to happen if you accidentally hit the account you want to use twice on first run. Here is how I fixed it on my tablet (using paraphrased wording):

  • go to Settings->Applications
  • find Google Magazines/Google Currents
  • View the application information
  • Touch Force Stop and the warning that pops up after about the application possibly misbehaving
  • Touch Clear Data
  • Touch Home and reopen the app.

You should no be back to the original “select the account to use” screen. Be careful to only click your account once. The Nexus screen is very sensitive!

“Security? That’s the OS’s/Networks Job!”

~ Steve ~ Leave a comment

I spend a good amount of my time doing software development. I’m one of those guys that has a bad habit of starting projects, getting half or three fourths of the way through and then coming up with another project to do (leaving the original out on in the cold). Needless to say I end up playing with a lot of tools and libraries to help with projects but I’ve started to notice a pattern. The assumption that behind the firewall everyone is friends.

In a more recent project I was working on it became apparent that a queuing system of some kind was going to be needed. Instead of running out and picking the most popular flavor of the month I figured the best move would be to give a few different systems used for queuing a run and see how they worked out. In general I was impressed with their abilities but found the security lacking greatly in a number of them.

Applications

Please be aware I’m not trying to discount any of these applications.The two I tried directly I really liked from a development point of view.

Redis

One of the earlier ones I checked out was Redis. It was blazing fast but the security model is interesting.

Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket.

(Source)

To make matters even more interesting it has support for a single password passed plainly over the wire. Granted, it’s possible to use an SSL proxy as the guide points out but with one user non-repudiation could be a serious problem (especially if logs go back to NAT’d addresses). In effect the security model of Redis seems to require a single tenant, well logged (at network, host and app level) and heavily ACL’d environment. With cloud hosting I’m not so sure how well one could ensure this is the case at all times. Granted, if it’s a single developer running his own infrastructure or a very small company/group/team then it could be possible that the model would work well enough. Honestly I couldn’t get over the fact I’d have to tell friends who wanted to play with the project they’d have to make a special environment before installing.

Beanstalk

I didn’t end up trying beanstalk but did notice it had similar pitfalls. As Kurt Seifried points out in his blog:

The major downside to beanstalkd is that it doesn’t provide any encryption of network traffic or authentication capabilities, so any client with access to a running instance of a beanstalkd server will have access to all the queues in that running instance. This can be gotten around by wrapping beanstalkd in SSL (using stunnel or a similar service) to secure communications and limiting access to beanstalkd queues based on either IP address or by requiring SSL client authentication.

(Source)

So again, if you want to use the service you must either setup extra hoops and/or have an incredibly locked down infrastructure.

ZeroMQ

ZeroMQ is really cool. But you end up with similar problems of network ACL’s providing all of your protection unless you write your own authentication and authorization mechanisms.

What security features does ØMQ support?

None at the moment. ØMQ does not deal with security by design but concentrates on getting your bytes over the network as fast as possible. Solutions exist for security at the transport layer which are well understood and have had many man-years of development invested in them, such as IPsec or OpenVPN.

(Source)

Granted zmq is a bit lower level and used as a building block instead of a solution so it is understandable why some things are pushed back upon the developer to implement as needed.

But Who Cares?

It’s more about being aware.

  • Can anyone promise that network ACL’s won’t be modified to enable a shiny new application?
  • Can you be sure that the other side of the SSL connection will remain safe  and trustworthy?
  • Is any data making it’s way through which can have an effect on process inside the firewall guaranteed safe (example)?
  • If the hosts are multi tenant or in the cloud are you sure everyone who has access to the VM’s or networks are trustworthy?

You and/or the developers of these apps wouldn’t have come up with some kind of security solution if it was OK for any random Joe to play with the service. If someone is able to interact with a service which is “soft on the inside” then it’s likely that service would be an early target.

Simple Examples

For example, let’s imagine an attacker gets access to the service because he is able to take control of an approved host. If the service on the other side is Redis then the attacker could sit and gain information painlessly before copying work from that point forward. If it is a zmq port then an attacker could attach another process to it and get either a copy of everything (SUB, ”) or a subset of data (PULL). Beanstalk probably has similar abilities. The security on the other side of the connection, whether inside or outside the firewall, ends up being as important as the security on the inside as the level of access to the service is more or less the same. All or nothing.

Using an SSL tunnel and only allowing specific hosts may constitue as defense in depth on paper it doesn’t seem to be enough. Maybe I’m to paranoid but if there was authentication and basic authorization in or around the service an intruder would need to gain further information or perform more attacks to gain access.

App.Net, Good, Bad and the Unfocused Problem

~ Steve ~ Leave a comment

When I first heard of app.net I was somewhat skeptical. The idea of a pay to join social site did make sense to me but I wasn’t so sure it would make sense to many other people. After seeing a few people from other social networks state they had backed the project I figured I might as well join in (hi kids!) and, so far, I’m glad I did.

The Good

Quality

One thing I’ve noticed on other social networks is the lack of real conversations. It’s a bunch of people all yelling to get attention in your feed. The conversations on app.net have been pretty good in terms of quality. Granted, a lot of the talk is either somewhat technical/geek talk or about app.net itself but it still beats out many other social networks in my opinion.

It’s big, but small

The service is still small enough that, if you so wish, you can watch the global feed to jump into conversations and meet new people. It’s sort of like the Asheville, NC of social networks.

I’m not the product.

Do  I have to say anything more about that one? It’s just plain nice being the customer.

The Bad

Where is ___?

Like all new social networks your friends are probably not on it. At least not yet. There is no promise they ever will be on it. It’s a gamble but then again so was joining any other social network in the first few years of their creation.

It’s a social network.

I have to throw this in there for good measure. It’s a social network. Some people will be annoying, unfriendly, loud, etc… Luckily mute is built directly in to the web interface and API allowing you to keep some of the higher offenders from bugging you. The good news is that I have not encountered much of this yet with one exception …

The Unfocused Problem

This is the exception and, in my opinion, is the biggest problem at the moment. For those who are not on ADN this may sound like an odd issue as it’s not uncommon for people to flood their followers on other services with random posts that mean very little. There has been a lot of talk on ADN about cross posting from other services which I call unfocused posts. In general I don’t think cross posting is a problem unless it’s excessive or makes references to things that do not exist in the current service. For instance, if someone posts a retweet/repost from Twitter to ADN referencing a user who is only on Twitter.

Why is this happening?

I think it’s happening for one of two reasons: “This is how it works” and “I paid for it…”

This is how it works.

This is a social problem for social networks (ha!). It’s the assumption that social networks should list all your social network traffic so everyone can see it. A good example would be FourSquare on Twitter. If someone is interested in your FourSquare check in’s they are likely your friend on FourSquare but yet people flood Twitter with FourSquare posts.

I paid for it…

This is more specific to ADN. Since it’s a pay to post service there is probably more of a need to post. If someone joined up and then decides it’s not yet worth their attention I tend to believe they have a higher probability of cross posting from a service they are using actively. The thought process being “I paid for the account, I might as well use it.”

Solutions

One solution which is being worked on is filtering via annotations. I can see that being very helpful as long as the applications which enable cross posting end up filling out annotations and clients (including ADN’s web interface) allow for filtering based on these annotations. ADN will probably end up providing the client functionality web side in some form or another and some of the applications doing cross posting will probably fill out annotations properly but cross posts may still find a way through.

Here is a possible example of an innocent cross post which wouldn’t have annotations attached:

  1. User has a mobile microblogging client installed
  2. User has it set up to post to Twitter, Facebook and ADN
  3. User sends a “tweet” to a friend on Twitter
  4. Result is three posts (one on each service). Only twitter has the proper user context.

In this case I don’t think the client would really know that the user only exists on Twitter and that it should add annotations for ADN. It’s simply a post with a user reference.

In my off time I’ve been trying to come up with a stop gap solution via time based thresholds which I’ll bring up in a later post in greater detail.

Conclusion

If you are a geek of any kind it’s probably worth your time and money. The community is small and growing, the impact one user can have is still pretty high and, over a bit of time, you can probably make some more quality tech friends and contacts.