Sunday, May 29, 2005

Digital Restrictions Management and Treacherous Computing

It is long since copyright enforcing institutions exceeded the limit of decency in their "holly war" against piracy. They arrived to a point where they are calling intellectual property infringement "a crime" and children are thought that "piracy funds terrorism" [1][2][3]. Maybe these absurd arguments are enough to pass some bills through the US Senate or further terrorize the middle-class American citizens, but I always thought that to the rest of us they were just nonsense and filthy lies.

Apparently I was so wrong. These lies actually did manage to pass a very controversial law entitled the Digital Millennium Copyright Act (DMCA) in the US Senate, which criminalizes production and dissemination of technology that can circumvent measures taken to protect copyright, not merely infringement of copyright itself, and heightens the penalties for copyright infringement on the Internet. And if this is not enough the US Senate is looking to pass the Consumer Broadband and Digital Television Promotion Act (CBDTPA) that would be even more restrictive than the DMCA. It would prohibit any kind of technology which can be used to read digital content without Digital "Rights" Management (DRM). Unfortunately these victories for copyright-owning interests (publishing, film, music and major software companies) over the copyright users' interests are not common only to the US. In Europe the EU Copyright Directive comes close enough to the US DMCA although many aspects are not specified in the Directive and and depend of each EU member's "implementation".

Content publishers argue that DRM technologies are necessary to prevent huge revenue losses caused by illegal duplication of their works. Even though this argument is also questionable I will accept for now that copyright holders are affected by piracy. What I find dangerous is the ease with which civil liberties are sacrificed just to protect copyright. With DRM the users are no longer in charge of how they use the media: they are not able to make full use of devices they rightfully own, they are not able to make legal copies for backup purpose and they are not able to quote or make compilations under the right of fair use.

However, the DRM lobbyists don't limit their influence to the distribution of copyrighted music or movies, they are starting to become more concerned with computing. The DRM umbrella is broad enough so that it can cover any technology that can be used to control and restrict the use of "digital media". No, DRM is not about rights, but about restrictions, so a much more appropriate term for it is Digital Restrictions Management.

Now back to computing, something big has just happened: Intel has secretly added DRM features to its newly released dual-core Processors [4][5][6]. They will most likely try to ruin our freedoms under the pretext that will stop non-signed drivers, viruses, piracy, terrorism, drug smuggling and cancer. Well, as you might imagine, none of these will happen, but what might happen is that both Windows and Intel will strengthen their monopolies by destroying interoperability. And if all goes well for Intel the other processor producers (AMD, IBM, nVIDIA, ATI, Sony, Transmeta, HP are all members of the "Trusted" Computing Platform Alliance) might start adding DRM to their chips too. The wonderful dreams of free software and civil rights in cyberspace will be things of the past then, optimistic prophecies that never came true.

If you are worried about your digital rights, here are some places you might want to visit:

  1. Electronic Frontier Foundation - a nonprofit group of passionate people working to protect your digital rights.
  2. Trusted Computing FAQ
  3. AgainstTCPA.com - Computers and Internet gave you freedom. TCPA would TAKE your FREEDOM.
  4. Anti-DMCA.org - Corporations, we've had enough. Take back the Net!
  5. Can you trust your computer?, Richard Stallman, 2002
  6. The Right to Read, Richard Stallman, 1997
  7. Free Culture, Lawrence Lessig, Basic Books, 2004 - How Big Media Uses Technology and the Law to Lock Down Culture and Control Creativity. Available for free download.
  8. Beyond Fear, Bruce Schneier, Springer, 2003 - In his latest book, security guru Bruce Schneier explains how security really works. More than this he invites us to take a critical look at not just the threats to our security, but the ways in which we're encouraged to think about security by law enforcement agencies, businesses, and national governments and militaries.

Saturday, May 28, 2005

OpenDocument

The OpenDocument is a standard XML-based file format suitable for office applications. It covers the features required by text, spreadsheets, charts, and graphical documents. OpenDocument is highly interoperable by making use of existing standards like HTML, SVG, XSL, SMIL, XLink, XForms, MathML or Dublin Core wherever possible.

