Re: Rechartering WebApp WG

On Wed, Feb 10, 2010 at 5:42 PM, Marcos Caceres <marcosc@opera.com> wrote:
>
>
> On Feb 11, 2010, at 2:10 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>> On Wed, Feb 10, 2010 at 4:59 PM, Marcos Caceres <marcosc@opera.com> wrote:
>>>>>>>
>>>>>>> I'm sooooooo totally for that. I want nothing more than to have more
>>>>>>> engagement and input from you guys. Our URI spec is in last call and
>>>>>>> so
>>>>>>> is
>>>>>>> the access request spec. The specs are really small. Please find a
>>>>>>> few
>>>>>>> hours
>>>>>>> and help us align if we haven't already. It's never too late to
>>>>>>> comment
>>>>>>> and
>>>>>>> help us fix stuff if it's borked. We are doing the best we can here,
>>>>>>> and
>>>>>>> certainly don't want to go against the web security model.
>>>>>>
>>>>>> It's funny that you say that, because last I commented on a widget
>>>>>> spec was in relation to the signing spec. I then expressed dislike for
>>>>>> the use of xml canonicalization and, IIRC, a few other non-trivial
>>>>>> aspects of the spec. But was told that the spec was too far along and
>>>>>> it was too late to change :-)
>>>>>
>>>>> That is correct. Many members working on widgets believed that the use
>>>>> cases
>>>>> were met by XML digsig (even with it's reliance on xml
>>>>> canonicalization)
>>>>> and
>>>>> I was led to believe that it is in fact implementable. I know of one
>>>>> implementation thus far, so the jury is still out. It's still too early
>>>>> for
>>>>> me to say if it was a mistake to take XML digsig over JAR signing. If
>>>>> it
>>>>> proves a mistake (I.e., no one implements), then it's logical to look
>>>>> for
>>>>>  alternatives. I won't claim to understand the xml canonicalization
>>>>> issue,
>>>>> but people I talk to still tell me it won't be a problem. You want to
>>>>> add
>>>>> some tests to the test suite?:)
>>>>
>>>> I don't doubt that it's implementable. However I still think there are
>>>> much simpler solutions that make things easier both for authors and
>>>> browser implementors. See for example the way that mozilla signs XPI
>>>> files.
>>>
>>> I don't disagree with you on the implementation side (and Im happy to
>>> hear
>>> that you think it can be implemented - I'll keep my fingers crossed). On
>>> the
>>> author side, I honestly don't know how much of a difference it will make.
>>> I'm sure someone will create a dead easy click once packager for widgets,
>>> if
>>> they haven't done so already. But is there something inherently wrong
>>> with
>>> our current technological choice that would not allow that? (if yes,
>>> please
>>> send to public-webapps, which is where we discuss widgets ;))
>>
>> Ah, the old "the tools will save us" argument ;)
>
> Ooooh, snap!! walked straight into that one :D
>
>>
>> Yes, tools can certainly help. But that doesn't remove from the fact
>> that something that's simpler to author would be simpler for authors.
>
> It's crypto: by definition, its really complicated; I don't know how much
> easier one could make it. And reading
> https://developer.mozilla.org/en/Signing_a_XPI I can see Mozilla's solution
> is far from easy to use. I was expecting point and click, but I see a lot of
> scary (for me) command line stuff. One even need a special zip tool because
> of the whole META/inf thing?
>
>> What about situations when you want to dynamically generate widgets,
>> say using PHP?
>
> What about it? Won't a simple command line tool work? You could have a GUI
> version and a command line version. Like Zip.
>
>> Or if you don't speak the language(s) the tool is
>> localized to.
>
> I don't understand this one? I guess as above.
>
>> Or if a web-based tool happens to be down because of
>> server upgrades?
>
> I'm sorry, but i'm not really following as to what this has to do with our
> choice to use XML DigSig as the sig format? Despite my silly tools will save
> us mishap, my original question is still: is XML digsig limited in some way
> that all the above command/GUI/web interfaces could not be built on it (if
> they haven't already)? And what are the advantages of XPI signing over the
> current model? Is it the availability of tools to make sigs what makes it
> better or is it that the sig format simpler? I can't see it being too much
> simpler from an authors perspective.

I am admittedly far from an expert in how our XPI signing works. I'm
told it's essentially like Suns signed JAR files, but we use a
different crypto algorithm. My argument isn't that one is more or less
feature full, it's all about solving enough of the relevant use cases
as simply as possible.

And it's definitely true that signing is always going to be hard.

> And once you implement it and get it
> running, won't the XML cononicalization problems go away?

Code problems never go away. There's always some level of maintenance
that needs to happen, fix security bugs, fix behavior bugs, fix spec
bugs. And then there is of course the extra compile time for
developers and download time for users.

/ Jonas

Received on Thursday, 11 February 2010 02:03:52 UTC