Re: [widgets] API - openURL security considerations
Marcos,
first of all, kudos for thinking about security considerations for this method.
I'm glad you're considering factors like interaction flooding and tons of
windows opening.
Reviewing the spec text:
http://www.w3.org/TR/2009/CR-widgets-apis-20091222/#the-openurl-method
... I wonder whether the specification actually says that openURL will ever
return upon success. You say that the widget's browsing context must not be
navigated (for security reasons -- which ones? Access to special features
within the widget context?) -- but do you forbid simply destroying the widget
(or never returning) when openURL is invoked?
If the method never returns, then the attack you're concerned about is probably
infeasible (which would be good news); it would also tie widgets into a very
specific application model that I don't know is desirable. You probably want
to clarify this.
So, to the security considerations:
- if openURL can be executed multiple times, then pretty much everything one
can say about pop-ups applies
- as Adam said, file: URIs deserve some extra thought
- it's perhaps worthwhile to spell out to implementers that there are many ways
to write a URI handler that isn't safe, e.g., assuming that just because a
scheme has a particular syntax that syntax is actually followed.
Regards,
--
Thomas Roessler, W3C t...@w3.org
On 8 Feb 2010, at 17:36, Marcos Caceres wrote:
At Opera we've been discussing some of the security implications around the
openURL method in the widgets API spec. We think the spec might benefit if we
were to add a non-normative security consideration section for openURL.
We are basically concerned about protecting against a simple attack such as:
while(true){
openURL(http://...;);
}
The following text, which I did not write, can serve as a basis for the note
- we are presenting it here for discussion, and you'll note it uses different
terminology than the one found in the spec. In other words, please don't
consider the following to be spec text, it needs a fair amount of editing but
tries to get to the heart of the problem:
[[
APIs to open external programs, such as opening a URL in a browser, SHOULD
only be allowed automatically if the widget has focus. Opening such an
external program, SHOULD result in the widget losing focus, for the purpose
of opening more external programs. User interaction with the widget may
restore the focus to the widget. Widget Managers MAY offer a dialog for other
attempts to open external programs, or MAY fail the operation. User agents
MAY also offer an override for users to allow a widget to open external
programs automatically, even when minimized in the background.
Security considerations: Widgets may have managed run-time constraints, for
instance on memory usage or domain access, and opening multiple instances of
external programs may easily exceed those constraints. External programs may
present dialogs to perform harmful actions, e.g. download dialogs, and
multiple new windows in a short time span may allow for interaction flooding
attacks or may lead to warning fatigue. This security measure ensures that
users get a reasonable chance to manage the run-time constraints, and ensures
that only one external program and/or dialog can be opened at a time.
See http://www.w3.org/TR/wsc-ui/#popups for more details.
]]
We would appreciate any feedback people have about the proposed text.
RE: [whatwg] Window id - a proposal to leverage session usage in webapplication
[cross-posting as a similar amount of discussion has taken place on the two groups] Sebastian Hennebrueder wrote: The browser should generate an id unique per browser window and sent it as request header with every browser request. Request Header -- X-Window-Id: 279078917624897 Right, I have also used this technique successfully since several years and it is quite a nice solution for managing multiple windows. Though, currently this is only usable for Ajax apps (XHR.setRequestHeader) due to the missing pieces you point out. Using the Window id Having a window id, we can save the list of opened menus/ widgets per window in the user session. We split up the user session in slices. In pseudocode it looks like this: id = request['x-window-id'] context = session[id] menus = context['menus'] For other readers on the group it may be good to clarify that this is the server side session you are talking about. The whole point of adding this feature is to support server- centric applications better. It is quite interesting that HTML 5 solves the problem for the client side of JavaScript applications. The sessionStorage allows fine grained controll if data is seen by all windows or just by the current. The problem only persists for client - server applications. Exactly. Recent additions in this area of HTML5 mainly enhance the programming experience for applications that use script. I made an overview of this last year [1], suggesting to enhance the state handling model for server-centric apps. Below is a table with a related subset of the state management features mentioned, and your suggestion would fill the gap at *: NON-URL-BASED STATE MANAGEMENT (FOR GET PAGES W/A) Scope Script-centric Server-centric - -- -- user agent WS localStorage http-only cookies cookies cookies browsing context WS sessionStorage - * window.name document - - history entry push/replaceState N/A within document (#hash urls etc) The response from Ian Hickson was in short to direct these kinds of things to the HTTP WG, and that he expected applications to use Ajax-like interaction models instead. It has since struck me that HTML5 is quite client-focused, so I haven't invested time in bringing up any more server- centric discussions. I do think there is a need though, to cater for the classical server-side applications' state management. But I am not sure what WG wants to do this. Best regards Mike Wilson [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020423.html
[IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp k...@sitepen.com wrote: * Use promises for async interfaces - In server side JavaScript, most projects are moving towards using promises for asynchronous interfaces instead of trying to define the specific callback parameters for each interface. I believe the advantages of using promises over callbacks are pretty well understood in terms of decoupling async semantics from interface definitions, and improving encapsulation of concerns. For the indexed database API this would mean that sync and async interfaces could essentially look the same except sync would return completed values and async would return promises. I realize that defining a promise interface would have implications beyond the indexed database API, as the goal of promises is to provide a consistent interface for asynchronous interaction across components, but perhaps this would be a good time for the W3C to define such an API. It seems like the indexed database API would be a perfect interface to leverage promises. If you are interested in proposal, there is one from CommonJS here [1] (the get() and call() wouldn't apply here). With this interface, a promise.then(callback, errorHandler) function is the only function a promise would need to provide. [1] http://wiki.commonjs.org/wiki/Promises Very interesting. The general concept seems promising and fairly flexible. You can easily code in a similar style to normal async/callback semantics, but it seems like you have a lot more flexibility. I do have a few questions though. Are there any good examples of these used in the wild that you can point me towards? I used my imagination for prototyping up some examples, but it'd be great to see some real examples + be able to see the exact semantics used in those implementations. I see that you can supply an error handling callback to .then(), but does that only apply to the one operation? I could easily imagine emulating try/catch type semantics and have errors continue down the line of .then's until someone handles it. It might even make sense to allow the error handlers to re-raise (i.e. allow to bubble) errors so that later routines would get them as well. Maybe you'd even want it to bubble by default? What have other implementations done with this stuff? What is the most robust and least cumbersome for typical applications? (And, in te complete absence of real experience, are there any expert opinions on what might work?) Overall this seems fairly promising and not that hard to implement. Do others see pitfalls that I'm missing? J
Web Sockets API, buffer handling after the connection is closed
Hi,
I wonder why send() needs to buffer anything after the connection is
closed. bufferedAmount is defined: If the connection is closed, this
attribute's value will only increase with each call to the send() method
(the number does not reset to zero once the connection closes)
Why not clear the buffer right after dispatching close event and then
throw if send() is called, or something similar?
Or is the current behavior there just so that the example works;
send new data whenever socket.bufferedAmount == 0. (Though the send may
not actually send the data ever)
The example could be a bit different
var socket = new WebSocket('ws://game.example.com:12010/updates');
socket.onopen = function () {
setInterval(function() {
if (socket.readyState == WebSocket.OPEN socket.bufferedAmount == 0)
socket.send(getUpdateData());
}, 50);
};
-Olli
[IndexedDB] Inverted indexes (for full text search)
In addition to looking at the UA side of the IndexedDB AI, I've been talking to our web apps teams about it to get their initial impressions. I'm going to batch most of the feedback together in another email, but this is a big enough feature and important enough to all of those teams that I wanted to keep this in its own thread. All of the Google apps put a large emphasis on search. For example, the search within Gmail, reader, docs, wave, etc. In fact, I actually can't (off the top of my head) think of a Google app that we'd want to work offline that doesn't put a heavy emphasis on search. Thus search is a pretty important part of the offline experience for any of our apps. In Gears (and SQLite) there's full text search. This did a decent job of enabling offline search and providing a decent experience to offline users. Full text search is a pretty large beast though, and carries with it a lot of baggage...much of it tied in closely with SQL. Doing full text search completely in JavaScript (even with IndexedDB) is almost certainly not manageable for anything other than trivial amounts of data. (Definitely not one of our email accounts.) Implementing full text search in JS with Inverted indexeshttp://en.wikipedia.org/wiki/Inverted_index doing the heavy lifting should be practical though. As such, we'd like to propose Inverted Indexes be added to the spec. Anyhow, I'd like to know what concerns/objections others might have to adding this to IndexedDB. From some f2f conversations at TPAC, it sounded like there was general support at a high level, but I'm sure there will be many details to hammer out. I think we (Google) would be happy to come up with a concrete proposal if that'd be helpful. Thoughts? Thanks! Jeremy P.S. Scott Hess knows _way_ more about the details of full text search than I do, so I've cc'ed him on this.
Re: [IndexedDB] Detailed comments for the current draft
On Wed, Feb 3, 2010 at 3:37 AM, Pablo Castro pablo.cas...@microsoft.comwrote: I prefer to leave composite keys to a future version. I don't think we can get away with this. For indexes this is quite common (if anything else to have stable ordering when the prefix of the index has repeats). Once we have it for indexes the delta for having it for primary keys as well is pretty small (although I wouldn't oppose leaving out composite primary keys if that would help scope the feature). After talking to some of our web app teams at Google, I'm going to have to strongly agree with this. As far as we can tell, there's no efficient way to emulate this behavior in JavaScript and it's a pretty common use case.
[IndexedDB] Deleting/managing databases and entity stores
Some feedback/issues based on talks with web apps teams at Google. With WebSQLDatabase, there's been some concern and headache over users being able to easily delete individual databases without fully understanding the consequences (and the fact that it might break apps in strange and unpredictable ways). It'd be nice if we could do better for IndexedDB. Some possible ideas (mostly just brainstorming): modify the version number or have a tainted bolean that says when something other than the web app has mucked with the database (so a web app can then do an integrity check); have a boolean for database that says if one entity store / index is deleted, we strongly suggest they all be deleted; in addition to the description string have a string for a message shown to a user when confirming that they really do want to muck with things; suggest to UAs that they explain the consequences of manually editing a database in any UI they have to do so. In the absence of any change, I think our teams intend to use the description field to warn users, but it seems as though we can do better than that. Should we also allow apps to give a hint to the UA that says this can safely be deleted and/or least recently used parts of this can be deleted safely? A common use case for persistent storage is as a cache. Sometimes this is in the context of an app that only works online and sometimes it's a part of an offline-enabled app that builds data structures that can be deleted at will. It really seems as though we should make it easier for a UA to reclaim cache space that's not being used. Are we sure we want the spec to say User agents may automatically delete stored data after a period of time. (section 4.1). This seems to go against the prevailing decision when we talked about this in the context of LocalStorage. In the absence of any information making it explicit that information is expendable, it seems as though any deletion should be done only when explicitly confirmed by a user. What is the rational for not allowing enumeration of databases, entity stores, or indexes? One obvious use case is tools to allow you to hand-edit the data (for example, development tools). What is the rational against them? Thanks Jeremy
Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
On Feb 18, 2010, at 4: 31AM, Jeremy Orlow wrote Very interesting. The general concept seems promising and fairly flexible. You can easily code in a similar style to normal async/callback semantics, but it seems like you have a lot more flexibility. I do have a few questions though. Are there any good examples of these used in the wild that you can point me towards? I used my imagination for prototyping up some examples, but it'd be great to see some real examples + be able to see the exact semantics used in those implementations. The node.js community has some experience with promises. Here was a recent discussion they had on promises and alternatives (although I think it was primarily syntax driven): http://groups.google.com/group/nodejs/browse_thread/thread/78ad3478317ee19c/625b1d0f013206fa If you're unfamiliar with node.js [1], it strives to always be asynchronous and non-blocking. There are a number of database wrapper modules, nearly all of which should give examples of using promises: http://wiki.github.com/ry/node/modules#database - Joe [1]: http://nodejs.org/
Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/18/2010 5:31 AM, Jeremy Orlow wrote: On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp k...@sitepen.com mailto:k...@sitepen.com wrote: * Use promises for async interfaces - In server side JavaScript, most projects are moving towards using promises for asynchronous interfaces instead of trying to define the specific callback parameters for each interface. I believe the advantages of using promises over callbacks are pretty well understood in terms of decoupling async semantics from interface definitions, and improving encapsulation of concerns. For the indexed database API this would mean that sync and async interfaces could essentially look the same except sync would return completed values and async would return promises. I realize that defining a promise interface would have implications beyond the indexed database API, as the goal of promises is to provide a consistent interface for asynchronous interaction across components, but perhaps this would be a good time for the W3C to define such an API. It seems like the indexed database API would be a perfect interface to leverage promises. If you are interested in proposal, there is one from CommonJS here [1] (the get() and call() wouldn't apply here). With this interface, a promise.then(callback, errorHandler) function is the only function a promise would need to provide. [1] http://wiki.commonjs.org/wiki/Promises Very interesting. The general concept seems promising and fairly flexible. You can easily code in a similar style to normal async/callback semantics, but it seems like you have a lot more flexibility. I do have a few questions though. Are there any good examples of these used in the wild that you can point me towards? I used my imagination for prototyping up some examples, but it'd be great to see some real examples + be able to see the exact semantics used in those implementations. Promises are heavily used in the E programming language, the Twisted project (python). In JavaScript land, Dojo's Deferred's are an example of a form of promises and a number of SSJS projects including Node and Narwhal. To see some examples, you can look at the Dojo's docs [1] (note that Dojo's spells it addCallback and addErrback instead of then, however we are looking to possibly move to the CommonJS promise for Dojo 2.0). Here is somewhat random example of module that uses Deferred's [2] [1] http://api.dojotoolkit.org/jsdoc/1.3/dojo.Deferred [2] http://download.dojotoolkit.org/release-1.4.1/dojo-release-1.4.1/dojox/rpc/JsonRest.js I see that you can supply an error handling callback to .then(), but does that only apply to the one operation? I could easily imagine emulating try/catch type semantics and have errors continue down the line of .then's until someone handles it. It might even make sense to allow the error handlers to re-raise (i.e. allow to bubble) errors so that later routines would get them as well. Yes, that's exactly right, errors can be raised/thrown and propagate (when an error handling callback is not provided) to the next promise, and be caught (with an error handler) just as you have expected from the analogous propagation of errors across stack frames in JS. Maybe you'd even want it to bubble by default? What have other implementations done with this stuff? What is the most robust and least cumbersome for typical applications? (And, in te complete absence of real experience, are there any expert opinions on what might work?) I think it is pretty clear you want propagation, just like with normal sync errors, it is very handy to have a catch/error handler low down in the stack to generically handle various errors. Overall this seems fairly promising and not that hard to implement. Do others see pitfalls that I'm missing? There are certainly numerous design decisions that can be made with promises. * If an error occurs and an error handler is not provided in the current event turn (note that an event handler can be provided at any point in the future), should the error be logged somewhere? * If an callback handler is added to an already fulfilled promise, should the callback be executed immediately or in the next event turn? Most JS impls execute immediately, but E suggests otherwise. * One pitfall that a number of prior implementations have made is in having callback's return value mutate the current promise instead of returning the new one, the CommonJS spec makes it clear that then() should return a new promise that receives the return values from the callback. - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt9aNIACgkQ9VpNnHc4zAxMBgCfUG0/CVTgV15MBe8uQRDc6RPW
[IndexedDB] Lots of small nits and clarifying questions
I'm sorry that I let so much IndexedDB feedback get backlogged. In the future, I'll try to trickle things out slower. * * *Indexes:* 1) Creation of indexes really needs to be made more clear. For example, does creation of the index block everything until it's complete or does the database get created in the background? What if I have 1gb of my mail stored in IndexedDB and then a database migration adds an index? Is my app completely unusable during that time? What if the browser is exited half way through building (you can't just delete it)? What happens if you query the database while it's building in the background-building case (should it emulate it via entity-store-scans)? These are all very important questions whose answers should be standardized. 2) Why are Indexes in some database-global namespace rather than some entity-store-global namespace? I know in SQL, most people use the table name as a prefix for their index names to make sure they're unique. Why inherit such silliness into IndexedDB? Why not connect every index to a particular entity-store? 3) What happens when unique constraints are violated? 4) I don't remember anything explicitly stating that when a value changes that an index has a keypath referring to, that index should be updated. 5) It definitely would be nice to be able to index more than just longs and strings. 6) The specific ordering of elements should probably be specced including a mix of types. *Key ranges / cursors:* 1) Is an open or closed key range the default? 2) What happens when data mutates while you're iterating via a cursor? 3) In the spec, get and getObject seem to assume that only one element can be returned...but that's only true if unique is true. What do you do if there are multiple? 4) Why can the cursor only travel in one direction? 5) What if you modify a value that then implicitly (via the key-path) changes the index that your cursor is currently iterating over? *Transactions:* 1) We feel strongly that nested transactions should be allowed. Closed nested transactions should be simple to implement and will make it much easier for multiple layers of abstraction to use IndexedDB without knowledge of each other. 2) In the spec, dynamic transactions and the difference between static and dynamic are not very well explained. 3) I'm not sure that I like how the spec talks about commits being durable but then later says Applications must not assume that committing the transaction produces an instantaneously durable result. The user agent may delay flushing data to durable storage until an appropriate time. It seems like the language should be made more consistient. Also, it seems like there should be some way to ensure it is durable on disk for when it's absolutely necessary. (But maybe with a note that UAs are free to rate limit this.) *Misc:* 1) Structured clone is going to change over time. And, realistically, UAs won't support every type right away anyway. What do we do when a value is inserted that we do not support? 2) It seems that you can only be connected to one database at a time? If so, why? 3) Do we have enough distinct error codes? For example, there are multiple ways to get a NON_TRANSIENT_ERR when creating a transaction. Error strings can help with debugging, but they can differ between UAs. It seems as though all errors should be diagnosable via the error codes. 4) In 3.3.2, openCursor takes in an optional IDBKeyRange and then an optional direction. But what if you don't want a range but you do want a particular direction? Are implementations expected to handle this by looking at whether the first parameter is a IDBKeyRange or not? Same goes for IDBIndexSync. 5) Similarly, put takes 2 optionals. Depending on the object store it may or may not make sense for there to be a key param. I guess the javascript bindings will need to have knowledge of whether a key is expected and/or disallow boolean keys? It'd probably be better to avoid this from a bindings point of view. 3.2.2.4 - why would you skip the next step? 3.2.2.6 - should be preform one or the other, right? 3.2.2.6.1 - should be if it has a key generator right? 3.3.2 - if createObjectStore converts a null name to the empty string, why woudln't openObjectStore, create/open index, and removeObjectStore/removeIndex? Thanks, Jeremy
[widgets] Draft minutes from 18 February 2010 voice conf
The draft minutes from the February 18 Widgets voice conference are available at the following and copied below: http://www.w3.org/2010/02/18-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before February 25 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conference 18 Feb 2010 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0656.html See also: [3]IRC log [3] http://www.w3.org/2010/02/18-wam-irc Attendees Present Art, Arve, Cyril, Marcos, Robin, Bryan, StevenP, Josh Regrets Frederick, Marcin, DavidR Chair Art Scribe Art Contents * [4]Topics 1. [5]Review and tweak agenda 2. [6]Announcements 3. [7]ISO MPEG-U and Widgets 4. [8]PC spec: proposal to publish PR 5. [9]Status 6. [10]AOB * [11]Summary of Action Items _ ArtB ScribeNick: ArtB scribe Scribe: Art Date: 18 February 2010 Cyril_Concolato right, even on IRC I don't even remember all the commands :( Review and tweak agenda AB: the agenda was posted yesterday ( [12]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/06 56.html ). Are there any change requests? [12] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0656.html MC: I would like to talk about ITS AB: we can add that to the PC agenda topic ... any other requests? [ No ] Announcements AB: does anyone have any short announcements? ISO MPEG-U and Widgets AB: we have invited Cyril Concolato to join us today to discuss ISO's Study text of ISO/IEC FCD 23007-1 (MPEG-U) ( [13]http://mpeg.chiariglione.org/working_documents/mpeg-u/pt1.zip ). Thanks for joining us today Cyril! ... Cyril, perhaps you could first give us a short overview of the group working on widget-related specs [13] http://mpeg.chiariglione.org/working_documents/mpeg-u/pt1.zip CC: I am not talking on behalf of MPEG ... I am only giving my personal point of view AB: OK; thanks for that clarification CC: MPEG-U is an ISO standard ... it has multiple parts and only Part #1 deals with widgets ... started Oct 2008 ... want solutions for widgets using MPEG technology ... e.g. streaming widgets over MPEG-2 ... started with a reqs and context setting ... both of those docs are publicly available ... based on those reqs, MPEG made a RfP ... we got some answers to that RfP and started a spec ... we refer to WebApps' PC spec and to what is nka TWI spec ... We started a liaison at the end of 2009 ... it bounced around a bit (got lost) ... so we sent a new liaision ... we have people working on different MPEG specs e.g. audio, video, 3d, formats, scene description, LaSER, etc. ... besides us, Telecom Italia, ETRI, Samsung, Intel (at one point in time) ... we do ref PC spec ... expect an MPEG UA should be a PC UA but also will include some extensions ... We understand WebApps is starting charter discussions ... want to collaborate on new work ... there were two points, one technical ... MPEG should split spec to confine some resualbe functions ... the 2nd issue is IPR ... MPEG does not work with Royalty Free by default ... IPR policy allows for RF but that is not the default ... But MPEG is willing to change its widget spec so that is is RF ... need to clarify something in the minutes Cyril_Concolato CC: MPEG is requesting its members to send patent and licensing declaration forms Cyril_Concolato CC: this form allows MPEG members to declare that they are willing to provide the technology with RF terms AB: thanks for those clarifications ... any comments about what CC has said so far? Scribe+ Josh scribe ScribeNick: timeless_mbp AB: I propose we go section by section, starting with section 1 ... darobin RB: I have JS: I haven't had time to read the document MC: I haven't reviewed it yet AB: I have only glanced at it ... Robin, any comments on section 1? CC: Section 1 is the scope, organization RB: I have questions... ... that would give people a better idea as they review it ... first question: in your overview, it says that this new (?) ... is meant to make it more compatible with existing ... ... to help with widgets ... to make it more compatible with e.g. flash CC: ok... ... when we had these requirements, we had several cases in mind ... e.g. streaming ... we wanted a configuration file to be able to point to a stream ... we had a requirement that a widget
Re: [widgets] API - openURL security considerations
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?
S
On 18 Feb 2010, at 09:50, Thomas Roessler wrote:
Marcos,
first of all, kudos for thinking about security considerations for
this method. I'm glad you're considering factors like interaction
flooding and tons of windows opening.
Reviewing the spec text:
http://www.w3.org/TR/2009/CR-widgets-apis-20091222/#the-openurl-method
... I wonder whether the specification actually says that openURL
will ever return upon success. You say that the widget's browsing
context must not be navigated (for security reasons -- which
ones? Access to special features within the widget context?) --
but do you forbid simply destroying the widget (or never returning)
when openURL is invoked?
If the method never returns, then the attack you're concerned about
is probably infeasible (which would be good news); it would also tie
widgets into a very specific application model that I don't know is
desirable. You probably want to clarify this.
So, to the security considerations:
- if openURL can be executed multiple times, then pretty much
everything one can say about pop-ups applies
- as Adam said, file: URIs deserve some extra thought
- it's perhaps worthwhile to spell out to implementers that there
are many ways to write a URI handler that isn't safe, e.g., assuming
that just because a scheme has a particular syntax that syntax is
actually followed.
Regards,
--
Thomas Roessler, W3C t...@w3.org
On 8 Feb 2010, at 17:36, Marcos Caceres wrote:
At Opera we've been discussing some of the security implications
around the openURL method in the widgets API spec. We think the
spec might benefit if we were to add a non-normative security
consideration section for openURL.
We are basically concerned about protecting against a simple attack
such as:
while(true){
openURL(http://...;);
}
The following text, which I did not write, can serve as a basis for
the note - we are presenting it here for discussion, and you'll
note it uses different terminology than the one found in the spec.
In other words, please don't consider the following to be spec
text, it needs a fair amount of editing but tries to get to the
heart of the problem:
[[
APIs to open external programs, such as opening a URL in a browser,
SHOULD only be allowed automatically if the widget has focus.
Opening such an external program, SHOULD result in the widget
losing focus, for the purpose of opening more external programs.
User interaction with the widget may restore the focus to the
widget. Widget Managers MAY offer a dialog for other attempts to
open external programs, or MAY fail the operation. User agents MAY
also offer an override for users to allow a widget to open external
programs automatically, even when minimized in the background.
Security considerations: Widgets may have managed run-time
constraints, for instance on memory usage or domain access, and
opening multiple instances of external programs may easily exceed
those constraints. External programs may present dialogs to perform
harmful actions, e.g. download dialogs, and multiple new windows in
a short time span may allow for interaction flooding attacks or may
lead to warning fatigue. This security measure ensures that users
get a reasonable chance to manage the run-time constraints, and
ensures that only one external program and/or dialog can be opened
at a time.
See http://www.w3.org/TR/wsc-ui/#popups for more details.
]]
We would appreciate any feedback people have about the proposed text.
smime.p7s
Description: S/MIME cryptographic signature
Re: [WebTiming] HTMLElement timing
On Wed, Feb 17, 2010 at 10:36 PM, James Robinson jam...@google.com wrote: * What precisely does 'parse' time mean for each element? For example, on a script tag does parse time include parsing the script itself, or executing it as well? What about for JS engines that do not distinguish between the two? Then there is also things like JITs, which at least in some engines run lazily. So a function isn't JITted until the first time it runs. Which may or may not be long after the script has executed. In firefox things are even worse because a function isn't traced until we've determined that it's a hot path, i.e. that it's run several times. / Jonas
Re: Web Sockets API, buffer handling after the connection is closed
Throwing will likely lead to sites breaking since it's likely that
many will not expect connections to get broken due to network issues.
Having bufferedAmount continuously increase seem to address the
example code you included. Or more generally, code that does:
if (socket.bufferedAmount X)
sendStuff(socket);
Note that you don't have to actually buffer anything. I.e. you can
just throw away the data that is sent and increase bufferedAmount with
the size of the data.
/ Jonas
On Thu, Feb 18, 2010 at 4:56 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
Hi,
I wonder why send() needs to buffer anything after the connection is closed.
bufferedAmount is defined: If the connection is closed, this attribute's
value will only increase with each call to the send() method (the number
does not reset to zero once the connection closes)
Why not clear the buffer right after dispatching close event and then
throw if send() is called, or something similar?
Or is the current behavior there just so that the example works;
send new data whenever socket.bufferedAmount == 0. (Though the send may not
actually send the data ever)
The example could be a bit different
var socket = new WebSocket('ws://game.example.com:12010/updates');
socket.onopen = function () {
setInterval(function() {
if (socket.readyState == WebSocket.OPEN socket.bufferedAmount == 0)
socket.send(getUpdateData());
}, 50);
};
-Olli
Re: [widgets] API - openURL security considerations
On Thu, 18 Feb 2010 22:09:00 +0100, Scott Wilson scott.bradley.wil...@gmail.com 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: Web Sockets API, buffer handling after the connection is closed
On Thu, 18 Feb 2010, Olli Pettay wrote: I wonder why send() needs to buffer anything after the connection is closed. bufferedAmount is defined: If the connection is closed, this attribute's value will only increase with each call to the send() method (the number does not reset to zero once the connection closes) Why not clear the buffer right after dispatching close event and then throw if send() is called, or something similar? It's so that if you write code that just sends continuously, you'll stop sending once the connection dies, even if you miss the close event. The UA doesn't have to actually buffer, just keep increasing the number by the length each time you get a send while closed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
