iConverged

Update: I have now created a sidebar widget titled “Tech Blogs I read” instead of updating this post. Please continue sending me quality tech blogs (with more focus on concepts and less on marketing) as you come across them and refer to the sidebar for updates and not this post - thx.

Total number of ‘market reporting’ VoIP blogs = k+1

where k=number of times you can blink in a day.

However, there are very few blogs that talk about more technology & architecture details and less market details for all things VoIP, SIP, IMS, web 2.0 (with focus on telecom).

So here is a call to unite!

We need a list of what I call ‘geek-talk’ - those that provide more technical insight into how things are.

Here is my list so far. Please update me /comment here with more tech-blogs and I will update this list

Many of these blogs are a mix of techno-marketing, but are written by people who are neck-deep in actually developing/architecting many of the talked about solutions themselves, and hence offer a more detailed insight.

last updated: Apr-30-2008

1. TurnGeek - focus on P2P, SBC, etc.
2. IMS Lantern - IMS architecture related
3. Voice of VoIPSA - VoIP Security
4. IMS Quality - Testing and Monitoring with focus on IMS
5. VoIP Survivor - general voip, with significant focus on their company products
6. TelCAB - IMS B/OSS
7. iConverged - this blog

don’t claim to be a heavy eBAY user. But, I do buy and sell stuff occasionally and my recent experience selling stuff on eBAY could be a good indicator of what is probably worrying the execs of EBAY: Managing scale.For the past month or so, I’ve been trying to sell a laptop on eBAY. I’ve listed the items two times already and here is what happened both times:

1. Within hours of listing, I get sent messages of two categories: People who want to cheat the sytem and barter offline and scammers with manufactured or stolen eBAY identities who want the “usual” information. I spend valuable time dutifully forwarding it to the security folks at eBAY.

2. During the weeklong listing, I spend even more time responding to form responses from eBAY and handling email discussions with CallCenter agents who plainly have no expertise in managing security.

3. During the last day or two of the auction, I will have three or four genuine buyers who I communicate with and keep engaged.

4. During the last minutes, I see bidding begin and notice my genuine buyers being beaten by scammers with stolen identities win the auction with outrageous bidding. I cannot do anything. Things move at the speed of the Internet!

5. I then get a “Congrats” email followed by a “sorry, the scammers beat us” email and to protect the integrity of the network (read: eBAY probably doesn’t want this information getting public) the entire listing is removed.

This got me thinking and I’ve come to the following conclusions that you might or might not agree with:

- E-Commerce is now no different than regular commerce. An Internet business will initially probably have advantages due to the network effect, but in the end they will end up just like the other utilities: they will struggle to manage scale and offer a compelling service. My eBAY experience was no different than calling my telephone or cable company: Form responses, casual processes to address core business competencies, and frustrating customer service.

- Internet establishments will progressively develop a tiered system. The big customers will get all the attention and the small/occasional customers will not be able to take any advantage of the benefits the network provides. It won’t be egalitarian like it used to.

- Secure E-Commerce is elusive. Internet businesses who depend on earning money through customers they trust will struggle to keep their infrastructure secure. There is a constant struggle between expanding the user base and offering a secure environment. There has to be a better way than the best computer scientists being routinely defeated by the dolts with a phone and a laptop from the most “backward” regions of the world.

eBAY is probably the most innovative of Internet businesses. Their annual report proudly states:

Everytime I wonder if there is anything left to do on these new generation of scrollable maps by Google and Yahoo, one of them surprise me. The latest is the neat addition of Google Maps street view (here) where you can see real street images and navigate around.

At this level of detail, for all those folks doing things you should not be, watch out, you are on a world-wide candid camera

(click on image for larger view)

In the past couple of days, I’ve been delving into supposed security issues that the new Web 2.0 and AJAX enabled sites produce and have been also looking into some claims I heard that for serious applications, one should stick to Flash, since it is inherently more secure, tried and tested than AJAX is today.

To investigate the inherent and publicized security issues within AJAX, we first need to understand the underlying technologies that AJAX uses. Specifically, AJAX comprises of:

a) XMLHttpRequest (XHR)– a new functionality, that has been added to most well known browsers today that allow an asynchronous communication mechanism between the browser and the webserver

b) Client side JavaScript – been around for a long time, an implementation of the ECMA script specification and used as a programming language for many web based applications

To properly assess AJAX related security issues, then, it makes sense for us to take a look at what sort of security issues do these two critical underlying technologies present.

