Tracker bug for new WebAPIs

Chris, bug 594543 is about Desktop Notifications for Firefox Desktop. According to bug 573588 and bug 595094, this is already implemented for Firefox Mobile. Is this bug really depending on the implementation on Desktop?

I just want to track it to completion. It's a capability we sorely need on desktop too.

WAC (http://www.wacapps.net/specifications) has done some work that's relevant here. Looks like they based their work on W3C WIPs and extended them.

WAC's APIs aren't Web-compatible, I wouldn't spend much time looking there for this specific project. There might however be value in getting resources from them as B2G is IMHO far closer to what WAC's goal should have been than what they've actually produced to date.

What do you mean by "Web-compatible"? I'm not sure and I would like to know :).

bug 649154 doesn't seem like a strict dependency here

(In reply to Andreas Gal :gal from comment #6) > bug 649154 doesn't seem like a strict dependency here That particular bug is for implementing the DOMCrypt API in a "moz" prefixed window property. The current draft of the spec from there only references Mozilla bug 649154 and bug 657432 as well as WebKit bug 62010. Bug 649154 is where all the current work seems to be, but should a new bug be filed for the final Javascript Cryptography API then that bug would be a better fit here.

(In reply to Chris Jones [:cjones] [:warhammer] from comment #5) > What do you mean by "Web-compatible"? I'm not sure and I would like to know > :). [Sorry for not replying earlier, I've been on vacation.] Web-compatible can mean many things and a full definition would be rather long. (In previous discussions on this topic it has been suggested that one should write one such Characterization of the Open Web. Known as the COW document, it is largely believed to be mythical.) I'll therefore stick to the issues that I see with WAC's current specifications. First, they often fail to integrate with existing Web APIs. For instance they have a File interface which is not the W3C File API and is unlikely to be compatible with it. Interfaces they define that accept files will therefore not accept W3C File objects, and conversely operations that accept W3C File objects will not take WAC files. There are often reasons for such overlaps, usually because the W3C (or other) version of the same functionality is not finalised and a large part of WAC's original goal being to ship an application runtime based on Web technology quickly, at the risk of being dirty. Nevertheless, it doesn't make for a great starting point in general (though ideas can naturally be cherry-picked here and there — smart people have put effort into several of these APIs). Second, and IMHO far more problematic, is the fact that WAC's APIs have not at all been defined with a Web security model in mind. The assumption is that there is a policy mechanism of some form that selectively enables/forbids specific interfaces or methods for a given application. This may seem minor — why not just front usage of such APIs with some kind of prompt as is done with Geolocation? — but in practice it has deeper implications. You don't want to put something like unfettered file system access behind a simple Geolocation-like prompt and providing specific, subsetted, and properly protected access to privileged device functionality will often require different API designs than if you assume full access in the design followed by some policy-based sieving. Beyond that one could also mention stylistic issues (which people often refer to as "APIs that look like Java) but I think those can generally be fixed rather easily, and aren't as important. I believe however that it would be useful to engage WAC one way or another. They have developers, domain experts, testers, real-world use cases, a desire to see Open Web technology power applications, and a number of other things that could open the door to useful cooperation. I just meant to caution about jumping into using WAC APIs as a starting point. PS: Full disclosure: I've done paid contracting work for WAC in the past and might again. Not that this affects my point of view or that I've been any less candid with them about the approaches I think work best.

(In reply to Robin Berjon from comment #8) > > Web-compatible can mean many things and a full definition would be rather > long. (In previous discussions on this topic it has been suggested that one > should write one such Characterization of the Open Web. Known as the COW > document, it is largely believed to be mythical.) I'll therefore stick to > the issues that I see with WAC's current specifications. > > First, they often fail to integrate with existing Web APIs. For instance > they have a File interface which is not the W3C File API and is unlikely to > be compatible with it. Interfaces they define that accept files will > therefore not accept W3C File objects, and conversely operations that accept > W3C File objects will not take WAC files. There are often reasons for such > overlaps, usually because the W3C (or other) version of the same > functionality is not finalised and a large part of WAC's original goal being > to ship an application runtime based on Web technology quickly, at the risk > of being dirty. Nevertheless, it doesn't make for a great starting point in > general (though ideas can naturally be cherry-picked here and there — smart > people have put effort into several of these APIs). > Agree that some of the WAC APIs are now superseded by other W3C APIs, e.g. Accelerometer, Orientation and File system come to my mind at a glance. However some of them may be still a good starting point, if not for the final API itself, at least for the use cases that those APIs enable. We (Telefónica) have already developed applications that enable the use cases listed in the WebAPI Wiki on top of a WAC implementation, and the only couple of functionalities we missed in the WAC APIs were a telephony API and another API for managing device settings. > Second, and IMHO far more problematic, is the fact that WAC's APIs have not > at all been defined with a Web security model in mind. The assumption is > that there is a policy mechanism of some form that selectively > enables/forbids specific interfaces or methods for a given application. This > may seem minor — why not just front usage of such APIs with some kind of > prompt as is done with Geolocation? — but in practice it has deeper > implications. You don't want to put something like unfettered file system > access behind a simple Geolocation-like prompt and providing specific, > subsetted, and properly protected access to privileged device functionality > will often require different API designs than if you assume full access in > the design followed by some policy-based sieving. > Yeah, WAC has that policy-based security model, but from my point of view, the APIs are very decouple from the security model. Furthermore, our implementation of the use cases is running on top a WAC 2.0 solution and it works smoothly (with no impact from the security model). > Beyond that one could also mention stylistic issues (which people often > refer to as "APIs that look like Java) but I think those can generally be > fixed rather easily, and aren't as important. > > I believe however that it would be useful to engage WAC one way or another. > They have developers, domain experts, testers, real-world use cases, a > desire to see Open Web technology power applications, and a number of other > things that could open the door to useful cooperation. I just meant to > caution about jumping into using WAC APIs as a starting point. I think those are fair statements, and more precise than "WAC's APIs aren't Web-compatible" :) , however, I would say that if there are no equivalent APIs out there for a functionality, it would not harm to have a look at what WAC did. > > PS: Full disclosure: I've done paid contracting work for WAC in the past and > might again. Not that this affects my point of view or that I've been any > less candid with them about the approaches I think work best. PS: Full disclosure also on my side: I have been also involved in WAC specifications (and working together with Robin in some of them).

I would like the suggest that proper management of local storage permissions become part of this specification. Storage quotas / limits, in particular, are abysmally inflexible and non-standard, as per: http://dev-test.nemikor.com/web-storage/support-test/ I have filed a separate bug for the storage quota requests here: https://bugzilla.mozilla.org/show_bug.cgi?id=681545 which is somewhat related to: https://bugzilla.mozilla.org/show_bug.cgi?id=658117 There is an interesting storage-related issue being tracked against Chromium (Google Chrome) here: http://code.google.com/p/chromium/issues/detail?id=61676 It deals with unifying the storage quotas so that all persistent mechanisms (webSQL, IndexedDB, localStorage) share a single quota, and all temporary mechanisms (sessionStorage, etc) share a single quota. This approach might be worth evaluating.

An issue we've discussed but apparently not documented anywhere is that it's possible that the only sane security model for hyper-abusable APIs like telephony or SMS is a URL whitelist, prepopulated by a trusted party like a device vendor (and editable by the user, if they jump through the right hoops). Rob suggests it could be worth clearly separating APIs intended for the "whitelisted Web" and those for all of it, back alleys and dark corners included.

Gerv Markham posted some thoughts on using EV certificates as the basis for other mechanisms to grant permissions to web apps http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/aaf8c1cf01bf8d1f# Noting that here so that folks CC'd on this bug are aware of the mozilla-dev-webapi mailing list / newsgroup. Please post followups to Gerv's post on dev-webapi.

Hi, just joining the discussion here, and pre-disclosure, I am currently involved in WAC and have worked with Robin and Daniel on WAC and W3C (DAP, Webapps). To Robin's points on the WAC APIs as a basis, particularly re "not Web-friendly": - Separate the WAC APIs from the policy framework (which is just one way to manage permissions) and its reliance upon DigSig, and the differences pale. A user-preference/permissions feature can be built various ways, and WAC's approach is just one and can be replaced without significantly impacting the APIs. - W3C is still trying to find its feet on APIs (and their design) outside traditional HTML5 and Webapps Web APIs, for which the declarative/Javascript approaches are fairly well established (WAC chose the Javascript approach also). But outside HTML5/WebAPIs the design approaches in W3C have not stabilized (even RESTful/resource-based approaches to device feature APIs are being considered - maybe they will also be considered here?). Clearly alignment with stable/supported W3C APIs would be a good thing, But until W3C really establishes a pattern for these supplemental APIs (e.g. the ones in B2G's scope), WAC's patterns are IMO just as good as anyone's. Until real rationales for design approaches are clarified, to me its still just a matter of style. But to be clear: for B2G, which I am very excited to see as a project, I welcome any approach that promotes SDO/initiative convergence, ease of use, and user safety for apps that want to use these APIs. I'll be following and contributing as possible on the mailing list.

Hey, do we have any bugs filed yet for device access to: -proximity sensor -compass (does MozOrientation cover cardinal directions?) -accelerometer -light sensor -microphone input

Those functionalities are covered by the Sensor AP: http://dev.w3.org/2009/dap/system-info/Sensors.html

Is there a reason there is no mention of Web Audio API on the Web API list?

(In reply to comment #16) > Is there a reason there is no mention of Web Audio API on the Web API list? Bug 779297 tracks the implementation of Web Audio.

I think this can be closed, as FIXED, 'cause it did what it needed to when WebAPIs were a thing. WebAPIs as stated for this bug aren't really a thing anymore (we now just have specs in general), and we haven't tracked anything specifically on this bug in a long time.