Re: Installing web apps

[Charles Pritchard]

I precisely*didn't*  want to get into a detail about whether everyone should use
widgets or will use widgets -- I want to argue for XMLHTTPRequest
being designed to be able to be used not only in an untrusted web page,
but e.g. from an installed widget, or node.js for that matter,
which means returning a defined error response when the privilege is
insufficient, instead of faking a network error.
I've been trying to write code which will work in any of these.


I've been there; even with  I hit some snags (which 
have since been fixed).

You're going to want an async privilege check ahead of time.

chrome.permissions.getAll is a good example if checking permissions via 
async, early on in the script.


It's reasonable, at this point, to assume that permissions will not be 
restricted once they are granted in the lifetime of the script.
I don't know if that's a reasonable assumption for the future. In the 
future case, you may need to do a permissions check before

any XHR call.

Probably best to do that, too.

When doing polyfill work, async booting is necessary.

-Charles

Re: Installing web apps

[Tim Berners-Lee]

On 2012-02 -01, at 15:23, Marcos Caceres wrote:

> Hi Tim,  
> 
> On Wednesday, 1 February 2012 at 16:42, Tim Berners-Lee wrote:
> 
>> Note that when people talk about installation, they often immediately discuss
>> packaging and manifest formats, which will need to be defined,
> 
> Um… we have a REC for that, remember?  

Yes, but I'm specifically trying to avoid the discussion of whether you use
widgets or manifests or node.js or what.

Sorry, we have come a long way from my original comment on public-webaps about 
the same-origin-policy needing a way of letting a script know why the 
access failed, which lead to Ian H saying that here was no need
for installation and my saying that there was.  So I was arguing for the need
for installation, and I am if course aware of widgets.

I precisely *didn't* want to get into a detail about whether everyone should use
widgets or will use widgets -- I want to argue for XMLHTTPRequest 
being designed to be able to be used not only in an untrusted web page,
but e.g. from an installed widget, or node.js for that matter,
which means returning a defined error response when the privilege is
insufficient, instead of faking a network error.
I've been trying to write code which will work in any of these.


Tim

Re: Installing web apps

[Marcos Caceres]

Hi Tim,  

On Wednesday, 1 February 2012 at 16:42, Tim Berners-Lee wrote:

> Note that when people talk about installation, they often immediately discuss
> packaging and manifest formats, which will need to be defined,

Um… we have a REC for that, remember?  

http://www.w3.org/TR/widgets/
> and for which
> we might have more than one, but is not the crux of the issue -- the crux is
> allowing it access to precious and/or sensitive resources.
>  

Wow, I'm *really* doub-founded (yet) again. Tim, are my emails going to your 
spam folder or something? Or are you deliberately just ignoring the widget work 
the W3C already invested 6 years on? We already solved all this stuff in the 
Widgets specs. I don't know why you keep ignoring them?   

Please go and read:  

http://www.w3.org/2008/webapps/wiki/WidgetSpecs

Please see:  
http://www.w3.org/TR/widgets/#the-feature-element-and-its-attributes

Please see projects like PhoneGap and WAC (that make use of W3C widgets to 
enable device APIs):

http://phonegap.com/
http://specs.wacapps.net/

  




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

Re: Installing web apps

[Paul Libbrecht]

Le 1 févr. 2012 à 21:03, Boris Zbarsky a écrit :

>> Android goes somewhat in this direction with its app-security model...
> 
> With all due respect, the app-security model on Android is a joke. Everyone 
> just clicks through the permissions grant without even reading what's being 
> requested, because _every_ app asks for a bunch of permission grants up front 
> and won't run until you grant them.  Any random game wants permission to do 
> arbitrary internet access (as mentioned earlier on this thread, already a 
> security hole if you happen to be behind a firewall when you run the game), 
> listen to your phone conversations, read your addressbook, etc.  Perhaps they 
> do have some sort of rarely-used features that require such access, but the 
> model forces them to ask for all the permissions immediately... and the user 
> is trained to just accept.

No, no app has yet demanded me my addressbook access and some apps add 
advertisement: and hey, I do not need network.

That's the general problem with demanding permissions... I agree it's in 
infancy.

However this is for an APP download, where you expect some level of trust 
(basically the essence of an app store's objective?).

If a random web-page starts to ask me the same, I would surely be talking 
differently!


Tim, did you say any reasons why the current widget model that can be installed 
as a sort of app on mobile devices is not an approximation of your desires?

paul

Re: Granting permissions, was Re: Installing web apps

[Boris Zbarsky]

On 2/1/12 3:02 PM, Charles Pritchard wrote:

On 2/1/12 11:57 AM, Boris Zbarsky wrote:

On 2/1/12 2:39 PM, Charles Pritchard wrote:

Mozilla said they were getting rid of their enable privilege API. I
don't know that they have.


It's being removed, slowly. For example, cross-site XHR (modulo
whatever CORS allows) is no longer possible even if you
enablePrivilege in current Gecko.

