I’ll confess that I’ve been a little sceptical about the Mozilla Popcorn.js effort over the last year or so. Putting twitter feeds beside a video doesn’t feel particularly interesting. The mozillapopcorn.org site says “Popcorn makes video work like the web”, but I haven’t understood what that means until now. It means 2 things. Firstly, a radially different video-on-the-web experience, where content and video are interleaved. Where video insn’t relegated to being a box on the page with a set of controls. Even simple things like being able to add a ticker to the bottom of the video which contains other ‘page’ content allows the video to be given much greater prominence. And secondly, it’s about the ‘view-source’ nature of the web, and extending this to video effects. Popcorn.js isn’t ‘editing’ the video, but applying effects and overlays in a non-destructive way. This makes it possible for people to come along and discover and learn how things were done. It’s early days for much of this, but I now at least understand why there’s so much excitement as it might have a profound impact on the future web.
Mozilla Popcorn (JS)
Published November 6, 2011 Uncategorized Leave a CommentTags: #mozfest, mozfest mozilla popcorn
Today I got a little distracted by a simple tweet… These planets look pretty cool, so I decided to try to create one. I jumped to Pixelmator which I bought a while ago. Uh. It doesn’t have a ‘Polar Coordinates’ filter. Oh well, I thought. How hard can it be to implement in Quartz Composer? Answer: Most of a day.
Was interesting to dig out basic trig knowledge, and I’m sure my solution isn’t optimal, but it was a fun way to spend an afternoon.
I got there in the end, but unfortunately a little late to actually spend the time to make a decent planet… maybe something for the train tomorrow.
Anyway, I’ve uploaded the .qtz file to downloads.illsley.org. Feel free to grab it and drop it in ~/Library/Compositions/ if you want to play with planets on the Mac.
The DigiNotar, Comodo, and other recent CA incidents has made it clear that the current CA/SSL model requires at least some reinforcement. An enhanced form of HSTS has been under discussion for a while, and this week an initial submission was made to the IETF’s websec group. It would work by allowing an HSTS response to ‘pin’ an HSTS enabled domain to a list of root certificates, end entity certificates, or public keys used from end entity certificates. This allows, for example gmail.com to say that for the next 6 months, only certificates from a set of CAs should be trusted by a browser. While it’s not a panacea, it would help detect and prevent SSL MITMing like that detected in the DigiNotar case. There is a bootstrap problem (the first time someone visits a site, the browser can be fooled), but incremental improvement and defence in depth is the order of business here. If you’re not careful, pinning could have negative consequences, and the spec is careful to minimise these – notably that if you limit yourself to a single CA, you can effectively be extorted when your existing certificate expires, as you have no choice but to pay for a new certificate from the pinned CA.
It’s this flexibility which introduces what I think is a difficult to solve problem. If you’re running a non-SSL site, and an attacker can gain access to your DNS (as recently happened to theregister.co.uk and others), they can ‘pin’ your users to a public key which you don’t have the private key to, and which isn’t revocable. At that point, you either rely on the browser vendors to somehow decide that you really do own your site, and push some kind of special unpin message to all browsers, or you pay up to the attacker to buy the private key, from which you can have a cert issued, and which you can then use to serve your site, and probably downgrade from pinning and HSTS.
In this case, we’ve essentially shifted trust from CAs to DNS registrars, who inevitably have less security expertise. Without HSTS+pinning, theregister.co.uk just had to wait for the registrar to correct the whois records, and for the DNS to propagate. With pinning, a similar registrar failure could have a much longer lasting impact. There are variants to this attack which simply require acting as a MITM, but in those cases, gaining a CA cert for a target domin is considered much harder.
This attack essentially targets the bootstrap phase which we already knew wasn’t secure. After a few days pondering solutions to the problem, the solutions I can come up with essentially further weaken the bootstrap phase, but enable pinning over the long-term without these problems for non-secured sites.
My proposal is to soften the effect of the ‘pin’ for 72 hours from when a domain is first pinned. If, in that period, a certificate which doesn’t correspond to the pin is encountered, the browser must apply heuristics to determine what to do. This may include user input or communication with white/blacklist services. It must not blindly obey the pin.
Why is it important to put this into the spec? If I think about the costs of setting up a truly secure and trustworthy blacklist/unpin service, the task is as complex as running a CA. I think it’s unreasonable to expect that browser vendors will want to get into that business. And even if they did, the time it might take for them to correctly identify the domain owner and correct pinning status would likely be lengthy. Any site owner setting a pin would be rightly upset if their site was incorrectly unpinned. Providing a short window (at the already weak boostrap phase) where a lower set of expectations is codified would provide cover to implement sensible heuristics and low-bureaucracy services to mitigate the worst of the problem, without implying that those same services would be appropriate for a general pin revocation scenario.
After watching the #osgitool session the other day which covered some pretty advanced OSGi tooling, it occurred to me that given the learning and migration curve to use OSGi, there are people a long way from using it, but who could benefit from the OSGi metadata everyone is spending time on.
How so? Well, Eclipse supports ‘Access Rules’ on dependency libraries which essentially mimic the Export-Package property in OSGi. A tool which allows you to easily set up this configuration based on the manifest would allow you to respect the (normally carefully crafted) Export-Package restrictions without going all the way to OSGi. Hopefully this means that you’re less likely to use APIs which are considered internal, and so when you’re upgrading the version of your dependency, there’s less likelihood of accidental incompatibilities.
The source to this (very simple) plugin is on github, and along with a built jar which you can drop in the dropins folder.
Then, to use it, simply right-click on a Java project and select “Refresh OSGi export restrictions”. This will then scan the dependent jars and their manifests, and for OSGi bundles, update the Access Rules to explicitly allow use of exported packages, and forbid use of all other packages (this is visible in the Java Build Path/Libraries tab).
If it’s useful and you have feedback, please use the tracker on github.
After more than five years working in the IBM Hursley Software Lab, I’ve decided that it’s time to move on. I’ve enjoyed my time in Hursley greatly and learned a lot, but in order to further grow my career, I’ve decided to leave the connectivity middleware space. I’ve worked with a lot of talented developers and architects in Hursley and around the globe on a variety of interesting projects and products, and I hope I cross paths with many of them in the future, and wish them all the best.
So what does the future hold? Well, a move away from a software product vendor to a company which uses technology and software in support of (and to drive) its business. Also a move from the leafy Hampshire countryside to Canary Wharf. On a date TBC in the not too distant future, I’ll start work as a software engineer at Morgan Stanley.
I’m really excited and looking forward to working with a new team on new challenges and learning a lot more about the finance industry.
I shook up my whole web presence last weekend because of an impending hosting renewal bill. I moved all of my hosting from dreamhost.com to an ec2 micro instance. This gives me a bunch more flexibility for a reasonable price, and gives me a little more exposure to the ec2 platform.
One of the benefits is the ability to host tomcat, and hence use some java on the web. My first attempt is that of a (private) URL shortener, providing urls at i5y.li
Why i5y.li? i5y is a shortening of Illsley, and li was a cheap ccTLD with some at least relevant letters (.ly which is probably the most obvious option is much more expensive.)
OSGi, Java Security Manager, and keeping things simple…
Published November 29, 2010 java , Tech Leave a CommentI’ve spent the last couple of hours trying to understand Java2 Security in an OSGi environment. There’s a presentation available at [link] which gave me lots of information and hints of what to search for and what to play with. I’ve also had a quick skim to the relevant section of the OSGi 4.2 spec. Here’s a quick summary of what I’ve discovered. It may not be 100% correct… do let me know if i’ve got the wrong end of the stick on something.
In an OSGi 4.2 environment, the Conditional Permission Service is king. Well… kindof. There are 3 sources of permission information to consider:
1. Java2 Security Policy
2. Dynamic(Programmatic) configuration of the Conditional Permission Service
3. Local Permissions. (Static, per bundle policy)
In a relatively static environment it appears that you could pretty much ignore the programmatic Conditional Permission Service and rely on the more static options 1 and 3.
In order to enable OSGi security, you start by enabling Java2 security with an ‘all permissions’ policy file. Yes, I did just say that. It seems counter intuitive, but in order to allow the OSGi Framework to do its thing, it needs full permissions. It seems to be plausible to give just the framework bundle(s) the All Permission in the policy, but this affects (removes) the implied permissions of the other bundles which breaks everything. More investigation required.
So, assuming you already have an OSGi application:
java -jar org.eclipse.osgi_3.6.0.v20100517.jar -Djava.security.manager -Djava.security.policy=all.policy
all.policy:
grant { permission java.security.AllPermission; };
And you’re in an identical situation to before. All code has all permissions. The up side is that it’s just a couple of steps to start restricting the priviledges of your bundles.
Add an empty file “OSGI-INF/permissions.perm” to a bundle, and apart from some implict permissions (e.g. to import packages, read/write the bundle configuration area), that bundle has had its permissions entirely removed. You can the start giving the bundle permissions e.g. by adding a line:
(java.io.FilePermission “/Users/*” “read”)
This provides a very simple way to enumerate the permissions a bundle requires and restrict it to them. It also provides a simple file to audit for each bundle. There are a couple of important things to note:
1. An empty file is not equivalent to no permissions.perm file. Make sure you have a permissions.perm file if you want restricted permissions.
2. The permissions.perm file specifies the maximum permissions the bundle requires. The framework/Conditional Permission Service in conjunction with the system security policy may result in lower available permissions.
This looks great for reducing the risks from exploits in bundles I develop, but clearly doesn’t help much with 3rd party bundles, which is where the Conditional Permission Service should come into its own. More on that once I’ve worked it through.
I’ve been asked a few times in the last couple of months whether I’d buy an iPad. My stock response has been probably not, but we’ll see what happens when I try one. That happened today. I bought an iPad.
So far I’m very happy with it. Its great for web browsing, watching videos, and I’ve got a couple of interesting apps for it. I’m also really happy with the quality of the onscreen keyboard. Having used an iPhone, I’d been sceptical that the iPad keyboard would be much better. I was wrong. It’s still not as good as a real keyboard, but it’s a huge improvement.
The combination of Apache OpenJPA and Derby provides a fantastic and simple way to prototype database apps in Java. The only downside is that there are a couple of gotchas I keep on finding myself hitting each time I start a new project. Here’s the simplest app I can think of and all the associated files for my later use. If it’s useful to you as well, have fun!
File: src/main/java/test/Account.java
package test;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
@Entity
public class Account {
private String name;
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private long id;
public Account(String name) {
this.name = name;
}
public String getName() {
return name;
}
public long getId() {
return id;
}
}
File: src/main/java/META-INF/persistence.xml
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"> <persistence-unit name="account"> <class>test.Account</class> <properties> <property name="openjpa.jdbc.SynchronizeMappings" value="buildSchema" /> <property name="openjpa.ConnectionURL" value="jdbc:derby:testdb;create=true" /> <property name="openjpa.ConnectionDriverName" value="org.apache.derby.jdbc.EmbeddedDriver" /> </properties> </persistence-unit> </persistence>
File: src/test/java/test/AccountTest.java
package test;
import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.EntityTransaction;
import javax.persistence.Persistence;
import junit.framework.TestCase;
public class AccountTest extends TestCase {
public void testAccount() {
EntityManagerFactory emf = Persistence.createEntityManagerFactory("account");
EntityManager em = emf.createEntityManager();
EntityTransaction et = em.getTransaction();
et.begin();
Account a = new Account("Bob");
em.persist(a);
et.commit();
System.out.println("a"+a.getId());
}
}
File: pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>test</groupId> <artifactId>test</artifactId> <packaging>jar</packaging> <version>1.0-SNAPSHOT</version> <name>test</name> <dependencies> <dependency> <groupId>org.apache.openjpa</groupId> <artifactId>openjpa-all</artifactId> <version>2.0.0</version> </dependency> <dependency> <groupId>org.apache.derby</groupId> <artifactId>derby</artifactId> <version>10.5.3.0_1</version> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.8.1</version> <type>jar</type> <scope>test</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.0.2</version> <configuration> <source>1.5</source> <target>1.5</target> </configuration> </plugin> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>openjpa-maven-plugin</artifactId> <version>1.0</version> <configuration> <includes>**/entities/*.class</includes> <excludes>**/entities/XML*.class</excludes> <addDefaultConstructor>true</addDefaultConstructor> <enforcePropertyRestrictions>true</enforcePropertyRestrictions> </configuration> <executions> <execution> <id>enhancer</id> <phase>process-classes</phase> <goals> <goal>enhance</goal> </goals> </execution> </executions> <dependencies> <dependency> <groupId>org.apache.openjpa</groupId> <artifactId>openjpa</artifactId> <version>2.0.0</version> </dependency> </dependencies> </plugin> </plugins> </build> </project>
