November 03, 2009
Since in this blog we try to speak about oversighted technologies - that is, technologies delivering far less than what they could - I think you will find this reading very interesting.
You can find the article here.
September 27, 2009
It's not far from what Microsoft named "Three Screens and a Cloud": the central hub, the Cloud, is the place where the data actually is. The user is able to access the data using either a PC, a TV or a Phone, either at home, work or in the metro.
What the tablet wars (or the phone wars, for that matter) are trying to determine is "how" is the user going to access the data. The concept, however, is already being sold as something certain, regardless of Stallman's opinions.
If we take it for granted, then what are the phones - or the PCs, or the TVs - good for? If we start reasoning in term of anything as a service, it doesn't really matter if your phone or your pc has 1Gb or 512 Mbs or RAM, as long as it is able to stream you multimedia representations somebody computed somewhere. Try OnLive to get an exact idea of what I'm speaking about.
This said, it seems to me this OS-Hardware war should transform itself in a form-factor war, which is most likely going to end up with some degree of flexibility for the mobile end (someone will prefer smaller factors, like phone, while someone will still like the larger screens laptops can offer and so on), and pervasive docking stations everywhere. Once you plug your phone on the dock you get access to a larger screen and to all your data and software in the cloud. Maybe your local-office cloud, maybe your personal cloud or maybe even some sort of "service provided customized cloud", it doesn't really matter.
However, phones will still play a critical role as KEYS. If we want to think about secure cloud computing we have to think about pervasive, high security encryption. Phones and other devices, then, will just become our personal wallets, storing access data we can unlock with a password which in order will unlock all our cloud stored data. That is, until we start to actually use biometrics... but that's another post.
September 22, 2009
In an enterprise environment, the solution would be to implement a proper Wi-Fi access infrastructure with a partial self-service procedure to enroll, get the certificate and thus create usernames and access logging. However, such a procedure is not really viable in a single shop. A luxury place, however, requires any solution to be easy to use for the customers and somehow classy: no on-demand generation of keys, no ugly panels and so on.
I googled around, and found some commercial solutions to the issue, each one proposing some sort of Captive Portal and monitoring solution. While I've not performed any comparative analysis of the commercial solutions, there was really nothing which make me "go wow", or that is really missing from the opensource solutions I will describe in a moment.
Why OS solutions for any high-level environment, you might ask. For once, customization.
There's only so much you can do with closed-source, commercial software, without great economical efforts. However, since we are sensible administrators and managers, we want something we don't have to tweak, something which "just works". And it seems there are a lot of free, working alternatives in the market.
ZeroShell is the first to come to mind, perfectly capable of doing everything we need. My friend Luca Carettoni performed some auditing on the platform some time ago, discovering some bugs which were promptly patched: this is not a life insurance, but it means that the level of security is at least able to pass a "free audit", which is more than most commercial solutions can guarantee.
Chillispot is another well known player of this market sector: it is able to run on any standard server, providing integration with a RADIUS server - however, the project is now dead and its most likely successor is Coova. Coova's aim is to create a firmware (based on OpenWRT) for a number of devices, which includes a web based panel and a powerful captive portal. Documentation is not as complete as it could be, but the project has an active community and can be tested in few minutes.
In the end, my pick was: start from either ZeroShell or Coova, and customize the captive portal interface and user management panel. Enrollment is "manual", since customers have to present their ID. Once their used has been created, it can be reactivated logging in the captive portal on future dates. In the end, the entire project would cost less than 200 EUR in hardware and a couple of days to configure and setup.
The results? A stable, completely custom - and most likely secure - hotspot.
Update: I've just come across Sputnik and the project seems to be vastly superior compared to the competitors!
August 28, 2009
In the end, my answers always follow the same patterns, so here you are my tips on choosing the right web application. What should you evaluate when you choose a web application?
- Vision and people
- Standards and integration
I know, the KISS (Keep It Simple, Stupid) unix paradigm would suggest to have a web application which only does a single task - a best of breed, if you wish. However, while we do have software management tools in Windows or Linux which can somehow keep application proliferation at bay, we don't have such tools when it comes to web applications. Managing 5 or 6 web applications is a real burden when compared to handling just one: updates, dependencies and so on, everything (or almost everything) has to be managed by hand. And don't even make me start with application servers. So, definitely go for
You should not stop ad data sheets or feature lists: install the product if you can, or try it on a virtual machines (most vendors are now shipping demo virtual appliances) and try to build up an idea of the actual features. There's always some gap between what's on paper and what's in the code!
A strong community is really a must have for any web based product, no matter if it is open or closed source. In the opensource world, having a strong community means the product will unlikely die out, while for a proprietary apps it means you will have more than just the official documentation.
A community also means addons and plugins which almost any modern web product will support. Just watch out, because you should evaluate addons one by one in the same way you evaluate your application.
Browse the forums, noting the date of the last posts, try to find active sites or blogs about the products and take note of who's using it. Do not trust the "BigCompanyX is using our product" claims, since especially in opensource software, given a large enough company any software is bound to be used in some department.
Security is always an issue when it comes to web applications. You should check the application history (try for a Google query like "YOUR.APP.HERE exploit" or "YOUR.APP.HERE security advisory") to get a rough idea of how many issues the application had in the past. Note that no issue is maybe even worse than a lot of issues: it likely means that no independent reviewer ever took a look at the application...
Take care, when you assess a CMS: you will find a lot of security issues on external or third party components, and it's often hard to tell if they are there due to the lack of security of the component or of the platform itself.
Nonetheless, a OneBugAMonth history is definitely a warning sign..
This is very important when it comes to large projects, like Content Management Sytems. Where is the software going? What the company will do with it? This is the most hard part to judge, since you will most likely not have any resource. My advice: go for the people. Search the web for the coders, take a look at their tweeter accounts and their other projects, if any.
Should you need a way to retrieve some email address, try FOCA: it will automatically fetch email addresses from any document on the company's website.
Look for proper standards. "We're using Java so we are standard" is one of the most widely heard of claims, and doesn't make any sense. Look for actual interoperability: open source code, web services, open and well documented data format.
Even the most well guarded, proprietary application can have well documented standards, saving everything in XML and thus being much more easier to integrate in your environment. Remember integration is a must.
Last but not least, look at the requirements and the technology the solution has been built around. Deploying a Zope based solution today might not be a great idea from a strategic perspective, no matter how much I like Zope. On the other hand, using a technology you're completely unfamiliar with can slow down deployment and makes management much more difficult. This said, you should reiterate the analysis on the underlying component as well: maybe the application will require Tomcat, maybe Oracle Application Server.
It really does make a difference: choose the wrong technology you and you will end in a cul-de-sac in no time.
August 24, 2009
That's exactly what's happening with real-time information flows: even black hat hackers are using real time technologies.
Whike the most well known real time application out there in the internet is twitter, as you most certainly know by now, it's not just tweeter anymore. Users are becoming more and more adept to retrieve data in real time and are actively starting to look for it. Even search giants like Google are getting more and more "real time" search results in their results-set.
However, this comes with a price: real time information is nowhere near as accurate and as deep as "old school" batch produced information. You cannot post an in-depth review on tweeter, so you're most likely going to just write "it works" or "it sucks" and that's it. This is not the sort of clean information organizations want to provide their users. However, and that's exactly the key to understand what's happening on the web, they are forced to do so. Users work and think in real time; your customers are using a real-time web, and you must do so as well, like it or not.
The "real-time revolution" is not a technological one. We've had forums and bb even before the internet as we know it now was born. However, it is a strong change of paradigm: users are now all of a sudden looking for those "contact me in real-time" boxes, they are asking questions expecting answers in real time. Email is just too slow for that.
At the same time, once you write something you've written it, you can't just deny it. So, we're facing a world where you (as a company representative) are expected to answer fast and do so correctly.
This I think, is one of the most important issue. To react, in a world where "when" is always "now", you have to be faster than yesterday, and the first thing you have to cut are decision times. Have the managers, the ones who can actually make a statement, interact with the web in real-time.
Need a good training on the whole real-time stuff? Maybe you should seriously ask your organization whether you understand what's going on in the internet or not. However, you can start by trying Yammer and see that (not if) it makes a difference.