There may be a different privilege setup eventually, but
enablePrivilege in its existing form is not a good API, especially for
the web.


So, in Gecko, is cross-site XHR something now specified explicitly in
the extension manifest?


Extensions in Firefox are a separate ballgame.  They currently always 
run with the same exact permissions (literally; the permissions object 
pointer is the same) as the browser UI itself.  This means they can do 
things that you could never do with enablePrivilege.



Chrome went ahead with specifying "optional permissions" in the
manifest, and when those are present in the manifest, they can be
requested via chrome.permissions.request. It's async, which is nice, and
is quite different than the synchronous Gecko model.

http://code.google.com/chrome/extensions/trunk/permissions.html


Firefox extensions never have to request permissions.  They always have 
them.



The special status of "file://" is still a special thing.


It'll go away, as enablePrivilege goes away in general.

-Boris

Re: Installing web apps

[Boris Zbarsky]

On 2/1/12 2:41 PM, Paul Libbrecht wrote:

Android goes somewhat in this direction with its app-security model...


With all due respect, the app-security model on Android is a joke. 
Everyone just clicks through the permissions grant without even reading 
what's being requested, because _every_ app asks for a bunch of 
permission grants up front and won't run until you grant them.  Any 
random game wants permission to do arbitrary internet access (as 
mentioned earlier on this thread, already a security hole if you happen 
to be behind a firewall when you run the game), listen to your phone 
conversations, read your addressbook, etc.  Perhaps they do have some 
sort of rarely-used features that require such access, but the model 
forces them to ask for all the permissions immediately... and the user 
is trained to just accept.



- Access to RAM at runtime, to a limit


I don't know how well such limits are handled by browsers, I've seen a lot of 
browser crashes for these reasons. Pointer?


Several JS engines have heap size limits and stack size limits and will 
throw exceptions when either is reached.


Any browser running web content in a separate process can impose global 
RAM limits on that process if desired (ulimit on Unix-like OSes, but 
Windows has similar functionality).



- CPU time when in background, to a limit


Same thing, the user-warning on slow script is not that limit!


Apart from timeout throttling UAs are not doing much here yet.  I expect 
they will do more.



There's plenty of things we can do to make the Web platform more
compelling and a better competitor to native apps, but adding "installing"
isn't one of them. That would in fact take one of the Web's current
significant advantages over native apps and kill it.


when you consider the success of app-stores, I think that I do not share this 
view.


Indeed.

-Boris

Granting permissions, was Re: Installing web apps

[Charles Pritchard]

On 2/1/12 11:57 AM, Boris Zbarsky wrote:

On 2/1/12 2:39 PM, Charles Pritchard wrote:

Mozilla said they were getting rid of their enable privilege API. I
don't know that they have.


It's being removed, slowly.  For example, cross-site XHR (modulo 
whatever CORS allows) is no longer possible even if you 
enablePrivilege in current Gecko.


There may be a different privilege setup eventually, but 
enablePrivilege in its existing form is not a good API, especially for 
the web.


So, in Gecko, is cross-site XHR something now specified explicitly in 
the extension manifest?


Chrome went ahead with specifying "optional permissions" in the 
manifest, and when those are present in the manifest, they can be 
requested via chrome.permissions.request. It's async, which is nice, and 
is quite different than the synchronous Gecko model.


http://code.google.com/chrome/extensions/trunk/permissions.html

The special status of "file://" is still a special thing. 
enablePrivilege in Gecko had semantics for such items, whereas Chrome 
does not. It seems like that part of Gecko is also being put aside, 
which is probably for the best. I've considered running a page from 
file:// a special form of installation.


It still is, with Chrome, as one can do things like iframe local 
content. Not something you can really do otherwise.


-Charles

Re: Installing web apps

[Boris Zbarsky]

On 2/1/12 2:39 PM, Charles Pritchard wrote:

Mozilla said they were getting rid of their enable privilege API. I
don't know that they have.


It's being removed, slowly.  For example, cross-site XHR (modulo 
whatever CORS allows) is no longer possible even if you enablePrivilege 
in current Gecko.


There may be a different privilege setup eventually, but enablePrivilege 
in its existing form is not a good API, especially for the web.


-Boris

Re: Installing web apps

[Paul Libbrecht]

Le 1 févr. 2012 à 20:03, Ian Hickson a écrit :
>>  - a calendar client
> 
> There are lots of calendar clients written on the Web today.
>>  - an IMAP client
> There are lots of mail clients written on the Web today.

These are not web-apps that can work offline longer than 2 minutes.
Android's GMail app is getting to be as bad.

But otherwise, many imap clients exist as desktop or in-device applications.
I think Tim is asking for something in the middle and the distance is pretty 
big.


