Re: RfC: moving Web Storage to WG Note; deadline June 29

On 6/21/11 11:26 AM, Marcos Caceres wrote:
> I agree that the focus should be the Web, but if other things benefit
> from the security and design decisions, all the better, no?

Sure.  I just don't think we should be doing things that are targeted 
only at non-web situations.

> The above still applies. This doesn't mean that "anything goes" once
> you leave the http:// realm.

I think that's where we disagree (though "the web" is not restricted to 
http:// for what it's worth).

> Extensions are still interacting with an extremely hostile environment: the Web. Thus should be subject to the
> same or more scrutiny, given their bridging between both worlds.

Yes, but I don't think that W3C working groups should be the ones 
defining extension security models or performing that scrutiny.

>> There is a big difference between "the browsing experience" and "the
>> platform".
>
> Not so much when they are made of the same fundamental stuff (html,css,js).

The big difference is that extension hosts can add whatever backdoor 
APIs they desire and this is perfectly OK; it's NOT OK to do that on the 
web.

For that purpose it doesn't matter what languages are used to interface 
with the APIs.

> Because we are debating if this becomes a WG Note or a W3C
> Recommendation based on Web Storage's value to the "Web Platform". If
> the Web Platform includes packaged Web applications, then I would want
> Web Storage to go to Rec.

Why should it be the W3Cs remit to standardize an API that several 
browsers happen to use for their extension API?

The API should (or should not, whichever) be standardized based on its 
web usage.  If browsers want to additionally standardize their extension 
APIs, that seems fine to me, but not something the W3C should be 
spending resources on.

> If not, then I need to take all the relevant
> bits from Web Storage and fold them into the Widgets Interface
> specification.

Widgets Interface is not quite the same thing as extension interfaces. 
Having a Widgets dependency on Web Storage is a good reason to consider 
taking Web Storage to Rec.

But then of course you have to deal with the fact that Web Storage is 
not actually implemented per spec in Chrome, say (nor will it be in 
Gecko once we move to a multiprocess model).

> We completely agree here: "work to use cases, don't fix the world".
> It's just that the API ended up being used in more places which was
> expected, so now we have a "throwing out the baby with the bath water"
> situation.

Do we?

If some company starts using a half-baked web API internally for 
something and then we figure out that it's half-baked and drop it 
entirely, are we throwing the baby out with the bath water?

Now the Web Storage situation is somewhat different, because actual 
web-facing UAs implement it.  But that's what should determined what 
happens to Web Storage, not who else not on the web has ended up using 
it.  In my opinion.

> But that's like saying: "The HTML WG should not concern itself with
> the needs of PHP,Perl, etc. developers."

Yep.

> That is true only to the
> extent that the HTML markup needs to be flexible enough to be
> generated server-side easily (or crafted by hand).

Sure.

> A similar issues applies here: alternative systems make use of these APIs and do their
> best to conform to the spec.

That last part is arguable, but let's posit it.

> The Web Storage spec does not restrict
> the applicability of the API to http://, hence the Working Group has
> to deal with the consequences when others find innovative uses for the
> API.

This last part I don't necessarily agree on.

All of which brings us back to the question of how we want to take this 
to Rec given that implementations do not match the spec wrt the storage 
mutex?

-Boris

Received on Tuesday, 21 June 2011 16:45:37 UTC