XSS – Cross-Site Scripting attacks – A Javascript and URL handling exploit

The concept here is straight-forward. XSS is not a technology – it refers to a technique, where a malicious user can construct an ‘evil’ input which when passed to a trusted, but vulnerable site, causes that site to compromise it’s users. Consider , for example, a site called www.goodsite.com. Which accepts a search query like so www.goodsite.com/q=mysearch. Now let us assume, that goodsite.com does not do a good job at ensuring that the input provided is validated well. One could construct a URI like www.goodsite/com/q=(insert malicious script code here) and send it off to goodsite. If goodsite let this pass, in effect, the script would be executed in context of the browser session for the user. So, if I were to send you this site URI, and you clicked it, I could for example, hijack your session cookie at goodsite and have it sent to me via embedded javascript (Javascript allows cross-domain HTTP requests). If you think this is trivially avoidable, you’d be surprised at how may ways there are to bypass web server checks. For example, take a look at the myspace exploit that used dynamic HTML and fragmented text blocks to hide substring matches to get caught by the web-server’s parser.

Ideally, one could consider that XSS should be disallowed, or, all webservers MUST ensure that all special characters are ‘safe’ized (encoded using HTML entities) to ensure that they are not interpreted at the remote side, rather, only displayed. However, with the increasing popularity of responsive web sites using AJAX related technologies, Mash-ups are becoming very common, and the ability for one domain to pass on data for remote script execution helps in managing load on the local host. XSS related vulnerabilties have been around for a long time, and have been successful in infecting a variety of web based solutions, including Php boards, google, apache, mozilla, myspace, yahoo and many more.

It is important to note that XSS depends on the following:

a) You somehow pass on a ‘malicious’ URI to a user and get him to click on it (it doesn’t make sense for you to execute the XSS vulnerability in your own browser context, unless you think you can launch a remote exploit due to a buffer underflow or overflow – that is a different attack, and not catagorized under XSS Attacks – more on this later)

b) It makes an assumption that the web-server receiving this information does not do a good job validating input

Effect of Web 2.0 on XSS attacks

Does Web 2.0 impact the risks of XSS attacks? Yes and No. Technically speaking, XSS has nothing to do with Web 2.0 and AJAX. It is a vulnerability that existed much before AJAX as a term was even coined. XSS attacks started surfacing almost as soon as javascript was introduced. However, with the proliferation of Web 2.0 sites, there is a significant increase in collaboration, mash-ups and multi-tenancy which all mean the same thing – there is a larger audience which can now be targetted for vulnerabilities. So the ‘No’ was a technical response. The ‘Yes’ was a market response – due to adoption. However, that is not to say that ‘Web 2.0 results in increased XSS vulnerabilities’. The right statement would be ‘Web 2.0 results in more people using potentially vulnerable techologies, which unless hardened, have a wider possibility of financial and reputation damage’ (heck, sounds like a lawyer crafted that, but you get what I mean). In addition, multi-tenancy (different applications on a single cluster of hosts) means exposed vulnerability of one application can compromise others, unless the multi-tenant host takes very special care of intra-trust-domains (providers usually do a good job of inter-trust-domains, but lag on trust within their own domain, which is why once you get it, you can usually do a lot of damage in periphery nodes).

XMLHttpRequest (XHR) & Javascript Repudiation Attacks

This is really is derivative attack on a compromised site (it is interesting to note most of the attacks rely on implementation gaps of web-servers). Assuming that you manage to get a malicious script code, using XHR you can issue as many HTTP commands in it to automatically, ‘agree to some terms and service’, ‘buy item’ etc. that don’t require any specific user input not known to the environment. The exact same thing is also possible to do with Javascript – so this is not really specific to AJAX only (The only new thing AJAX got in was XHR – Javascript existed much before hat). Since the web-server does not know which request came from an embedded XHR or an explicit user click, it is not possible to differentiate between the two.

Effect of Web 2.0 on Repudiation Attacks

Once again, with the hype and slickness of XHR+JS applications proliferating around the web, more people should concentrate on architectural and data protection besides only focussing on ‘how to make the interface slicker’. So again, Web 2.0 does not technically make the situation worse, but in the surge of trying to get out prettier applications, developers needs to go back to their basics on implementing a secure enviroment for distributed systems and input validation.

(AJAX) Bridging