>> As a user when I install an app, I want to be able to give it access to 
>> a selection of:
> 
> Providing access to these things when the app is installed is IMHO a net 
> worse security model than granting access to these things implicitly when 
> the feature is needed.

And this is the reason the normal model has been: no security model at all.
Desktop applications have been living well with some web interfacing... 
installing a web-app could start where desktop applications are then gradually 
go less demanding?

Android goes somewhat in this direction with its app-security model...

> Of the things you list, the following are already possible without an 
> up-front permission grant, in a manner more secure than an up-front grant:
> 
>> - Program storage, to a limit
>> - Whether it is permanently available or downloaded or cached for a while
>> - Access to RAM at runtime, to a limit

I don't know how well such limits are handled by browsers, I've seen a lot of 
browser crashes for these reasons. Pointer?

>> - CPU time when in background, to a limit

Same thing, the user-warning on slow script is not that limit!

>> - Access to the net, maybe to a bandwidth limit

really?

>> - Ability to access anything on the web
> 
> What's the use case for this?

An editor importing a web-page?

>> (I'll want to sync its local and shared data storage between all my 
>> devices too)
> 
> That's possible without the site knowing anything about it. Chrome already 
> does it to some extent.

Typical state of a young feature: Chrome does it without asking me, Firefox 
asks me if I want to use my own server ;-).

>> If I can't give power to apps, then the web app platform cannot compete 
>> with native apps.
> 
> There's plenty of things we can do to make the Web platform more 
> compelling and a better competitor to native apps, but adding "installing" 
> isn't one of them. That would in fact take one of the Web's current 
> significant advantages over native apps and kill it.


when you consider the success of app-stores, I think that I do not share this 
view.

paul

Re: Installing web apps

[Charles Pritchard]

On 2/1/12 11:03 AM, Ian Hickson wrote:

On Wed, 1 Feb 2012, Tim Berners-Lee wrote:

These apps have got to be able to completely
act as agents trusted by the user, like for example

- a web browser

You want to write a Web browser in a Web browser?


Ian, at present, you're the one defining what a web browser means. We've 
had some of this discussion on the "Attitudes and Direction" thread.


I've written an SVG implementation inside of a web browser. I've also 
produced HTML authoring tools inside the browser.


The browser is a great place to do it; it's got backup implementations, 
a safe scripting environment, CSS and DOM parts; it's well tested, and 
modern browsers are already installed on many machines. Many people do 
special kiosk implementations inside the browser. Some people even write 
ATs inside the browser.


Yes, a browser in a browser. Two browser vendors are pushing 
browser-only operating systems.



- an IMAP client

There are lots of mail clients written on the Web today.


As I understand it, gmail is a 300k LOC beast, and drove many early 
innovations in the Chrome web browser.


An IMAP client requires TCP acccess; this is something that I can see 
the Chrome browser is looking to open up through a websockets proxy.




and so on, none of these can you currently write as a web app, because
of CORS.

to work around by just wrapping IMAP in WebSockets. Nothing to do with
CORS (or even the same-origin policy).


It has something to do with CORS if the CORS policy on the remote server 
doesn't allow it.


Yes, I can waste bandwidth and use a trusted proxy server. But I don't 
want to, and I'd like to use my own cookies.

That's the CORS issue.




As a user when I install an app, I want to be able to give it access to
a selection of:

Providing access to these things when the app is installed is IMHO a net
worse security model than granting access to these things implicitly when
the feature is needed.


Mozilla said they were getting rid of their enable privilege API. I 
don't know that they have. Chrome certainly went for the privilege 
model, with the chrome.permissions namespace.


Providing granular access is a nice thing. There are times, such as 
kiosk setups and corporate intranets, where the access should be granted 
all at once. For trusted applications.


I've found that even for applicationCache, it helps to have an "install" 
button. Cause I hate showing off a project to someone and seeing a 
permissions prompt on load.

I've not figured out how to evict the app cache, though.



Of the things you list, the following are already possible without an
up-front permission grant, in a manner more secure than an up-front grant:


- Whether it is permanently available or downloaded or cached for a while


We do not have long running shared workers. There's no means to tell the 
browser that a page should run in the background at system start-up (or 
browser start-up) and continue running. We're close, on that end, but 
there is no BackgroundWindow spec at the moment.


Chrome just hacked on window.open('url', '#background') or #bg, or 
something like that.




- Ability to access anything on the web

What's the use case for this?



Authoring tools, assistive technologies and everything in between. And 
proxies and traffic shaping.


