RE: ISSUE-11: Gathering requirements [FileSystem API]

Hi again,

I don't mean that digital signing by nature makes widgets safe. Instead digital signing is intended to securely verify the identity of a web application, typically a web widget. It is then another decision to make whether the originator of the widget can be trusted or not. This is perhaps more of a philosophical discussion and is out of scope for this working group. We are actually trusting providers of web applications today. If we were not I can't see how web-based banking services or access policy framework like Bondi's would be possible at all.

The proposal is mainly targeting the case when an application (not the user) needs to authenticate itself towards a server. I don't propose any method to provision the credentials/secret information to the secure storage. This can be done through any "out of band method". The API must assure that only the "correct" application is allowed to access the secret information. This of course assumes that a decision is made to trust the originator of a securely identified web application. (If it is not possible to make a decision to trust certain web application originators then please explain to me how banking applications are possible.)

The other assumption is that the mobile platform is capable of protecting its memory from being accessed by other applications. This might be an issue in existing platforms and admit that my knowledge here is limited. However, if I interpret Brian LeRoux correctly iPhone and Android provides memory protection for memory space dedicated to a certain application. If the platform provides memory protection and we assume that the developer of a certain web application is a good guy is there any other way do "inject" malicious JavaScript to a web application running in the device? In what way is JavaScript more insecure than any other software language? Isn't this a question of the security the execution platform supports.

As I state above the main use case I am thinking of is storing credentials for application authentication to a server. For user login I agree that OpenID/OpenAuth are good alternatives even though this might not the best solution for every case. 


-----Original Message-----
From: Peter-Paul Koch [] 
Sent: onsdag den 7 oktober 2009 15:14
To: Nilsson, Claes1
Subject: Re: ISSUE-11: Gathering requirements [FileSystem API]

2009/10/7 Nilsson, Claes1 <>:
> Thanks for all comments. Nice to have a lively discussion :-)
> With my proposal I assume:
> * It is possible to securely verify the identity of the web application (typically a signed widget).

Yes, but that does not make the widget safe.

The problem is that a widget can import any JavaScript from the Web
and execute it. Obviously, this downloaded script may contain insecure
items, even when the widget itself doesn't.

So a malicious author creates a widget that imports a perfectly
innocent remote script, sends it in for review and signing, and as
soon as the widget has passed the tests and is actually downloadable
he changes the remote script to steal somebody's address book or

This is why widget security is such a terribly complicated subject,
and why signing is not the solution to our security problems.

> * The mobile platform is capable of preventing any other applications than the application the secret information is aimed for from accessing the information.

As I said earlier, any HTML/XML/JavaScript solution we can devise can
easily be copied to another widget. Signing would be a different
matter, but even signing does not make a widget safe.

> This of course places restrictions on the usage of this API and places requirements on the devices implementing the API.

I feel that the user should be asked for permission to access address
books and such, and that this permission-asking is a browser or OS
functionality that cannot be influenced by JavaScript.

> I would like to take your comments to an internal discussion with our security experts and come back with more meat to the discussion later.

Please do!


ppk, freelance front-end consultant,
agent, and trainer


Received on Friday, 9 October 2009 15:46:27 UTC