Bridging is a software concept that has long pre-dated Web 2.0. In effect, it is the process on installing a ‘gateway server’ in between multiple content sources. This ‘gateway server’ maintains a trusted relationship with the backend content servers and is also therefore capable of creating integration logic of how to ‘mesh’ these diverse contents together. This sort of bridging has increased in popularity, with the deployment of mash applications. It introduces another twist to XHR attacks. XHR cannot access HTTP pages which are outside the domain which is being served. For exampl
e, if a script was running at www.google.com, XHR can’t make a HTTP request to www.yahoo.com . However, if the application is being hosted on a bridge server, then one could use the bridge server URI to access content in the other backend site (for example, if the bridge server knowingly or un-knowingly supports URI redirection). Do note that Javascript also supports this capability, so you don’t need XHR for this. However, now that Browsers also support XHR, even if JS is disabled or blocked, one could launch similar exploits without it. What then happens is that by transitive relationship, if Yahoo were to offer its APIs to a trusted site, the users of that trusted site could now target attacks on Yahoo using common tricks like SQL injection, DoS (repeated HTTP requests via XHR in bulk) and similar.

Effect of Web 2.0 on XHR Bridging Attacks

Web based mash-up applications are proliferating today. The use of bridge servers to blend content from multiple sites are getting much more common place today (for instance, mashing google maps with craigslist, house searches and more). In any architecture, the fundamental principle of ‘a chain is only as strong as it’s weakest link’ applies equally here.

Javascript ‘Script Kidde’ Tricks

This is a compendium of many tricks which have plagued immature implementations of Javascript. Many of these tricks are very irritating and can destroy user experience. For example, Pascal Meunier maintains a list of some of these irritants, which work even today on the most recent of browsers, and they include:
a) Dynamically generating a fake page for a valid URI – a simple javascript trick where if you visit http://bad.com and click on a link there for ‘google.com’ it can result in your browser URL changing to google.com but displaying some other crafted page (it works in IE7, FF2.0 smarly displays the URL redirection)
b) Nasty JS code that traps browser events and does not let you navigate away from the page, unless you close the browser

And more.

Ofcourse, JS being a programming language, it can also be used for more serious purposes – like port scanning your own network and potentially reporting found results to an external site.

Effect of Web 2.0 on JS Vulnerabilties

Most of the web 2.0 world relies heavily on Javascript. Infact, I can point you to hundreds of sites, that blindly download ‘JS+XHR (AJAX) toolkits’ like prototype.js or others and start using their functions. Just an an example, prototype.js is a 64KB file densely packed with XHR and JS code. How many people actually look into that file ? What stops me from hosting a malicious prototype.js file and having people download that file and use it in their own context and have their context sensitive information sent out ? With the increasing use of JS in commercial sites in quest for a better user experience, the inherent implementation gaps of JS interpreters in browsers have a capability to do much more damage, simply due to a function of it being used in many more mainstream functions than before.

XHR+JS insecurities vs. Flash

Comparing this to Flash, when I googled around for vulnerabilities, most of them I came across, were to do with buffer exploits. Simply put, buffer exploits are set of techniques where a malicious user finds a spot of executable code that does not check for input length, and using that, provides a large enough string which overflows the allocated stack for that string. In addition to that, the string is crafted with machine opcodes at the right place, which causes the return address from that function to reach an address within that string, which is actually an encoded instruction set. Effectively it means that the remote user has managed to execute code on the remote platform, thereby launching an internal attack. Such attacks are very old and still prevalent. A great tutorial (old, but gold) for buffer exploits can be read here.

So while I found such buffer exploits, I did not have much success in finding actionscript related exploits similar in nature to those mentioned above. I did find references to ramdom posts on forums that said a few years ago, actionscript from Flash was in a similar stage, but it seems over the years, the implementation has improved. Again, this was a cursory look – I’d be happy to be pointed to similar exploits in the Flash world.

Buffer exploits will always remain – detecting and compromising buffer exploits don’t need an open programming language interface like JS. These exploits require more skill to probe and compromise (yes, I am aware of automated buffer exploit scanners, but applying them to different environments requires more skill) and is usually an art for a smaller niche community.

However, in the entire flash vs. AJAX security debate, I do have another concern. JS and XHR exploits need to be fixed by the ‘browser’ owners – Microsoft, Mozilla, Apple and others. Flash exploits need to be fixed by Adobe and can be done independent of the browser, since Flash is a 3rd party browser plugin, while JS and XHR are core browser implementations. I wonder if this would mean that relying on browser companies to fix issues takes a longer time than relying on Adobe to fix a plugin-issue. Anyway, as Web 2.0 with AJAX continues to go mainstream, only time will tell.