Google did a good job in their latest releases with "Copy Image". That 
feature actually works now to copy an image from one frame to another.
Copy and paste works fairly well (I'm working on the bug reports); 
allowing a user to copy and paste sections of a page from one site to 
another.


But they're only partial solutions, and they certainly don't match the 
ability granted in the chrome.webRequest namespace.





I want to be able to se where all my resources (including CPU, RAM,
'disk')  on my laptop or tablet or phone are being used up, just like I
do with music and movies.

You can do that today without an up-front permission grant. (q.v. Chrome's
task manager, for example.)


And in private namespaces, I'm sure you can access the data 
programatically. Or will be able to at some point.


Perhaps there's confusion here as to what an "application" means to you, 
Ian.





If I can't give power to apps, then the web app platform cannot compete
with native apps.

There's plenty of things we can do to make the Web platform more
compelling and a better competitor to native apps, but adding "installing"
isn't one of them. That would in fact take one of the Web's current
significant advantages over native apps and kill it.


What does "installing" mean to you?

For me, applicationCache is installing. Using web storage is installing.

Hell even using Cookies can be argued as installing. Thus the backlash 
against advertisers installing trackers on a person's computer.


On the iPhone, adding a bookmark to the home screen is installing. On 
the chrome store, it's often the case that people notice "hey, this is 
just a bookmark to a webp

Re: Installing web apps

[Jonas Sicking]

On Wed, Feb 1, 2012 at 8:42 AM, Tim Berners-Lee  wrote:
>
> On 2012-01 -20, at 14:32, Ian Hickson wrote
> in http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0238.html :
>
> On Fri, 20 Jan 2012, Tim Berners-Lee wrote:
> [...]
>
> There of course places where XHR is used and there is no
>
> cross-sitescripting security needed
>
>
> 1)  in a browser extension
>
> 2)  in node.js code trusted apps
>
>
> These aren't the Web, so they're probably out of scope of the CORS and XHR
> specs, but Anne can comment if he disagrees. :-)
>
>
> 3)  in web apps when web apps can, in I hope the near future, be
>
> installed, and flagged as trusted code
>
>
> Personally I think the idea of "installing" a Web app is anathema.
>
>
> You may, but others have a need for it.
>
> The open web platform is a strong contender
> for apps which you write once run anywhere
> and end up being a better alternative, or quietly
> moving out, native apps on all kids of device.
>
> These apps have got to be able to completely
> act as agents trusted by the user, like for example
>
> - a web browser
> - a calendar client
> - an IMAP client
>
> and so on, none of these can you currently write
> as a web app, because of CORS.

Nit: It's not CORS that is getting in your way. It's the web's default
same-origin-policy. CORS simply relaxes the s-o-p so it's strictly
helping you here.

But yes, we'll need a way to relax the same-origin-policy even in
cases when the target site wasn't built with the web security model in
mind.

> As a user when I install an app, I want to be able to give
> it access to a selection of:
>
> - Program storage, to a limit
> - Whether it is permanently available or downloaded or cached for a while
> - Access to RAM at runtime, to a limit
> - Access to the net, maybe to a bandwidth limit
> - CPU time when in background, to a limit
> - Ability to access anything on the web
> - Access to its own local storage up to a given limit
> - Access to shared local storage up to a given limit
> - Access to my location, as we currently allow an origin;
> - Access video and still camera, and sound
> - Access to other sensors such as temp, accelerometer, etc
>
> I want to be able to se where all my resources (including CPU, RAM, 'disk')
>  on my laptop or tablet or phone
> are being used up, just like I do with music and movies.
>
> I want maybe a couple of default profiles for all the above.
>
> (I'll want to sync its local and shared data storage between  all my devices
> too)
>
> If I can't give power to apps, then the web app platform cannot compete with
> native apps.
>
> I don't want the value of these setting to be the origin domain name of the
> script of the app,
> as that is too high a granularity.
>
> Note that when people talk about installation, they often immediately
> discuss
> packaging and manifest formats, which will need to be defined, and for which
> we might have more than one, but is not the crux of the issue -- the crux is
> allowing it access to precious and/or sensitive resources.

For what it's worth, we're working on a lot of these aspects at
mozilla as part of our Open Web Apps effort.

There are obviously a lot of subtle issues and tricky edge cases to
get right. For example while we want it to be "safe" to install any
web app, we also want to enable installed web apps to have elevated
privileges when we can establish that there's some sort of trust
relationship which ensures that the apps won't do anything harmful.

Some of the things that I've been arguing that we can grant installed
apps automatically are:

1. Use of system resources (CPU, disk space, network bandwidth, etc).
2. Ability to "annoy" the user, i.e. things like popups or replacing
the context menu.
3. Ability to finger print the user. This will allow access to things
like the users custom spellcheck dictionary.

The last one is the most controversial and something I haven't been
fully convinced of yet. It's more than likely something that won't be
an absolute.

I'm personally not a big fan of having strict limit for system
resources as that tends to make development hard and the limits will
either be fairly arbitrary or a pain for the user to constantly
manage. A better path is to enable the user to see how much system
resources a given app uses. This way the user can choose to uninstall
the app, or power users could choose to manually manage limits.

