Re: Screen Orientation Feedback
On Tue, Aug 12, 2014 at 9:59 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 12, 2014 at 5:35 AM, Rich Tibbett ri...@opera.com wrote: On Mon, Aug 11, 2014 at 11:33 PM, Jonas Sicking jo...@sicking.cc wrote: I'm not arguing that we remove the relative angle that's in the spec right now. I'm arguing that for device orientation events, we should provide coordinates relative to the screen as well. This topic was filed as an issue against the DeviceOrientation spec in March (https://github.com/w3c/deviceorientation/issues/4). Interest from implementers is a strong indicator to proceed with such spec additions. Active implementer engagement around spec clarifications and additions is quite low right now. Cool, if we can have this added to an updated DeviceOrientation spec then that's definitely the best solution here. Though the issue above seems to suggest that the spec would define that the existing alpha/beta/gamma properties would be redefined to be screen-relative rather than device relative. Is that really going to be web compatible? I don't think mozilla would feel comfortable leading with such a change given our limited influence for mobile content. But if browsers with bigger mobile marketshare make such a change we'd definitely follow. Do you have any indication that there's interest in that? A safer option seems to be to introduce screenAlpha/screenBeta/screenGamma (or something similarly named) and make those relative to the screen. Sounds good to me. That is something that I'm fairly sure I can make happen in Gecko. OK. I believe we could implement these properties in Chromium based on this intent (pending following the correct process there of course). Do you have any thoughts on providing screen-adjusted devicemotion event data also (i.e. acceleration, accelerationIncludingGravity, rotationRate) or do you plan to just stick to providing screen-adjusted deviceorientation event data for now? - Rich / Jonas
Re: Screen Orientation Feedback
On Mon, Aug 11, 2014 at 11:33 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Aug 8, 2014 at 6:44 AM, Mounir Lamouri mou...@lamouri.fr wrote: Maybe this feedback should be more for DeviceOrientation than Screen Orientation. There has been a few discussions there (public-geolocation). This is the type of procedural issues that I'd really rather not get caught in. I think it's fine to defer to the DeviceOrientation spec, but only if we think there's any chance of it getting added there anytime soon. Given that no drafts, to my knowledge, has been published for a DeviceOrientation v2, that does not seem to be the case. Anyway. I am not convinced that adding new properties will really fix how developers handle this. I asked around and it seems that native platforms do not expose Device Orientation relative to the screen. I am not sure why we should expose something different on the Web platform. I don't think the fact that other platforms do not supply screen relative orientation events is a strong technical argument for why we shouldn't. I'm definitely in favor of looking at what other platforms do, but not with the mindset that what other platforms do is the right thing to do, but rather to see if they have good solutions that we could learn from. Surely other platforms will make design mistakes, just like we do. I think we should work on providing developers the right tools in order for them to do the right thing. I totally agree with this. For all the use cases that I can think of for getting the coordinates relative to the screen is more important than relative to the device. This includes: * A navigation page which shows a map as well as how the device is oriented relative to the map. * A navigation page which shows a map orientated so that the on-screen map matches real world. * A game where an in-game character is controlled by tilting the device left and right to make the character walk left vs. right. I'm sure there are use cases where you need to know the orientation relative to the device rather than relative to the screen, they just seem to be less common to me. Given that, the right tool seems to be to provide the DeviceOrientation events relative to the screen and allow them to be compensated to be relative to the device if needed. Sadly it's too late for that. Authors already have the wrong tool as a default since the DeviceOrientation spec is written and implemented the way it is. However we can at least give authors the right tool as well, by introducing screeAlpha etc. For example, without the Screen Orientation API, they do not know the relative angle between the device natural orientation and the screen. This API is not yet widely available. Some version of it ships in Firefox and IE but is prefixed. It should be in Chrome Beta soon. I don't think the right tool to do the right thing in this case means give them coordinates in a coordinate system that they don't want, and then give them enough information to transform the coordinate into the coordinate system that they do want. I'm not arguing that we remove the relative angle that's in the spec right now. I'm arguing that for device orientation events, we should provide coordinates relative to the screen as well. This topic was filed as an issue against the DeviceOrientation spec in March (https://github.com/w3c/deviceorientation/issues/4). Interest from implementers is a strong indicator to proceed with such spec additions. Active implementer engagement around spec clarifications and additions is quite low right now. / Jonas
Re: Proposal Virtual Reality View Lock Spec
On 26 Mar 2014 08:37, Brandon Andrews warcraftthre...@sbcglobal.net
wrote:
I searched, but I can't find anything relevant in the archives. Since
pointer lock is now well supported, I think it's time to begin thinking
about virtual reality APIs. Since this is a complex topic I think any spec
should start simple. With that I'm proposing we have a discussion on adding
a head tracking. This should be very generic with just position and
orientation information. So no matter if the data is coming from a webcam,
a VR headset, or a pair of glasses with eye tracking in the future the
interface would be the same. This event would be similar to mouse move with
a high sample rate (which is why in the event the head tracking and eye
tracking are in the same event representing a user's total view).
interface ViewEvent : UIEvent {
readonly attribute float roll; // radians, positive is slanting the
head to the right
readonly attribute float pitch; // radians, positive is looking up
readonly attribute float yaw; // radians, positive is looking to the
right
readonly attribute float offsetX; // offset X from the calibrated
center 0 in the range -1 to 1
readonly attribute float offsetY; // offset Y from the calibrated
center 0 in the range -1 to 1
readonly attribute float offsetZ; // offset Z from the calibrated
center 0 in the range -1 to 1, and 0 if not supported
readonly attribute float leftEyeX; // left eye X position in screen
coordinates from -1 to 1 (but not clamped) where 0 is the default if not
supported
readonly attribute float leftEyeY; // left eye Y position in screen
coordinates from -1 to 1 (but not clamped) where 0 is the default if not
supported
readonly attribute float rightEyeX; // right eye X position in screen
coordinates from -1 to 1 (but not clamped) where 0 is the default if not
supported
readonly attribute float rightEyeY; // right eye Y position in screen
coordinates from -1 to 1 (but not clamped) where 0 is the default if not
supported
}
Then like the pointer lock spec the user would be able to request view
lock to begin sampling head tracking data from the selected source. There
would thus be a view lock change event.
(It's not clear how the browser would list which sources to let the user
choose from. So if they had a webcam method that the browser offered and an
Oculus Rift then both would show and the user would need to choose).
Now for discussion. Are there any features missing from the proposed head
tracking API or features that VR headsets offer that need to be included
from the beginning? Also I'm not sure what it should be called. I like
view lock, but it was my first thought so head tracking or something
else might fit the scope of the problem better.
Some justifications. The offset and head orientation are self explanatory
and calibrated by the device. The eye offsets would be more for a UI that
selects or highlights things as the user moves their eyes around. Examples
would be a web enabled HUD on VR glasses and a laptop with a precision
webcam. The user calibrates with their device software which reports the
range (-1, -1) to (1, 1) in screen space. The values are not clamped so the
user can look beyond the calibrated ranges. Separate left and right eye
values enable precision and versatility since most hardware supporting eye
tracking will have raw values for each eye.
Hi,
I published an article today that explains how we can build VR experiences
in today's web browsers on top of the deviceorientation event:
http://dev.opera.com/articles/view/w3c-device-orientation-usage/
There's also a simple VR demo available @
http://people.opera.com/richt/release/demos/orientation/virtualreality/.
Let me know if you see anything missing from there. A lot of what you are
requesting may be best left up to fully-featured 3D frameworks.
- Rich
Re: [widgets] Does anyone still care about Widget Updates?
On May 14, 2013, at 11:00 PM, Marcos Caceres w...@marcosc.com wrote: On Tuesday, 14 May 2013 at 14:32, Arthur Barstow wrote: Scott indicated [1] Wookie implemented Widget Updates and Chaals indicated [2] he would followup with Opera but I couldn't find a response from them in the list archive. Do we have two (complete?) implementations of the spec? Opera, Richard? It's not clear to me if we should drop this spec (i.e. publish as a WG Note) or if there are sufficient resource commitments to continue to advance it along the REC track. Marcos - what is the status of the test suite http://dev.w3.org/2006/waf/widgets-updates/test-suite/? (The Implementation Report doesn't look good http://dev.w3.org/2006/waf/widgets-updates/imp-report/.) -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0256.html [2] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0261.html Unless someone else wants to take this, I suggest we just publish as a note. Publishing this as a WG note works for me. - Rich
[File API] Blob URI creation
Hi, Right now we call window.URL.createObjectURL to obtain a Blob URI. As a developer I'd like Blob URI creation functions to hang off the Blob interface directly making things a bit simpler and more intuitive. It seems like we could be far less verbose in Blob URI creation by making a Blob.url method that would return a new, unique, one-time only Blob URI at all times. That means we won't have long-lived Blob URIs living in a document and developers won't need to call revokeObjectURL on Blob URIs obtained in this way. The first time any resulting Blob URI is dereferenced then user agents would automatically revoke the associated Blob URI, preventing reuse elsewhere. If the web app needed a new Blob URI to use elsewhere they would call Blob.url again to obtain a new, unique, one-time only Blob URI. It's not obvious that we should let Blob URIs hang around indefinitely or make developers responsible for calling revokeObjectURL manually. Since the creation of a Blob URI seems to have relatively little overhead, it seems reasonable that we could create a new Blob URI each time .url is called. I wrote a quick Blob.url shim that should help to demonstrate this proposal: http://jsfiddle.net/MV233/ The same addition would apply for MediaStream (i.e. MediaStream.url) though the spec says createObjectURL only takes a Blob object at the moment (which seems wrong but that is what I'm working to). This API method could alternatively be called .getURL or .createURL. The method does return dynamic content and it does seem to act more like a method than an attribute so that would make sense IMO. At best this would be a replacement for window.URL.createObjectURL. At worst, it's a convenient shortcut for developers to creating and using no-nonsense Blob URIs. -- Rich Tibbett Opera Software ASA
Re: [File API] Blob URI creation
On May 30, 2012, at 6:55 PM, Glenn Maynard gl...@zewt.org wrote: On Wed, May 30, 2012 at 11:09 AM, Rich Tibbett ri...@opera.com wrote: The first time any resulting Blob URI is dereferenced then user agents would automatically revoke the associated Blob URI, preventing reuse elsewhere. If the web app needed a new Blob URI to use elsewhere they would call Blob.url again to obtain a new, unique, one-time only Blob URI. I'm not sure if you've followed the other threads, but the release on first use (oneTimeOnly) approach is broken; I hope nobody else is implementing that. (I don't know why it's in the spec; it's a poor, error-prone interface, and it's inherently not interoperable.) The release at the next stable state (autoRevoke) approach is much more sane. Yes, this might be a better solution. I was working on what was available in the editor's draft and looking for a way to remove the need to ever call revokeObjectUrl. That is, you shouldn't ever have to pass a Blob URI obtained via Blob.getURL through revokeObjectUrl because it assumes some auto-revocation behavior. Using microtasks to release at the next stable state does seem ok as long as developers have a very good understanding of when a Blob URI will be implicitly revoked. Saying that you can use a Blob URI exactly once, as per onetimeonly could still end up being easier to understand though.
Re: Is BlobBuilder needed?
Jonas Sicking wrote: Hi everyone, It was pointed out to me on twitter that BlobBuilder can be replaced with simply making Blob constructable. I.e. the following code: var bb = new BlobBuilder(); bb.append(blob1); bb.append(blob2); bb.append(some string); bb.append(myArrayBuffer); var b = bb.getBlob(); would become b = new Blob([blob1, blob2, some string, myArrayBuffer]); or look at it another way: var x = new BlobBuilder(); becomes var x = []; x.append(y); becomes x.push(y); var b = x.getBlob(); becomes var b = new Blob(x); So at worst there is a one-to-one mapping in code required to simply have |new Blob|. At best it requires much fewer lines if the page has several parts available at once. And we'd save a whole class since Blobs already exist. Following the previous discussion (which seemed to raise no major objections) can we expect to see this in the File API spec sometime soon (assuming that spec is the right home for this)? This will require a coordinated edit to coincide with the removal of BlobBuilder from the File Writer API, right? Thanks, Rich / Jonas
Re: [DRAFT] Web Intents Task Force Charter
N.V.Balaji wrote: - From: timeless timel...@gmail.com Sent: Friday, November 11, 2011 3:23 AM To: Marcos Caceres w...@marcosc.com; public-webapps@w3.org; public-device-a...@w3.org Subject: Re: [DRAFT] Web Intents Task Force Charter Anyway, to your underlying question: Android Intents and I believe some of the web Intents proposals have two forms: 1. Fire and forget (mailto:, outbound video/audio/document) 2. Establish bidirectional communications link I see two variants here. Simple request-response case (contact picker) and a continuous dialog case. I am wondering should all intents expose some UI. Can they just expose a URL and allow the caller to use those URLs with XHR or EventSource. So this was the exact concept behind our earlier proposal for Discovery: http://people.opera.com/richt/release/specs/discovery/Overview.html At this point it would be beneficial to focus on how Web Intents can solve this problem rather than pushing two similar-but-slightly-different proposals. It doesn't necessarily need to expose that particular abstraction (i.e. HTTP URLs) if we can get a similar persistent data flow going via the Intents model. It does help to set expectations early though and we should discuss further when the TF starts up. Seems we're all keen to get going. - Rich
Re: [DRAFT] Web Intents Task Force Charter
Hi Robin, all, Robin Berjon wrote: Hi all, here is a draft of the Intents joint Task Force charter for comments from WebApps and Device APIs. A TF charter is nothing formal and requires no overhead — it can live as an email in a mailing list, it just documents the existence of the TF, and gives a few indications as to how it works. I've added some notes below about the points that may be contentious. If no one screams bloody murder by Monday I'll ask the Team to set things up. It's short but we've discussed this together last week, and DAP intends (no pun, err, intended) to rely rather heavily on Intents so we'd rather move fast rather than wait for WebApps to recharter, which could take a few months. The Web Intents Task Force works on a joint deliverable of the WebApps and Device APIs WGs that aims to produce a way for web applications to register themselves as handlers for services, and for other web applications to interact with these through simple requests brokered by the user agent (a system commonly known as Intents, or Activities). The mailing list on which the TF's discussions take place is public-inte...@w3.org. The chair is Robin Berjon. Operational modalities such as whether or not to have phone and/or face to face meetings, as well as where to store the draft document are left to the TF to decide for itself. Decisions are made by consensus inside of the task force and do not require separate ratification by the wider groups. It is important to note that until such a time as the WebApps WG is rechartered with Intents in its list of deliverables, it will be necessary for participants in WebApps who are not in Device APIs and wish to make substantive contributions (just joining the discussion and providing comments is always fine) to make an RF commitment for this deliverable (not necessarily for other DAP deliverables, naturally). For more details on this, please contact the W3C Team. ISSUES: • The description isn't terribly precise, but I think it works • As I've said before, I am only putting myself forward as chair because so far no one else stepped up. I don't mind doing it, but I equally don't mind letting someone else do it. I don't expect it to be a very demanding position. WDYT? Opera would like to explore Local Device and Local Network Discovery as a subset of Web Intents. At this point, having studied the Web Intents proposal, we're unclear how this would work considering that: a.) to register a URL endpoint as an intent provider the user must visit a web page (presumably hosted by the target device itself) and capture the intent registration from that page before that intent provider can be used within the UA. WHAT WE ACTUALLY WANT: to enable auto-discovery and auto-registration of local device services and locally networked device services to the point that the user doesn't need to go out and register local devices and services upfront. When a user requests a particular service, they can then directly choose a device that implements the requested service rather than having to go through the indirection of searching out, navigating to and registering each intent provider first. b.) to then subsequently use a registered intent provider the concept is to open that provider, again as a web page in a seperate tab within the UA. From here we can then establish a bi-directional web messaging channel on which we can send and receive messages to communicate to and from that web page that is representing the current local service. WHAT WE ACTUALLY WANT: to communicate transparently with a locally-connected service (after user authorization has been established), without requiring that service to manifest itself as a web page in a new browser tab. We'd also like to speak the protocol (web sockets, http, etc) that the device currently supports. My assumptions on Web Intents above may be incorrect. I'd appreciate some clarification if this is the case. Perhaps someone could take the time to describe exactly how a user could communicate with an existing TV device in their home from a web browser supporting web intents based on the above requirements? br/ Rich
Re: [DRAFT] Web Intents Task Force Charter
Dominique Hazael-Massieux wrote: Le jeudi 10 novembre 2011 à 16:27 +0100, Rich Tibbett a écrit : Hi a.) to register a URL endpoint as an intent provider the user must visit a web page (presumably hosted by the target device itself) and capture the intent registration from that page before that intent provider can be used within the UA. My understanding is that this is not a MUST at all, but the way Web-based services can be added by a user. For a local network approach, my take would be that the browser would be doing the discovery, and possibly offer the user to add local services to the list of available providers when such a service matches the requested intent. Typically, a gallery intent (i.e. requesting a list of medial files) would make the browser list local media galleries (from UPnP) in addition to the registered Web services (e.g. your on-line photo albums). This works for me. b.) to then subsequently use a registered intent provider the concept is to open that provider, again as a web page in a seperate tab within the UA. From here we can then establish a bi-directional web messaging channel on which we can send and receive messages to communicate to and from that web page that is representing the current local service. I think the Web-page-in-a-separate tab is also an optional aspect of Web intents; the browser could serve as a broker between the local-network service and the Web page. This is unclear but I hope we end up with something that provides non-tabbed (direct) interaction also. In some cases it may be superfluous to have a separate window open that denotes the service endpoint. Perhaps someone could take the time to describe exactly how a user could communicate with an existing TV device in their home from a web browser supporting web intents based on the above requirements? Here is a rough sketch: * user hits a Web page that wants to load a picture from his gallery * that Web page asks for an intent for media gallery * the browser shows to the user the list of services that can provide media galleries; having detected that there are such services on the local network, it includes these services in the list * the user wants to pick a picture from the gallery hosted on his TV, so picks the TV set in the list of services * from then on, the browser turns the messages sent by the Web page via postMessage() into UPnP requests that the TV set can respond to, and also turns the responses into messages that the Web page can deal with. This also has the potential of working. We might need to allow a web page to perform pass-through messaging in the format it wants. If we have a bi-direcitonal channel between a service endpoint and the user agent then I guess we could push whatever we needed over that (e.g. json, protobufs, key/value sets, xml, etc)...or the UA could abstract some of that away if we could find a reasonable model for that. Dom Thanks for the quick reply and good to ensure this stuff gets captured in the TF charter. As Chaals said, let's get going on this. The concept of Web Intents is great and we're not married to any particular proposal at this point. We can see if it works for our UCs when the task force kicks off. - Rich
Re: Adding Web Intents to the Webapps WG deliverables
Arthur Barstow wrote: [ + DAPI Chairs and Team Contact ] Hi Ian, All - for now, I think it is OK to use public-webapps for *technical* discussions regarding James' proposal. Let's plan to continue the charter-related part of this discussion during WebApp's TPAC meeting. I added it to the Monday October 31 13:00-15:00 time slot: http://www.w3.org/2008/webapps/wiki/TPAC2011#Agenda_Monday.2C_October_31 (FYI, Robin added a Merge DAP into WebApps, proposed by Robin Berjon topic ins this same time slot.) Robin is proposing an interesting idea. Perhaps we could form a sub-group in WebApps to work on Device related features. Exactly what device-related features get picked up would be at the discretion of those involved. The options at this point are a.) None b.) some or c.) all of the deliverables of DAP transferring over to a group that has more comprehensive IP exclusion coverage. It would be a lot easier if everyone joined the DAP WG instead but I feel we're going nowhere with that approach. - Rich
Re: [widgets] Killing file:// of evil (widget URI ready for pub)
Marcos Caceres wrote: I've updated the Widget URI scheme spec, and it's now ready for publication as a new WD. Link for others is: http://dev.w3.org/2006/waf/widgets-uri What's new? I completely rewrote it. Now defines a dereferencing model that fakes HTTP responses (so hopefully now will work with JQuery mobile + XHR). This has some fairly wide-reaching applications so thanks! As always, comments welcomed Some quick comments from first reading: 1. I wonder if the spec should also cover 'Relative URI Reference Resolution' as per the previous spec? Some examples for that would also be useful. 2. In the spec, the term 'synthesizing' is not defined. What does this section mean? 3. Do we need to be explicit on the mapping of widget uri components to window.location? Thanks, Rich
Re: Adding Web Intents to the Webapps WG deliverables
Ian Hickson wrote: Why not just improve both navigator.registerContentHandler and navigator.registerProtocolHandler? http://groups.google.com/group/web-intents/browse_thread/thread/3dff7c2cdf5815b8 I tend to agree with rolling this in to RCH and RPH and seeing if we could refine the processing algorithms therein to satisfy the security issues highlighted in that thread (i.e. ensuring the cross document messaging channel setup from a window.open with a registered protocol handler is origin bound).
[proposal] Local-Networked Service [Discovery and] Messaging API
not represent the consensus of any standards group and should not be referenced as anything other than an unofficial draft which is a work in progress. Best regards, Rich Tibbett [1] http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions#Use_Cases
Test suites and RFC2119
RFC2119 'Key words for use in RFCs to Indicate Requirement Levels' defines the keyword 'SHOULD' as: This word, or the adjective RECOMMENDED, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Generally, I think we can agree that anything less than MUST or MUST NOT requirements in a spec are pretty useless when it comes to conformance testing. We try to write specs to these keywords but other keywords tend to creep in to most specifications. We currently define tests in test suites for SHOULD requirements. A problem occurs when those tests are used to gauge the overall compliance of an implementation to the full test suite. An implementation could theoretically be 100% compliant without needing to pass non-MUST and non-MUST NOT tests. Perhaps we should introduce 'bonus' points for SHOULD/SHOULD NOT/MAY and RECOMMENDED tests and not have them contribute to overall compliance output, thereby allowing implementations to claim 100% compliance to MUST/MUST NOT tests. An implementation can then optionally collect any available, optional bonus points as available from requirements marked up with other keywords. Wondering if there is any set W3C thinking on this or a way of including SHOULD tests in test suites but clearly indicating that they are, basically, optional and do not count towards the overall compliance score? I couldn't find anything in [1]. - Rich [1] http://www.w3.org/TR/test-methodology/
Re: [widgets] Plan to get Widget Updates LC ready?
Arthur Barstow wrote: Richard, Marcos - what is the plan to get Widget Updates spec LC ready (see [1] for LC requirements)? http://dev.w3.org/2006/waf/widgets-updates/ I think Marcos wanted to have a pass over the spec. We didn't receive much feedback on the previous Working Draft and we've since implemented this for Opera Extensions. I'm happy to push this to LC pending Marcos' review. - Rich
Re: [widget] technology/specification name
Marcos Caceres wrote: On Fri, Jun 24, 2011 at 1:28 AM, Charles Pritchardch...@jumis.com wrote: One issue which comes up is that widget is also used in ARIA to describe ui elements. I suspect we'll see apps used ubiquitously; widget seems to e reserved to early experiments in linked apps; apps via iframe. Like many on this thread, I don't have a strong objection against the name. I rather appreciate the thread, it's bringing out more distinctions as to what we're talking about and targeting. Lets just change it to Packaged Web Apps. Agreed. I'd couple that with the short-hand term 'web package'.
Re: [Widgets] URI spec needs HTTP responses and dereferencing model
On Thu, Jun 9, 2011 at 1:29 PM, Marcos Caceres marcosscace...@gmail.com wrote: Hi, The current widget URI spec does not work with XHR and hence can't be used with popular JS libraries like JQuery Mobile. This makes the URI scheme basically useless for a massive number of use cases. Oops :) To fix it, the widget URI spec needs to respond with HTTP responses when a URI is dereferenced... similar to what blob:// does: http://www.w3.org/TR/FileAPI/#processingModel Are there are any plans to undertake a Provisional (or Permanent) URI Scheme Registration for the widget URI? [1] The guidelines and procedures of that process seem to form a handy general checklist for minting URI schemes and should be capable of catching idiosyncrasies such as this. Perhaps we should get the widget URI proposal peer reviewed by the W3C URI IG [2] and, perhaps, the IETF HTTP WG [3] before publication also. I mention this since you mention the blob URI scheme. That has recently been making the rounds on both of the listservs mentioned above resulting in some interesting discussions. - Rich [1] http://tools.ietf.org/html/rfc4395 [2] http://www.w3.org/2001/12/URI/ [3] http://datatracker.ietf.org/wg/httpbis/charter/ -- Marcos Caceres http://datadriven.com.au
Re: Request for feedback: DOMCrypt API proposal
I wonder whether the problem is actually just one of generating
sufficiently cryptographically secure PRNGs or whether there are real
benefits to creating a full-blown UA-based Crypto API and the can of
worms that might open.
There was a proposal on the WHATWG back in February for producing a
cryptographic pseudo-random number generation API (ala the NS4
window.crypto.random API IIRC) within browsers [1].
A 2009 Stanford white paper entitled 'Symmetric Cryptography in
Javascript' [2] detailed a number of optimizations to make symmetric
cryptography performant in pure-Javascript (i.e. maximizing
precomputation, loop unrolling, bitslicing). There is an implementation
available at [3]. The paper concluded by saying that one of their
biggest problems was finding a way to generate enough cryptographic
randomness in the browser for key generation - other than that their
solution is quite performant.
So would window.crypto.random allow performant symmetric and asymmetric
cryptography to be written in pure JS? It would be good to see some
benchmarks between JS and Native around SHA256 and SHA512 key generation
(for example) to really understand the performance benefits that this
API could bring.
Other than that, it's still a very rough proposal but it could be
interesting pending some performance benchmark data (or details of
additional benefits that this proposal brings) :)
- Rich
[1]
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/030241.html
[2] http://crypto.stanford.edu/sjcl/acsac.pdf
[3] http://crypto.stanford.edu/sjcl/
David Dahl wrote:
Hello public-webapps members,
(I wanted to post this proposed draft spec for the DOMCrypt API (
https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest ) to this list
- if there is a more fitting mailing list, please let me know)
I recently posted this draft spec for a crypto API for browsers to the whatwg
(see: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031741.html)
and wanted to get feedback from W3C as well.
Privacy and user control on the web is of utter importance. Tracking,
unauthorized user data aggregation and personal information breaches are
becoming so commonplace you see a new headline almost daily. (It seems).
We need crypto APIs in browsers to allow developers to create more secure
communications tools and web applications that don’t have to implicitly trust
the server, among other use cases.
The DOMCrypt API is a good start, and more feedback and discussion will really
help round out how all of this should work – as well as how it can work in any
browser that will support such an API.
This API will provide each web browser window with a ‘cipher’ property[1] that
facilitates:
asymmetric encryption key pair generation
public key encryption
public key decryption
symmetric encryption
signature generation
signature verification
hashing
easy public key discovery via meta tags or an ‘addressbookentry’ tag
[1] There is a bit of discussion around adding this API to window.navigator or
consolidation within window.crypto
I have created a Firefox extension that implements most of the above, and am
working on an experimental patch that integrates this API into Firefox.
The project originated in an extension I wrote, the home page is here:
http://domcrypt.org
The source code for the extension is here: https://github.com/daviddahl/domcrypt
The Mozilla bugs are here:
https://bugzilla.mozilla.org/show_bug.cgi?id=649154
https://bugzilla.mozilla.org/show_bug.cgi?id=657432
Firefox feature wiki page:
https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI
You can test the API by installing the extension hosted at domcrypt.org, and
going to http://domcrypt.org
A recent blog post updating all of this is posted here:
http://monocleglobe..wordpress.com/2011/06/01/domcrypt-update-2011-06-01/
The API:
window.cipher = {
// Public Key API
pk: {
set algorithm(algorithm){ },
get algorithm(){ },
// Generate a keypair and then execute the callback function
generateKeypair: function ( function callback( aPublicKey ) { } ) { },
// encrypt a plainText
encrypt: function ( plainText, function callback (cipherMessageObject) ) {
} ) { },
// decrypt a cipherMessage
decrypt: function ( cipherMessageObject, function callback ( plainText ) { }
) { },
// sign a message
sign: function ( plainText, function callback ( signature ) { } ) { },
// verify a signature
verify: function ( signature, plainText, function callback ( boolean ) { } )
{ },
// get the JSON cipherAddressbook
get addressbook() {},
// make changes to the addressbook
saveAddressbook: function (JSONObject, function callback ( addresssbook ) {
}) { }
},
// Symmetric Crypto API
sym: {
get algorithm(),
set algorithm(algorithm),
// create a new symmetric key
generateKey: function (function callback (
Re: [widgets] Widget Updates tests?
Scott Wilson wrote:
Just one more thing...
Test ta-processing2-14, Tests that update-info element's src attribute need to be
valid, else it is ignored. The widget is not updated or replaced.
However, the value to fail with is fail.wgt which ought to be interpreted as
a relative URL, in which case the expected result would be to turn this into:
http://people.opera.com/harig/wupdres/resources/fail.wgt
Which is valid.
So, the test needs to have a different value to be an invalid src attribute.
Missed this one - it has been fixed and the src attribute has been set
to an invalid IRI (':') as required.
- Rich
Re: [widgets] Widget Updates tests?
Scott Wilson wrote: Right, I've done some basic work on the tests in Apache Wookie - most of them seem to work OK so far; I need to do interactive testing next - I've tested processing the update element in config.xml and acquiring and validating the UDD, but not actually processing the updates. However there are some issues I've found so far: Test ta-preparation1-8 This fails to parse as a valid widget as the XML isn't well-formed Test ta-processing2-3 I get a content type of text/html when getting the UDD Test ta-processing2-7 I get an error of the UDD XML not being well-formed Test ta-processing2-9 I get a content type of text/html when getting the UDD All the above tests have been fixed. Test ta-processing2-16 We throw a UDD parse exception when a UDD has a relative URL for the src attribute, but the test seems to assume you just silently fail to update the widget? The processing in this case was underspecified in the spec. I've updated the specification to allow for relative URLs to be included in the 'src' attribute. The resolution system for relative URL src attributes to absolute valid IRIs has also been included in the spec (i.e. resolve relative URLs relative to the UDDs IRI). Relative URLs are not allowed in the update-description element of a widget's config.xml. We've therefore replaced ta-processing2-16 test with a test to check that the resolution of src attribute relative URLs is working correctly. Test ta-processing2-19 I get a content type of text/html when getting the UDD Test ta-processing2-20 I get a content type of text/html when getting the UDD These tests have been fixed. HTH, Rich
Re: [widgets] Widget Updates tests?
Arthur Barstow wrote: Thanks for the update Richard. Is this spec ready for LCWD publication? If not, what remains to be done before it is LC-ready? Opera is happy for this specification to proceed to LCWD. I believe Marcos wanted to take a pass over the spec so I'll leave him to inform the group on those plans. Marcos, if we aim for LCWD in 2-3 weeks will that be OK? Also, I would appreciate any implementation data you can share so we can update [1] I've updated the wiki with a placeholder for Widget Updates. At Opera we've implemented this specification for Opera Extensions. We'll be uploading Opera's test results shortly. Since the bulk of the specification is relatively new (~6 months), Opera Widget Updates do not currently implement this specification but use a proprietary update mechanism. If others have any implementation support to add I hope they will let us know so we can improve the spec as required. Thanks, Rich [1] http://www.w3.org/2008/webapps/wiki/WidgetImplementation
[widgets] Widget Updates
We've been working on getting the Widget Updates specification in to publication shape over the last few weeks and it would be good to get further review of the current specification with a view to pushing it to Last Call. The latest draft of this specification can be found here: http://dev.w3.org/2006/waf/widgets-updates We've added the ability for developers to signal that their widget is at end-of-life, signalling to the user agent to disable and/or uninstall the widget when an 'HTTP 410 Gone' message is received in response to querying the Update Description Source for a new Update Description Document. This response can optionally contain the Update Description Document indicating the reason for end-of-life within the details tag for the user agent to display or log as required. All feedback is welcome on this list. - Rich
Re: [widgets] Widgets Updates
On 14/08/2010 03:12, Bernard Traversat wrote: Should we have a more explicit way to specify and notify users that some updates may require data conversion and user data will be converted after the widget is updated? Due to the error-prone nature of such conversion, users may want to back up their data before proceeding with an update. I'm not sure I understand what you mean. User data is not stored in a widget package itself. An update to an existing widget should be able to access the storage space used by previous versions of the same widget. If data conversion is required perhaps you have a use case we could look at. Regards, Rich
[widgets] Widgets Updates
Over the last few days I've been updating the Widgets Updates specification with Marcos. The latest editor's draft is available here: http://dev.w3.org/2006/waf/widgets-updates/ Please review and propose any input or feedback on the mailing list. This draft does not assume consensus of the working group on the material at this point. Kind regards, Rich -- Rich Tibbett Opera Software
[widgets] Widgets Updates
Over the last few days I've been updating the Widgets Updates specification with Marcos Cáceres. The latest editor's draft is available here: http://dev.w3.org/2006/waf/widgets-updates/ Please review and propose any input or feedback on the mailing list. This draft does not assume consensus of the working group on the material at this point. Kind regards, Rich -- Rich Tibbett Opera Software
HTML Device element status
I realize that the HTML Device element [1] is still in its infancy but should the scope of this spec be modified to integrate with other APIs as proposed here: http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0026.html ? The proposed device element seems like the most logical fit for such a non-form-based control - Any extensions to input type=file would invoke a file picker which AFAICS would not make for an ideal UX for non-file-specific information interaction. Rather than getting in to the UI/UX of the device element, the ability to pass parameters to any resulting device control would open up a ton of possibilities. I know first hand that we don't deal in roadmaps, but should we assign some priority to fleshing out such a fundamental element as device? Many thanks, Richard [1] http://dev.w3.org/html5/html-device/
HTML Device element status
I think I'm asking this question in the wrong place and so I'm re-posting to the more appropriate public-html-comments list. ** Please be sure to remove public-webapps@w3.org from any replies to avoid cross-posting ** - Richard On Tue, Jul 6, 2010 at 12:41 PM, Rich Tibbett rich.tibb...@gmail.comwrote: I realize that the HTML Device element [1] is still in its infancy but should the scope of this spec be modified to integrate with other APIs as proposed here: http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0026.html ? The proposed device element seems like the most logical fit for such a non-form-based control - Any extensions to input type=file would invoke a file picker which AFAICS would not make for an ideal UX for non-file-specific information interaction. Rather than getting in to the UI/UX of the device element, the ability to pass parameters to any resulting device control would open up a ton of possibilities. I know first hand that we don't deal in roadmaps, but should we assign some priority to fleshing out such a fundamental element as device? Many thanks, Richard [1] http://dev.w3.org/html5/html-device/