Conclusion

What we observe, then, is that most of the vulnerabilties of AJAX are little to do with AJAX and more to do with inherent vulnerabilties of immature implementations and bad architectural choices by developers. Most of the vulnerabilities above boil down to:

a) User Input is not validated well
b) Data Integrity and logical firewalling is not thought out well
c) Current implementations of javascript in browsers is rather dismal
d) If your architecture is insecure, no technology can rescue you

What Web 2.0 is doing is making these technologies mainstream. As more people use it, many more bugs come out, and many more people think of hacking insecure sites for fun and profit (nothing new with that). I think overall, this will be beneficial for the web community - there is nothing like taking a technology mainstream to make it robust ! But in the process, developers and marketeers need to be aware that this is an evolving process and should do everything possible to safeguard their own data from the imperfections in the implementation of their chosen tools.

References

http://namb.la/popular/tech.html
http://ajaxian.com/by/topic/security/
http://www.technicalinfo.net/papers/CSS.html
http://insecure.org/stf/smashstack.html
http://www.actionscripthero.co
m/adventures/
http://www.viruslist.com/en/analysis?pubid=184625030

Lazy days are just perfect for me to catch up with reading. This Saturday, as I was browsing through the Internet reading up on new (at least for me) trends and technologies, I came across a recent I-D on a scheme called Identity Based Encryption (IBE) here. The premise and applicability of this technology seemed pretty interesting, so I read more here, here and other places. This technology is currently being pioneered by a relatively new company, called Voltage Security.
I don’t claim to understand complex mathematics, so I am going to restrict my comments on its applicability. Simply put, IBE is not a complete replacement of existing asymmetrical cryptographic algorithms. It allows a mechanism where an arbitrary string could be used by the ’sender’ as a means to encrypt a message. Based on that identity string, the receiver can obtain a private key to decrypt it, as long as the receiver can satisfactorily prove to some ‘Key Server’ that it is the rightful owner of that ‘arbitary identity’ string. This eliminates the need for certificate exchanges before a communication takes place in traditional PKI schemes.

This makes more sense when we apply a deployment model to it. Consider for example, two parties: usera@att.com and userb@vzw.com

In the current mechanism of PKI based security, the following happens:

1. UserA contacts a key server to obtain the certificate of userB. Let us assume that the keyserver for vzw domain resides at vzw.com.
2. UserA then needs to compare the certificate with a revocation list, to ensure that the certificate has not been revoked for some reason
3. UserA should also check whether this key has been signed as authentic from some central authority (say, like Verisign)
4. UserA then extracts userB’s public key from the certificate, encodes the message, and sends it off
5. UserB, assuming that it has its private key is now able to decrypt the message
6. (If User B did not have his private key, or it needed to be refreshed, it would contact its key server at vzw.com securely to obtain it)

There are several issues with this approach:

1. The process of certificate management and verification is expensive for userA
2. For this to work, it is necessary for UserB to have a public certificate created in the first place, or userA cannot even contact UserB
3. The mechanism of directly distributing public keys (the long string of digits you usually see in many mails and sites that say ‘My Public RSA Key is below:’) binds it statically to the associated identity (this will be clear when I talk about the advantages of IBE)

With IBE, steps 1-4 are greatly reduced. Here is what happens with IBE:

1. usera@att.com wants to communicate securely with userb@vzw.com. First, userA contacts vzw.com to obtain what is know as a Master Private key, for the vzw.com domain (remember, we are assuming a deployment model where each master domain manages its own security, and hence, we assume each primary domain will have its own unique master key. Nothing stops multiple domains to use some central master key server, however)
2. Next user A uses the identity string userb@vzw.com as the public key of userb and encrypts the message along with the received master key. What this means is that userB receives an encrypted s/mime message with the From, To and other routing headers intact, but a garbled text body
3. userB now contacts its key server at vzw.com and performs a security exchange proving it is the rightful owner of the identity. Once satisfied, vzw.com provides userB with its private key which userB can then use to decrypt
4. Once userB has received its private key, it does not need to contact vzw.com’s key server each time - it can continue using the same key henceforth, based on the expiry and policies as set by verizon’s key server (this is the same as PKI). In other words, IBE essentially provides a mapping between a abitrary string and the PKI private key that will eventually be used to decrypt the message.

This has some very interesting ramifications:

