Re: Status of Selectors API Level 1 Candidate
On Tue, 22 Feb 2011 22:40:34 +0100, Mike Taylor wrote: http://dev.w3.org/2006/webapi/selectors-api-testsuite/003.html I get a 404. http://dev.w3.org/2006/webapi/selectors-api-testsuite/003.xhtml -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] Zip vs GZip Tar
On Wed, 28 Apr 2010 18:48:52 +0200, Gregg Tavares wrote: Has there been any consideration of switching the spec to a stream-able format like gzipped tar files? It seems like a shame to miss this use case. A streamable container, while intriguing, also has issues. For streaming to be of use, you need to specify the order of resources: the widget's configuration file and start file should be the first two files in the resource bundle. Are there readily available (on all major platforms) tools that do this, easily? (Other than that, see timeless' comments about this really being too late for the current spec) -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: CSS WG comments on View Modes Media Feature spec
On Thu, 11 Mar 2010 09:36:19 +0100, Daniel Glazman wrote: - if the current medium (CSS-speaking) is 'projection', does it assume view-mode is fullscreen? What about the other way round? (Opera for instance assumes 'projection' when fullscreen is on) I personally don't think assuming full-screen for projection media is right. While Opera switches to projection on full screen, I could easily see the case for having projection mode turned on in content embedded on web pages, for use cases like slideshare, 280 North, Google Docs presentations. Or for that matter, just keeping whatever media is current when switching to full screen. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] API - openURL security considerations
On Thu, 18 Feb 2010 22:09:00 +0100, Scott Wilson wrote: Hi both, Apache Wookie (incubating) currently implements the widget.openURL method by directly calling the browser's window.open() function - in this example is there anything particularly special about the fact its being called by a widget? Should our implementation do anything extra, or is it better just leaving it to the browser to handle any problems? The way I view this is roughly as follows: 1. window.open() opens a URL within the context of the widget, for instance for the purpose of authenticating a widget using something like oAuth. 2. widget.openURL() is used to pass a URL from a widget to the default protocol handler on a system for any given protocol, for instance to pass a URL from the widget to the web browser on the system, to place a phone call or pass a magnet link to a bittorrent client The underlying difference here is that window.open would retain a reference to the widget, usually through window.opener, while widget.openURL is fire and forget. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: Rechartering WebApp WG
On Thu, 11 Feb 2010 05:40:04 +0100, Doug Schepers wrote: Hi, Folks- Scott Wilson wrote (on 2/9/10 10:32 AM): There are a couple of additional areas it would be useful to consider for future work in the Widgets space, specifically: - inter-widget communication (both single-user and multi-user, e.g. collaboration) I find this item to be interesting and worth taking on, but I think we ought to also evaluate it in a wider context than widgets. Are these deliverables the Widgets folks are willing to take on? If so, are there clear use case & requirements documents, and available editing resources? Scott - you've already implemented and deployed functionality like this in Wookie, right? -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [WARP] Use cases for local network access
On Tue, 02 Feb 2010 19:09:26 +0100, Stephen Jolly wrote: All, As actioned in the 21st Jan teleconference, here are the use cases that have motivated my specific proposal for supporting local network access in the WARP spec (see http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0173.html for details). 1. A developer wishes to write widgets that can connect to the web API exposed by a network-connected television or personal video recorder (aka digital video recorder) on their home network. This API allows (for example) the channel being viewed to be changed or the list of scheduled recordings to be modified, via a user interface presented by the widget. During this teleconference, I was asked to elaborate my position on this topic. The advantage of creating a definition of a local network is the following variant of the use case: A developer wants to write a widget that posts whatever channel the user switches to on a network-connected TV to http://μblogging.example.com/. The problem, with WARP as is that, since the network address of said TV is indeterminate, the developer's only option is to allow the widget to connect to any URL it wishes (specifying '*' in origin, or add a large (read: huge) set of origins in order to be able to do this. My proposal would be to add a second attribute to the specification, a boolean, such as origin-local, which would replace any IP address the user agent considers to be local, link-local or even local-machine addresses. Alternatively, should fine-grained distinction between the three, these could alternatively be keywords in the existing origin attribute. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
One , multiple resources
This is an excerpt of something I wrote on the #webapps IRC channel: hm I have some exploratory work here (not going into details) let's just say that for feature isn't enough but an example is actually Opera's own Unite (looking a bit further, though) let's say I wanted to spawn two workers, each with their own web service simply speaking, I can't currently, all I can do is: http://xmlns.opera.com/webserver";> The problem is roughly that the param key-value pair is insufficient when a needs to both specify and configure multiple resources, such as one Opera Unite widget configuring two different web services. The example above could only ever load one single service per widget (and it would be what's specified in the widget's element, to boot). A widget which wanted to configure one document per widget would need to nest the 's in something. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [WARP] Extending access to local network resources
On Thu, 21 Jan 2010 12:45:46 +0100, Stephen Jolly wrote: but I think that a "link-local" restriction is a better match to my use cases. I'm wondering if you are able to share a few example use cases, to aid understanding of what you want to achieve. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [WARP] Extending access to local network resources
On Thu, 14 Jan 2010 19:04:18 +0100, Stephen Jolly wrote: There are a very large number of such networks in use worldwide: I believe that the vast majority of home networks and many wireless networks fall into this category. The BBC is specifically concerned that the lack of distinction between local network resources and Internet resources in the current WARP model could prevent widgets from being able to access network resources served from media devices on home networks. Anyway, the specific proposal I would like to make is for another special value of the "origin" attribute of the "access" element in the widget configuration document called "link-local" or similar, an associated special value in the access-request list and an associated processing rule that says that when the "link-local" value is specified, the user agent should grant access to network resources on the same subnet(s) as the user agent. Just so we are on the same page here, by link-local, you mean exactly what (for IPv4) is defined in RFC 3927, which roughly translates to «Two devices connected directly, without involvment of DHCP» - a.k.a. 169.254.0.0/16? 2. Users are likely to want control over which specific networks a widget is granted access to, rather than just a blanket "yes" or "no" permission to access whatever local network(s) to which the host may be connected when the widget is running. I don't think that this is something that can or should be dealt with in the configuration of widgets. I believe that good user experiences can be constructed to give the user that control, but I won't go into detail unless somebody asks me to. I don't think going into detail is necessary at this stage. 3. I would expect most *useful* widgets that can access local network resources to need some kind of ability to browse the local link for resources to access. Again, I think that's out of scope for a WARP alteration/supplement; it's the sort of thing people use mDNS + DNS-SD or UPNP's SSDP for, but those aren't web protocols, and Robin's threatened to drag me into the DAP WG if I start talking about device APIs. The mDNS-bit is about local service discovery, and likely belongs in the DAP, yes. 4. Clearly the "local network" and the "local link" are not necessarily the same thing. I'm proposing a solution targeting the latter because (a) it actually has a useful definition and (b) I believe it to be sufficient for the use cases I care about. Provided my understanding of link-local is in line with yours, I would prefer a mechanism for accessing the local network. I look forward to your comments and criticisms - in particular I would like to understand the holes that Arve says are opened by making a distinction between "local" and "remote" IP addresses. To moderate my statement a bit - it's more a concern than a risk, when you at all allow access to "local network", and you have relaxed cross-domain security, a maliciously crafted widget can potentially attack local networking equipment such as routers. (This risk also exists on the web, but is generally less practical, given that an attacker would be shooting blind due to the same-origin-policy) The other problem is one of the definition of local network not being entirely clear - the archetypal definition is the IPv4 one with four reserved IP ranges. That definition breaks for IPv6, and it breaks for networks not using NAT. In order to have a useful definition, the network would have to provide information about the locality of any given host a widget tries to access. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: File API: Directories and System
On Wed, 09 Dec 2009 19:22:08 +0100, Robin Berjon wrote: Note, I'm replying to both lists, but have set reply-to to public-device-apis as discussed in the joint WebApps API - DAP face to face, here is a rough proposal for the Directories and System parts of the File API: http://dev.w3.org/2009/dap/file-system/file-dir-sys.html There are two entry points. One is through navigator.device.fileSystems(), which upon success lists all available FSs. Naturally that only expected to be exposed in trusted environments (like widgets). Some issues: 1. File and Directory are now mutually exclusive through the type attribute of the "Entry" interface. This means that it's impossible to have transparent handling of archive-type files. I would, given Widgets and ODF, at least expect having the ability to support transparent traversal in to .zip files from any specification, and thus rework the proposal into entries of one type, with properties denoting one or the other. 2. This specification should really be one about directory traversal, and I would prefer to see any dependencies on FileReader or FileWriter removed. This implies merging the relevant parts of Directory and FileEntry into one type, namely "Entry". 3. When directory creation is concerned - having to recurse into the directory you want, just in order to create a new file/directory handle is somewhat inconvenient. 4. Dates associated with a file table entry are missing 5. Some (file system) properties of a file (read/write/execute/archive/hidden) are missing 6. There seems to be no error handling when traversing in to directories where the UA has no access. 7. I'm not sure I think the zip() method belongs in this spec at all: It seems fairly arbitrary 8. If zip is to be kept, it needs to apply equally to any entry. It also must be made async, as compression may take a long time. 9. The spec lacks any means to handle invalid file names. Note that doing this is difficult, painful, and not at all consistent across file systems, OSes and implementations. As an example, it's possible to create filenames in Windows that Windows can't later delete. 10. The spec doesn't seem to concern itself with the character encoding of the underlying file system. Intentional, or accident? 11. The spec also lacks a means of handling symbolic or hard links, or junctions 12. The mediaType attribute when creating a new file is superfluous on some systems, or may be in direct conflict with the file name. 13. The spec fails to address the file locking semantics on most operating systems. Note that this problem should ideally be handled over to methods from stream/blob interfaces. Comments are very much welcome, *BUT* it is very much appreciated if they can be made on the DAP's mailing list (public-device-a...@w3.org) rather than here. Further replies directed to public-device-apis -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [WARP4U] WARP with UPnP
On Thu, 03 Dec 2009 12:12:23 +0100, Stephen Jolly wrote: Keeping things simple, the most compelling use case I can see (aka the one I care about...) is where the developer wants to write a widget that can access resources on a network with no centralised DNS or developer-predictable IP addresses. This is the case for many home networks. Through Opera Unite, Opera has a considerable interest in the discoverability of local web services (being agnostic with regards to the definition of "local", and the actual underlying implementation, whether that is called UPnP, m-DNS, or something entirely different). At Opera, we already have (experimental) running code and DOM interfaces for such local service discovery. This spec is not in conflict with the WARP specification, nor does it have dependencies on it. We would be willing to, given some preparation, provide this as input for a new working item. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [WARP4U] WARP with UPnP
On Wed, 02 Dec 2009 13:18:43 +0100, Arthur Barstow wrote: It would be helpful to have a clear definition of at least: the problem statement, use case(s), requirement(s), security considerations, proposed syntax and semantics, UA processing model. I would propose dropping any syntax and semantics, until we have a proper definition of the problem. What are we trying to solve? -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: Use Cases and Requirements for Saving Files Securely
On Thu, 12 Nov 2009 10:59:04 +0100, Jonas Sicking wrote: Like I said, I think this might be possible to work around in the implementation by making sure to neuter all executable files before they go to disk. I'm not sure it's possible to make complete workarounds. In the idealized case, Linux depends on the execute being set. Many desktop users will have wine installed, though, in which case the wine program loader will pick up and execute the file, regardless of any extension. (It can of course be argued that this is a fundamental problem of how wine is set up to integrate with the OS) -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: Rename “File API” to “FileReader API”?
On Wed, 11 Nov 2009 02:47:50 +0100, Maciej Stachowiak wrote: I think file writing (once the script has securely received a file handle) has different security considerations than directory manipulation and opening of arbitrary files. File writing should be designed with the browser security model in mind, because it's something that is reasonable to expose to Web content, given the right model for getting a writable handle (private use area or explicitly chosen by the user via "Save As" dialog) Note that both explicit content and private use areas/sandboxes has security implications. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: Use Cases and Requirements for Saving Files Securely
On Mon, 02 Nov 2009 21:48:58 +0100, Doug Schepers wrote: Please send in use cases, requirements, concerns, and concrete suggestions about the general topic (regardless of your opinion about my suggestion). One concern: There are historical vulnerabilities, such as http://secunia.com/advisories/10968/> wherein a system could be compromised by the user navigating to a folder containing a malicious file, using the system's default file navigator. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: Rename “File API” to “FileReader API”?
On Tue, 10 Nov 2009 10:59:23 +0100, Adam Barth wrote: Which is the proper mailing list to follow development of the file writing API? I'd like to follow it's security considerations. public-device-a...@w3.org -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: HTML extension for system idle detection.
On Thu, 17 Sep 2009 22:13:09 +0200, Frederick Hirsch wrote: 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? This is what I was getting at when asking the question initially: * an employer could use it to determine whether an employee is using his computer or not * ad delivery networks could use it for behavioral tracking and targeting of advertising. Selling a "cure for loneliness" might stick more with someone who spends 16 hours daily in front of an active computer. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: HTML extension for system idle detection.
On Thu, 17 Sep 2009 00:05:58 +0200, 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. What exactly are the security and privacy implications of detecting system idle activity in the browser? -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On Wed, 02 Sep 2009 16:26:19 +0200, Robin Berjon wrote: Reading that thread I don't see a consensus emerging one way or another, and a lot of options appear to be considered that seem to be out of scope (or too close to the metal) for this specification. I see some arguments around using file: that could be used, but none seem to explain how it could be without entirely precluding other file: access (which could potentially be needed) or minting special names (e.g. a special file host), which strikes me as a bad idea. In my opinion, the "file:" protocol needs to be avoided *at all costs*. User agents have, in over fifteen years of trying, not managed to agree on how to implement it interoperably, varying from how to encode drive and host names (on some operating systems) to how you deal with path traversal and content protection issues. Neither have they managed to agree on what "origin" means, or whether it is acceptable to accept active content in this context. We could spend man-years in trying to come up with something "interoperable" and be exactly where we were yesterday. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: Moving alerting methods to DAP (was: Re: [widgets] Draft Minutes from 13 August 2009 Voice Conf)
On Mon, 24 Aug 2009 11:34:18 +0200, Robin Berjon wrote: Given that HTML5 is trying to get to LC within this decade, I doubt they'll accept that. The tendency is more to trim as many things out of the specification as they can find editors to sustain. Arve: I don't think DAP is right, but WebApps is OK if HTML WG doesn't want them Care to detail why? This is a purity-above-all argument, really, hence "think" instead of "does not belong in DAP". Alerting methods are in no way device-specific or device-bound. Nor are they particularily specific to widgets (or HTML5, for that matter). -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: File API to separate reading from files
On Wed, 19 Aug 2009 21:21:54 +0200, Jonas Sicking wrote: I do like the idea of having a stream primitive. I think we'll need that for other things in the future such as reading data from a camera, or reading data from a microphone. I quite concur, and for the widget space, actually writing data is a real use-case. However I'm not convinced that we should force people to use streams to deal with the simple use case of reading data from a file. In 95% (if not more) of the cases the user simply wants to get the contents of the file, and so forcing them to do that using: Does the presence of an IOStream primitive exclude getAs*? -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: Widget Accessibility
On Fri, 14 Aug 2009 12:55:35 +0200, Marcos Caceres wrote: That is, widgets have no real knowledge of HTML, CSS, etc. You can have a fully conforming widget that has no interface at all. Just reiterating this point: Opera Unite [1], while currently using a proprietary manifest format are essentially widgets whose only interface is HTTP. ___ [1] http://unite.opera.com/> -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: Widget Accessibility
On Thu, 13 Aug 2009 19:45:14 +0200, Simon Harper wrote: As far as I can see, the browser is the (JavaScript+HTML) interpreter, therefore a richer accessibility bridge is required, which will not be addressed by ARIA alone. Just to clarify something here: The Widgets P&C specification is agnostic with regards to the underlying technology platform, and does not actually require the content contained within the widget to be web content/applications. If you want to use "Widgets" as a container/packaging format for, say, Windows or Linux applications, you are most certainly free to do so (not that I would recommend it, though). As such, I believe the widget space is the wrong arena to discuss accessibility issues, unless some part of the widget family of specifications directly prohibit accessible applications. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [File API] data URL method
On Thu, 02 Jul 2009 18:38:03 +0200, Jonas Sicking wrote:
On Thu, Jul 2, 2009 at 2:58 AM, Anne van Kesteren
wrote:
I tend to think that if we are going to introduce a URL scheme to point
to file data on the system we should not be adding the data URL method.
As far as I can tell there are no benefits to introducing it as it will
only increase memory usage when used by authors and the uses it has can
be perfectly achieved using the local file URL. Also, the local URL can
be a synchronous API as there is no need to read the entire file
directly and store it all into memory. You only need to return a URL.
I.e. instead of
file.getAsDataURI(
function(dataURL) { img.src = dataURL }
)
you would get
img.src = file.localURL
which is better in many ways and not worse in any way I can think of
(maybe apart from moving the discussion with the TAG regarding a new
URL scheme a little bit ahead).
This would be a more interesting discussion if someone could actually
come up with a spec for localURL :)
Opera's File IO implementation for Widgets and Unite services (Which I
would very much prefer to see unified with this spec, since there is a lot
of overlap) has a concept of "local" URLs which is roughly as follows:
mountpoint://mountpoint-name/path/to/file
Where the path is the relative path from the file object corresponding to
the mountpoint name. The original path is not exposed.
Note that even when selecting just a file, actually having a path
reference is useful, if you at some point want to treat common archive
formats as directories you want to descend in to, for the purpose of
opening resources in for instance ODF or epub format documents.
Mostly it's the lifetime issue that concerns me. How long is such a
URL expected to work, and how do we prevent people from using it
longer than that?
Our initial security context is a bit different from in file upload, but
the lifetime is one of the following:
1. Until unmounted manually, this is probably not a good idea for a file
upload context.
2. Until the document is either destroyed or reloaded. In the context of
file upload, I would assume "until the user navigates away from the
document would be sufficient.
--
Arve Bersvendsen
Opera Software ASA, http://www.opera.com/
Re: [widgets] Please include a statement of purpose and user interaction expectations for
On Tue, 02 Jun 2009 14:57:46 +0200, Henri Sivonen wrote: Please state the purpose of . (That it's for authorizing features that don't participate in the Web-oriented browser security model.) Please include a corresponding UA requirement to obtain authorization from the user for the features imported with . (It seems that the security aspect requires an authorization and doesn't make sense if the dangerous feature are simply imported silently.) As far as I can tell, the spec doesn't currently explain what the UA is supposed to do with the 'feature list' once built. Such authorization may be made in a number of other ways than 'from the user'. A user agent distributor may for instance use signatures on applications to determine that the feature is safe[1] to access. [1] «Safe»: here meaning that an application signed with a particular signature is in compliance with criteria regarding both security and privacy-related concerns. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] Public keys in widgets URI scheme?
On Wed, 27 May 2009 23:09:11 +0200, Adam Barth wrote: Note that "random per-instance origin" here would normally imply that the instance is created exactly once, on installation, instead of a new instance for every invocation, so a widget should keep the origin across invocations. But not across updates? Currently, the update spec is in somewhat of a hiatus, but in my world, updating a widget would preserve its instance identifier. Anything else would be pointless. (I'll answer to the separate bit about preferences tomorrow, but the gist is that it's instance-bound, but not origin-bound) -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] Public keys in widgets URI scheme?
On Wed, 27 May 2009 20:37:53 +0200, Adam Barth wrote: Do widgets not plan to make use of localStorage? This seems useful, for example, in a weather widget, to store the list of ZIP codes that the user wants to see the weather for. This issue is twofold: 1. A widget is simply a packaging for any application, and may use any technology a widget user agent supports, so in that sense, a widget that supports HTML5 should support anything in widget transparently and without workaround. This implies that widgets with underlying support would support HTML5 localStorage 2. The Widgets APIs and events uses the same storage interface as HTML5 localStorage for storing preferences, and as such it is stored (although in this case, the storage is not origin-bound, like in HTML5. With a random per-instance origin, the widget won't be able to access its localStorage from its last invocation. Note that "random per-instance origin" here would normally imply that the instance is created exactly once, on installation, instead of a new instance for every invocation, so a widget should keep the origin across invocations. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On Tue, 26 May 2009 17:38:48 +0200, Jean-Claude Dufourd wrote: 2- the browser will have to resolve the relative URI to an absolute URI because of the DOM spec, hence a possible vulnerability by divulging private information (e.g. actual name of current user in file: URI example of Apple Dashboard widgets) to scripts running in the widget. ... Marcos mentions the widget V2 spec and extensibility as one reason for adopting the proposed URI scheme. I would like to understand how V2 and extensibility could make the URI scheme either seen by the author or exchanged between implementations, or make its absence otherwise imperil implementations. Thanks. The main issue here, I think, is one of being proactive on this front. Given that absolute URIs are required for resolution, and that UA vendors will, unless specified, have to pick a URI scheme of their own, the situation may well arise where they have specified something that would either be insecure (eg. file:), incompatible ( again, file:) or inappropriate (all schemes that fail to make query strings and fragment identifiers useful) -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On Fri, 22 May 2009 21:31:11 +0200, William Edney
wrote:
Arve -
Getting the value of 'src' here using
'document.images[0].getAttribute("src")' should return the relative path.
The Microsoft guys made a big deal out of the fact that IE8 (in IE8
'strict standards' mode) will now properly return the relative path when
'getAttribute()' is used, but the full path (as you state), when the
'property access' version of the call is used. In IE < 8, some extra JS
to determine base path and then relativize the value would be necessary
in those browsers.
What Microsoft is doing here is fairly irrelevant. Gecko, Webkit and
Presto all return the absolute URI for my exact example. What you might
be thinking of is getAttribute, which does return the raw contents of the
attribute, but this is, afaict, not what browsers use to actually resolve
the URI.
Cheers,
- Bill
On May 22, 2009, at 2:22 PM, Arve Bersvendsen wrote:
On Fri, 22 May 2009 20:21:56 +0200, Mark Baker wrote:
I thought he had (somewhat grudgingly) accepted that way (the use of
relative references) forward, as IIRC, the widget: scheme idea was
dropped about that time. Has some new requirement emerged since then
that makes relative references an undesirable option?
The problem here is that no user agent implementation I am aware of
uses 'relative' URIs when resolving nodes. If you provide src="foo/bar/baz.png" /> - they all compose an absolute URI from the
string representing the relative URI, and expose that when you query
for the attribute value, so putting my markup fragment into a document
at the root of http://example.com/:
// The following Outputs <a rel="nofollow" href="http://example.com/foo/bar/baz.png">http://example.com/foo/bar/baz.png</a>
alert(document.images[0].src);
--Arve Bersvendsen
Opera Software ASA, http://www.opera.com/
--
Arve Bersvendsen
Opera Software ASA, http://www.opera.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On Fri, 22 May 2009 19:13:35 +0200, Larry Masinter wrote: What makes a set of widgets "related"? Is there an attack where based on UUID knowledge where two unrelated widgets could somehow appear "related"? What "existing infrastructure for security" are you planning to reuse? Not having to rewrite from the bottom up how XMLHttpRequest works, and is checked in most user agents, as an example (It goes for a lot of other code in DOM). Often, security loopholes are introduced when reusing security infrastructure designed for one context in a way that it wasn't designed for. "thismessage:/" basically didn't allow references outside the package at all. By adding a UUID and alluding to "related" packages as possibly being available, "widget" might become a vector. I'm not saying it is, I'm just saying that getting external review for security mechanisms and assumptions is critical. Larry -- http://larry.masinter.net -Original Message- From: Arve Bersvendsen [mailto:ar...@opera.com] Sent: Friday, May 22, 2009 9:55 AM To: Larry Masinter; marc...@opera.com; public-pkg-uri-scheme; public-webapps Subject: Re: [widgets] Widgets URI scheme... it's bck! On Fri, 22 May 2009 17:29:57 +0200, Larry Masinter wrote: If the widget: scheme is intended for inter-package references then there are security issues with that. If not, then why the UUID? At the time of writing, I do not see them being used for inter-package references (If my understanding equals yours here, as in "references between otherwise unrelated widgets". The UUID? Well, it actually eases implementations a bit, since an implementation can use the UUID as "domain" when requests are made, which actually allows vendors to reuse existing infrastructure for security checks and so on. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On Fri, 22 May 2009 20:21:56 +0200, Mark Baker wrote: I thought he had (somewhat grudgingly) accepted that way (the use of relative references) forward, as IIRC, the widget: scheme idea was dropped about that time. Has some new requirement emerged since then that makes relative references an undesirable option? The problem here is that no user agent implementation I am aware of uses 'relative' URIs when resolving nodes. If you provide src="foo/bar/baz.png" /> - they all compose an absolute URI from the string representing the relative URI, and expose that when you query for the attribute value, so putting my markup fragment into a document at the root of http://example.com/: // The following Outputs <a rel="nofollow" href="http://example.com/foo/bar/baz.png">http://example.com/foo/bar/baz.png</a> alert(document.images[0].src); -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On Fri, 22 May 2009 17:29:57 +0200, Larry Masinter wrote: If the widget: scheme is intended for inter-package references then there are security issues with that. If not, then why the UUID? At the time of writing, I do not see them being used for inter-package references (If my understanding equals yours here, as in "references between otherwise unrelated widgets". The UUID? Well, it actually eases implementations a bit, since an implementation can use the UUID as "domain" when requests are made, which actually allows vendors to reuse existing infrastructure for security checks and so on. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On Fri, 22 May 2009 15:25:40 +0200, Mark Baker wrote: I'm curious to learn where the requirement that "Must not allow addressing resources outside a widget" came from? Can you point to a precedent for such a restriction in any other protocol? I remember TimBL writing something to the effect of "Anywhere you can use a URI, you can use any URI", possibly in his design issues, but I can't find a reference right now. The point here is that the widget URI scheme is only supposed to be used to synthesise an origin so nodes in the DOM can be sensibly resolved for resources inside the package. The reason for choosing a synthetic scheme are: 1. A web (http(s?)) origin will not work, because a widget MAY be distributed over other channels than the web (such as bluetooth, pre-bundled on devices, installed through third-party package managment systems (debian packages/repositories)). 2. Further, (some) widgets might not provide an authorative means of determining the web origin of the widget, if any such origin existed in the first place. 3. A well-behaved widget runtime should provide complete isolation from the underlying operating system, including the layout of the file system 4. It must not be possible for a widget to resolve and reference resources in other widget packages on the same system (The underlying assumption here is that it should not be possible for a widget running on a user agent to determine which other widgets are running or installed on the same system. Points 1/2 pretty much invalidate http as a valid origin, while 3/4 invalidates the use of file: (which also has an entirely different set of compatibility issues between web ua's that I doubt will be resolved anytime soon.) -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] Call for Input: Use Cases and Requirements for Widgets Access Request spec
On Fri, 22 May 2009 11:17:26 +0200, Scott Wilson wrote: [About use-cases and requirements for widgets access requests] Is there a particular preferred format for submitting use cases? Not that I know of, but I would much prefer to see one thread per use-case on this list, so they can be discussed separately, and also discussed as separate items in phone conferences. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widget] Security model
On Tue, 19 May 2009 11:18:36 +0200, Marcos Caceres wrote: > With my "editor" hat on, I would like to propose the following > security model for widgets: > > 1. If no element is used, the application type (e.g., HTML, > Flash, whatever) is responsible for providing the security > context/rules under which the widget runs. For HTML this means that a > widget runs as if you had dragged a HTML file from your hard-drive > into the Web browser. It's at this stage I should point out that "dragged a HTML file from your hard-drive in to the web browser" has no really consistent security model. * Some browsers will restrict XHR (and similar interfaces) to only work for valid subtrees of the top-level document. * Some browsers will also enforce the previous rule for inlines * Some browsers will allow cross-protocol loading of inline resources * Some browsers will restrict this * Other browsers, where the scripting hooks go fairly infinitely deep into the operating system (Hi, MSIE), will disable scripting and active content entirely. It should also be pointed out that there are requirements floating about that basically say "No network access, unless expressly requested by the widgets" > This defers the security problem to HTML5 or whoever wants to make use > of widgets as a packaging format. HTML5 already has to deal with > situation where HTML files are run locally or with a synthetic origin > (think email attachments). This is a cop-out that *will* result in incompatible implementations of widgets, because a security model (including the network access bits of it) is sorely needed. > 2. If is used, then this is an "op-in" to a "widget security > model" and all network activity is blocked by all means (like a > firewall), except those access requests made via element that > have been granted by the UA. Access requests are granted via the UA > security policy, which is outside the scope of the Widgets spec. This would result in widgets that have no use for network access getting access, which may or may not be acceptable on mobile devices. My proposal is roughly: 1. Adopt Opera's prior proposal as a starting model, work out the kinks, and leave this as the default model 2. Opt-in for "external-origin" widgets, which follow the W3C security model. Widgets claiming to use this model, can also easily be embedded on the web, and would work as a "stamp of inline-widget" approval. > I personally think should be removed from Widgets 1.0 and > deferred to Widgets 2.0 once it is properly sorted out. In my opinion: absolutely not, even if it implies delaying Widgets. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] window modes in P&C, was Re: Small question aboutlatestversionof "P&C specs" (11th Mar 2009)
On Mon, 11 May 2009 15:10:57 +0200, wrote:
> I received an email from Arve explaining the possible "spoofing"
> scenario.
Oops. I thought I'd sent that mail to everyone, and not just to Ivan personally.
> He says this, and I think he is right:
>
>> Forgive my ignorance, but... "spoofing attack"? O_o
>
> 1. Widget A is started in "Floating mode"
> 2. Widget A requests, and gets a mode change to "Application mode"
> 3. Widget A creates UI that looks like widget application grid 4. User
> thinks she or he is interacting with the application grid, and starts
> widget B 5. User types sensitive data into what she or he thinks is
> Widget B, while typing into widget A.
>
>
> Given this, I agree with Arve and I think we are fine here.
>
> Regards
>
> ---
> Ivan De Marino
> Orange Labs
> Mobile and Web Software Engineer, R&D UK
> tel. +44 20 8849 5806
> mob. +44 7515 955 861
> mob. +44 7974 156 216
> ivan.demar...@orange-ftgroup.com
>
>
> This e-mail, and any files transmitted with it, is intended only for the
> use of the person/s or entity to whom it is addressed. If you are not
> the intended recipient (or authorised to receive information for the
> intended recipient) you must not use, disclose, copy, print or rely on
> this e-mail. If an addressing or transmission error has misdirected this
> e-mail, please notify the author by replying to this e-mail and delete
> all copies of this e-mail. Thank you.
>
> France Telecom R&D UK Ltd is a company registered in England and Wales
> with company number 4193379. Our registered office is Minerva House,
> Montague Close, London, SE1 9BB.
>
> -Original Message-
> From: Marcos Caceres [mailto:marc...@opera.com]
> Sent: 11 May 2009 13:59
> To: DE MARINO Ivan RD-ILAB-LON
> Cc: ar...@opera.com; public-webapps@w3.org
> Subject: Re: [widgets] window modes in P&C, was Re: Small question
> aboutlatestversionof "P&C specs" (11th Mar 2009)
>
>
>
> On 5/11/09 1:43 PM, ivan.demar...@orange-ftgroup.com wrote:
>> Forgive my ignorance, but... "spoofing attack"? O_o
>>
>
> I guess Arve means click jacking.
>
>> I'll explain the scenario I have in mind:
>> - Widget calls the API "requestModeChange(> desired
>> mode>);"
>> - WUA checks if that mode is valid (the string is valid) and if the
>> WUA "likes" the mode (there could be WUA that supports only
>> "fullscreen", for example)
>> - WUA does a "modechange" on the Widget
>
> would it not be easier to just set the widget.viewMode property? If it
> works, then the mode changes, onModeChange is fired. If it fails,
> nothing happens (or an error is thrown):
>
> function changeMode(aMode){
> widget.viewMode = aMode;
> }
>
> widget.onModeChange = function(){
> ...
> }
>
> changeMode("banana"); //nothing happens
> changeMode("mini"); //nothing happens
>
> What might be useful is an event object that tells you what the window
> mode changed from to... maybe.
>
>> Where exactly you think there could be a "confused UI" or a
> "spoofing"?
>
> I guess a floating widget that mimics another application, or a full
> screen widget that emulates a locked screen asking you to enter your
> username and password.
>
>>
>>
>> ---
>> Ivan De Marino
>> Orange Labs
>> Mobile and Web Software Engineer, R&D UK
>> tel. +44 20 8849 5806
>> mob. +44 7515 955 861
>> mob. +44 7974 156 216
>> ivan.demar...@orange-ftgroup.com
>>
>>
>> This e-mail, and any files transmitted with it, is intended only for
> the
>> use of the person/s or entity to whom it is addressed. If you are not
>> the intended recipient (or authorised to receive information for the
>> intended recipient) you must not use, disclose, copy, print or rely on
>> this e-mail. If an addressing or transmission error has misdirected
> this
>> e-mail, please notify the author by replying to this e-mail and delete
>> all copies of this e-mail. Thank you.
>>
>> France Telecom R&D UK Ltd is a company registered in England and Wales
>> with company number 4193379. Our registered office is Minerva House,
>> Montague Close, London, SE1 9BB.
>>
>> -Original Message-
>> From: Arve Bersvendsen [mailto:ar...@opera.com]
>> Sent: 11 May 2009 12:25
>> To: DE MARINO Ivan RD-ILAB-LON; marc...@opera.com
>> Cc: public-webapps@w3.org
>> Subject: Re: [widgets] window modes in P&C, was Re: Small question
>> aboutlatestversion o
Re: [widgets] window modes in P&C, was Re: Small question about latestversion of "P&C specs" (11th Mar 2009)
On Mon, 11 May 2009 13:14:40 +0200, wrote: > About the "widget requesting a resize", I sent in the past an email to > Arve about something similar but not quite the same: a sort of "request > mode change" or something. This would allow widgets to ASK the WUA for > "mode change". > Any news about that? As I've noted in the past, I don't really think this is a good idea, as the distinction between "floating" and "application" (or whatever we do with this in the end), will result in a confusing UI at best. At worst, we could end with UI spoofing attacks. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: Storage and widgets
On Sat, 25 Apr 2009 20:01:20 +0200, Scott Wilson wrote: > I think perhaps the underlying assumptions may vary according to the > type of UA? > > However, I think even on a single-user O/S (e.g. mobile) or in a > sandboxed user context you would still want to maintain storage of > preferences on a per-instance basis. Correct, and this is what Opera's implementation currently does. In addition, Opera also defines an entirely separate context for every widget, so that cookies or history is not shared between widget instances. For widget storage, we can probably add some prescriptive text to the A&E spec, but I'll have to admit that I'm not at all sure of where to put those other concerns, except in a separate specification. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
public-webapps@w3.org
On Fri, 24 Apr 2009 13:21:15 +0200, Marcos Caceres wrote: >> In that case, it is not a request, so widget.changeMode() >> would be more appropriate, where a user agent MAY choose to not honor >> the request. >> > > If it doesn't, it would throw an exception. Right? I would much prefer that it didn't, were we to specify this, as it would be consistent with other APIs for managing windows and sizes: window.open() never throws, neither does resizeTo|resizeBy|moveTo|moveBy -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
public-webapps@w3.org
On Fri, 24 Apr 2009 12:26:29 +0200, wrote: > Hello guys. > > What would you think of an API for empowering the Widget to "ask for > mode change"? > Something like: > widget.ModeChangeRequest(); > > Of course the WUA can ignore the request. In that case, it is not a request, so widget.changeMode() would be more appropriate, where a user agent MAY choose to not honor the request. It should be noted, however, that this is problematic on device for a number of reasons, given that floating or mini widgets would typically exist on some "desktop" or in an application grid, so these mode changes are problematic from a UX-view (and may as well have a security implication or two) -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: Storage and widgets
On Thu, 23 Apr 2009 20:17:07 +0200, Thomas Roessler wrote: > Guido Grassel is reminding me that the HTML5 storage API keys off > origin. Thy means another wrinkle or the uri scheme/origin discussion. Note that only the instantiations of storage, through the localStorage and sessionStorage, are using origin. The storage interface itself does not, so I do not see any immediate consequences with regards to preferences or any uri scheme discussion. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
New Widgets A&E Editors Draft
We've pushed a new editors draft of Widgets API's and events on http://dev.w3.org/2006/waf/widgets-api/Overview.html>. Notable changes include: * Removed section 5. Resources are URI scheme agnostic, and package-internal URIs are instead expected to use whichever protocol is actually specified * Removed section 6. We instead rely on the Widget interface being instantiated on whatever is considered the "Global" object, whether this is window or something else. * Removed show/hide() as of my earlier mail to the list. * Addressed all red block issues (save the acknowledgments) I would like to push this to a working draft as soon as possible, and have a short editing period before aiming for LC. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
[Widgets A&E] Removing show() and hide()
The show() and hide() methods from the Widgets A&E specification has a lot of potential to be abused, and annoying. In this sense, it should really be hidden behind a definitions, so a User Agent can optionally allow or disallow the feature. With that in mind, I would propose dropping these two methods from A&E, and leave them to later be specified as an extension. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] s on s
On Wed, 18 Mar 2009 23:22:54 +0100, Robin Berjon wrote: I see a limited use case for the sort of example you propose, but I'm nevertheless going to push back against it. One reason is that it can already be described with features, to witness: Getting in to the edge cases here: What if I have an application where falling back to read access is acceptable, if write fails (In other words, failure to adhere to some option is not fatal)? -- Arve Bersvendsen Developer, Opera Software ASA, http://www.opera.com/
Re: [widgets] s on s
On Wed, 18 Mar 2009 16:19:34 +0100, Robin Berjon wrote: On Mar 18, 2009, at 15:38 , Marcos Caceres wrote: It might be good to add an s element on the element to allow options to be set for features using name-value pairs. For example: http://clothing.com/api";> Do you have some examples that involve things that aren't pants? Does this suffice? The intent would be to allow a widget UA to allow native UI for selecting this, not dependent on for instance browseForDirectory(). -- Arve Bersvendsen Developer, Opera Software ASA, http://www.opera.com/
Re: [widgets] Making config.xml mandatory
On Mon, 09 Mar 2009 14:12:38 +0100, Hillebrand, Rainer wrote: Which different security privileges does a widget have in comparison to any other content? Doesn't it depend on a security policy that we do not define in the W3C? While this is not yet defined by the W3C or other organizations, pre-existing implementations do indeed have different privileges: 1. Commonly, widget runtimes may ignore the same-origin policy that browsers have used 2. Some legacy implementations essentially have shell access, and bundle a set of Gnu (or gnu-like) tools 3. Filesystem access 4. Extended device API work is ongoing, such as OMTP's initiative -- Arve Bersvendsen Developer, Opera Software ASA, http://www.opera.com/
Re: [Widgets] APIs and Events preference change
On Mon, 09 Mar 2009 12:20:25 +0100, Arthur Barstow wrote: Arve, On Mar 5, 2009, at 9:14 AM, ext Arve Bersvendsen wrote: After the last F2F in Paris, I spoke to Ian Hickson about the Storage APIs in HTML5, and my understanding is now that his intent is to split this part of the spec into a separate document. This makes it much easier for us to reference an external spec, given that the scope of such a specification is much smaller. One comment I received is: [[ At the moment, there is no way to separate the localStorage for pages that are stored in the same domain and file system is considered one domain. The result is that widgets could see each other's preferences. ]] What are your thoughts on how to change the definition of localStorage? Note that there is a difference between localStorage and Storage. I am assuming that an implementation will place a (different) instance of a Storage interface on the widget.preferences object. This object would not be bound to the same storage instance as window.localStorage, and instead have its origin set to that of the widget (whatever URI scheme or origin we end up with once those issues are resolved), translated: The widget interface would not end up using the same storage area. This already seems to be permitted by the current spec, still residing in HTML5 [1], where there are two separate Storage instances in window.localStorage and window.sessionStorage ___ [1] http://www.w3.org/TR/html5/structured-client-side-storage.html#the-storage-interface> -- Arve Bersvendsen Developer, Opera Software ASA, http://www.opera.com/
[Widgets] APIs and Events preference change
After the last F2F in Paris, I spoke to Ian Hickson about the Storage APIs in HTML5, and my understanding is now that his intent is to split this part of the spec into a separate document. This makes it much easier for us to reference an external spec, given that the scope of such a specification is much smaller. I have updated the spec, currently reflected in http://dev.w3.org/2006/waf/widgets-api/Overview.src.html to be in line with the current state of this future specification. Note that the Storage API as involved here obsoletes the need for the set/getPreference methods, and they are now commented out to reflect this. If the change is acceptable, it should close ACTION-233 and ACTION-313 -- Arve Bersvendsen Developer, Opera Software ASA, http://www.opera.com/
Re: SVG as Widget Icon (was: Request for Comments: Last Call WD of Widgets 1.0: Packaging & Configuration spec; deadline 31 Jan 2009)
On Wed, 28 Jan 2009 19:59:53 +0100, Doug Schepers wrote: On another topic, I would like to use Widgets with pure SVG content, rather than including HTML... I didn't see a clear way to do this, nor was it explicitly disallowed. I'll review the spec more to see if there are problems in this regard. Informational: Opera's pre-P&C-implementation allows widgets in any format that Opera can handle natively, using the widgetfile element [1][2]. Given that the P&C-specification does not explicitly disallow or mandate a content type for the start file, I would expect this behavior to be conformant in an implementation of P&C [1] http://dev.opera.com/articles/view/opera-widgets-specification-1-0-third-ed-2/#xml_widgetfile_element> [2] Should be testable both in Opera 9.6x and the upcoming Opera 10.00 -- Arve Bersvendsen Developer, Opera Software ASA, http://www.opera.com/
Re: [widgets] A proposal on widget modes
On Thu, 22 Jan 2009 14:25:02 +0100, Priestley, Mark, VF-Group wrote: Hi Arve, Thanks for your feedback - I'm glad our thinking is along similar lines. Some responses to your comments below. Some responses below. Note that I have cut parts to which I have no direct answer yet. Application mode is required outside of a mobile context, to differentiate between chromeless (e.g. Opera Widgets/Dashboard/etc) and widgets with OS Chrome (e.g. the Adobe AIR view state model) [MP] We are of course fine with an application mode being defined, we just don't have an opinion on what it should be... From your description we assume it will be as per the floating mode but with chrome? There are some expected differences in behavior. 1. Floating widgets are expected to be draggable from any area of the widget, except where defined by [CSS] to not be draggable. 'Application' Widgets are not expected to exhibit this behavior. 2. Application widgets are expected to be user-resizable, and so authors cannot rely on the widget having any particular viewport size. This makes them behave much more like 'fullscreen' in a mobile context, or like a regular web page in a browser. a.)onModeChange - an event triggered when the widget transitions to a new mode; It needs to be specified _when_ this event is triggered. Is it prior to the mode switch taking place? Is it a DOM event, or a callback. Is it cancellable? [MP] We think that this should be a DOM event that takes place after the switch of modes. Not cancellable. The downside to letting this happen after the mode switch, is that the widget might in this callback want to a.) Only one floating mode widget can have focus. The widget with focus must have the highest z-index; This is in direct conflict with Window behavior on Unix/Linux system, where a window can have a lower z-index than other windows, and still be focused. It is also in conflict with Opera's current desktop widget implementation, where it is possible to push widgets to stick to the desktop and as such be overlaid by other windows. [MP] Good points - so we could instead say something like the last widget that the user interacted with has focus? Would that work? I'm not really sure there is a need to say anything really - because we'd be well into the domain of specifying interaction requirements and behavior of operating systems. -- Arve Bersvendsen Developer, Opera Software ASA, http://www.opera.com/
Re: [widgets] A proposal on widget modes
} } Yes, from my standpoint, this seems to be a good proposal, but we might want to clear it with the CSS working group. -- Arve Bersvendsen Developer, Opera Software ASA, http://www.opera.com/
Re: [widgets] Agenda for 18 December 2008 voice conference
On Tue, 16 Dec 2008 13:01:16 +0100, Arthur Barstow wrote: Below is the draft agenda for the December 18 Widgets Voice Conference (VC). I'm going to have to send my regrets. -- Arve Bersvendsen Developer, Opera Software ASA, http://www.opera.com/
Re: partial signing (Re: ACTION-163)
On Thu, 04 Dec 2008 15:42:46 +0100, Thomas Roessler <[EMAIL PROTECTED]> wrote: Have you considered what the requirements would be for external resources, e.g., scripts sourced through a script tag? That would have to be determined by a security model that applies to the signed package. Opera's implementation could for instance allow: https://good.example.com/script.js"</a>;> ... while it could deny http://bad.example.com/script.js"</a>;> -- Arve Bersvendsen Developer, Opera Software ASA, http://www.opera.com/
b. Action-233 "Research the Widget object's preference attribute to make sure it uses the correct type";
Re: <http://www.w3.org/2008/webapps/track/actions/233> If we are deprecating preferences in favor of HTML5 persistent storage, this action point is irrelevant. -- Arve Bersvendsen Developer, Opera Software ASA, http://www.opera.com/
ACTION-163
Opera's current position is that we do not wish to allow partial signing, as a) Unsigned components in a signed package can always in some way be treated as executable code, and thus it undermines any security model, or forces vendors to implement a much more complex tainting model for the content. b) As for having different signatures for different components: While this is slightly less problematic, it should not fall in under use cases solved for any v1.0 specification, as it also complicates any security model too much at this stage. -- Arve Bersvendsen Developer, Opera Software ASA, http://www.opera.com/
Re: [widgets] Version string
On Mon, 27 Oct 2008 20:11:20 +0100, Jon Ferraiolo <[EMAIL PROTECTED]> wrote: We came up with an approach at OpenAjax Alliance for version strings where the string must begin with N.N (or N.N.N or N.N.N.N) but can contain arbitrary alpha text after the number value. Then we defined how to do numeric comparisons between the leading numeric parts of two different version strings. So, you are allowing something like 2.6.27.4-foo3 and 2.6.27.4-foo4 or 1.2.3.gcc4.qt3 1.2.3.gcc4.qt4 Is any judgment whether one version in these cases is newer than the other? If so, which is newer of the following? 1.2.☺ 1.2.☻ -- Arve Bersvendsen Developer, Opera Software ASA, http://www.opera.com/
Re: [widgets] Preferences API
On Tue, 30 Sep 2008 18:28:59 +0200, Marcos Caceres <[EMAIL PROTECTED]> wrote: While I, in principle, agree that not replicating existing storage APIs is a good thing, are we sure that all widget implementations will implement HTML5? As Jonas said, we would just mandate that implementations implement just that one part of HTML5. Or, we just rip that part of HTML5 and put it in our spec and make sure we keep them synced. If we are to do one of these, I'd very much prefer not to have to keep it continously updated until 2022. Also, are we sure that a preference storage may not have additional requirements that make them a bad match (such as encryption of stored data)? I also agree with Jonas that if it's good for widgets, it's probably good for HTML5 as a whole. For V1 of widgets, I think that HTML5's storage meets r26 [1]. But if new requirements arise (such as data encryption) we should work with the HTML-WG on that. Note that encryption, which was my example here, may be an implementation detail. I was just trying to say something about the requirement for HTML5 and Widgets might be different. -- Arve Bersvendsen Developer, Opera Software ASA, http://www.opera.com/
Re: [widgets] Preferences API
On Tue, 30 Sep 2008 01:35:42 +0200, Marcos Caceres <[EMAIL PROTECTED]> wrote: Hi All, I think we should dump the Widgets preferences API in favor of HTML5 DOM's storage API. Basically, preferences API basically replicates what DOM Storage already defines. Also, DOM storage is already implemented across three or four browsers and we can assume the specification to be fairly stable (or hopefully it will be by the time we get to CR). Dumping the preferences API will also avoid problems in the future as HTML5 becomes prevalent in the market. While I, in principle, agree that not replicating existing storage APIs is a good thing, are we sure that all widget implementations will implement HTML5? Also, are we sure that a preference storage may not have additional requirements that make them a bad match (such as encryption of stored data)? -- Arve Bersvendsen Developer, Opera Software ASA, http://www.opera.com/
Re: [Widgets] Requirements LC
On Fri, 20 Jun 2008 12:25:04 +0200, timeless <[EMAIL PROTECTED]> wrote: On Fri, Jun 20, 2008 at 11:08 AM, Arve Bersvendsen <[EMAIL PROTECTED]> wrote: The security policy proposed by Opera (and mostly implemented already) allows you to XHR any content stored within the package archive itself, just as it would allow you to include the contents of a package through
Re: [Widgets] Requirements LC
On Fri, 20 Jun 2008 09:11:42 +0200, Marcos Caceres <[EMAIL PROTECTED]> wrote: On Fri, Jun 20, 2008 at 5:04 PM, Marcos Caceres <[EMAIL PROTECTED]> wrote: To which Timeless replied... Yes, that is possible (using XHR to load the config from within the package), but then you have to walk an XML tree which sucks. The other way is to use the properties that we have bound to the Widget object. Check out http://dev.w3.org/2006/waf/widgets-api/Overview.src.html yeah, i'm sure such things are possible in some theoretical sense, but i want to make sure that the API you're asking for doesn't specifically do/enable this. Arve? What does the proposed security policy say about this? Can XHR be used to GET resources inside the package? The security policy proposed by Opera (and mostly implemented already) allows you to XHR any content stored within the package archive itself, just as it would allow you to include the contents of a package through