Other problems with giving installed web apps elevated privileges is
how do we explain this to the user such that they make a safe informed
decision. For example asking the user "Do you want to allow this app
to connect to the internet" sounds innocent enough, but the user
probably doesn't realize that this means that the app can read data
from inside corporate firewalls.

This isn't to say that we shouldn't allow these things. It just will
take a lot of design work, experimenting and iterating to get it
right.

/ Jonas

Re: Installing web apps

[Ian Hickson]

On Wed, 1 Feb 2012, Tim Berners-Lee wrote:
> 
> These apps have got to be able to completely
> act as agents trusted by the user, like for example
> 
>   - a web browser

You want to write a Web browser in a Web browser?


>   - a calendar client

There are lots of calendar clients written on the Web today.


>   - an IMAP client

There are lots of mail clients written on the Web today.


> and so on, none of these can you currently write as a web app, because 
> of CORS.

I don't think it has anything to do with CORS. An IMAP client, that is, a 
mail client that communicates to a remote server using the IMAP protocol 
rather than HTTP or WebSockets, is only not possible today because there's 
no raw sockets API (which there can't safely be). The problem is trivial 
to work around by just wrapping IMAP in WebSockets. Nothing to do with 
CORS (or even the same-origin policy).


> As a user when I install an app, I want to be able to give it access to 
> a selection of:

Providing access to these things when the app is installed is IMHO a net 
worse security model than granting access to these things implicitly when 
the feature is needed.


Of the things you list, the following are already possible without an 
up-front permission grant, in a manner more secure than an up-front grant:

> - Program storage, to a limit
> - Whether it is permanently available or downloaded or cached for a while
> - Access to RAM at runtime, to a limit
> - CPU time when in background, to a limit
> - Access to the net, maybe to a bandwidth limit
> - Access to its own local storage up to a given limit
> - Access to shared local storage up to a given limit
> - Access to my location, as we currently allow an origin;
> - Access video and still camera, and sound
> - Access to other sensors such as temp, accelerometer, etc

(Temp isn't current exposed, but there's no reason it couldn't be the 
same way as other things.)


> - Ability to access anything on the web

What's the use case for this?



> I want to be able to se where all my resources (including CPU, RAM, 
> 'disk')  on my laptop or tablet or phone are being used up, just like I 
> do with music and movies.

You can do that today without an up-front permission grant. (q.v. Chrome's 
task manager, for example.)


> I want maybe a couple of default profiles for all the above.

That's more complicated than having on profiles at all.


> (I'll want to sync its local and shared data storage between all my 
> devices too)

That's possible without the site knowing anything about it. Chrome already 
does it to some extent.


> If I can't give power to apps, then the web app platform cannot compete 
> with native apps.

There's plenty of things we can do to make the Web platform more 
compelling and a better competitor to native apps, but adding "installing" 
isn't one of them. That would in fact take one of the Web's current 
significant advantages over native apps and kill it.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Installing web apps

[Tim Berners-Lee]

On 2012-01 -20, at 14:32, Ian Hickson wrote
in http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0238.html :

> On Fri, 20 Jan 2012, Tim Berners-Lee wrote:
> [...]
>> There of course places where XHR is used and there is no 
>> cross-sitescripting security needed
>> 
>> 1)  in a browser extension
>> 2)  in node.js code trusted apps 
> 
> These aren't the Web, so they're probably out of scope of the CORS and XHR 
> specs, but Anne can comment if he disagrees. :-)
> 
> 
>> 3)  in web apps when web apps can, in I hope the near future, be 
>> installed, and flagged as trusted code
> 
> Personally I think the idea of "installing" a Web app is anathema. 

You may, but others have a need for it.

The open web platform is a strong contender
for apps which you write once run anywhere
and end up being a better alternative, or quietly
moving out, native apps on all kids of device.

These apps have got to be able to completely
act as agents trusted by the user, like for example

- a web browser
- a calendar client
- an IMAP client

and so on, none of these can you currently write
as a web app, because of CORS. 

As a user when I install an app, I want to be able to give
it access to a selection of:

- Program storage, to a limit
- Whether it is permanently available or downloaded or cached for a while
- Access to RAM at runtime, to a limit
- Access to the net, maybe to a bandwidth limit
- CPU time when in background, to a limit
- Ability to access anything on the web
- Access to its own local storage up to a given limit
- Access to shared local storage up to a given limit
- Access to my location, as we currently allow an origin;
- Access video and still camera, and sound
- Access to other sensors such as temp, accelerometer, etc

I want to be able to se where all my resources (including CPU, RAM, 'disk')  on 
my laptop or tablet or phone
are being used up, just like I do with music and movies.