1. userA can now send secure emails to userB without the problems of first getting its public key
2. The computational power requirement for userA reduces (think cell phones and battery consumption)
3. userB could choose to setup its private key after receiving a secure message from userA.
4. Since the outgoing encryption is based on a string, ad-hoc policies are very simple to implement without the cost of re-invoking/revoking certifcates.
5. Since keys are generated on demand, the key server is essentially stateless, which lends to better scaling for the key server (thanks to a person in the ‘know’ who read and reminded me of this point)

Consider some use-cases:

1. Assume that avaya.com corporation has deployed this scheme, then any emails encrypted with “avaya.com” can generate a private key that applies to all avaya employees. Similarly, an Avaya employee could send an ad-hoc encrypted email only to “sip.avaya.com” for all it’s SIP development list organization. These strings and relation to an appropriate private key is therefore dynamic. You don’t need to pre-create dozens of certificates for such relationships. If a key server for a domain does not want to honor that identity string attribute, it can reject it.

Finally, since the mathematical foundation allows for association with arbitrary strings, each domain can set its own key generation rules. This brings us to my last interesting read, “Fuzzy IBE”. In this approach, the authors extend the scheme to allow for ‘fuzziness of accuracy’. In this approach, when UserB tries to communicate with vzw’s key server to provide he is indeed userB@vzw.com, instead of key exactness, the server and the client (server=VZW key server, client=user B) negotiate a set of attributes which defines B. The server could choose to grant userB it’s private key even if not all attributes are exactly matching. The degree of error tolerance, however is key and the paper discusses algorithms to securely prove its veracity given a particular tolerance. Why is this useful ? Consider for example, the new phones being launched with voice recognition scan or biometric scans. Such idenity proofs are a combination of multiple attributes, and there is no guarantee that are all the same all the time. For example, an iris recognition could go astray, if you just got punched in your eye by the boyfriend of a girl you were trying to warm up to. Or, your voice recognition identity may go astray if you happened to be partying all night before, screaming ‘Who Let The Dogs Out’ So all in all, IBE offers a very convenient approach to standard certificate mechanisms that hopefully will really help in domain based security systems by greatly reducing existing pains that plague the certificate community. In addition, being able to map a URI (identity) to an encryption mechanism should greatly help its deployment in the VoIP space as well.

Playing Devil’s advocate (or when keeping 4 devices instead of one is a good thing):

One Device. In your pocket. Large Screen, hi speed over the air connection. Your phone, your planner, your email, your presence, your Instant Messaging client, your gaming console, your shopping center. It remembers all your preferences and your details. Just ‘one click and go’. Watch TV, order PPV – just one click. Listen to music, buy new albums – one click. Read documents, interact.

In other words, that little PDA of yours is your home away from home. Always connected. How much better can it get ?

One Word: Security

As phones get more ‘powerful’ they morph into general purpose machines, succeptible to the same remote exploits, DoS and security issues an open PC on the internet is. To top it off, many phones work on embedded OSes that cannot offer expensive virtual address space and address locking mechanisms making it easier for one application to write over the address space of others (think heap and stack exploits). Proof of concept viruses for smart phones are already old news (here and here. ) Most of the attacks on PDA phones use the basic concept of buffer overflow techniques - which are very powerful. The idea is this: Whenever a function is called, the return address to the calling function is stored in a stack. When the function exits, the return address is popped off the stack and control transfers to that return address. The idea, then, is to somehow overwrite that stored return address with one that points to malicious code. For example: if a badly written app does an strcpy(pFoo,fnData) and fnData is a userinput, I could craft a string for fnData that is large enough,that in trying to store fnData, the application overwrites it stack; and that string is actually a binary coded exploit that knows exactly where to place a modified return address to point back to another place in that same string, that is the malicious code. Ta-dah. We have an exploit. This is nothing new - techniques for buffer overflow exploits have existed for years. Just that our phones were too ’specific purpose’ for it to do much harm.

Why is this only a problem related to ’smarter phones’ ? Well, what is the worst that has happened to your ‘old’ phone ? You downloaded a game and it crashed your system. That’s it, right ? What is the worst that has happened to your email ? You clicked on a link, and it installed a trojan and your mail server sent a 100 viagra emails to all your buddies, from you. Ouch. What can happen if your phone presence is compromised ? Now put them all together as a converged application platform, where one application compromise can lead to a trojan compromising other installed applications. What happens if you click on your outlook client in your phone and that installs a trojan that takes over your phone control ? How cool – hackers now have multiple application routes and ports from which they can think of attacking your complete phone. Hey, its not a phone anymore – it’s a converged device ! A powerful computer in your palm. And since all these applications sit next to each other in your phone, if one application is compromised, a trojan can attack other applications within your phone – and no firewall can help, because its already in your phone ! Hooray. And if you don’t think this is real, there are already theories out there which acheive buffer exploits via SMS messages.