Version 1.0 of the OpenDocument specification was approved as an OASIS standard in May, 2005. The European Union also recommended OpenOffice.org as the basis for standard file formats and document interchange, and the OpenDocument format is likely to become an ISO Standard. OpenDocument already enjoys the support of several major players like Sun , IBM, HP, Novell and even Adobe.

The first programs implementing OpenDocument are already available in beta. Version 2.0 of OpenOffice.org will use it as the default file format, but there will be a filter for the upcoming version 1.1.5 as well. Also the open source project KOffice is going to include the OpenDocument format, planned for version 1.4. The Abiword project announced an import/export filter for the format and it is very likely that many other office suites like StarOffice from Sun or IBM Workplace will soon follow.

OpenDocument is:

  • An open, XML-based file format.
  • An open standard, supported by the OASIS and ISO standards groups.
  • The default file format for the upcoming OpenOffice.org 2.0 and KOffice 1.4 and others.
  • A top prospect for an official format for the European Commission.
  • Our best chance to fight vendor lock-in associated with proprietary formats.

References

  1. OASIS Open Document Format for Office Applications (OpenDocument) TC
  2. OpenDocument FAQ
  3. The Future Is Open: What OpenDocument Is And Why You Should Care - by Daniel Carrera - Grocklaw
  4. Open Document Format Approved - Slashdot.org

Sunday, May 22, 2005

SSL is killing the Web interactivity

It is well-known that the server performance degrades considerably for SSL transactions compared to the non-SSL case. However, many people running Web servers are (mis)using SSL for a lot of not-security-critical content. In most cases this leads sever overloading and unacceptable long waiting times for the clients. The best example of this is probably SourceForge.net, whose servers are overloaded 100% of the time as they are using SSL for almost all of the administration tasks. Most of these tasks are not security critical, but they are time critical to many of us. Using SSL for them is like wearing a firefighter's full turn out gear to protect you from getting a minor burn when having a family barbecue. It is overkill.


As for me, I am starting to graw tiered of waiting for Web pages to load over HTTPS. It takes so long that I sometimes give up before it's done. If there was a way to disable SSL for services like SourceForge.net, I would do it right away. The productivity decrease is so high with SSL that I am ready to give away security just to be able to get my work done.


Important Facts:

  • SSL increases computational cost of transactions by a factor of 5 to 7
  • On a 1.4 GHz Xeon machine the computational demand of an initial handshake is around 175 ms and that of a resumed handshake is around 2 ms.
  • RSA computations are the single most expensive operation in TLS, consuming 20-58% of the time spent in the web server.

Further Reading:

  1. V. Beltran, J. Guitart, D. Carrera, J. Torres, E. Ayguadé and J. Labarta, Performance Impact of Using SSL on Dynamic Web Applications., XV Jornadas de Paralelismo, pp. -, Almeria, Spain. September 15-17, 2004. PDF File (144 KB)
  2. Kant, K., Iyer, R., & Mohapatra, P. (2000). Architectural impact of secure socket layer on Internet servers. Computer Design, 2000, International Conference, 7-14. PDF File (248 KB)

  3. C. Coarfa, P. Druschel, and D. Wallach. Performance analysis of TSL web servers, 2002. PDF File (144KB)

  4. H. Xubin, A Performance Analysis of Secure HTTP Protocol. PDF File (154 KB)


Thursday, May 19, 2005

Using JAXP 1.3 with JBoss 4

Some of my ADF classes heavily rely on DOM L3 and they won't run with the default settings of JBoss 4.0.2 (and its old endorsed parser). They run just fine with the JAXP 1.3 parser that comes with Java 5.0 so I tried to get rid of the endorsed directory. Unfortunately just removing the directory won't help, as the JAXP 1.3 classes are not added to the classpath by default. I tried to add %JAVA_HOME%\jre\lib\rt.jar to the classpath but this still didn't fix the problem. I sill got a lot errors and the most interesting one was a java.lang.NoClassDefFoundError: org/apache/xerces/xni/parser/XMLEntityResolver.

