But who wants to be thought of as a consumer? Truth be told, I never really liked Apple or Steve Jobs very much until I started reading stories collected on Folklore.org, a collection of stories maintained by Andy Hertzfeld. These stories really won me over. As a software developer, my emotions are mixed that I haven’t tried my hand at a startup. Folklore’s stories both relieve me and inspire me to want to try. The original Macintosh really was a great story to tell. I hope it takes less time for the equivalent story of the iPod and iPhone to come out, I’d be interested in hearing it.

As I listen to this week’s Security Now! podcast, I thought of a potential useful addition to the SSL trust model we employ today.

In a (probably technically deficient) nutshell, SSL works in the following way:

1. a client sends a request to a server, initiating what is known as the handshake
2. the server responds with a copy of its certificate (typically in a chain format that contains the certificates of the CAs that signed it
3. the client software verifies that it trusts at the very least the last CA in the list presented to it as an authority
4. after that verification is done, further traffic is encrypted using a less computationally intensive key that is securely exchanged

The main issue (in my opinion) with the current trust model SSL uses is that it is based upon the hope that a certificate authority never does the wrong thing. In the case of DigiNotar, an immediate certificate revocation list update could be posted by them to withdraw the validity of the certificate in question, but it’s far safer to merely not trust the company that issued the certificate as a result. I propose adding an optional step to the trust model that allows the service provider some say in what certificate authority (or authorities) they choose to use. As the Security Now! podcast likes to joke, why are we trusting the Hong Kong post office to be a certificate authority for anyone online? The Internet already employs a handy key/value pair lookup service throughout its infrastructure called DNS. In a similar vein to Yahoo!’s DomainKeys why not add a DNS record for either a list of valid certificate serial numbers or a list of trusted CAs? Doing so would definitely change the landscape of trust online, as the service endpoint could have an extra layer of verifiability to it rather than trusting the contents served up by the endpoint itself. Since the DNS records are presumably owned by the same folks who should be running the endpoint, the client can verify that the certificate served by the endpoint indeed matches up with what the DNS record allows it to be.

This should address the flaw of having to trust content served by a potentially untrustworthy source. In addition, it only adds a minimum of new steps to the verification process and allows for optional implementation of such trust extensions. On the other hand, it also creates a second weak point that historically has been weaker than the CAs. However, I believe that adding an optional verify step to the SSL handshake would reduce the threat of man in the middle attacks over trustworthy connections without totally reinventing the system of trust we use in today’s Internet.

One criticism of Maven (esp. when compared to Apache Ivy) is a lack of enforcement of hard version numbers in dependencies. Maven allows you to specify inclusive and exclusive ranges for dependencies. The problem is, by default Maven doesn’t enforce those ranges.

Here’s an example of two modules. The first has a hard dependency of JUnit 3.8.1 while the second explicitly wants 4.0.

<project>
	<modelVersion>4.0.0</modelVersion>
	<groupId>name.joshpeters.example</groupId>
	<artifactId>Module1</artifactId>
	<version>1.0.0-SNAPSHOT</version>
	<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>[3.8.1]</version>
		</dependency>
	</dependencies>
</project>

<project>
	<modelVersion>4.0.0</modelVersion>
	<groupId>name.joshpeters.example</groupId>
	<artifactId>Module2</artifactId>
	<version>1.0.0-SNAPSHOT</version>
	<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>[4.0]</version>
		</dependency>
	</dependencies>
</project>

Now a good practice would be to prevent builds from succeeding if there are incompatibilities with the dependencies. If Module1 fails to execute using JUnit 4, it’d be nice to know as soon as possible. (Another criticism of Maven is that it tends to obfuscate any errors encountered.)

Fortunately, as with most things Maven, the solution lies in the use of plugins. In this case, we can configure the Maven Dependency Plugin to run its analyze-only goal during resource processing. Doing so will trigger a failure anytime we have such version issues in our dependencies at a time in our build where we get more value (IMO) out of failing.

Normally, the verify phase would be where the dependency plugin would execute, which may not be executed at all if you just execute mvn package! We don’t want such a false positive if we can avoid it, so here’s a configuration that gets us what the more Ivy-style failure:

<project … >
…
	<dependencies>
		<dependency>
			<groupId>name.joshpeters.example</groupId>
			<artifactId>Module2</artifactId>
			<version>1.0.0-SNAPSHOT</version>
		</dependency>
		<dependency>
			<groupId>name.joshpeters.example</groupId>
			<artifactId>Module1</artifactId>
			<version>1.0.0-SNAPSHOT</version>
		</dependency>
	</dependencies>
	<build>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-dependency-plugin</artifactId>
				<version>2.2</version>
				<executions>
					<execution>
						<id>analyze</id>
						<goals>
							<goal>analyze-only</goal>
						</goals>
						<phase>process-resources</phase>
						<configuration>
							<failOnWarning>true</failOnWarning>
						</configuration>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>
…
</project … >

failOnWarning set to true will cause analyze-only to fail whenever there are dependency compatibility issues.

Here’s what Maven 3 now reports back early in its lifecycle:

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.615s
[INFO] Finished at: Wed Apr 06 21:06:35 CDT 2011
[INFO] Final Memory: 5M/268M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.2:analyze-only (analyze) on project PROJECT: Dependency problems found -> [Help 1]

Now that YouTube, Gmail, and all of the rest of Google’s flagship assets are now accessible through the SPDY protocol, we are pleased to announce that a future version of Chromium (as well as Google Chrome and all versions of Chrome for Android) will remove support for HTTP.

Progress is not easy, and we know this move may adversely affect some of our customers (namely the ones who use the web for non-Google approved uses), but the future is now. SPDY offers many attractive new features that HTTP does not, so HTTP has got to go. Consumers will get used to the reality that nearly all of their favorite sites no longer work with our browser and can look forward to the day Chrome automatically updates itself to remove support for A technology not controlled by Google.

We know that our customers expect Chrome to be the fastest browser out there, which is why we ruthlessly cut out de facto standards in wide use after helping to get the public excited about those very standards in the first place. Just as we did away with animated GIF support (YouTube always was a better choice anyway) and non-Unicode character set support (up yours “Windows-1252″), HTTP can now be considered a museum piece next to Gopher.

What are you going to do, switch to Firefox?

Happy birthday to the director of 12 Monkeys, Time Bandits (which I just introduced to my wife this weekend), and my all-time favorite movie Brazil.

Tideland creeped me out though.

The issue with iOS and its Gmail integration is that there is no way out of the box to invite folks to a calendar event. If you choose the Exchange setup path instead of the Gmail setup path, you can get that killer feature back on your handheld device (I assume this would also work in Outlook, but I don’t use that for personal mail).

Another benefit of using Google as an Exchange server is that your contacts will be synched up too. The key setting is the server name, which is m.google.com. Using that setting enables you to have a calendar that you can add attendees to.

As well as its bloodier sequel (with lots of movie references).

If you wanna buy the album, use the link below and I get a teeny, tiny sum of money.