Re: Installing web apps
Hi Dimitri, On Feb 7, 2012, at 18:26 , Dimitri Glazkov wrote: Robin, this is a pretty interesting and thoughtful treatise and while I am still digesting parts of it, I can't help but think that the key in identifying precise boundaries and relative position of these two universes is defining one in terms of another. Namely, we may want to explore if Web App sandbox/container can be a System App (I also heard the term Platform App). And if it can be, it both definitively enumerates the set of limitations and APIs imposed by this container System App and dovetails nicely into that whole browser-in-a-browser discussion. I'm still trying to wrap my head about what exactly your proposal would imply, sorry if what follows is fuzzier than a Little Pony on a bad hair day. As written, your proposal makes a lot of a sense to me. We have an omnipotent system on one side, and on the other a less powerful one that can run in the former. So defining the subset in terms of the whole seems logical. But as soon as I try to do anything practical with the idea I start hitting aporetic walls. It doesn't mean that it's a bad idea of course, just that I don't know what to do with it. I'm hoping you can help :) We could apply it in a brute force manner by listing all the features that the omnipotent system supports and flagging those that are excluded in-browser. But I doubt that that would be very useful, we wouldn't learn anything knew from it. Note that the people who worked on policy-based security systems for Web technology (e.g. WAC, webinos) have often discussed the possibility of producing a policy that matches the default browser security model (I don't know if they eventually did); this would be the same. If however I try to be subtler and more abstract about it, I circle right back to a dividing line of more harmful than what is tolerable inside a sandbox which I mentioned previously. Stuff that's in that group doesn't get to be in the browser context. The good news is that I don't think we need a strong definition for the distinction that I'm suggesting. I think that we can get away with a rough idea of what goes where and how to build it (which I believe we more or less have, though it needs to be documented). And with experience, we can refine it. Still, I'd like to address your idea more satisfactorily :) -- Robin Berjon - http://berjon.com/ - @robinberjon
CfC: publish WD of Clipboard API and events; deadline February 16
This is a Call for Consensus to publish a new WD of the Clipboard API and events spec using the latest ED as the basis (Hallvord has not yet prepared it for publication in /TR/): http://dev.w3.org/2006/webapi/clipops/clipops.html Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. If you have any comments or concerns about this proposal, please send them to public-webapps by February 16 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. -ArtB
Re: Installing web apps
On Wednesday, February 8, 2012 at 10:33 PM, Adrienne Porter Felt wrote: I agree that the current UI is not great. However, I disagree about everyone clicking through permission grants. I've done two user studies and found that about ~18% of people look at permissions for a given installation, and about ~60% look occasionally. We found that most have no idea what they really mean -- but that is a separate problem pertaining to the presentation. Also, about 20% of people have in the past avoided apps that they considered bad because the permissions alerted them to something that they didn't like. Did you publish this research somewhere? Would be interested to know your sample size and type, response rate, etc. It's in submission, but I can put together a tech report if you are interested. Results are from two studies: self-reported data from 308 online Android users (recruited via Admob), and confirmed by an observational study of 25 Android users in the bay area (selected from a large pool of Craigslist applicants so that they match the overall Android population by gender, age, etc.). I think a technical report would be great to have (even if it's just a bullet summary of findings). It will give us some data to reference, which is so often lacking in debates around here. One thing I've found is that developers often don't understand the relationship between Intents and permissions in Android. A common mistake is for an app to ask for the READ_CONTACTS permission even though it's actually using an Intent to access contacts (which doesn't need the permission). Either that, or apps will unnecessarily implement things that are already provided via Intents for no particular reason. I think these issues could be avoided on the Web by first introducing something that can be accessed via WebIntents and only later introducing direct access via permissions, and also making the documentation very clear. Do you think this might be a consequence of developers copy/pasting permissions? I wonder if anyone has looked into that (might be easy to see overlaps or replication across applications). I've found several cases of bad permission behavior being copied and pasted by developers, although I am sure there are more cases than I found since I did not originally go out looking for it. (If you check out section 6.3 of http://www.cs.berkeley.edu/~afelt/android_permissions.pdf I give a few other examples of common reasons why developers ask for more permissions than they need.) Thank you! This is very helpful to us that are not able to keep up with the literature on the matter. -- Marcos Caceres
[clipboard] Event definition
Hi Hallvord, At http://dev.w3.org/2006/webapi/clipops/clipops.html#clipboard-event-interface, a reference to DOM *2* Events is made; it should be updated. Also, the initClipboardEvent method should be removed in favour of a constructor, as described at http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#constructing-events. HTH Ms2ger
Re: [Clipboard] Processing model feedback (and other)
Anne van Kesteren ann...@opera.com skreiv Fri, 09 Sep 2011 16:48:36 +0200 As a high-level comment it seems to me the organization of the specification needs some changing. The processing model is about how to deal with a copy/paste/cut operation it is not about firing an event (that is mainly part of it). The events section meanwhile is about how users invoke a copy/paste/cut operation and not so much about firing an event either (the event summary boxes are not needed I think). I agree that the event summary tables aren't really required, and have removed them. I'm not quite sure what else I should do specifically to address the comment that the organization of the specification needs some changing. For example regarding The processing model is about how to deal with a copy/paste/cut operation it is not about firing an event (that is mainly part of it). ..it happens to be *the* part of the processing this spec is all about :)..? You can also invoke such actions from script via the execCommand() APIs apparently, but that does not appear to be described in detail. It's mentioned in the #integration-with-other-scripts-and-events section (8). I'm not sure where else to mention it or what more detail is needed. execCommand() is presumably spec'ed in Aryeh's rich text editing work. So first I think it would make sense to clearly distinguish between operations and events. Can you give me an example of a specific change to the spec's outline or vocabulary that would help make this distinction? Because there is a processing model that includes dispatching events the section on events can probably be removed. The requirements made therein are redundant. Indeed. The spec evolved this way, section 4 with normal prose description of how things are expected to work predates section 5 and the processing model that give more exact implementation details. So we could drop all of section 4 and just keep the processing model. However, I think keeping the short prose description for each event in section 4 makes sense. It makes the spec more readable (and implementors are readers too) and makes it clear what behaviour the processing model intends to dictate. You will still need a section that defines when the operations are invoked. If section 4 were to be removed, or generally? Alternatively, you could leave that out of scope for the HTML Editing APIs specification. For execCommand() I'll do that, I think. Apart from this I noticed a few other things: * the BODY element should probably be defined as reference to what it is in HTML. Added generic reference to HTML5 after both instances of BODY element. Would it be better to refer to a specific section directly? I'd happily just link the text the BODY element directly to http://www.w3.org/TR/html5/sections.html#the-body-element but it seems like specs must be a bit more pedantic about things and list references at the bottom etc..? * If you define an internal flag do not use code for it, but var or maybe dfn. Fixed. I think I've once read a spec or recommendation dealing with best markup for a spec, but I can't find it now. If you know what document I'm likely thinking about please send me a link :) * If you reference externally used terms mention that somehow. E.g. DataTransfer's mode flag is actually called drag data store mode. DataTransfer in HTML is defined in terms of drag data store so it would make sense to talk about the same thing here. (Maybe get it renamed from drag to something more neutral?) Changed instances of mode to drag data store mode, kind to drag data item kind etc. Added a reference for the HTML5 DnD chapter, and some more referencing to this on first usage of DataTransfer. (IMO it becomes harder to read though - as long as we're dealing with properties of a precisely specified object it should be OK to refer to their property names like item and type. Mode is a bit special in that it is AFAIK an internal flag and not visible to script authors.) * If the current clipboard part contains HTML- or XHTML-formatted text seems really vague (how do you tell whether it contains that?) as are the steps that lead to creating some kind of tree. They probably need to reference something specific in HTML. Slightly elaborated - better now? * The Fire the event step should be more elaborated: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#firing-events Firing an event surely should be specified elaborately elsewhere. I added another reference to DOM2-Events (though fire probably is used without being precisely spec'ed there..). * The Process the default action step should instead talk about whether or not the http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#canceled-flag of the event ended up being set and what to do when it is not. Seems pretty readable and precise to me as-is. * Since
Re: [clipboard] Event definition
Ms2ger ms2...@gmail.com skreiv Thu, 09 Feb 2012 13:26:39 +0100 http://dev.w3.org/2006/webapi/clipops/clipops.html#clipboard-event-interface, a reference to DOM *2* Events is made; it should be updated. Well, I guess it should. On the other hand..what should it be updated to? AFAIK DOM3 Events is still a working draft (though a very mature one), and there *seems* to be/have been a bit of political bickering between DOM3 Events and a new spec called DOM Core or DOM4 which is also a working draft and one I haven't read closely enough to make any statement about maturity. AFAIK it makes no technical difference whether this spec references DOM2, DOM3 or DOM4 in this context. So, *if I don't want to be involved in politics*, can't I just reference the published DOM2 Events and be done with it? :-p Also, the initClipboardEvent method should be removed in favour of a constructor, as described at http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#constructing-events. Done in response to Anne's feedback. -- Hallvord R. M. Steen Core tester, Opera Software
Re: [clipboard] Event definition
Ms2ger, the same old issue with referencing a released spec or not... that was heavily discussed! Or am I wrong? Is there any reason that makes that sentence obsolete in DOM 2? I would have no issue that the clipboard document references both but it would become unreleasable if it had to rely on specifications that are not released. MathML for CSS had to suspend its becoming of a REC because CSS 2.1 and 3 weren't released yet... and this sounds like normal. It did not take very long in this case. I like Hallvord's response to this. paul Le 9 févr. 2012 à 13:26, Ms2ger a écrit : Hi Hallvord, At http://dev.w3.org/2006/webapi/clipops/clipops.html#clipboard-event-interface, a reference to DOM *2* Events is made; it should be updated. Also, the initClipboardEvent method should be removed in favour of a constructor, as described at http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#constructing-events. HTH Ms2ger
Re: CfC by 02-14: Add IME API to the charter
On Wed, 08 Feb 2012 22:38:51 +0100, Robin Berjon ro...@berjon.com wrote: On Feb 8, 2012, at 13:29 , Charles McCathieNevile wrote: thanks to Mike and the Google guys, we have http://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/Overview.html which explains what an IME API would do and why it would be useful. I believe we have editors but it doesn't name a test facilitator (don't blame me, Art chose that as the name ;) ) and we need one. I am assuming that will be forthcoming, so this is a formal call for Consensus to add this item to the charter. Silence will be considered assent, positive response is preferred, and the deadline is the end of Tuesday 14th February. A strong and hearty +1. Opera is in favour too. cheers Chaals -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan litt norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: April face-to-face meetings for HTML and WebApps
On Thursday, February 9, 2012 at 4:18 AM, Andres Riofrio wrote: Regarding the checklist: perhaps these things are only relevant if there are Christian/Jewish/Muslim people in the group. And if there are people that prefer not to meet on Saturday. It seems to me more reasonable to expect people with prior commitments, that plan to attend, to speak up, and expect the rest to understand and try to come to a consensus. That's why people ask for objections anyway. Right, sometimes one might have to make sacrifices and forgo a Saturday or observing some religious thingy out of respect for the sectarian nature of the W3C membership (and for the advancement of our beloved and sacred Web). Kind regards, Marcos
Templates 2: The Real World
Hey everyone, I've been following the HTML Parsing and the template element thread/conversation since it began yesterday and it's very interesting, but one thing keeps coming to mind - has anyone working on template spent any significant time using the existing web template systems and practices? Here are a few that are fairly common and in production use: Mustache.js (logic-less) https://github.com/janl/mustache.js Embedded.js (logic) http://embeddedjs.com/ JST (gaining developer mindshare) http://ricostacruz.com/backbone-patterns/#jst_templates This list is by no means intended to be comprehensive or to imply any endorsement - in fact, I don't use any of these (I use underscore.js's super simple pre-compiled templates) Benchmarking information: http://www.viget.com/extend/benchmarking-javascript-templating-libraries/ Rick
Re: Installing web apps
On 2/9/12 1:21 PM, Marcos Caceres w...@marcosc.com wrote: On Wednesday, February 8, 2012 at 10:33 PM, Adrienne Porter Felt wrote: I agree that the current UI is not great. However, I disagree about everyone clicking through permission grants. I've done two user studies and found that about ~18% of people look at permissions for a given installation, and about ~60% look occasionally. We found that most have no idea what they really mean -- but that is a separate problem pertaining to the presentation. Also, about 20% of people have in the past avoided apps that they considered bad because the permissions alerted them to something that they didn't like. Did you publish this research somewhere? Would be interested to know your sample size and type, response rate, etc. It's in submission, but I can put together a tech report if you are interested. Results are from two studies: self-reported data from 308 online Android users (recruited via Admob), and confirmed by an observational study of 25 Android users in the bay area (selected from a large pool of Craigslist applicants so that they match the overall Android population by gender, age, etc.). At Facebook, we use a pretty fine-grained permission system for users to grand third party apps access to their data, rights to post on their behalf, etc. The correlation between the number of permissions requested by the app and the percentage of users which will avoid using the app altogether is strong, so much so that we're warning devs against asking for too many permissions upfront: There is a strong inverse correlation between the number of permissions your app requests and the number of users that will allow those permissions. The greater the number of permissions you ask for, the lower the number of users that will grant them; so we recommend that you only request the permissions you absolutely need for your app. --https://developers.facebook.com/docs/authentication/ Only ask for the permissions you actually need; the more you ask for, the less likely users will grant them. Users may join your app and automatically trust their friends, but the first hurdle is trusting your app when first prompted with the permissions dialog. --https://developers.facebook.com/socialdesign/personalize/ Instead, we advocate a permissions model which lies somewhere in the middle of what has been discussed here so far: There's an initial request of permissions done prior to the app being first used. If these permissions are granted, they are granted indefinitely (or until the user revokes them). If they are not, the app just can't be used. After that, the application has the possibility to ask extra permissions any number of times. This is typically done following a user action that the existing permissions won't allow. Permissions granted that way (and this is key difference with the models discussed so far) are also granted indefinitely. Best, --tobie
Re: Installing web apps
On Thursday, February 9, 2012 at 3:17 PM, Tobie Langel wrote: The correlation between the number of permissions requested by the app and the percentage of users which will avoid using the app altogether is strong, so much so that we're warning devs against asking for too many permissions upfront: big ask, but can you be more precise here? Like 5 permission requests = 80% drop off. Also, can you really correlate installs with permissions (it might be something else that is putting users off, which consequently correlates with the drop off in installs -or how did you statistically determine causality which prompted FB to warn developers to reduce the number of permission requests? and do you see a change in behavior after having asked developers not to ask for too many permissions?).
xframe or iframe type='cross-domain'
I've been working with cross-domain iframes. This technology has a lot of potential, but the current API is very difficult to use. Just search the web for cross-domain iframe info and you can read how many developers are confused. I believe a simple change could make a huge difference. My suggestions are related to http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html The current model for a cross-domain iframe is it's just a restricted same-domain iframe. So both iframes have a contentWindow property as their key API anchor. Sounds consistent and economical. But it's not, because developer code written to process contentWindow references cannot work with cross-domain iframe contentWindow objects. As far as I can tell, a cross-domain iframe contentWindow has only one valid property, postMessage(). By no stretch of anyone's imagination is the object a window. Calling this thing we get a contentWindow is a mean lie to developers; it forces us into Exception-oriented programming where we try every recipe on the Web looking for something that does not emit errors. On the other hand, there is an important Web API focused on postMessage() as outlined in the spec above. Generally (though not exclusively) the spec refers to objects with postMessage() as ports. Thus my proposal: 1. create a spec-only base class element with the current properties of iframe, except no contentWindow or contentDocument 2. inherit iframe from the spec-only base class, add contentWindow and contentDocument 3. inherit a new element (eg xframe) or element type (eg iframe type='cross-domain'), add property port 4. Access to xframe.contentWindow would result in undefined (yay!, no funky errors) 5. Access to iframe.port would result in 'undefined': developers now have a simple test. 6. xframe.port would have postMessage. I believe the port could in fact be a MessagePort. (http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#messageport) I know that some may view this suggestion as trivial. I would just ask you to talk to web app developers who have tried or considered using cross-domain iframe messaging. jjb
Re: xframe or iframe type='cross-domain'
On 2/9/12 12:04 PM, John J Barton wrote: As far as I can tell, a cross-domain iframe contentWindow has only one valid property, postMessage(). By no stretch of anyone's imagination is the object a window. Calling this thing we get a contentWindow is a mean lie to developers; it forces us into Exception-oriented programming where we try every recipe on the Web looking for something that does not emit errors. So here's the thing. If the element is called iframe it needs to have a contentWindow property. The thing that cross-domain iframes return could be returned from some other property, but what should contentWindow then return for cross-domain iframes? Of course using a different element name solves that problem. 1. create a spec-only base class element with the current properties of iframe, except no contentWindow or contentDocument 2. inherit iframe from the spec-only base class, add contentWindow and contentDocument 3. inherit a new element (eg xframe) or element type (eg iframe type='cross-domain'), add property port It'd have to be a new element if it has a different API. The benefit is a cleaner API and not having to define what happens when the type changes. The drawback is that your fallback behavior in UAs without support for the new feature is quite different. Is that a problem? Developer feedback definitely needed there. -Boris
Re: xframe or iframe type='cross-domain'
On Thu, Feb 9, 2012 at 9:22 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/9/12 12:04 PM, John J Barton wrote:
As far as I can tell, a cross-domain iframe contentWindow has only one
valid property, postMessage(). By no stretch of anyone's imagination
is the object a window. Calling this thing we get a contentWindow
is a mean lie to developers; it forces us into Exception-oriented
programming where we try every recipe on the Web looking for
something that does not emit errors.
So here's the thing. If the element is called iframe it needs to have a
contentWindow property. The thing that cross-domain iframes return could be
returned from some other property, but what should contentWindow then return
for cross-domain iframes?
If we added 'port' to iframe and if we managed to change all of the
documentation to point devs toward iframe.port for messaging, then it
would be ok if contentWindow remained as it is now. I would expect
that the Web would quickly direct developers who have problems using
contentWindow towards using port.
We already have some emerging libraries for postMessage communications, eg
https://github.com/kriskowal/q-comm
My suggestion just help devs attach the right thing to these
libraries: they need a 'port'.
Of course using a different element name solves that problem.
1. create a spec-only base class element with the current properties
of iframe, except no contentWindow or contentDocument
2. inherit iframe from the spec-only base class, add contentWindow
and contentDocument
3. inherit a new element (eg xframe) or element type (eg iframe
type='cross-domain'), add property port
It'd have to be a new element if it has a different API.
The benefit is a cleaner API and not having to define what happens when the
type changes.
The drawback is that your fallback behavior in UAs without support for the
new feature is quite different. Is that a problem? Developer feedback
definitely needed there.
Extending the API on iframe would make fallback easy even though it
lacks elegance:
if (iframe.port) {
// modern browser
} else {
// we still deal with contentWindow carefully for old timers
}
jjb
Re: xframe or iframe type='cross-domain'
On 2/9/12 12:43 PM, John J Barton wrote:
The drawback is that your fallback behavior in UAs without support for the
new feature is quite different. Is that a problem? Developer feedback
definitely needed there.
Extending the API on iframe would make fallback easy even though it
lacks elegance:
if (iframe.port) {
// modern browser
} else {
// we still deal with contentWindow carefully for old timers
}
The fallback issue I was talking about is that if you mint a new element
called xframe then it wouldn't even load pages in an old browser.
-Boris
Re: xframe or iframe type='cross-domain'
On Thu, Feb 9, 2012 at 10:01 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/9/12 12:43 PM, John J Barton wrote:
The drawback is that your fallback behavior in UAs without support for
the
new feature is quite different. Is that a problem? Developer feedback
definitely needed there.
Extending the API on iframe would make fallback easy even though it
lacks elegance:
if (iframe.port) {
// modern browser
} else {
// we still deal with contentWindow carefully for old timers
}
The fallback issue I was talking about is that if you mint a new element
called xframe then it wouldn't even load pages in an old browser.
Yes, sorry, I did understand that. Let me try again:
If, rather than using xframe, we simply add port to iframe then,
as you implied originally, there is no fall back problem. Fallback is
as above.
jjb
connection ceremony for iframe postMessage communications
Recently I've been working with iframe messaging. The postMessage
solution has a lot of advantages and good traction across iframes,
WebWorkers, and browser extensions, with lots of overlap with Web
Sockets.
However the technology has two significant problems. First is the
contentWindow that is not a window confusion I discussed recently.
Second concerns the connection setup. I describe the second problem
here.
The basic communications solution is simple enough:
window.addEventListener('message', handler, false); // I'm listening!
portToOtherWindow.postMessage(message); // I'm talking to you!
However the solution has two significant problems:
1. There is no way to know if portToOtherWindow is connected before
you issue postMessage()
2. All iframes send messages to the same handler.
The first problem arises because web apps are increasingly
asynchronous for load performance and other reasons.
This leads developers to look for events that will tell them about
'load' on iframes, and that leads them to try
iframe.contentWindow.addEventListener(). It works fine for same-domain
iframes, but fails for cross-domain.
The second problem arises because the handler is attached to the
window and not to an object related to the connection between the two
windows.
To workaround for these problems developers have to
1. create a handshake message sequence, AND
2. de-multiplex messages.
OR
3. No use cross-domain iframes
Notice that if multiple developers each create different a handshake
and de-multiplexing solutions, then we end up with isolated
collections of compatible iframes or we end up with
handshake-detection code in iframes.
To leverage an iframe component, a Web page needs to solve two hard
problems: 1) understand the API the component needs and 2) understand
the connection ceremony. The first part is fundamental to using the
component. The second part is just busy work.
I think we should have a standard solution to the connection problem
for cross-domain iframes.
Note that this problem is not shared by other uses of postMessage:
1. WebWorkers uses port
2. WebSockets: server always starts first, object is connection not window
2. MessageChannel: object is connection not window.
Ideas?
jjb
Re: [webcomponents] HTML Parsing and the template element
On Wed, Feb 8, 2012 at 11:25 PM, Henri Sivonen hsivo...@iki.fi wrote: On Thu, Feb 9, 2012 at 12:00 AM, Dimitri Glazkov dglaz...@chromium.org wrote: == IDEA 1: Keep template contents parsing in the tokenizer == Not this! Here's why: Making something look like markup but then not tokenizing it as markup is confusing. The confusion leads to authors not having a clear mental model of what's going on and where stuff ends. Trying to make things just work for authors leads to even more confusing here be dragons solutions. Check out http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state Making something that looks like markup but isn't tokenized as markup also makes the delta between HTML and XHTML greater. Some people may be ready to throw XHTML under the bus completely at this point, but this also goes back to the confusion point. Apart from namespaces, the mental model you can teach for XML is remarkably sane. Whenever HTML deviates from it, it's a complication in the understandability of HTML. Also, multi-level parsing is in principle bad for perf. (How bad really? Dunno.) I *really* don't want to end up writing a single-pass parser that has to be black-box indishtinguishable from something that's defined as a multi-pass parser. (There might be a longer essay about how this sucks in the public-html archives, since the SVG WG proposed something like this at one point, too.) This makes sense. As an aside, this is also why implementing templates as a script tag is a bad idea. == IDEA 2: Just tweak insertion modes == I think a DWIM insertion mode that switches to another mode and reprocesses the token upon the first start tag token *without* trying to return to the DWIM insertion mode when the matching end tag is seen for the start tag that switched away from the DWIM mode is something that might be worth pursuing. If we do it, I think we should make it work for a fragment parsing API that doesn't require context beyound assuming HTML, too. (I think we shouldn't try to take the DWIM so far that a contextless API would try to guess HTML vs. SVG vs. MathML.) Sounds like a good direction to explore. I'll play with this. The violation of the Degrade Gracefully principle and tearing the parser spec open right when everybody converged on the spec worry me, though. I'm still hoping for a design that doesn't require parser changes at all and that doesn't blow up in legacy browsers (even better if the results in legacy browsers were sane enough to serve as input for a polyfill). Yeah, Adam expressed a similar concern. I must admit, before digging into the HTML parsing, I was a bit more bullish about making this just work. Turns out, there's this delicate balance between the reality and the proper solution. I am still optimistic we can find something that both doesn't look like a gross hack and degrades well in most cases. :DG -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: connection ceremony for iframe postMessage communications
On 2/9/12 1:15 PM, John J Barton wrote: This leads developers to look for events that will tell them about 'load' on iframes, and that leads them to try iframe.contentWindow.addEventListener(). It works fine for same-domain iframes, but fails for cross-domain. Adding a load listener to the iframe element itself should work for this, no? That doesn't help with the second problem, of course -Boris
Re: Installing web apps
As you are saying, we seem to be talking of different things, even if I have a problem seeing how different. You make a difference between apps using web technologies accessed by HTTP or not, which I thought close to installed or not. You postulate the absence of a safe and usable way of escalating privileges for apps. That is probably what I most react to. You are talking of either sandboxing, or unfettered access. That is basically the difference between web apps and native apps in iOS, and I hate it! I can live with it only because Apple does some strict checking on native apps, but I hate relying on their judgment on privacy-related data. So I hope you are wrong, and we can find a workable model with finer grain. Best regards JC On 8/2/12 14:21 , Robin Berjon wrote: On Feb 8, 2012, at 01:06 , Jean-Claude Dufourd wrote: On 7/2/12 05:31 , Robin Berjon wrote: The first problem is that of the security model. A lot of smart people have tried to come up with a lot of different solutions here, often involving signatures, policies, intricate user interfaces, etc. I think that's all massively over-engineered. Once you take into account the fact that the number of applications that actually need this level of privilege is only a tiny fraction of the whole, you realise that you can just give up on privilege policies. These are just regular apps: they have unfettered access — period (within the limits of the underlying platform's permissions system naturally). They ought to be harder (and unusual) to install, and maybe should look different, but that's it. We might want to give them strong CSP protection by default to defend against XSS attacks, but that's a detail. JCD: I strongly disagree with you there, Robin. I do not see why installed apps should have more access. You're the one calling them installed apps :) In the section you quote above (and, unless I made a mistake, in the entirety of my post) I don't refer to high-privilege apps as installed. The installation method is largely an orthogonal problem. I personally think that it should be close to impossible to access a page in one's browser and by mistakenly clicking on a dialog to grant it permissions that would be dangerous. You probably need at least something involving multiple clicks with no quick keyboard bindings and a speed bump. Normal apps and installed apps should have the same security model, but installed apps may have permanently remembered security clearances, and that could be the only difference. That's not the line that I'm drawing. I'm drawing a line between browser apps and the rest. I'm further pointing out that the number of applications that actually fall into the rest category is smaller than most people expect once we have a generic user-mediation security system, such as Intents provide. That works *because* the number of security clearance dialogs (or the size of their content) can be diminished, perhaps even to the point that they disappear in most cases. Under this approach, System Apps are few are far apart. For a lot of users I suspect it might even be possible that they would never want any beyond those preinstalled. Safety comes from cutting the escalation vector, and making interactions between users and security about what the user wants to do rather than about a personal security policy decision — which most people (myself very much included) don't want to hear about. My proposal is as simplistic as yours, but in the opposite direction. You are saying installed apps should have all rights, I am saying installed apps should obey the exact same security as normal apps. In your system, it is dangerous to install an app, but it is very simple. In mine, there is no danger, but it is a bit more work. It's difficult for me to reply to this properly since you're making a distinction that isn't the one I'm making. How does the approach you propose acquire privileges? Upfront permissions are a security no-go. Doorhanger/infobars don't scale to multiple permissions. Facebook's current model which mixes both in moderation (ask only the smallest set you absolutely need upfront, in full knowledge that asking too many permissions decreases your adoption, and ask more in the flow of user actions) could be an interesting option but I don't know if it could scale to the sort of dangerous features that we'll eventually need for a full platform. The missing part in your description above is there is no danger *if we have a way of escalating privileges from web apps in a safe, usable manner*. To the best of my knowledge we don't, hence the noodling on a different approach. Java tried that for applets, and Java is now gone from the web apps stage. Applets could gain a lot of permissions! It was a terrible model, and has nothing in common with what I'm thinking about :) -- JC Dufourd Directeur d'Etudes/Professor Groupe Multimedia/Multimedia Group Traitement du Signal et
Re: connection ceremony for iframe postMessage communications
On Thu, Feb 9, 2012 at 11:49 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/9/12 1:15 PM, John J Barton wrote:
This leads developers to look for events that will tell them about
'load' on iframes, and that leads them to try
iframe.contentWindow.addEventListener(). It works fine for same-domain
iframes, but fails for cross-domain.
Adding a load listener to the iframe element itself should work for this,
no?
I guess you mean: by issuing
iframe.addEventListener('load', handler, false);
you get notified when the iframe load event has completed (but you
don't need to touch the contentWindow property).
This will work if the iframe ensures that it completes its connection
work before 'load'. This prevents the iframe from using async loading
for the scripts that create the connection and for any code that
handles messages from the parent. Which, in a typical iframe
component, would be all the code, since its main job is to provide for
the parent.
In addition this solution requires that the above addEventListener be
attached after the iframe is inserted (so the iframe exists) but
before the parent's 'load' event (which is after the iframe load and
thus too late.
So I'd say it does not solve the original problem and it's hard to use
too. Other than that it's a fine idea ;-).
jjb
Re: Templates 2: The Real World
On Thu, Feb 9, 2012 at 6:56 AM, Rick Waldron waldron.r...@gmail.com wrote: Hey everyone, I've been following the HTML Parsing and the template element thread/conversation since it began yesterday and it's very interesting, but one thing keeps coming to mind - has anyone working on template spent any significant time using the existing web template systems and practices? Here are a few that are fairly common and in production use: Mustache.js (logic-less) https://github.com/janl/mustache.js Embedded.js (logic) http://embeddedjs.com/ JST (gaining developer mindshare) http://ricostacruz.com/backbone-patterns/#jst_templates This list is by no means intended to be comprehensive or to imply any endorsement - in fact, I don't use any of these (I use underscore.js's super simple pre-compiled templates) Benchmarking information: http://www.viget.com/extend/benchmarking-javascript-templating-libraries/ Short answer: yes. Particularly, I know that Rafael has spent significant time with several of the templating systems, and Dimitri and several others have had at least a decent exposure to them and the developers of them. ~TJ
Re: connection ceremony for iframe postMessage communications
On Thu, Feb 9, 2012 at 11:49 AM, Boris Zbarsky bzbar...@mit.edu wrote:
That doesn't help with the second problem, of course
Ok here are some ideas, riffing off the web messaging doc
1 To iframe element add:
readonly attribute MessagePort port;
'message' events from the iframe to the containing window (via
window.parent.postMessage) will be delivered to any port listener (as
well as the global window handler).
This solves the multiplexing part, the container listens to a
per-iframe object.
'connect' event would be raised and delivered (synchronously) as soon
as the iframe issues window.parent.addEventListener('message'...) and
vice versa.
This solves the async start up part, each side waits for 'connect'
before issuing its first postMessage. The 'connect' for the
second-place racer triggers the first real message.
Pro: also solves the
cross-domain-iframes-don't-really-have-contentWindow problems I
discussed before.
familiar addEventListener API, reuses MessagePort
existing iframe code would just work
2. Have HTMLIFrameElement implement MessagePort.
This is similar to #1 but the message port functions are attached to
the iframe element directly rather than to its port property.
Pro: resembles Worker
Con: resembles Worker.
3. To window add:
[TreatNonCallableAsNull] attribute Function? onconnect;
The function would be called when the iframe issues
window.parent.addEventListener('message')
The onconnect event delivers a 'port'; the event.target would be the
iframe element
This solves the multiplexing problem: the container listens to a
per-iframe port object. Container can compare the event.target to its
iframes to decide which port is associated with which iframe.
This solves the async startup by causing the container to act like
a server: it must listen for connections early.
(Modeled on
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#handler-sharedworkerglobalscope-onconnect,
since the parent window is shared by all of its enclosed iframes )
This second one seems like it solves the async problem by cheating.
Couldn't we just issue addEventListener('message',...) first in the
parent window? The reason 'connect' is better is that it is
out-of-band. If we use 'message' for setting up the connection, then
we must hold postMessage traffic until we get the first 'message'.
Thus the logic in the message handler must have two paths switching on
'first', exactly the problem we try to avoid. With 'connect', the
'message' handler just focuses on communications, not set up.
Pro: A bit more modern, as it follows SharedWorkers
Seems like it could be expanded to inter-window communications
a la Web Intents
Again it seems like the iframe code is all the same.
While I have experience with the iframe problems, I don't have
experience with the features I've cobble together here. Any feedback?
If I had any hints about the issues involved in a real implementation
and standard I'd work on simulating this with JS.
jjb
Re: safeguarding a live getData() against looping scripts? (was: Re: clipboard events)
On Wed, 18 May 2011, Daniel Cheng wrote: On Wed, May 18, 2011 at 16:54, Hallvord R. M. Steen hallv...@opera.comwrote: Not 100% sure what you mean by concerns - do you mean for example if I drag a selection that embeds local images from my local word processing application to an online editor? I don't know how/if DnD handles this use case. CCing Ian. We're going out of our way to do lots of special processing for HTML in a paste. Why doesn't a drop of HTML get the same treatment? Presumably the scenario is that hostile page A provides some content and gets the user to select and copy or drag it to page B's contentEditable region, including any script in the selection, which once pasted becomes a cross-site scripting vulnerability. As far as I see it, the right way to solve this is for dragging, copying, dropping, and pasting of HTML to filter the DOM using a whitelist. It's not clear to me that this needs to be done in an interoperable way. I've mentioned this in the drag-and-drop spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: connection ceremony for iframe postMessage communications
On Thu, 9 Feb 2012, John J Barton wrote: However the solution has two significant problems: 1. There is no way to know if portToOtherWindow is connected before you issue postMessage() Just have the target message you when it's ready. 2. All iframes send messages to the same handler. Pass a MessagePort to the target when you start a new conversation, and do the rest of the conversation on that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: connection ceremony for iframe postMessage communications
On Thu, Feb 9, 2012 at 4:42 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 9 Feb 2012, John J Barton wrote:
However the solution has two significant problems:
1. There is no way to know if portToOtherWindow is connected before
you issue postMessage()
Just have the target message you when it's ready.
Ah, ok, just to translate (in case anyone understood what I was
talking about before): there already exists an out-of-band
introduction system, the global postMessage(), which can be used to
set up the in-band channel by sending MessageChannel ports as
Transferables.
Let me see if I can understand this.
Both sides create MessageChannel objects;
both sides window.addEventListener('message', handler, false)
both sides issue other.postMessage(..., *, [channel.port2]);
The second-place finisher in the race succeeds in posting its port2 to
the first-place racer. The first-place racer knows it 'won' because it
gets the port. But how does the second-place racer know it should use
channel.port1 rather than continue waiting? I guess the first-place
racer can send an ACK.
If yes, then this ACK message needs to be standard for cross-domain iframes.
We also need the containing window's global introduction handler to
associate the given port with the correct iframe. The difficulty here
is that no property of event.source is available (similar I suppose to
iframe.contentWindow having nothing but errors to offer beyond only
postMessage). Experimentally
event.source === other
is true in the handler. Is this given by the standard?
2. All iframes send messages to the same handler.
Pass a MessagePort to the target when you start a new conversation, and
do the rest of the conversation on that.
Yes this part is cool.
jjb
Re: connection ceremony for iframe postMessage communications
On Thu, 9 Feb 2012, John J Barton wrote:
On Thu, Feb 9, 2012 at 4:42 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 9 Feb 2012, John J Barton wrote:
However the solution has two significant problems:
1. There is no way to know if portToOtherWindow is connected before
you issue postMessage()
Just have the target message you when it's ready.
What I meant was just to do this on the receiving side (inside the
iframe), after the onmessage handler has been set up (which we are
assuming happens after the 'load' event for some reason):
parent.postMessage('load', '*');
That way you don't have to depend on the 'load' event, you can just wait
for the message from the inner frame. Then when you get it, you know you
can start sending..
And when you do send, you just send a message whose contents are just a
single key saying what API endpoint you want, and a port, which you then
use for all communication for that particular API call.
No races or anything.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
