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

>> As I state above the main use case I am thinking of is storing credentials
>> for application authentication to a server.
> I'm concerned that you guys are just talking past one another. Can you maybe
> provide a piece of code that exemplifies what you have in mind (with made-up
> names and all)? That would make it easier for people to point out what they
> disagree with, how they'd break it (or not), etc.

Yes, you're probably right we're talking past one another.

I have only two points to make:

1) Signing will not solve the security issue. As long as we all agree
on that, I'm happy.
2) Any way of storing login data MUST NOT be dependent on JavaScript;
that is, the data must not be read out by a script. That could
constitute a security problem. As long as there's another mechanism
for setting and getting login data, I'm happy.

To illustrate the second point: suppose a widget contains a login
script for Flickr:

var login = device.getLoginData('Flickr');

Now the app is logged into Flickr.

The problem is that anyone could open the widget, add a line, re-zip
the widget, and distribute it. Now it reads:

var login = device.getLoginData('Flickr');

We must prevent the login data from being retrieved in this second
case. That prevention should be a layer deeper than JavaScript. As far
as I understand there might be a way of signing a widget and then make
sure this signing is broken when somebody else opens it. If the widget
is not signed, the device.getLoginData call fails.

I know next to nothing about signing, so I'm just repeating what I
heard. I'd like to know if such signing would constitute adequate

An even more insidious way of doing the same would become possible if
the widget donwloads a remote script from the Internet. That script
could change the original, harmless login function to the second,
malicious version. Worse: it wouldn't break the signing because the
widget itself would not be changed (if I understand signing

The original author might be malicious himself, and change the remote
script once the widget has passed the signing process. But even if
he's completely honest and trustworthy, a malicious entity could, for
instance, mess with the DNS records somewhere so that the widget does
not download the harmless remote script from the true server, but a
malicious remote script from a completely different server.

It's this kind of scenario that I'm worried about.

Hope this helps,

Received on Thursday, 15 October 2009 11:50:23 UTC