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

> 1) Signing gives:
>  - Authentication, i.e. secure indentification of the creator of the signature.
>  - Integrity protection, i.e. assures that the signed data has not been changed after the signature was created.

OK, so I do understand signing a bit. That's good to know <g>.

> 2) The scenarios you describe will not be possible if we assume that only digitally signed web applications, e.g. Web Widgets signed according to http://www.w3.org/TR/widgets-digsig/, are allowed to access the proposed "secure data storage" API. A widget's content can of course be copied and altered but access to the "secure data storage" API will in this case be denied by the device's widget runtime as the signature will be invalid.

This I don't quite understand. I see the basic point, but wonder what
happens in the case of externally downloaded scripts.

If a widget downloads an external script from the Internet, will the
signing become invalid? It shouldn't, because there are use cases for
downloading external scripts.

On the other hand, as I said before an externally downloaded script
can become a danger.

> 3. When Mr Good has created the widget it is submitted to the "authorities" of Happy Social that reviews the widget to check that the widget is not doing anything evil. If ok the widget is signed, which means that all content of the widget is integrity protected.

But the external script may be changed later. And it's not part of the
widget content proper, because it's not in the widget zip. Exactly how
does one check for these contingencies?

> Notes:
> a. Any attempts for Mr Good, turning out to be evil, to change the widget after it has been signed will fail as the device will find the signature invalid.
>
> Are there obvious gaps in the hypothetical scenario above?

Same question as above: does this also go for externally downloaded scripts?

> Are there any specific security issues with JavaScript compared to other languages?

Yes. Mainly the downloading of dangerous external scripts. Once a
script is accepted within a certain JavaScript runtime and runs in a
web page or widget context, it has access to all global variables of
all other scripts. Essentially this means that you can steal pretty
much anything that's defined in a JavaScript context and send it to
another server via Ajax. Some protection is given by using local
variables and closures, but many JavaScript authors don't quite know
how to do that and/or don't bother. (Not good, I know, but it's the
reality of the web/widget game.)

------------------------------------------------------------------
ppk, freelance front-end consultant,
agent, and trainer
http://www.quirksmode.org/about/
------------------------------------------------------------------

Received on Wednesday, 21 October 2009 09:31:00 UTC