So again, security. I hope application developers and phone OEMs realize that badly written applications lend themselves to easy exploits and as the convergence dream is racing ahead, so are security concerns. Gee, this was nothing. Here is a paranoid look at how wonderful it can get (click on image for larger version).

UPDATE (Nov/17/05): It seems Sony is in a bigger mess than I thought - I recently read that they actually ripped code for their DRM software from Jon ‘DVD’ Johansen’s Fair Play code which I understand is under LGPL. Obviously, this is a copyright violation. Oh well, they seem to be getting into a deeper mess with each day.

Original Article:
It is human nature - controversies are what we thrive on. As much as we like to hear about heroes, it is villians who make our day. This time, Sony-BMG faces the wrath of the righteous.

The story so far:

1. Sony has been shipping DRM protected CDs for a while now

2. Mark Russovich discovers, almost by accident, that Sony installs a program in your computer that actually installs some hidden files and also ensures that those files are cloaked (in other words, a normal user will never be able to see these files, unless he knows exactly how). In short, Sony installs a driver that hides any files that begin with the special letters ‘$sys$’

3. To Make it worse, Sony does not provide a clean uninstaller - to uninstall, one has to go through cumbersome filling up of forms and periods of non-response.
Mark discovers that when he tries to uninstall the software manually, it ‘trashes’ his CD player. Basically, what Sony does is that it attaches itself as a filter to the CD device driver - if you forcibly remove Sony’s secret drivers, the device driver filter chain gets corrupted and boom - your CD player is no longer visible.

4. Mark gets mad, hacks his way through the DRM process and finally manages to
return his computer to stability (Mark is an established and highly respected Windows hacker)

5. Mark checks the EULA for the DRM software and rightfully finds it to be purposely vague about the intent of the ‘installed software’

6. In the mean time, mainstream media picks up on this and overnight, Sony becomes the new Satan everyone is talking about. Consumer rights have been violated, and so on…..
Class action lawsuits are filed (what would the world be without class action lawsuits… *sigh* )
In the meatime, consumers go haywire in forums around the world, promising never to use anything Sony, including digital cameras. (Don’t worry, the moment Sony releases their next Camera to the market all these promises will be dutifully pushed under the carpet - but till then, it makes great media news)

7. To make things worse, some virus writers exploit the new discover that Sony DRM software cloaks files that begin with “$sys$” and write a virus that begins with those letters. Guess what, Sony happily hides those files too from checkers.

8. In the meantime, Sony does a lame press notice and releases an uninstaller which is partially tested.

Fine. My 2 cents:

a) Sony did mention in the EULA about the ‘proprietary software’. They also mention that it does not transmit private information of clients - this is actually true.

b) Sony’s EULA is worded, as usually, heavily in favour of Sony. The liability is severely limited and the grounds of winning any law suit against them is low to none.

c) The fact that Sony’s cloaking resulted in exploits like the virus writer did is true. However, this is not an something that can be held in court against them. It is similar, to, say, installing sendmail in your computer and someone designing an exploit of sendmail. Sure that exploit never would have existed if sendmail was not vulnerable. Same holds true for Windows vulnerabilities. Software bugs happen. Sony’s DRM code did many wrongs, but this part is bogus. This is why the EULA protects software with the ‘AS IS’ para. Most software vendors do this to protect themselves.

d) Sony did a horrible job as a followup. Instead of trying to please their customer base with a good patch , their uninstaller release was directed only to the press, and to top it off, badly tested. This seems to me, to be an act of defiance by Sony which seems to say ‘Yes, we did. So what. Simmer down, have a cookie’.

e) However, the software does not directly violate anything expressed in the EULA. For example, Sony does not say it will provide an uninstaller. It words it as ‘until removed or deleted‘ - whether manual or automatic, is not explictly stated. Yes, this is wordsmithing a contract, but that is what lawyers do.

Does this mean I will stop using Sony ? Hell No ! Not me. But that is just me. Welcome to the world of DRM. If you choose to buy DRM software or hardware, accept the fact the vendors will do everything possible to enforce DRM. If you have problems, fight DRM as a concept (and best of luck with it).

In other words, please don’t change the focus to ‘Sony is Evil’ - fight the larger concept of DRM if you must.