Rechartering of W3C Device APIs Working Group
L. David Baron
http://lists.w3.org/Archives/Public/public-new-work/2011May/0000.html
http://www.w3.org/2010/11/DeviceAPICharter.html
the W3C is rechartering the Device APIs and Policy working group,
and renaming it to the Device APIs working group.
We (especially those who have been involved with the group) should
think about what we should say in the charter review. If we submit
a substantive charter review, I think it probably should include
comments based on the issues that caused us to leave the group a
while back. (If we do send review comments in the hope that the
group's charter would change in a way that we'd return to the group,
we should probably be specific about what changes we think would be
needed for the group to be effective such that we'd return.)
Since I wasn't directly involved in the group, my memory of the
issues that caused us to leave is perhaps a little short on details:
my memory was that the issues were both the emphasis on policy
aspects that are inappropriate for the Web and other aspects of the
API that were either not Web-like or not appropriate for the Web.
In any case, I'd be interested in thoughts on what we should say in
this charter review (deadline June 9), particularly from those of
you who have been involved in the group in the past.
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Henri Sivonen
> We (especially those who have been involved with the group) should
> think about what we should say in the charter review.
> other aspects of the
> API that were either not Web-like or not appropriate for the Web.
I wasn't previously involved, but it seems to me that the charter still
contains deliverables that aren't appropriate for the Web (or my
imagination isn't good enough to guess Web use cases).
Why should a Web app (as opposed to a non-Web phone vendor-provided
widget written in HTML) be able to read the battery level of the device?
Why should a Web app be able to manage overall audio volume (as opposed
to managing the volume of a given <video> or <audio> element)?
Scanning the local network for services seems scary on surface.
OTOH, some proposed deliverables seem to overlap with WHATWG/WebRT work
without any indication of cooperation. Specifically, media capture may
overlap with WebRT work.
>From stuff like battery level, volume level and management of local
media file storage, I still get the feeling that this charter isn't for
a group that's speccing APIs for the Web but for a group that is
speccing a way to write various management UIs that come bundled on
phones using HTML/CSS/JS. It's unclear why that's worth standardizing.
That is, who'd write phone management UIs is HTML/CSS/JS *and* want to
be able to swap the engine at will? (After all, e.g. HP writing their
bundled UIs on top of their bundled WebKit doesn't required
standardization.)
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Jonas Sicking
"Calendar API, an API to access a calendar service (e.g. to add an
entry, to edit an entry, to delete an entry)
Tasks API, an API to access a personal task management / organizer
service (e.g. to add, edit, delete a task)
Contacts API, an API to access a contacts or address book service
(e.g. to add an entry, to edit an entry, to delete an entry)
Messaging API, an API to create and send a message. The API is
agnostic to the underlying messaging service (e.g. e-mail, SMS, MMS).
Gallery API, an API to manage the local media file storage"
These look interesting, but has some serious security concerns. I'm
interested to hear about what general approach is being taken here. In
particular I'd like to hear from the people that we have working on
this.
"Capture API, an API to manage a device’s camera and microphone, e.g.
to take a picture or record a sound"
This is already being worked on in the RTW WG, no? At least the parts
not already covered by HTML (HTML4 and HTML5 alike).
"An API to discover the current network characteristics
An API to react to a device power status
An API to retrieve data generically from sensors
An API to manage vibration
An API to manage systems beeps
An API to manage application menus
An API to manage the read the current audio volume level of a device
An API for requesting and managing user permissions to use device features
An API to discover devices and services on the same device, on the
local network, or directly connected, e.g. by USB and Bluetooth."
I'm not excited about these. Seems like a high cost in privacy vs. a
low value for websites. Definitely not something I'd like to see W3C
spend time on at this point in time.
"An API that allows web applications to register themselves as
handlers/providers based on data string identifiers and an API that
enables other web applications to discover these handlers/providers
and gain permission to interact with them."
This is somewhat more interesting, though raises tricky security questions.
"Privacy Mechanism for Device APIs"
Here's where the rubber meets the road. It concerns me a bit that this
is listed as a separate deliverable. I'm not convinced that that is
how we'll have to do it. The canonical counter example is file
handling (<input type=file> and drag'n'drop) which doesn't require a
separate mechanism for getting security, but rather has security built
in.
So in short, while there are some interesting topics here. I'm not
convinced that it's worth our efforts. There simply seems to be too
much that we are not interested in.
/ Jonas
On Thu, May 12, 2011 at 10:16 PM, L. David Baron <dba...@dbaron.org> wrote:
> As described in:
> http://lists.w3.org/Archives/Public/public-new-work/2011May/0000.html
> http://www.w3.org/2010/11/DeviceAPICharter.html
> the W3C is rechartering the Device APIs and Policy working group,
> and renaming it to the Device APIs working group.
>
> We (especially those who have been involved with the group) should
> think about what we should say in the charter review. If we submit
> a substantive charter review, I think it probably should include
> comments based on the issues that caused us to leave the group a
> while back. (If we do send review comments in the hope that the
> group's charter would change in a way that we'd return to the group,
> we should probably be specific about what changes we think would be
> needed for the group to be effective such that we'd return.)
>
> Since I wasn't directly involved in the group, my memory of the
> issues that caused us to leave is perhaps a little short on details:
> my memory was that the issues were both the emphasis on policy
> aspects that are inappropriate for the Web and other aspects of the
> API that were either not Web-like or not appropriate for the Web.
>
David Ascher
can make progress on uplifting to standards some of the APIs that are in
use today to allow device-independent APIs, in particular Contacts &
Messaging, where we've gone to the point of some prototyping work.
> "An API to discover the current network characteristics
> An API to react to a device power status
> An API to retrieve data generically from sensors
> An API to manage vibration
> An API to manage systems beeps
> An API to manage application menus
> An API to manage the read the current audio volume level of a device
> An API for requesting and managing user permissions to use device features
> An API to discover devices and services on the same device, on the
> local network, or directly connected, e.g. by USB and Bluetooth."
>
> I'm not excited about these. Seems like a high cost in privacy vs. a
> low value for websites. Definitely not something I'd like to see W3C
> spend time on at this point in time.
The alternative to having standardized APIs is that platform-specific
APIs are all that's available to app developers, and as a result makes
the web platform less compelling in contrast. The data so far seems to
indicate that there's real value to users in making apps integrate with
devices... My own take is that I'd rather have more than one party help
influence these APIs, and preferably that someone with a stake in
protecting users is involved early.
To be clear: I fully share your concern that these APIs have to bake in
the appropriate security & privacy principles, and I think we should
take a more active role to ensure so, rather than stay on the sideline.
I don't have any personal experience with the pragmatic implications of
the w3c process, though, so I'm agnostic on the question of whether a
specific working group is an effective means to promoting effective
security & privacy for delivery of application capability via the web.
I'm also unable to judge the opportunity cost relative to other
comparable use of our resources.
--david
L. David Baron
> From stuff like battery level, volume level and management of local
> media file storage, I still get the feeling that this charter isn't for
> a group that's speccing APIs for the Web but for a group that is
> speccing a way to write various management UIs that come bundled on
> phones using HTML/CSS/JS. It's unclear why that's worth standardizing.
> That is, who'd write phone management UIs is HTML/CSS/JS *and* want to
> be able to swap the engine at will? (After all, e.g. HP writing their
> bundled UIs on top of their bundled WebKit doesn't required
> standardization.)
It seems like the motivation may be less things like phone
management UIs and more things like packaged Web apps (e.g., W3C
widgets or other packaging mechanisms), perhaps sold through app
stores.
Henri Sivonen
> management UIs and more things like packaged Web apps (e.g., W3C
> widgets or other packaging mechanisms), perhaps sold through app
> stores.
Why do packaged apps need to see the battery level or manage the system audio volume setting?
L. David Baron
> > It seems like the motivation may be less things like phone
> > management UIs and more things like packaged Web apps (e.g., W3C
> > widgets or other packaging mechanisms), perhaps sold through app
> > stores.
>
> Why do packaged apps need to see the battery level or manage the
> system audio volume setting?
I'm not sure, but there are people we could ask. And it's entirely
possible we could argue for the list to be trimmed down.
In any case (based on discussions I've had at the AC meeting) it
sounds like the list of deliverables is derived from two sets of
submissions of specs originally designed for widget-like stuff.
It sounds like there's a desire for at least some of the DAP work
from companies that are building mobile apps for different mobile
platforms (think of things like Facebook shipping an app for iOS and
an app for Android) wanting to build more internal pieces of if not
all of these apps using Web technology.
Mark Finkle
> It sounds like there's a desire for at least some of the DAP work
> from companies that are building mobile apps for different mobile
> platforms (think of things like Facebook shipping an app for iOS and
> an app for Android) wanting to build more internal pieces of if not
> all of these apps using Web technology.
I think some of the desire comes from existence of tools like PhoneGap
(http://docs.phonegap.com/) that have lower level APIs allowing
developers to build mobile applications using web technologies.
Asa Dotzler
>> It seems like the motivation may be less things like phone
>> management UIs and more things like packaged Web apps (e.g., W3C
>> widgets or other packaging mechanisms), perhaps sold through app
>> stores.
>
> Why do packaged apps need to see the battery level or manage the system audio volume setting?
>
While I think it's noble and right of us to scrutinize features like
this so that bad ideas don't make it into the Web platform, I'm not sure
we're the right group of people to determine what Web developers would
like to be doing with apps.
For example, why shouldn't a Web app be able to mute the system. I use
Flash Web apps on the desktop (Pandora, for one) that can do this today
so there's clearly demand for it.
I think we should be doing some actual research on what Web app
developers want from device APIs. We may decide that the things Web
developers want are unreasonable but I think we hurt ourselves if we cut
that list prematurely.
- A
Matt Brubeck
> Why do packaged apps need to see the battery level or manage the system audio volume setting?
Most mobile platforms support "widgets" - small views that can be embedded in a home screen or launcher. Some of the most popular widgets are things like battery monitors and toggles for system settings. The proposed API could make it possible to write these widgets (or full-blown apps with similar features) using open web technologies and have them work across platforms.
Another use case is for apps that change their behavior in response to battery levels or other phone settings. For example, they might stop making network requests if the battery is low or when a high-speed network is not available. (I'm not as convinced of this use case; it might be handled better with higher-level APIs to tell apps to start or stop using resources.)
Matt Brubeck
Most mobile platforms support "widgets" - small views that can be embedded in a home screen or launcher. Some of the most popular widgets are things like battery monitors and toggles for system settings. The proposed API could make it possible to write these widgets (or full-blown apps with similar features) using open web technologies and have them work across platforms.
Doug Turner
When I was involved, the specs were drifting into a very 'java-like' feel. This is partly due to the couple of API submissions that were built around the idea that you could extend web features into the DOM/js-binding via Java. Much of this has changed, I think.
I was also very concerned about the privacy/xml-policy aspects of the API. I believe this would stifle the 'ease' of web programming, as well as give the false promise that this API was somehow more secure than another apis. (You don't have to think about this sort of thing when you build a IOS app! Why should you have to deal with this when you build a web app?). I may have been hypersensitive to this issue because of the over-year-long battle over GeoPriv-thinking in the Geolocation WG. In this case, some members wanted privacy policy embedded in to javascript objects which would explain how the object could be used. Please look up the geo mailing list notes for the details. To me, this was a bad idea and any WG that wanted to think about it (again) was a WG that I didn't want to waste time on.
Somewhat a smaller point, I think the DAP's charter is pretty huge. Instead, i think smaller charters might be the way to go to make faster progress? Ignoring the GeoPriv issues, I think the Geo WG worked quite well. It was narrowly focused on a small feature. The WG membership consisted of interested and active browser venders that wanted the web to move forward now. It had a very few face to face meetings where we hashed out the details. And we got to work and implemented it very quickly. Another example of this sprint-style-wg is the Web Notification WG. Small group, focused on quick design and implementation. To me, I don't think that is anything at all like what the DAP currently is. The DAP is a wide net of "everything else we need to be a web platform". I do not think is very helpful.
As for where we add these features, we have already started adding them directly to the navigator object off of the global. This is where new features will go. We will not invent a new object to insert under navigator just for the sake of calling it navigator.dap. or whatever.
Maybe the DAP has moved closer to what we'd have hoped it would be. Maybe not.
Happy to hear feedback.
Doug
----- Original Message -----
From: "Arun Ranganathan" <ar...@mozilla.com>
To: "L. David Baron" <dba...@mozilla.com>, dev-pl...@lists.mozilla.org, "Doug Turner" <do...@mozilla.com>, "Brad Lassey" <bla...@mozilla.com>
Sent: Wednesday, May 18, 2011 10:49:26 AM
Subject: Fwd: Rechartering of W3C Device APIs Working Group
We should send substantial feedback about what we think works on the web and what doesn't.
A while ago, we agreed that our thoughts on this matter were that device APIs should evolve along lines that consider:
1. Whether the device capability integrates with an existing HTML element so that the security implications are understood, and so that adding to the DOM interface follows a cowpath. An example might be the various extensions to <input type=" "> and the File API. Also, <video...> and the Stream API. These integrate with HTML, and allow us to consider things in terms of what we've already evolved on the web. This is true of WebGL as well -- we add interfaces to the Canvas API (and <canvas>) which actually give us "access" to the GPU (and hence our thinking on drivers).
2. An asynchronous design, and whether the new capability integrates with the event model. We've seen this for Orientation events and other things, and we're keen that nothing blocks on the main thread. We also use the term asynchronous for how the Geolocation prompt stops the flow of things till permission is granted, and said as much about user-facing prompts at the workshop before this WG was created: http://arunranga.com/articles/2008/position-paper.html
3. Whether we really need a new top-level object. In theory, we didn't necessarily need one for Geolocation, but it's good we shipped it :)
4. That security based on policy files wasn't sound for the web. The earlier Device API WG was obsessed with this. Has our stance on this changed, or have they decided it's not part of the charter? I think Mike Hansen and others should be involved here.
-- A*
-------- Original Message --------
Subject: Rechartering of W3C Device APIs Working Group
Date: Fri, 13 May 2011 07:16:08 +0200
From: L. David Baron <dba...@dbaron.org>
To: dev-pl...@lists.mozilla.org
As described in: http://lists.w3.org/Archives/Public/public-new-work/2011May/0000.html http://www.w3.org/2010/11/DeviceAPICharter.html the W3C is rechartering the Device APIs and Policy working group,
and renaming it to the Device APIs working group.
We (especially those who have been involved with the group) should
think about what we should say in the charter review. If we submit
a substantive charter review, I think it probably should include
comments based on the issues that caused us to leave the group a
while back. (If we do send review comments in the hope that the
group's charter would change in a way that we'd return to the group,
we should probably be specific about what changes we think would be
needed for the group to be effective such that we'd return.)
Since I wasn't directly involved in the group, my memory of the
issues that caused us to leave is perhaps a little short on details:
my memory was that the issues were both the emphasis on policy
aspects that are inappropriate for the Web and other aspects of the
API that were either not Web-like or not appropriate for the Web.
In any case, I'd be interested in thoughts on what we should say in
this charter review (deadline June 9), particularly from those of
you who have been involved in the group in the past.
-David
Brad Lassey
emphasis to the feeling that DAP's focus is too broad. I think that's a
point that's been talked about between individuals, but never shared
more widely. My experience of calling into the DAP conference calls
(back when I did) was that the group would rat hole on minutia of one
particular API and then gloss over the rest for lack of time. I think in
the very least camera and other media APIs should be moved into their
own WGs as well as PIM (contacts, calendar etc). There may be others
that can benefit from having their own WG, but those especially have
enough domain specific issues that I feel they can't be serviced
properly by such an over arching group.
-Brad
Anant Narayanan
> I agree with just about everything Doug just said but wanted to add emphasis to the feeling that DAP's focus is too broad. I think that's a point that's been talked about between individuals, but never shared more widely. My experience of calling into the DAP conference calls (back when I did) was that the group would rat hole on minutia of one particular API and then gloss over the rest for lack of time. I think in the very least camera and other media APIs should be moved into their own WGs as well as PIM (contacts, calendar etc). There may be others that can benefit from having their own WG, but those especially have enough domain specific issues that I feel they can't be serviced properly by such an over arching group.
+1 - I think the scope of the DAP charter covers too many things and this makes it much harder to participate with real meaning. The camera and microphone device APIs are well within the scope of the newly formed RTCweb working group and should, in my opinion, be completely omitted from the DAP charter.
I would vouch for splitting out many of the other areas it wishes to cover as well (Contacts and Calendar are sufficiently complicated to require fairly concentrated focus).
Regards,
-Anant
L. David Baron
> As described in:
> http://lists.w3.org/Archives/Public/public-new-work/2011May/0000.html
> http://www.w3.org/2010/11/DeviceAPICharter.html
> the W3C is rechartering the Device APIs and Policy working group,
> and renaming it to the Device APIs working group.
>
> We (especially those who have been involved with the group) should
> think about what we should say in the charter review. If we submit
> a substantive charter review, I think it probably should include
> comments based on the issues that caused us to leave the group a
> while back. (If we do send review comments in the hope that the
> group's charter would change in a way that we'd return to the group,
> we should probably be specific about what changes we think would be
> needed for the group to be effective such that we'd return.)
In any case, I've done a bit of gathering of the feedback in this
thread, plus some in-person conversations with various people, to
try to write up comments that we should send. (The deadline for
comments is Sunday.)
What I've come up with so far is below.
Thoughts?
-David
My organization:
(x) suggests changes to this Activity Proposal, and only supports the
proposal if the changes are adopted [Formal Objection]
Comments:
There are too many diverse areas in this Device API charter for it to
attract the necessary expertise for each of them. Many of these areas
should be split out into separate groups, though how many groups are
needed depends on the complexity of the APIs intended to be designed.
For example, if the "Messaging API" is a mechanism to send a blob to a
mechanism like Android's sharing menu, it might be reasonable to design
it within a group covering many other topics, but if it's an API
intended to deal with addressing recipients of messages it likely needs
a dedicated group that can attract expertise in that area.
For a start, the Calendar API, Tasks API, Contacts API, and Messaging
API don't seem to be at all about devices: they're about access to the
user's data, and clearly seem separate from the rest of the charter.
Some of these areas are also *very* complex, and designing a good API
requires expertise in the field, which is hard to attract to a group
covering that work along with a bunch of other areas.
The Capture API also seems to be an area that should likely be separate;
it likely has close ties to WebRTC and other work going on in the
Audio/Video space.
(I don't have an opinion about whether it's more appropriate to have
separate working groups or multiple, mostly separate, task forces within
a single working group.)
Listing a "privacy mechanism" as a separate specification is a bad
approach. Privacy considerations need to be incorporated into each of
the specifications as needed; these are going to differ between
specifications (particularly for the data-rather-than-device
specifications and for the Capture API). That said, it may be
appropriate to leave some of the privacy issues to implementations, but
even when doing this care needs to be taken when designing the APIs:
for example, when implementing an API might require asking the user, the
API should be asynchronous.
*Some* of these privacy issues may be less of a problem for applications
that the user has chosen to install. However, these APIs should have a
privacy model that works on any Web page the user happens to visit, and
not just for applications that the user has chosen to install.
The APIs should address security and privacy concerns well enough that
browser vendors can implement these APIs and expose them to Web content,
and implementation exposed to Web content should be part of the PR
entrance criteria. This includes building consensus that the tradeoff
between the privacy/security risks and the additional capabilities is
worthwhile for each feature.
The charter should also mention maintaining consistency with the style
and capabilities of existing Web APIs. One of the problems in the
history of the group was APIs that were more Java-like than Web-like in
style; this is bad for developers since APIs that are more consistent to
each other should be easier to remember how to use. Likewise, another
problem has been failure to integrate with existing integration points
that are appropriate, such as <input type="file"> and <video>.
Doug Turner
Doug
----- Original Message -----
From: "L. David Baron" <dba...@dbaron.org>
To: dev-pl...@lists.mozilla.org
Robin Berjon
thanks for putting this together. I'd like to provide some feedback
representing simply myself, not the group.
On Jun 17, 4:39 am, "L. David Baron" <dba...@dbaron.org> wrote:
> My organization:
>
> (x) suggests changes to this Activity Proposal, and only supports the
> proposal if the changes are adopted [Formal Objection]
The core of my feedback here is that you are making your support
conditional on changes but not indicating clearly what changes you
would like to see nor at times which problems it is you are attempting
to address. I think that clarifying this aspect would be most helpful.
> There are too many diverse areas in this Device API charter for it to
> attract the necessary expertise for each of them. Many of these areas
> should be split out into separate groups, though how many groups are
> needed depends on the complexity of the APIs intended to be designed.
(...)
> (I don't have an opinion about whether it's more appropriate to have
> separate working groups or multiple, mostly separate, task forces within
> a single working group.)
Work tends de facto to organise itself around groups of people who
form competence domains. WebApps is working mostly fine despite having
in its remit Web IDL and the selectors API, the File API and Workers,
Sockets and IndexedDB, etc. When DAPv1 was created my initial
suggestion was to put all its APIs into WebApps as well (and the
policy stuff in its own group). I don't think that having a large
remit is an issue in itself. And a large group means less
administrative overhead.
I'm all for organising the group into TFs whenever that helps. I'm not
sure how to articulate that charter-wise in order to suggest an actual
change since groups can always organise into task forces and that is
generally left up to the group's consensus. Maybe "Given the broad
spectrum of deliverables involved, the group is encouraged to organise
itself into multiple task forces that may attract the requisite
expertise"?
Note that in fact, DAP has spawned public-contacts-coord, public-
calendar-coord, and public-privacy which are used to coordinate with
(respectively) IETF/PoCo/CAB, IETF/CalConnect, and the wider privacy
community. They're not highly active lists, but for instance the
Contacts and Calendar APIs have essentially been developed under the
watchful eyes of the relevant communities.
> For a start, the Calendar API, Tasks API, Contacts API, and Messaging
> API don't seem to be at all about devices: they're about access to the
> user's data, and clearly seem separate from the rest of the charter.
I always said this group, if separate, should have been called the
"bunch of APIs that are missing from the web application stack working
group". Apparently some people thing it doesn't have quite a ring to
it.
I don't think that it would make sense to drop these given that
Contacts is well advanced and has generated a decent amount of
interest, Calendar and Tasks can rely on the same design, and
Messaging is really simple and also pretty close to being finished
(yes, it's just about sending a list of blobs around).
> Some of these areas are also *very* complex, and designing a good API
> requires expertise in the field, which is hard to attract to a group
> covering that work along with a bunch of other areas.
Good expertise is hard to attract anyway. I'd rather have a charter
that lists deliverables that don't get done because we can't find the
people than to have competent and willing people but need to jump
through rechartering hoops to add a deliverable. Broad means flexible,
too. Keep in mind that it also has IP protection advantages — I don't
need to tell you why Geolocation and Notifications are in separate
groups.
> The Capture API also seems to be an area that should likely be separate;
> it likely has close ties to WebRTC and other work going on in the
> Audio/Video space.
We've already coordinated with WebRTC about which group would be best
off doing what. I think we're pretty much covered there but I'd be
happy for the charter to be clearer about it if you have some
suggested text.
> Listing a "privacy mechanism" as a separate specification is a bad
> approach. Privacy considerations need to be incorporated into each of
> the specifications as needed
As it says in the charter, the "Working Group also aims at crafting
APIs that are both secure and privacy-enabling by design, based on the
current Web browser security model". I agree that this deliverable is
poorly described (well, not described) and could use some refining.
The idea is certainly not to have one spec define the privacy
mechanism for all the others — that would be downright unworkable.
Besides, we'd have to also change all the existing drafts that are
nicely privacy-aware by design which would be a shame.
> That said, it may be
> appropriate to leave some of the privacy issues to implementations
That's already the case in existing drafts, do you mind clarifying
what it is you would wish to change?
>, but
> even when doing this care needs to be taken when designing the APIs:
> for example, when implementing an API might require asking the user, the
> API should be asynchronous.
Likewise, that's already the case in existing drafts, I'm not sure
what you are suggesting should be different?
> *Some* of these privacy issues may be less of a problem for applications
> that the user has chosen to install. However, these APIs should have a
> privacy model that works on any Web page the user happens to visit, and
> not just for applications that the user has chosen to install.
The wording in the charter seems to me to be stronger than the one you
are putting forward (will not vs should): "APIs that cannot be
demonstrated to be implementable securely within the default browser
context will not be released. This does not preclude these APIs to
support use cases of installable Web applications." Are you asking
that it be softened? If so, I strongly disagree. Whenever people have
tried to build APIs that were sort-of Web-like but without the Web's
constraints they've eventually ended up shooting themselves in the
foot. DAP has been sticking to this discipline with increasing
strictness and I think the result is much better for it.
> The APIs should address security and privacy concerns well enough that
> browser vendors can implement these APIs and expose them to Web content,
> and implementation exposed to Web content should be part of the PR
> entrance criteria.
The sentence I quote above follows one that starts with "To advance to
Proposed Recommendation". I don't mind repeating that it is also a PR
criterion if you think it's clearer — it might make the text clunkier
but then again it's a charter we're talking about :)
> This includes building consensus that the tradeoff
> between the privacy/security risks and the additional capabilities is
> worthwhile for each feature.
Which is often a hard discussion because people who have use cases
requiring a feature tend to be less risk-averse than those who don't.
I've been trying to think of a set of criteria that we could use to
arbitrate the grey cases where it might hurt the user a little bit as
part of a trade-off (e.g. by improving browser fingerprinting, or
leaking some very generic information such as that she's on a 2G
network) but I'll admit that I haven't been very successful so far.
That being said if there were no such discussions to be had we
probably wouldn't need a group. So I'm not sure how this feedback
would change the charter? If you have a rough shopping list to decide
the on-the-fence cases it would certainly be immensely helpful.
Note that this type of consideration is the red thread that ties the
group together. All the APIs listed involve access to information that
is sort of "outside of the browser's box". The domains may vary but
having the same set of people work together on how to expose
everything from your battery level to your cat's IM ID makes sense
IMHO and helps.
> The charter should also mention maintaining consistency with the style
> and capabilities of existing Web APIs.
If you have a specific sentence you want to put in the charter, I
think it could be a good idea. That being said, I have a special
mocking sneer that I use to keep people from writing Java-like APIs. I
haven't had to use it twice.
> One of the problems in the
> history of the group was APIs that were more Java-like than Web-like in
> style; this is bad for developers since APIs that are more consistent to
> each other should be easier to remember how to use. Likewise, another
> problem has been failure to integrate with existing integration points
> that are appropriate, such as <input type="file"> and <video>.
If you're going to include this paragraph I think that it would prove
most useful if you were to provide examples of such offences taken
from http://dev.w3.org/2009/dap/ so as to best inform the group. If
however you're referring to inputs that were made to the group and had
those flaws, then I certainly agree, but I don't know that there's
anything we can do by charter to prevent that. (Which is why I
developed said sneer.) I'm not sure that "This is a family-friendly
working group, people should refrain from sending Java-like APIs to
it" would get through review (although I'd sure support it).
Thanks a lot for taking the time to work on this!
PS: Have you looked at Opera's feedback concerning asynchronous
participation? I'm a little bit surprised that you're not coming out
in support for it. Oversight or differing opinion?
Robin Berjon
after replying to the proposed vote, I'd also like to cover a few of
the very interesting comments that have been made here in the hope of
dispelling issues and finding a good mode of a operation for DAP.
Henri wrote:
> Why should a Web app (as opposed to a non-Web phone vendor-provided
> widget written in HTML) be able to read the battery level of the device?
At conferences it's actually something that comes up surprisingly (to
me) often. People see it as a way of managing the performance of their
app: frills on when there's power, off when there isn't. If it were a
"non-Web phone vendor-provided widget written in HTML" thingie why
would we need a standard? Also, we'd be able to expose a lot more
information.
> Why should a Web app be able to manage overall audio volume (as opposed
> to managing the volume of a given <video> or <audio> element)?
Why indeed? That's not part of the charter. The charter does, however,
have "to read the current audio volume level of a device". Initially
this was proposed simply as a way of knowing if the device was muted
with the use case that you would use visual indicators when the audio
is muted, not download audio if not needed, etc. Personally I'm
certainly not married to it, but either way there never was any
question of managing global volume, that would suck. I'd actually want
the opposite: I want a security prompt before allowing a site to play
any sound whatsoever.
> Scanning the local network for services seems scary on surface.
Yes it's scary, but it's dead useful. That makes it hard to get right
but worth trying. It's key to home networking and if would be good if
Mozilla were at least a little bit involved because it would really
suck if transitioning into the home network went as beautifully as
Mozilla's transition into mobile :-/
> OTOH, some proposed deliverables seem to overlap with WHATWG/WebRT work
> without any indication of cooperation. Specifically, media capture may
> overlap with WebRT work.
Coordination with WebRTC is written in the charter. What's more, we've
already had a coordination call with them to figure out what should go
where and we seemed to be rather aligned on that. As a result it
looked like most of the coordination around streams, getUserMedia(),
etc. which would involve WHATWG would fall most on WebRTC's side. That
being said, I certainly don't mind coordinating with WHAT.
>From stuff like battery level, volume level and management of local
> media file storage, I still get the feeling that this charter isn't for
> a group that's speccing APIs for the Web but for a group that is
> speccing a way to write various management UIs that come bundled on
> phones using HTML/CSS/JS.
If your feeling were right it would certainly be a concern, but I'll
need more than a feeling to go on and make changes! Why would anyone
want to standardise device-management software?
Jonas wrote:
> "Calendar API...Tasks API...Contacts...Messaging...Gallery"
> These look interesting, but has some serious security concerns. I'm
> interested to hear about what general approach is being taken here. In
> particular I'd like to hear from the people that we have working on
> this.
The entry point for Contacts is asynchronous, the exact security model
is naturally left up to implementations. That having been said, the
draft does discuss several options starting with the dumb but workable
"use some kind of non-modal" to "since it's a file-upload-like dialog
it's possible that valid auto-invocation events might be enough". The
prompt is also intended to allow the user to filter which contacts
from a search are actually returned, and which contact fields are
included. Calendar and Tasks are to have similar approaches.
Messaging is just mailto/mmsto with attachments. The security model is
that it opens your local MUA with a message ready. As for Gallery,
frankly I don't know. I'd like to have more input from people who care
about it — at this point I see it doable with everything from a dumb
hint on a file upload control, to some funky metadata search API. It
really depends on what folks want.
> "An API to discover the current network characteristics
> An API to react to a device power status
> An API to retrieve data generically from sensors
> An API to manage vibration
> An API to manage systems beeps
> An API to manage application menus
> An API to manage the read the current audio volume level of a device
> An API for requesting and managing user permissions to use device features
> An API to discover devices and services on the same device, on the
> local network, or directly connected, e.g. by USB and Bluetooth."
>
> I'm not excited about these. Seems like a high cost in privacy vs. a
> low value for websites. Definitely not something I'd like to see W3C
> spend time on at this point in time.
I find your lack of faith disturbing. To go very quickly:
• network characteristics matches what's already in Android WebView,
it's just a heuristic that allows people to pick different content
depending on likely bandwidth. It exposes virtually no privacy-
sensitive information.
• device power: see to Henri above
• data generically from sensors: this always seemed vague to me, but
the use cases are massive from home temperature to health interfaces.
The privacy and security implications are massive, too. I'm unsure how
to handle it to be honest, but somehow I suspect it will go with what
you list below (or discovery).
• application menus: see http://berjon.com/blog/2011/06/integration-menu.html
• vibration: I have game developers asking me for this one every
other day. I've also seen other applications of this, though I'm not
sure I'd want to list them as use cases in an official document.
• system beeps: so you can build your own R2? I don't know, I'm not
fascinated by this one.
• current audio volume: see to Henri above
• requesting and managing user permissions to use device features:
that's just what Web Notifications had, see
http://dev.w3.org/2009/dap/perms/FeaturePermissions.html,
http://dev.w3.org/2009/dap/docs/feat-perms/feat-perms.html,
http://dougt.org/wordpress/2011/03/device-api-permission-management/,
or if you're into kinky stuff http://w3c-test.org/dap/proposals/request-feature/
• discovery: mashups for the home :)
> "An API that allows web applications to register themselves as
> handlers/providers based on data string identifiers and an API that
> enables other web applications to discover these handlers/providers
> and gain permission to interact with them."
>
> This is somewhat more interesting, though raises tricky security questions.
The current plan is to build on the merged version of Powerbox and Web
Intents, see http://web-send.org/introducer/, http://webintents.appspot.com/,
http://paul.kinlan.me/so-what-is-happening-with-web-intents. This has
legs
> "Privacy Mechanism for Device APIs"
>
> Here's where the rubber meets the road. It concerns me a bit that this
> is listed as a separate deliverable. I'm not convinced that that is
> how we'll have to do it.
You're being too mild. This would be a downright stupid way of doing
it. The idea here is that if there are mechanisms that can be shared
between specs, the charter wants to keep it open for the group to
specify them (similar to Feature Permissions, maybe). But all specs
have their own privacy mechanism for sure.
David Baron wrote:
> It seems like the motivation may be less things like phone
> management UIs and more things like packaged Web apps (e.g., W3C
> widgets or other packaging mechanisms), perhaps sold through app
> stores.
No, that's not the motivation. Sure, some people want to sell web apps
(and they should), but the guiding design is stuff that works on the
web. For the rest, there's WAC.
> It sounds like there's a desire for at least some of the DAP work
> from companies that are building mobile apps for different mobile
> platforms (think of things like Facebook shipping an app for iOS and
> an app for Android) wanting to build more internal pieces of if not
> all of these apps using Web technology.
You don't ship an app for iOS and one for Android. You ship multiple
versions for each, plus what you ship on other platforms (if you're
large enough), plus a (mobile) web site. It's a dreadful mess, all of
that because there are still too many things that the Web doesn't
offer in terms of integrating with the local platform (as opposed to
talking to the cloud at large). These apps should be handled by just
the web site, and it shouldn't have to be mobile-oriented. Not adding
a lot of these APIs is actually breaking the Web by forcing people
into other solutions.
Brad wrote:
> My experience of calling into the DAP conference calls
> (back when I did) was that the group would rat hole on minutia of one
> particular API and then gloss over the rest for lack of time.
I would certainly see value in splitting work into smaller Task Forces
(not necessarily one per spec though) that can move independently of
one another perhaps more easily. As for the calls, you should have
said so! Me, I hate all manners of calls anyway so I don't much care
either way, but WG organisation is nothing if not flexible to match
member needs (so long as they speak up). Speaking personally, I'd be
more than happy with a group in which individual TFs would decide to
have their own calls (or no call at all, or perhaps only at irregular
intervals when you need to get people on the same page and email isn't
working). I'm not sure that everyone would agree, but it's certainly
something that can be pushed. There are others who feel the same.
Anyway, I think that's enough from me for today. Enjoy your weekend :)
Mike Shaver
> It's key to home networking and if would be good if
> Mozilla were at least a little bit involved because it would really
> suck if transitioning into the home network went as beautifully as
> Mozilla's transition into mobile :-/
I'm not sure I'm interpreting this correctly, so I'll just ask: is there
something specific that you want to avoid here? Is it something related to
how we've been involved in geo or camera API or similar?
Mike
L. David Baron
> thanks for putting this together. I'd like to provide some feedback
> representing simply myself, not the group.
>
> On Jun 17, 4:39 am, "L. David Baron" <dba...@dbaron.org> wrote:
> > My organization:
> >
> > (x) suggests changes to this Activity Proposal, and only supports the
> > proposal if the changes are adopted [Formal Objection]
>
> The core of my feedback here is that you are making your support
> conditional on changes but not indicating clearly what changes you
> would like to see nor at times which problems it is you are attempting
> to address. I think that clarifying this aspect would be most helpful.
I think suggesting the work needs to be divided up is relatively
clear.
But I also don't want to be more prescriptive that necessary to
describe what we want; the more prescriptive I am, the more likely
the various responses the W3C receives will contradict each other.
> > There are too many diverse areas in this Device API charter for it to
> > attract the necessary expertise for each of them. Many of these areas
> > should be split out into separate groups, though how many groups are
> > needed depends on the complexity of the APIs intended to be designed.
> (...)
> > (I don't have an opinion about whether it's more appropriate to have
> > separate working groups or multiple, mostly separate, task forces within
> > a single working group.)
>
> Work tends de facto to organise itself around groups of people who
> form competence domains. WebApps is working mostly fine despite having
> in its remit Web IDL and the selectors API, the File API and Workers,
> Sockets and IndexedDB, etc. When DAPv1 was created my initial
> suggestion was to put all its APIs into WebApps as well (and the
> policy stuff in its own group). I don't think that having a large
> remit is an issue in itself. And a large group means less
> administrative overhead.
Not if it has teleconferences that discuss all topics mixed
together, which is huge administrative overhead.
> I'm all for organising the group into TFs whenever that helps. I'm not
> sure how to articulate that charter-wise in order to suggest an actual
> change since groups can always organise into task forces and that is
> generally left up to the group's consensus. Maybe "Given the broad
> spectrum of deliverables involved, the group is encouraged to organise
> itself into multiple task forces that may attract the requisite
> expertise"?
>
> Note that in fact, DAP has spawned public-contacts-coord, public-
> calendar-coord, and public-privacy which are used to coordinate with
> (respectively) IETF/PoCo/CAB, IETF/CalConnect, and the wider privacy
> community. They're not highly active lists, but for instance the
> Contacts and Calendar APIs have essentially been developed under the
> watchful eyes of the relevant communities.
I don't think separating out the coordination with others into a
separate list is sufficient; separating out the list where the work
happens is what's needed.
> > For a start, the Calendar API, Tasks API, Contacts API, and Messaging
> > API don't seem to be at all about devices: they're about access to the
> > user's data, and clearly seem separate from the rest of the charter.
>
> I always said this group, if separate, should have been called the
> "bunch of APIs that are missing from the web application stack working
> group". Apparently some people thing it doesn't have quite a ring to
> it.
>
> I don't think that it would make sense to drop these given that
> Contacts is well advanced and has generated a decent amount of
> interest, Calendar and Tasks can rely on the same design, and
> Messaging is really simple and also pretty close to being finished
> (yes, it's just about sending a list of blobs around).
Generated interest from whom? Is it likely to have multiple
implementations?
> > Some of these areas are also *very* complex, and designing a good API
> > requires expertise in the field, which is hard to attract to a group
> > covering that work along with a bunch of other areas.
>
> Good expertise is hard to attract anyway. I'd rather have a charter
> that lists deliverables that don't get done because we can't find the
> people than to have competent and willing people but need to jump
> through rechartering hoops to add a deliverable. Broad means flexible,
> too. Keep in mind that it also has IP protection advantages — I don't
> need to tell you why Geolocation and Notifications are in separate
> groups.
I agree these are advantages of the current approach, and why I'd be
open to a clear division into task forces.
> > The Capture API also seems to be an area that should likely be separate;
> > it likely has close ties to WebRTC and other work going on in the
> > Audio/Video space.
>
> We've already coordinated with WebRTC about which group would be best
> off doing what. I think we're pretty much covered there but I'd be
> happy for the charter to be clearer about it if you have some
> suggested text.
I'm still rather concerned that the work that really needs to be
coordinated as described in
http://weblogs.mozillazine.org/roc/archives/2011/06/media_processin.html
is being split up into even more pieces.
> > Listing a "privacy mechanism" as a separate specification is a bad
> > approach. Privacy considerations need to be incorporated into each of
> > the specifications as needed
>
> As it says in the charter, the "Working Group also aims at crafting
> APIs that are both secure and privacy-enabling by design, based on the
> current Web browser security model". I agree that this deliverable is
> poorly described (well, not described) and could use some refining.
> The idea is certainly not to have one spec define the privacy
> mechanism for all the others — that would be downright unworkable.
> Besides, we'd have to also change all the existing drafts that are
> nicely privacy-aware by design which would be a shame.
So what is it intended to be?
> > That said, it may be
> > appropriate to leave some of the privacy issues to implementations
>
> That's already the case in existing drafts, do you mind clarifying
> what it is you would wish to change?
>
> >, but
> > even when doing this care needs to be taken when designing the APIs:
> > for example, when implementing an API might require asking the user, the
> > API should be asynchronous.
>
> Likewise, that's already the case in existing drafts, I'm not sure
> what you are suggesting should be different?
I'm pointing out an *exception* to my previous statement.
Assurances that the exception is already true in existing drafts
aren't particularly comforting.
> > *Some* of these privacy issues may be less of a problem for applications
> > that the user has chosen to install. However, these APIs should have a
> > privacy model that works on any Web page the user happens to visit, and
> > not just for applications that the user has chosen to install.
>
> The wording in the charter seems to me to be stronger than the one you
> are putting forward (will not vs should): "APIs that cannot be
> demonstrated to be implementable securely within the default browser
> context will not be released. This does not preclude these APIs to
> support use cases of installable Web applications." Are you asking
> that it be softened? If so, I strongly disagree. Whenever people have
> tried to build APIs that were sort-of Web-like but without the Web's
> constraints they've eventually ended up shooting themselves in the
> foot. DAP has been sticking to this discipline with increasing
> strictness and I think the result is much better for it.
I'm not asking for it to be weakened; I think it would be sufficient
if the reference to security in that section were instead a
reference to security *and* privacy.
> > The APIs should address security and privacy concerns well enough that
> > browser vendors can implement these APIs and expose them to Web content,
> > and implementation exposed to Web content should be part of the PR
> > entrance criteria.
>
> The sentence I quote above follows one that starts with "To advance to
> Proposed Recommendation". I don't mind repeating that it is also a PR
> criterion if you think it's clearer — it might make the text clunkier
> but then again it's a charter we're talking about :)
Sorry, I think I missed that bit; I was looking mainly at the
Deliverables part and the stuff below it.
> > This includes building consensus that the tradeoff
> > between the privacy/security risks and the additional capabilities is
> > worthwhile for each feature.
>
> Which is often a hard discussion because people who have use cases
> requiring a feature tend to be less risk-averse than those who don't.
> I've been trying to think of a set of criteria that we could use to
> arbitrate the grey cases where it might hurt the user a little bit as
> part of a trade-off (e.g. by improving browser fingerprinting, or
> leaking some very generic information such as that she's on a 2G
> network) but I'll admit that I haven't been very successful so far.
> That being said if there were no such discussions to be had we
> probably wouldn't need a group. So I'm not sure how this feedback
> would change the charter? If you have a rough shopping list to decide
> the on-the-fence cases it would certainly be immensely helpful.
>
> Note that this type of consideration is the red thread that ties the
> group together. All the APIs listed involve access to information that
> is sort of "outside of the browser's box". The domains may vary but
> having the same set of people work together on how to expose
> everything from your battery level to your cat's IM ID makes sense
> IMHO and helps.
I think listing things as work items in the charter gives them the
presumption that this tradeoff has already been made. I think there
are just too many work items in the charter to do so adequately
during the charter review.
> > The charter should also mention maintaining consistency with the style
> > and capabilities of existing Web APIs.
>
> If you have a specific sentence you want to put in the charter, I
> think it could be a good idea. That being said, I have a special
> mocking sneer that I use to keep people from writing Java-like APIs. I
> haven't had to use it twice.
>
> > One of the problems in the
> > history of the group was APIs that were more Java-like than Web-like in
> > style; this is bad for developers since APIs that are more consistent to
> > each other should be easier to remember how to use. Likewise, another
> > problem has been failure to integrate with existing integration points
> > that are appropriate, such as <input type="file"> and <video>.
>
> If you're going to include this paragraph I think that it would prove
> most useful if you were to provide examples of such offences taken
> from http://dev.w3.org/2009/dap/ so as to best inform the group. If
> however you're referring to inputs that were made to the group and had
> those flaws, then I certainly agree, but I don't know that there's
> anything we can do by charter to prevent that. (Which is why I
> developed said sneer.) I'm not sure that "This is a family-friendly
> working group, people should refrain from sending Java-like APIs to
> it" would get through review (although I'd sure support it).
I think I'd have to leave these to others who have been more
involved in looking at existing drafts.
> PS: Have you looked at Opera's feedback concerning asynchronous
> participation? I'm a little bit surprised that you're not coming out
> in support for it. Oversight or differing opinion?
Oversight. I added:
We also strongly support Opera's feedback regarding asynchronous
participation, which is essential in a group with work in such diverse
areas and in which many participants may only be participating in a
small fraction of the work.
-David
Henri Sivonen
> Why would anyone
> want to standardise device-management software?
Carriers might want to write a carrier-specific layer of user-facing
software, including device management, as HTML/CSS/JS and use the same
code on Presto and on various WebKit ports when the browser engine might
vary from handset to handset.
(I thought this reason was a major driver behind BONDI and DAP. I may
have thought wrong, of course.)
Robin Berjon
On Jun 17, 2011, at 17:32 , Mike Shaver wrote:
> On Jun 17, 2011 8:20 AM, "Robin Berjon" <robin....@gmail.com> wrote:
>> It's key to home networking and if would be good if
>> Mozilla were at least a little bit involved because it would really
>> suck if transitioning into the home network went as beautifully as
>> Mozilla's transition into mobile :-/
>
> I'm not sure I'm interpreting this correctly, so I'll just ask: is there something specific that you want to avoid here? Is it something related to how we've been involved in geo or camera API or similar?
Sorry that I was unclear. No, it's not related to Mozilla's participation in specific groups. What I'd like to avoid is for Mozilla to miss upcoming landscape shifts in the same way that it massively missed the mobile shift, leading to the present situation of, in effect, a WebKit-only world. It didn't have to be.
Mobile isn't the last of landscape shifts, there will be others. I think that we're seeing the pieces come together for the next one being home networking and appliances. I was simply pointing out that it would be *really* nice if Mozilla were to catch that one ready to roar.
--
Robin Berjon - http://berjon.com/ - @robinberjon
Robin Berjon
> On Fri, 2011-06-17 at 05:15 -0700, Robin Berjon wrote:
>> want to standardise device-management software?
>
> software, including device management, as HTML/CSS/JS and use the same
> code on Presto and on various WebKit ports when the browser engine might
> vary from handset to handset.
Okay, but you wouldn't go to W3C for that. Carrier-specific software isn't exactly the hot topic that it was in 2004. And even then, people just injected the APIs they wanted into whatever SVG implementation was available — it didn't require a standard (not even a vague description in a Word document hidden in a numbered zip file on OMA's FTP server). Nowadays I reckon people would mostly just use the OS's customisation features.
> (I thought this reason was a major driver behind BONDI and DAP. I may
> have thought wrong, of course.)
I wasn't there when BONDI was started but I'm pretty sure that the main driver was to create an ecosystem for application development based on web technology. I think that BONDI's primary mistake was to believe that reproducing the design errors that J2ME/JSR made using a different language was going to produce a different result. Some people walked into DAP with that understanding but they were in for a disappointment since there was no way that a web specification was ever going to work that way (at least by default — if you have some "installed app" functionality you may be able to skip some security, but that's largely an implementation decision, even though it's good if the specification can support that usage easily as well).
Robin Berjon
On Jun 18, 2011, at 20:14 , L. David Baron wrote:
> On Friday 2011-06-17 02:56 -0700, Robin Berjon wrote:
>>
>> I don't think that having a large
>> remit is an issue in itself. And a large group means less
>> administrative overhead.
>
> Not if it has teleconferences that discuss all topics mixed
> together, which is huge administrative overhead.
That's certainly true, but easily fixed. If there's support for this it can even be done before the new charter goes into effect, it's fully up to the group to make that call.
>> I don't think that it would make sense to drop these given that
>> Contacts is well advanced and has generated a decent amount of
>> interest, Calendar and Tasks can rely on the same design, and
>> Messaging is really simple and also pretty close to being finished
>> (yes, it's just about sending a list of blobs around).
>
> Generated interest from whom? Is it likely to have multiple
> implementations?
PhoneGap implements an older version and I'd expect them to keep up. Labs have been playing with it though I don't know where it currently stands (https://mozillalabs.com/contacts/). Opera has been editing the specification, though I won't speculate as to their plans. I've been contacted by someone from Google, though I don't know if it's the Chrome team. As for from whom, well mostly developers at conferences I've attended recently such as Paris Web or the Korean Future of WebApps.
>> As it says in the charter, the "Working Group also aims at crafting
>> APIs that are both secure and privacy-enabling by design, based on the
>> current Web browser security model". I agree that this deliverable is
>> poorly described (well, not described) and could use some refining.
>> The idea is certainly not to have one spec define the privacy
>> mechanism for all the others — that would be downright unworkable.
>> Besides, we'd have to also change all the existing drafts that are
>> nicely privacy-aware by design which would be a shame.
>
> So what is it intended to be?
Starting from the point where each specification was expected to have its own security mechanism, something like Feature Permissions sprouted up (in Web Notifications, which was really not chartered to handle it). My understanding is that this deliverable is there so that if the same happens with privacy we can address it.
>>> That said, it may be
>>> appropriate to leave some of the privacy issues to implementations
>>
>> That's already the case in existing drafts, do you mind clarifying
>> what it is you would wish to change?
>>
>>> , but
>>> even when doing this care needs to be taken when designing the APIs:
>>> for example, when implementing an API might require asking the user, the
>>> API should be asynchronous.
>>
>> Likewise, that's already the case in existing drafts, I'm not sure
>> what you are suggesting should be different?
>
> I'm pointing out an *exception* to my previous statement.
> Assurances that the exception is already true in existing drafts
> aren't particularly comforting.
I'm sorry, I think we're talking at cross-purposes. I simply mean that all security/privacy entry points that can't be handled smartly (e.g. by integrating with the DOM) in DAP's APIs are asynchronous, and that the UI mechanism used to present the user with the best choice is always left up to the implementation (even though some specifications provide examples and suggestions).
>>> This includes building consensus that the tradeoff
>>> between the privacy/security risks and the additional capabilities is
>>> worthwhile for each feature.
>>
>> Which is often a hard discussion because people who have use cases
>> requiring a feature tend to be less risk-averse than those who don't.
>> I've been trying to think of a set of criteria that we could use to
>> arbitrate the grey cases where it might hurt the user a little bit as
>> part of a trade-off (e.g. by improving browser fingerprinting, or
>> leaking some very generic information such as that she's on a 2G
>> network) but I'll admit that I haven't been very successful so far.
>> That being said if there were no such discussions to be had we
>> probably wouldn't need a group. So I'm not sure how this feedback
>> would change the charter? If you have a rough shopping list to decide
>> the on-the-fence cases it would certainly be immensely helpful.
>
> I think listing things as work items in the charter gives them the
> presumption that this tradeoff has already been made. I think there
> are just too many work items in the charter to do so adequately
> during the charter review.
I think that you're presuming a presumption that just isn't there. The WG acts as a feature sieve, only going for what can be implemented safely. If you look at the DAP v1 charter, it had a far broader feature-set, notably things like reading from your local mailboxes (and being notified of new messages) or a UI API (whatever that means). These got shot down, with messaging now being essentially mailto with attachments and UI restricted to things that seem useful (and potentially safe).
I'd be very happy if we were able to filter more before the group starts, but frankly these discussions work best amongst the technical folks in the group than in the AC...
>> PS: Have you looked at Opera's feedback concerning asynchronous
>> participation? I'm a little bit surprised that you're not coming out
>> in support for it. Oversight or differing opinion?
>
> Oversight. I added:
>
> We also strongly support Opera's feedback regarding asynchronous
> participation, which is essential in a group with work in such diverse
> areas and in which many participants may only be participating in a
> small fraction of the work.
Thanks, that's all good feedback. I think that asynchronous participation can also help a lot manage the breadth of scope.
Boris Zbarsky
> What I'd like to avoid is for Mozilla to miss upcoming landscape shifts in the same way that it massively missed the mobile shift, leading to the present situation of, in effect, a WebKit-only world.
This had more to do with WebKit having better embedding APIs (in part
due to trying to do less and in part due to better API design) and the
marketing from being used on iOS than due to us "massively missing the
mobile shift", as far as I can tell...
Or put another way, there was nothing preventing a non-Mozilla entity
creating a mobile Gecko-based browser, just like multiple non-Apple
entity did so with WebKit. They chose not to do that, though.
-Boris
Mike Hommey
FWIW, the Maemo browser is using Gecko. I don't know about Meego,
though.
Mike
Robin Berjon
sorry for taking a little while to respond, I've been distracted.
On Jun 21, 2011, at 05:53 , Boris Zbarsky wrote:
> On 6/20/11 6:29 AM, Robin Berjon wrote:
>> What I'd like to avoid is for Mozilla to miss upcoming landscape shifts in the same way that it massively missed the mobile shift, leading to the present situation of, in effect, a WebKit-only world.
>
> This had more to do with WebKit having better embedding APIs (in part due to trying to do less and in part due to better API design) and the marketing from being used on iOS than due to us "massively missing the mobile shift", as far as I can tell...
The way you put it makes it sound as if it was just bad luck. Even if that may indeed be the case, I think it's worth keeping in mind that there may be reasons other than coincidence why WebKit ended up in a better position in the first place, in order to avoid the same situation happening again. I'm pretty certain that iOS had nothing to do with that — it only came out in 2007 and when I stopped working with the mobile industry in 2006 people there had already largely given up on Gecko (except IIRC Nokia).
I'm not trying to diminish Mozilla's many accomplishments and certainly not attempting to assign blame — I'm simply concerned that some of the comments in this thread are eerily reminiscent in both style and content of those I used to hear about mobile in the pre-iPhone era. It is little more than a strong feeling of déjà vu, and I very much hope I'm wrong, but I find it worrying enough that I thought I'd raise a quick cassandric flag.