When I had a look at rt.jar the path to the
XMLEntityResolver class is now com/sun/org/apache/xerces/internal/xni/parser. Trying to hack past the NoClassDefFoundError I also added the contents of the endorsed directory to the classpath (after removing the -Djava.endorsed.dirs=%JBOSS_ENDORSED_DIRS%" and adding rt.jar to the classpath)

Well, this made Jboss start without errors but it has not solved my problem. I was still getting the same error as before when I tried to perform some DOM L3 functions:

Unexpected Error in method: public abstract void net.sf.adf.transport
.JMSTransportRemote.send(net.sf.adf.acl.ACLMessage) throws net
.sf.adf.transport.SendingException,java.rmi.RemoteException

java.lang.AbstractMethodError: org.apache.xml.serialize
.DOMSerializerImpl.getDomConfig()Lorg/w3c/dom/DOMConfiguration;


at net.sf.adf.acl.xml.XMLCodec.encode(XMLCodec.java:63)
at net.sf.adf.transport.JMSTransport.send(JMSTransport.java:133)
at net.sf.adf.transport.JMSTransport.send(JMSTransport.java:119)

The code that caused this exception is this:

Code
public String encode(ACLMessage message) throws EncodingException {
Document doc = encodeDOM(message);
try {
DOMImplementationLS domImplLS =
(DOMImplementationLS)doc.getImplementation();

StringWriter sw = new StringWriter();
LSOutput output = domImplLS.createLSOutput();
output.setCharacterStream(sw);

LSSerializer serializer = domImplLS.createLSSerializer();
DOMConfiguration config = serializer.getDomConfig();

In the end I managed to make it work by adding one final touch to the solution described above. Instead of the (arguably) more portable way of obtaining a DOMImplementation:

Code:
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
DOMImplementation domImpl = builder.getDOMImplementation();


I directly used the DOMImplementation from JDK1.5, that is:

Code:
DOMImplementation domImpl = (DOMImplementation)com.sun.org.apache.xerces
.internal.dom.DOMImplementationImpl.getDOMImplementation();

This is not a nice solution, but it was the best I could find on my own. If you have a more elegant I would be interested in finding out about it.

In both cases I had to make sure that the DOMImplementation supports LS 3.0:

Code:
  if (!domImpl.hasFeature("LS", "3.0")) {
throw new ParserConfigurationException(
"Load/Save 3.0 not supported");
}


and finally I used it to create new documents:

Code
Document doc = domImpl.createDocument(namespaceURI,
rootElementQualifiedName, docType);

cast it to a DOMImplementationLS and parse existing ones:

Code:
     DOMImplementationLS domImplLS = (DOMImplementationLS)domImpl;

LSInput input = domImplLS.createLSInput();
input.setCharacterStream(reader);
LSParser parser = domImplLS.createLSParser(
DOMImplementationLS.MODE_SYNCHRONOUS,
validating ? "http://www.w3.org/TR/REC-xml" : null);
// for schema validation this would be set to
// "http://www.w3.org/2001/XMLSchema"
parser.getDomConfig().setParameter("validate", validating);
Document doc = parser.parse(input);

or serialize in-memory DOM trees:

Code:
     DOMImplementationLS domImplLS =
(DOMImplementationLS)doc.getImplementation();

LSOutput output = domImplLS.createLSOutput();
output.setCharacterStream(writer);

LSSerializer serializer = domImplLS.createLSSerializer();
serializer.write(doc, output);

There are so many people who don't have the slightest idea all these are possible using the DOM and it's very good JDK1.5 implementation. It is a pity that JBoss is still shipping with a hard-wired full-of-bugs old implementation of Xerces when JAXP 1.3 works great.

Essentially it would not be very hard to make JBoss 4 work with JAXP 1.3 instead of 1.2. I just did a quick search in the JBoss 4.0.2 source for the phrase org.apache.xerces and there are only 11 java source files containing it. According to the JAXP 1.3 relese notes the most important incompatibe change in JAXP 1.3 is that the packages for Xerces and Xalan got renamed. This was made on purpose and makes it possible to deliver to the JDK1.4 without using the endorsed standards mechanism. This change lets you reference newer Apache libraries in the classpath, so application developers can use them in the same way that would use any other additions to the Java platform.

I am not saying that moving the implementation of JBoss to JAXP 1.3 will be painless, but this is a necessary evolution. Until that happens I hope that the workarounds I describe above will help you unleash the power of JBoss and DOM L3 processing.