I want maybe a couple of default profiles for all the above.

(I'll want to sync its local and shared data storage between  all my devices 
too)

If I can't give power to apps, then the web app platform cannot compete with 
native apps.

I don't want the value of these setting to be the origin domain name of the 
script of the app,
as that is too high a granularity.

Note that when people talk about installation, they often immediately discuss
packaging and manifest formats, which will need to be defined, and for which
we might have more than one, but is not the crux of the issue -- the crux is
allowing it access to precious and/or sensitive resources.

Tim

Re: CG for Speech JavaScript API

[Rick Waldron]

Apologies, cited the wrong message in this thread, please forgive.


( Rick: -2 ;)  )

On Wed, Feb 1, 2012 at 10:20 AM, Rick Waldron wrote:

> So, one of the biggest issues facing the web right now is the ones that
> aren't seen by end users of web sites - they are seen by web developers who
> have to wade through cryptic, often bizarre, frequently asymmetrical and
> almost alway too concise or too verbose APIs. Proposal and spec authors
> have the power to change this, and I understand it's hard to open your work
> for others to pick apart, but think of it this way: if you came to work and
> someone in the office had brought in new desks and computers without asking
> you and just said "use this, because I said so and I know better", at the
> very least, you'd be frustrated. There are too many examples of DOM APIs
> that suck and not enough examples of ones that are great and easy to use.
>
> Rick
>
>
>
> On Wed, Feb 1, 2012 at 9:51 AM, Charles McCathieNevile 
> wrote:
>
>> Hi Satish,
>>
>>
>> On Wed, 01 Feb 2012 10:50:25 +0100, Satish S  wrote:
>>
>>  Re the mail list, if we turn this around and look at it from the
 perspective of someone that is mostly interested in the CG and not
 WebApps, they would then receive close to an additional 2K emails
 per quarter.

>>>
>>>   I really don't think you want that so I recommend against using
 public-webapps.

>>>
>>> Speech API discussions could use a "[speech api]" prefix in the email
>>> subject so that participants can filter emails based on that. I see this
>>> style being used by File API and possibly others in the webapps mailing
>>> list.
>>>
>>
>> True, but those are deliverables of the Web Apps group. Which already has
>> a number of deliverables, and a lot of mail traffic for work it has agreed
>> to take on. We have already moved various kinds of work to other lists to
>> reduce that traffic.
>>
>>
>>  As Glen mentioned keeping discussions in the webapps mailing list
>>> will provide visibility to a wider audience, with a balanced web-centric
>>> view for new JavaScript APIs.
>>>
>>
>> The wider audience are welcome to subscribe to a list for the group
>> working on the API - but they may not want to. The fact that you add
>> messages to people's inbox doesn't mean that they will read them, as we all
>> know already. I do not think it is reasonable to use this list for the work
>> given that it has not been accepted as a work item by the group.
>>
>> Cheers
>>
>> Chaals
>>
>> --
>> Charles 'chaals' McCathieNevile  Opera Software, Standards Group
>>je parle français -- hablo español -- jeg kan litt norsk
>> http://my.opera.com/chaals   Try Opera: http://www.opera.com
>>
>>
>

Re: CG for Speech JavaScript API

[Rick Waldron]

So, one of the biggest issues facing the web right now is the ones that
aren't seen by end users of web sites - they are seen by web developers who
have to wade through cryptic, often bizarre, frequently asymmetrical and
almost alway too concise or too verbose APIs. Proposal and spec authors
have the power to change this, and I understand it's hard to open your work
for others to pick apart, but think of it this way: if you came to work and
someone in the office had brought in new desks and computers without asking
you and just said "use this, because I said so and I know better", at the
very least, you'd be frustrated. There are too many examples of DOM APIs
that suck and not enough examples of ones that are great and easy to use.

Rick



On Wed, Feb 1, 2012 at 9:51 AM, Charles McCathieNevile wrote:

> Hi Satish,
>
>
> On Wed, 01 Feb 2012 10:50:25 +0100, Satish S  wrote:
>
>  Re the mail list, if we turn this around and look at it from the
>>> perspective of someone that is mostly interested in the CG and not
>>> WebApps, they would then receive close to an additional 2K emails
>>> per quarter.
>>>
>>
>>   I really don't think you want that so I recommend against using
>>> public-webapps.
>>>
>>
>> Speech API discussions could use a "[speech api]" prefix in the email
>> subject so that participants can filter emails based on that. I see this
>> style being used by File API and possibly others in the webapps mailing
>> list.
>>
>
> True, but those are deliverables of the Web Apps group. Which already has
> a number of deliverables, and a lot of mail traffic for work it has agreed
> to take on. We have already moved various kinds of work to other lists to
> reduce that traffic.
>
>
>  As Glen mentioned keeping discussions in the webapps mailing list
>> will provide visibility to a wider audience, with a balanced web-centric
>> view for new JavaScript APIs.
>>
>
> The wider audience are welcome to subscribe to a list for the group
> working on the API - but they may not want to. The fact that you add
> messages to people's inbox doesn't mean that they will read them, as we all
> know already. I do not think it is reasonable to use this list for the work
> given that it has not been accepted as a work item by the group.
>
> Cheers
>
> Chaals
>
> --
> Charles 'chaals' McCathieNevile  Opera Software, Standards Group
>je parle français -- hablo español -- jeg kan litt norsk
> http://my.opera.com/chaals   Try Opera: http://www.opera.com
>
>

