Re: Heads-up: Some buzz about access-control

Thomas Roessler wrote:
> Apparently, the Mozilla folks have announced support for the
> access-control spec, and caused some buzz about it.
> 
> I've dropped some pointers to this WG's public comment address.

I tried to reply on the blog the forwarded message links to, but it 
seems to have comments disabled at this point.

Unfortunately the guy doesn't seem to neither have read the relevant 
specs, nor done even the most basic testing. None of the attacks he 
describe work, or rely on bugs in the server that would already allow 
XSS attacks.

The latest Firefox3 alpha does have access-control support for XHR, 
though using a now outdated spec. I plan on updating to the latest spec 
soon.

/ Jonas

Re: Heads-up: Some buzz about access-control

Re: widget namespace

Hi David,
> I've made one, available from http://hasather.net/widgets/widgets.rnc

Great!

> Keep in mind that my RELAX NG skills are pretty rusty, and that I didn't
> read the spec super closely when creating it. Hopefully, it's pretty
> accurate though,

Thanks David, can I have your permission to include it into the editor's draft?

I'll update it as the spec develops.

Kind regards,
Marcos

--

-- 
Marcos Caceres
http://datadriven.com.au

Re: widget namespace

Marcos Caceres wrote:

Marcos, sorry, you'll get this twice.

>> Keep in mind that my RELAX NG skills are pretty rusty, and that I didn't
>> read the spec super closely when creating it. Hopefully, it's pretty
>> accurate though,
>
> Thanks David, can I have your permission to include it into the editor's  
> draft?

Yes, of course 

Just one thing I noticed: the chrome attribute is just mentioned in the  
spec, but it's never defined what it is for, or what the legal values are.
Currently, the declared content is just "text" in the schema, but I  
suppose this is wrong.

--

-- 
David Håsäther

Re: Heads-up: Some buzz about access-control

On Sat, 01 Sep 2007 01:59:32 +0200, Jonas Sicking <jonas <at> sicking.cc> wrote:
> Thomas Roessler wrote:
>> Apparently, the Mozilla folks have announced support for the
>> access-control spec, and caused some buzz about it.
>>  I've dropped some pointers to this WG's public comment address.
>
> I tried to reply on the blog the forwarded message links to, but it  
> seems to have comments disabled at this point.
>
> Unfortunately the guy doesn't seem to neither have read the relevant  
> specs, nor done even the most basic testing. None of the attacks he  
> describe work, or rely on bugs in the server that would already allow  
> XSS attacks.
>
> The latest Firefox3 alpha does have access-control support for XHR,  
> though using a now outdated spec. I plan on updating to the latest spec  
> soon.

Cool! The most notable thing I noticed was that it implements the  
Content-Access-Control header as opposed to Access-Control, but I haven't  
played much with the implementation so far...

--

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Re: Heads-up: Some buzz about access-control

On Thu, 30 Aug 2007 09:55:52 +0200, Thomas Roessler <tlr <at> w3.org> wrote:
> Apparently, the Mozilla folks have announced support for the
> access-control spec, and caused some buzz about it.
>
> I've dropped some pointers to this WG's public comment address.

I commented
on
http://www.gnucitizen.org/blog/i-dont-think-that-you-understand-firefox3-vulnerable-by-design

as it seems he hasn't carefully studied the specifications (nor the  
implementation as Jonas pointed out). (I just replied again, but that's  
still in moderation.)

--

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

ISSUE-16 (ArtB): AC: Add some rationale to the Introduction [Access Control]

ISSUE-16 (ArtB): AC: Add some rationale to the Introduction [Access Control]

http://www.w3.org/2005/06/tracker/waf/issues/

Raised by: Arthur Barstow
On product: Access Control

Raised by: TAG (via Stuart Williams)
See: http://lists.w3.org/Archives/Public/public-appformats/2007Aug/0025.html

[ ACTION-107] Updating version list identifier algorithm

Asserting responsibility for this task that was proxy assigned me through  
Anne, based on the August 7-9 f2f meeting, here is a new proposal for  
version list identifers, including a version list comparison algorithm

Version list and identifier

