I have a proposal for an extension to javascript to enable browsers to
access system idle information. Please give me feedback and suggestions on
the proposal.
Thanks!
SUMMARY
There currently is no way to detect the system idle state in the browser.
For example this makes it difficult to deal
On Thu, 17 Sep 2009 00:05:58 +0200, David Bennett d...@google.com wrote:
I have a proposal for an extension to javascript to enable browsers to
access system idle information. Please give me feedback and suggestions
on the proposal.
What exactly are the security and privacy implications
Apologies, I should have also forwarded this onto the WebApps group for
your information.
Thanks,
David.
From: public-device-apis-requ...@w3.org
[mailto:public-device-apis-requ...@w3.org] On Behalf Of David Rogers
Sent: 15 September 2009 18:44
To: public-device-apis
Subject: BONDI
Hey Cam,
On Sep 17, 2009, at 01:56 , Cameron McCormack wrote:
I’m open to suggestions on how to proceed. Splitting the spec into
parallel 1.0 and 1.1 versions could be done, but not without a little
effort.
Based on what you've said I'd figure that the best might be to move it
to LC soon,
Hi David,
On Sep 17, 2009, at 00:05 , David Bennett wrote:
I have a proposal for an extension to javascript to enable browsers
to access system idle information. Please give me feedback and
suggestions on the proposal.
Thanks!
SUMMARY
There currently is no way to detect the system idle
Regrets, I have a conflicting meeting.
Best regards,
Bryan Sullivan | ATT
Dear Jere,
On Sep 15, 2009, at 12:49 , jere.kapy...@nokia.com jere.kapy...@nokia.com
wrote:
I'm a sucker for all things ABNF. :-)
Well it's always good to have one of those around!
/1/ Is it the intent that the 'opaque authority' corresponds exactly
to the
iauthority definition in the
On Sep 3, 2009, at 16:18 , Marcos Caceres wrote:
(additional typo found, at bottom of email)
Also,
widget:///secret-identities/marcosc/batman.foaf note the ///
That's not a typo, it's a URI with no authority!
--
Robin Berjon - http://berjon.com/
On Sep 3, 2009, at 14:25 , Marcos Caceres wrote:
Many specifications in the Web stack depend on a context being
defined
that includes a current IRI. This is easily provided for documents
retrieved over HTTP, or from the local file system, but is currently
undefined for documents extracted from
The draft minutes from the September 17 Widgets voice conference are
available at the following and copied below:
http://www.w3.org/2009/09/17-wam-minutes.html
WG Members - if you have any comments, corrections, etc., please send
them to the public-webapps mail list before 24 September
On Sep 15, 2009, at 21:12 , Marcin Hanclik wrote:
I do not think they are so different.
Frederick is correct in his interpretation of the intent of the
specification: they are meant to be different.
feature points to anything, we can still build the interpretation.
But it is meant and
On Sep 7, 2009, at 15:11 , Marcin Hanclik wrote:
is pretty simple, logical, and gets the job done for most use cases.
The above is not the case e.g. for mailto: or tel:, specifically if
you want to be more specific/selective with the additional arguments
(a la subdomains).
There is a
On Sep 8, 2009, at 11:00 , Marcin Hanclik wrote:
As stated in my original email, one of the targets is that access
is not an obstacle for DAP.
The design was based on:
- not restricting DAP's ability to define a security policy
- enabling boolean access to URIs
- having pattern matching
On Sep 10, 2009, at 15:00 , Frederick Hirsch wrote:
Is the fundamental difference of feature and access the following:
feature - API set expected to be possibly used
access - network resource to be accessed.
Exactly. I think that part of the confusion stems from the different
uses of URIs.
Hi Robin,
I understand the 80/20 principle.
It is about quality.
I am however not sure that publication of the spec as is will result in the
companies listed below to adjust to the correct meaning.
BONDI has network-access which is different
It was done, because there was no access when BONDI
On Sep 9, 2009, at 16:06 , Breitschwerdt, Christian, VF-Group wrote:
Wrt the latest draft of WARP, I noticed that the usage example of
the access element is actually not very meaningful as the last
access element with uri=* allows access to practically everywhere,
thus turning the earlier
Hi Robin,
Herewith I reply to both your recent answers [1] and [2].
It is good for me to see that the intentions and scope of the WARP spec get
clarified upon discussion.
Schemes such as sms and tel are definitely out of scope for
this simple approach.
If so, then please add clear rules to
What is the relation of access element to openURL from Widget interface
specification?
openURL examples use sms: and tel:.
As discussed in another mail thread [1], the scope of WARP in terms of
programmatic usage of URIs focuses on XHR.
Should then openURL be incorporated there as well?
Hi Robin,
Please bear in mind that my proposal moves the access's @uri to param
name=uri value=XXX/ and not to feature's @name.
The distinction is clear.
Thus there seems to be no confusion.
Thanks,
Marcin
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax:
In section 1.3 [1] (non-normative) I suggest changing all the instances of word
service to resource.
Service could mean e.g. mail, telephony, messaging service etc. and WARP is
about access to retrievable network resources.
Thanks,
Marcin
[1]
Hi Robin,
I am further trying to align the syntax and semantics of WARP.
The design was based on:
...
- enabling boolean access to URIs
...
As in the previous emails, I assume that WARP should more underline the
retrievable character of the network RESOURCE.
Then mailto: should not be
Below is some information about a 1-day BarCamp-type gathering on
accessible media to be held at Stanford on Sunday November 1
(precedes the W3C's annual TPAC meeting week [1]).
The organizers of this event are Apple's David Singer and Stanford's
John Foliot. If want to attend, you are
On Thu, Sep 17, 2009 at 12:50 AM, Arve Bersvendsen ar...@opera.com wrote:
On Thu, 17 Sep 2009 00:05:58 +0200, David Bennett d...@google.com wrote:
I have a proposal for an extension to javascript to enable browsers to
access system idle information. Please give me feedback and suggestions
All,
The Web Security Context Working Group asked WebApps to review
Section 7.4 of their Web Security Context Working Group spec:
http://www.w3.org/TR/wsc-ui/#robustness-apis
If you have any comments, please send to the following list by
September 24 at the latest:
The title of the spec is actually Web Security Context: User
Interface Guidelines:
http://www.w3.org/TR/wsc-ui/#robustness-api
On Sep 17, 2009, at 1:57 PM, Barstow Art (Nokia-CIC/Boston) wrote:
All,
The Web Security Context Working Group asked WebApps to review
Section 7.4 of their Web
On Thu, Sep 17, 2009 at 10:35 AM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Sep 17, 2009 at 12:50 AM, Arve Bersvendsen ar...@opera.com wrote:
On Thu, 17 Sep 2009 00:05:58 +0200, David Bennett d...@google.com wrote:
I have a proposal for an extension to javascript to enable browsers to
isn't the mere knowledge of the level of activity on a device a
possible privacy concern, and couldn't the pattern of activity offer a
traffic analysis type opportunity?
regards, Frederick
Frederick Hirsch
Nokia
On Sep 17, 2009, at 1:35 PM, ext Jeremy Orlow wrote:
On Thu, Sep 17, 2009
All,
Months ago, I reserved a room on November 2-3 so that WebApps' API
group [API] could meet f2f during the W3C's annual TPAC meeting week
(Nov 2-6 [TPAC]). I reserved a separate meeting room on those same
days for WebApps' widgets group [Widgets].
I started an agenda for the Widget
I don't believe that's what Frederick is talking about. Also, fuzzing and
rounding don't apply to the proposal you just sent out since it's now just
an event (rather than a timer based API).
I think there is some merit to Jonas and Frederick's comments. We are
leaking more information (but not a
On Thu, Sep 17, 2009 at 2:13 PM, Jeremy Orlow jor...@chromium.org wrote:
I don't believe that's what Frederick is talking about. Also, fuzzing and
rounding don't apply to the proposal you just sent out since it's now just
an event (rather than a timer based API).
Well, there is still a
Cameron McCormack:
I’m open to suggestions on how to proceed. Splitting the spec
into parallel 1.0 and 1.1 versions could be done, but not without a
little effort.
Robin Berjon:
Based on what you've said I'd figure that the best might be to move
it to LC soon, as planned, and if it gets
Art, Chaals,
This is a request to publish the WebSimpleDatabase draft as FPWD.
Please let me know if you need anything from me.
The draft can be accessed from http://dev.w3.org/2006/webapi/WebSimpleDatabase/
Highlights of this draft are:
Provides transactional access to a local, persistent
* Jeremy Orlow wrote:
As far as I know, there really aren't any. This was discussed on WhatWG
(before being directed here) and IIRC there were no serious security or
privacy concerns. The minimum resolution of the event makes attacks based
on keystroke timing impossible. Some people suggested
33 matches
Mail list logo