Re: CG for Speech JavaScript API

[Charles McCathieNevile]

Hi Satish,

On Wed, 01 Feb 2012 10:50:25 +0100, Satish S  wrote:


Re the mail list, if we turn this around and look at it from the
perspective of someone that is mostly interested in the CG and not  
WebApps, they would then receive close to an additional 2K emails

per quarter.



 I really don't think you want that so I recommend against using
public-webapps.


Speech API discussions could use a "[speech api]" prefix in the email
subject so that participants can filter emails based on that. I see this
style being used by File API and possibly others in the webapps mailing
list.


True, but those are deliverables of the Web Apps group. Which already has  
a number of deliverables, and a lot of mail traffic for work it has agreed  
to take on. We have already moved various kinds of work to other lists to  
reduce that traffic.



As Glen mentioned keeping discussions in the webapps mailing list
will provide visibility to a wider audience, with a balanced web-centric
view for new JavaScript APIs.


The wider audience are welcome to subscribe to a list for the group  
working on the API - but they may not want to. The fact that you add  
messages to people's inbox doesn't mean that they will read them, as we  
all know already. I do not think it is reasonable to use this list for the  
work given that it has not been accepted as a work item by the group.


Cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

Re: CfC: to add Speech API to Charter; deadline January 19

[Charles McCathieNevile]

On Mon, 30 Jan 2012 08:43:26 +0100, Charles McCathieNevile  
 wrote:



Further explanation from Apple...

--- Forwarded message ---