A string is a valid version list if it consists of one or more valid mix
of strings separated by a U+002E (.) character.

The rules for parsing a version list are as given in the following
algorithm. When invoked, the steps must be followed in the order given,
aborting at the first step that returns a value. This algorithm will
return an ordered list, which may be empty.

1. Let input be the string being parsed.

2. Let version list be an ordered list of unsigned integers which is
initially empty.

3. Split input on U+002E (.) retaining the order the items had in the
original string, while dropping the U+002E (.) character in the process.
If this resulted in two or more items let those be the ordered list
items, in the order left-to-right. If this operation left input
unchanged let items be an ordered list with a single item input.

Comparing version lists

When comparing two different version lists 'n' and 'm', determining
which version identifier is has the greater value, apply the following
algorithm:

1. Let p = 0. Let this be the start index for the indexed item in each
    of the lists n and m.
2. Compare the list items n[p] and m[p] using a natural sort algoritm [1]
    2.1. If the version list item n[p] is nonexistent, assume that this
         item will, in any sort be assumed to be less than any existing
         value. Likewise, apply this to list item m[p].
    2.2. If the comparison of n[p-1] and m[p-1] has not established
         any version order, or the items n[p-1] and m[p-1] do not exist,
         and the list items n[p] and m[p] do not exist, consider version
         list n to be identical to version list m and exit the comparison.
    2.3. If n[p] < m[p], let version list m represent the greater version
         identifier and exit the comparison.
    2.4. if n[p] > m[p], let version list n represent the greater version
         identifier and exit the comparison.
    2.5. If n[p] = m[p], let p = p + 1 and go back to item one in the
         algorithm.

[1] I am unable to find a formal definition, but
http://www.unicode.org/unicode/reports/tr10/ may come close to meeting
our needs.

--

-- 
Arve Bersvendsen

Developer, Opera Software ASA
http://www.opera.com/

Re: [Widgets 1.0] Automatic Updates (1.0)?

On 2007/08/31, at 4:27 PM, Marcos Caceres wrote:

> Hi Mark,
>
> On 8/30/07, Mark Nottingham <mnot <at> yahoo-inc.com> wrote:
>> You shouldn't need to extend HTTP at all for this use case; use the
>> URI, look at the ETag, Last-Modified, If-None-Match and If-Modified-
>> Since headers, along with the 304 response. Also, please recommend
>> that responses be cacheable for some reasonable amount of time (e.g.,
>> Cache-Control: max-age=3600).
>
> Good point. However, I need to investigate the implications (if any)
> of dynamically generated widgets and widgets sent over HTTPS. Do you
> see any potential issues? I'll try to write up a model based around
> Etags and related HTTP1.1 caching controls next week and see if there
> is any need for a separate spec for auto-updates at all. Regardless,
> given your knowledge of caching, any further input are appreciated.

Would be happen to help. WRT dynamic widgets and HTTPS, some use  
cases would help, but I don't see anything immediately.

>> Also, is the indirection of a manifest really necessary? Why not just
>> have them periodically poll the archive of the widget itself?
>
> Sorry, I don't understand what you mean by "the indirection of a
> manifest". Can you please explain what you mean by the above a bit
> more.

Just wondering why it's necessary to have a split between the widget  
and the metadata in the file (as per your example).

> Also, one cannot assume that a widget was always acquired directly
> from a web server: it might be the case that an end-user sends a
> widget to another end-user, say, over Bluetooth. Those widgets should
> still be able to connect back to their point origin and check if an
> update is needed.

I don't think that affects things, as long as the widget 'knows' what  
its URI is.

Cheers,

--
Mark Nottingham       mnot <at> yahoo-inc.com

Minutes from WAF WG's August 7-9 f2f meeting

The WAF WG had a f2f meeting August 7-9 in Oslo, Norway. The minutes  
from the meeting are available:

    <http://www.w3.org/2007/08/07-waf-minutes.html>
    <http://www.w3.org/2007/08/08-waf-minutes.html>
    <http://www.w3.org/2007/08/09-waf-minutes.html>

Regards,

Art Barstow
---