...
2. Speech is an area with IPR -- it's been an active research area for  
decades; we may have some. Without doing a lot more work I don't know  
the extent to which the proposed work would encounter IPR, but I think  
it would be prudent to think about that.  It may be best to have the  
work done in a less general-purpose WG (though, as I say above, I  
don't think WebApps should really be seen as general-purpose), and  
actively seek to set a scope and a membership that minimize issues  
down the road.


This feedback has been essentially replicated but more forcefully in  
Team-confidential responses. While it is theoretically possible to put the  
proposal in the charter anyway, in practice it will just get shot down in  
AC review by Team-confidential responses, so it would be a waste of time.


Given that, there is not consensus to add the item.

Chairs

Chaals (and Art)

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

[Bug 15830] incorrect protocol spec ref

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15830

Julian Reschke  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Julian Reschke  2012-02-01 13:24:23 
UTC ---


*** This bug has been marked as a duplicate of bug 13700 ***

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 15830] New: incorrect protocol spec ref

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15830

   Summary: incorrect protocol spec ref
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: trivial
  Priority: P2
 Component: WebSocket API (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: julian.resc...@gmx.de
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


"WebSocket Protocol Internet-Draft:
http://www.whatwg.org/specs/web-socket-protocol/";

Why is this linking to a draft that has been obsolete for over 17 months?

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 15829] New: wrong bug tracker ref

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15829

   Summary: wrong bug tracker ref
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: trivial
  Priority: P2
 Component: WebSocket API (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: julian.resc...@gmx.de
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


"our public bug database" links to

  http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG

(wrong WG)

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: CG for Speech JavaScript API

[Peter Beverloo]

The fact that Rick picked the wrong full name already outlines the issue.

I'm strongly in favor of using non-abbreviated names as well, which also
applies to the "SpeechReco" and "TTS" JavaScript interfaces.  While they
may be obvious for people familiar with speech recognizion, a significant
group (if not the majority) of Web Developers won't be.

Peter

On Wed, Feb 1, 2012 at 12:40, Dan Burnett  wrote:

> To clarify,  is short for , not .  This is, in
> fact, an extremely common abbreviation for anyone who uses speech
> recognition APIs today because it takes so long both to say and type
> "recognition" after the 10,000th time.
>
> Nevertheless, a Working Group standardizing this could choose something
> other than  for the name.
>
> -- dan
>
> On Feb 1, 2012, at 12:11 AM, Rick Waldron wrote:
>
> > Just wondering why, in 2012, there are proposals for elements with
> abbreviated names. Please stop doing that.
> >
> > 
> >
> > Is two characters longer and infinitely more intuitive. Say no to
> mistakes like 
> >
> > Rick
> >
> > On Jan 31, 2012, at 11:51 PM, Bjoern Hoehrmann 
> wrote:
> >
> >> * Glen Shires wrote:
> >>> We at Google propose the formation of a new Community Group to pursue a
> >>> JavaScript Speech API. Specifically, we are proposing this Javascript
> API
> >>> [1], which enables web developers to incorporate speech recognition and
> >>> synthesis into their web pages, and supports the majority of use-cases
> in
> >>> the Speech Incubator Group's Final Report [2]. This API enables
> developers
> >>> to use scripting to generate text-to-speech output and to use speech
> >>> recognition as an input for forms, continuous dictation and control.
> For
> >>> this first specification, we believe this simplified subset API will
> >>> accelerate implementation, interoperability testing, standardization
> and
> >>> ultimately developer adoption.
> >>
> >> Looking at "HTML Speech Incubator Group Final Report", there is a propo-
> >> sal for a  element. Let's say the Community Group adopts this idea
> >> and several browser vendors implement it. Is the assumption that Mozilla
> >> would implement a  element while Microsoft would implement some
> >>  element if they choose to adopt this, or would they agree on a
> >>  element? Or would they implement a  element? If
> >> they implement plain , there is not much room for a Working Group,
> >> where this might be standardized in the future, to make major changes,
> >> meaning they would be mostly rubber-stamping the Community Group output.
> >> --
> >> Björn Höhrmann · mailto:bjo...@hoehrmann.de ·
> http://bjoern.hoehrmann.de
> >> Am Badedeich 7 · Telefon: +49(0)160/4415681 ·
> http://www.bjoernsworld.de
> >> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
> >>
> >
>
>
>

Re: CG for Speech JavaScript API

[Dan Burnett]

To clarify,  is short for , not .  This is, in fact, 
an extremely common abbreviation for anyone who uses speech recognition APIs 
today because it takes so long both to say and type "recognition" after the 
10,000th time.

Nevertheless, a Working Group standardizing this could choose something other 
than  for the name.

-- dan

On Feb 1, 2012, at 12:11 AM, Rick Waldron wrote:

> Just wondering why, in 2012, there are proposals for elements with 
> abbreviated names. Please stop doing that.
> 
>  
> 
> Is two characters longer and infinitely more intuitive. Say no to mistakes 
> like 
> 
> Rick
> 
> On Jan 31, 2012, at 11:51 PM, Bjoern Hoehrmann  wrote:
> 
>> * Glen Shires wrote:
>>> We at Google propose the formation of a new Community Group to pursue a
>>> JavaScript Speech API. Specifically, we are proposing this Javascript API
>>> [1], which enables web developers to incorporate speech recognition and
>>> synthesis into their web pages, and supports the majority of use-cases in
>>> the Speech Incubator Group's Final Report [2]. This API enables developers
>>> to use scripting to generate text-to-speech output and to use speech
>>> recognition as an input for forms, continuous dictation and control. For
>>> this first specification, we believe this simplified subset API will
>>> accelerate implementation, interoperability testing, standardization and
>>> ultimately developer adoption.
>> 
>> Looking at "HTML Speech Incubator Group Final Report", there is a propo-
>> sal for a  element. Let's say the Community Group adopts this idea
>> and several browser vendors implement it. Is the assumption that Mozilla
>> would implement a  element while Microsoft would implement some
>>  element if they choose to adopt this, or would they agree on a
>>  element? Or would they implement a  element? If
>> they implement plain , there is not much room for a Working Group,
>> where this might be standardized in the future, to make major changes,
>> meaning they would be mostly rubber-stamping the Community Group output.
>> -- 
>> Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
>> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
>> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
>> 
> 

Re: RfC: LCWD of Web Socket API; comment deadline October 21

[Julian Reschke]

On 2012-01-03 13:39, Arthur Barstow wrote:

On 12/29/11 8:48 AM, ext Julian Reschke wrote:

I note that

claims this was addressed but it was not.

(In the meantime the reference additionally is out-of-date as RFC 6455
has been published a few days later, and not waiting with publishing
the CR is a sort-of embarasssing #FAIL of W3C/IETF coordination).


The above is captured in bug 15400.


But apparently hard to fix.

Re: CG for Speech JavaScript API

[Satish S]

>
> Re the mail list, if we turn this around and look at it from the
> perspective of someone that is mostly interested in the CG and not WebApps,
> they would then receive close to an additional 2K emails per quarter.

 I really don't think you want that so I recommend against using
> public-webapps.


Speech API discussions could use a "[speech api]" prefix in the email
subject so that participants can filter emails based on that. I see this
style being used by File API and possibly others in the webapps mailing
list. As Glen mentioned keeping discussions in the webapps mailing list
will provide visibility to a wider audience, with a balanced web-centric
view for new JavaScript APIs.

--
Cheers
Satish