Re: [widgets] Killing file:// of evil (widget URI ready for pub)
I'm not sure if you're on device-apis, Marcos, but you might be interested in this - what happens when you no longer need to intercept localhost; http://www.w3.org/mid/6dfa1b20d858a14488a66d6eedf26aa35d61fed...@seldmbx03.corpusers.net Mark.
Re: [widgets] Killing file:// of evil (widget URI ready for pub)
Hi Marcos, On Sep 26, 2011, at 16:43 , Marcos Caceres wrote: > On Monday, September 26, 2011 at 4:31 PM, Robin Berjon wrote: >> Well, the advantage of a scheme is that it's solidly in the realm of the >> implementation to decide how to handle it. We've actually been bouncing >> ideas like the above around for a while (albeit with things like .app rather >> than .localhost) and it's a bit scary. It means that in some cases you're >> doing DNS resolution differently than the way in which you normally do it >> (which might just be relying on the system). > This is the problem I've run into at the moment. I can't seem to get around > it: > > * Either add sub domains to localhost in the "hosts" file > * use virtual hosts in Apache > * I don't think either gives me dynamic dns capabilities (for when I start > new widgets, I create a new subdomain… and no idea how to do it on Android… > there is no API, AFACT). > > All the java HTTP servers I have been looking at naturally assume a TCP/IP > socket. Replacing that with a, um, kinda native socket, is not really working > for me. Well, that's what you get for using Java in the first place — why would anyone do that? :) Depending on what platform you're using to implement this, this isn't a problem. For instance, in Gecko IIRC you can register yourself to be notified when a URI is about to be loaded, and you get not just the scheme but also (at least) the authority. This means that you could intercept calls to http://DEADBEEF.localhost and serve them yourself rather than ever hitting the network. I'm pointing out the implementation issue however because I have no idea if this approach is used elsewhere or if it would require some ugly hacking. Overall, the scheme approach uses a well-defined extensibility point in the architecture. Relying on magical DNS entries is really a hack (unless perhaps we register a TLD for it with defined behaviour. Oh gods no, it's already enough of a pain to register a scheme). If you want to support a local app engine access through the browser but not implemented in it, and that uses this DNS based approach then yeah you'll have to handle local DNS resolution. Note that the hosts file can be rewritten dynamically (by a process running as root). Plenty of tools (e.g. Localghost on Mac) do this sort of stuff. You can also run a local DNS server and hook yourself up to use it (I'm not sure if you're trying to build a real platform or just have fun here :). As for the server at the other end routing it properly that's a no-brainer: you just need to handle the Host header. But again it's not clear to me what you're trying to do — I'm just tossing solutions over the fence that have the shape of the problem you're describing. >> It means surprising results if you add >> c13c6f30-ce25-11e0-9572-0800200c9a66.app to your hosts file and see it do >> one thing in the browser and another in a widget. > > Yeah :( Or trying to stop a widget from getting into the resources of another > widget (referrer check to stop one widget getting into another widget seems > somewhat fragile)… and the battery sucking while(true){ } for the thread that > listens is not too nice either. Again, if you're implementing inside Gecko with the approach described above that's not a problem (IIRC it's implemented in Widgeon if you need example code — the problem of preventing cross-access for the http: scheme is no different from doing the same for widget:). You can simply control navigation policy, enforce same-origin, etc. If you're doing something different, well yes, you may be in trouble. > This presupposes that someone there will have an opinion :) I was, at least, > going to write my paper around this… but I imagine it will go a lot like… > "um, I tried doing this… it kinda didn't work, um… yeah… so, hhmm… would be > very useful, however" :). Knowing what doesn't work is also helpful — you could write a paper about failed approaches :) -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [widgets] Killing file:// of evil (widget URI ready for pub)
On Mon, Sep 26, 2011 at 5:26 PM, Mark Baker wrote: > On Mon, Sep 26, 2011 at 10:43 AM, Marcos Caceres > wrote: >>> There are however many useful benefits in tying a packaged web application >>> (using whatever packaging) to an origin, not the least of which is >>> same-origin policy and overall just being a regular web app (that may >>> happen to have been loaded differently). >> I still don't think it's that bad to do http://c13c6f30.whatever >> >> Mark, what is the issue with using sub.localhost? (i.e., why do you >> discourage using .localhost)? > > Sorry if I wasn't clear, but I wasn't discouraging it, just pointing > out that the implementer has many options. Ok, thanks for clarifying. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Killing file:// of evil (widget URI ready for pub)
On Mon, Sep 26, 2011 at 10:43 AM, Marcos Caceres wrote: >> There are however many useful benefits in tying a packaged web application >> (using whatever packaging) to an origin, not the least of which is >> same-origin policy and overall just being a regular web app (that may happen >> to have been loaded differently). > I still don't think it's that bad to do http://c13c6f30.whatever > > Mark, what is the issue with using sub.localhost? (i.e., why do you > discourage using .localhost)? Sorry if I wasn't clear, but I wasn't discouraging it, just pointing out that the implementer has many options. Mark.
Re: [widgets] Killing file:// of evil (widget URI ready for pub)
On Monday, September 26, 2011 at 4:31 PM, Robin Berjon wrote: > On Sep 23, 2011, at 18:26 , Mark Baker wrote: > > Well, this is progress, but it seems the only difference now between > > widget: and http: is the authority. And if that's the case, then > > instead of (from your example); > > > > widget://c13c6f30-ce25-11e0-9572-0800200c9a66/index.html > > > > why not go with this? > > > > http://c13c6f30-ce25-11e0-9572-0800200c9a66.localhost/index.html > > Well, the advantage of a scheme is that it's solidly in the realm of the > implementation to decide how to handle it. We've actually been bouncing ideas > like the above around for a while (albeit with things like .app rather than > .localhost) and it's a bit scary. It means that in some cases you're doing > DNS resolution differently than the way in which you normally do it (which > might just be relying on the system). This is the problem I've run into at the moment. I can't seem to get around it: * Either add sub domains to localhost in the "hosts" file * use virtual hosts in Apache * I don't think either gives me dynamic dns capabilities (for when I start new widgets, I create a new subdomain… and no idea how to do it on Android… there is no API, AFACT). All the java HTTP servers I have been looking at naturally assume a TCP/IP socket. Replacing that with a, um, kinda native socket, is not really working for me. Anyway, I don't think there is a way around this… I think the browser will always do it's own network request over TCP/IP and that will need to be intercepted through a socket (unless widget:// is supported natively). > It means surprising results if you add > c13c6f30-ce25-11e0-9572-0800200c9a66.app to your hosts file and see it do one > thing in the browser and another in a widget. Yeah :( Or trying to stop a widget from getting into the resources of another widget (referrer check to stop one widget getting into another widget seems somewhat fragile)… and the battery sucking while(true){ } for the thread that listens is not too nice either. > There are however many useful benefits in tying a packaged web application > (using whatever packaging) to an origin, not the least of which is > same-origin policy and overall just being a regular web app (that may happen > to have been loaded differently). I still don't think it's that bad to do http://c13c6f30.whatever Mark, what is the issue with using sub.localhost? (i.e., why do you discourage using .localhost)? > > Overall I'd rather wait for the outcome from the Offline Web Apps workshop to > have a definitive opinion on which approach is best. Be sure to be there! > http://www.w3.org/2011/web-apps-ws/ This presupposes that someone there will have an opinion :) I was, at least, going to write my paper around this… but I imagine it will go a lot like… "um, I tried doing this… it kinda didn't work, um… yeah… so, hhmm… would be very useful, however" :).
Re: [widgets] Killing file:// of evil (widget URI ready for pub)
On Sep 23, 2011, at 18:26 , Mark Baker wrote: > Well, this is progress, but it seems the only difference now between > widget: and http: is the authority. And if that's the case, then > instead of (from your example); > > widget://c13c6f30-ce25-11e0-9572-0800200c9a66/index.html > > why not go with this? > > http://c13c6f30-ce25-11e0-9572-0800200c9a66.localhost/index.html Well, the advantage of a scheme is that it's solidly in the realm of the implementation to decide how to handle it. We've actually been bouncing ideas like the above around for a while (albeit with things like .app rather than .localhost) and it's a bit scary. It means that in some cases you're doing DNS resolution differently than the way in which you normally do it (which might just be relying on the system). It means surprising results if you add c13c6f30-ce25-11e0-9572-0800200c9a66.app to your hosts file and see it do one thing in the browser and another in a widget. There are however many useful benefits in tying a packaged web application (using whatever packaging) to an origin, not the least of which is same-origin policy and overall just being a regular web app (that may happen to have been loaded differently). Overall I'd rather wait for the outcome from the Offline Web Apps workshop to have a definitive opinion on which approach is best. Be sure to be there! http://www.w3.org/2011/web-apps-ws/ -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [widgets] Killing file:// of evil (widget URI ready for pub)
On Friday, September 23, 2011 at 8:33 PM, Charles Pritchard wrote: > I've some strong reservations about expanding the scheme into dns-land. I''m still looking into this, but I don't know how we get around that. If you have any suggestions, sure would like to hear them. > > > > On Sep 23, 2011, at 9:59 AM, Mark Baker (mailto:dist...@acm.org)> wrote: > > > On Fri, Sep 23, 2011 at 12:41 PM, Marcos Caceres > (mailto:w...@marcosc.com)> wrote: > > > > On Thu, Sep 22, 2011 at 7:16 PM, Marcos Caceres > > > > mailto:marcosscace...@gmail.com)> wrote: > > > > Well, this is progress, but it seems the only difference now between > > > > widget: and http: is the authority. And if that's the case, then > > > > instead of (from your example); > > > > > > > > widget://c13c6f30-ce25-11e0-9572-0800200c9a66/index.html > > > > > > > > why not go with this? > > > > > > > > http://c13c6f30-ce25-11e0-9572-0800200c9a66.localhost/index.html > > > That might totally work:) The spec just needs to sandbox the request so > > > apps don't request resources from each other (i.e., I just hope it's not > > > hard to implement a kind of restricted-local-http server that widget:// > > > tries to be… hopefully you get what I mean here: requests/response is > > > instance specific, except where this could be used with postMessage… > > > Also, I was worried about muddying-up the two "protocols", even if they > > > are both http. > > > > > > Another minor nit is that some runtimes already implement widget:// … but > > > then again, they also implement http, so it might all be ok. Might have a > > > crack at trying to implement this on Android. > > > > That's great to hear, Marcos! I'll look for it in the market 8-) > > > > FWIW - I should have mentioned this before - I wouldn't recommend > > requiring the use of ".localhost", just mention it as one option that > > implementers might consider. For devices with their own IPs or DNS > > names, they should also have the option for using a more traditional > > authority; > > > > http:///widget-instance/c13c6f30-ce25-11e0-9572-0800200c9a66/index.html > > > > And obviously, in those cases, whether access is opened up to those > > widgets from outside the device is up to the implementers, carriers > > (where relevant), or (where I hope we get to eventually) user-defined > > access control policies. But it does create some interesting > > possibilities! > > > > Mark.
Re: [widgets] Killing file:// of evil (widget URI ready for pub)
I've some strong reservations about expanding the scheme into dns-land. On Sep 23, 2011, at 9:59 AM, Mark Baker wrote: > On Fri, Sep 23, 2011 at 12:41 PM, Marcos Caceres wrote: >>> On Thu, Sep 22, 2011 at 7:16 PM, Marcos Caceres >>> mailto:marcosscace...@gmail.com)> wrote: >>> Well, this is progress, but it seems the only difference now between >>> widget: and http: is the authority. And if that's the case, then >>> instead of (from your example); >>> >>> widget://c13c6f30-ce25-11e0-9572-0800200c9a66/index.html >>> >>> why not go with this? >>> >>> http://c13c6f30-ce25-11e0-9572-0800200c9a66.localhost/index.html >> That might totally work:) The spec just needs to sandbox the request so apps >> don't request resources from each other (i.e., I just hope it's not hard to >> implement a kind of restricted-local-http server that widget:// tries to be… >> hopefully you get what I mean here: requests/response is instance specific, >> except where this could be used with postMessage… Also, I was worried about >> muddying-up the two "protocols", even if they are both http. >> >> Another minor nit is that some runtimes already implement widget:// … but >> then again, they also implement http, so it might all be ok. Might have a >> crack at trying to implement this on Android. > > That's great to hear, Marcos! I'll look for it in the market 8-) > > FWIW - I should have mentioned this before - I wouldn't recommend > requiring the use of ".localhost", just mention it as one option that > implementers might consider. For devices with their own IPs or DNS > names, they should also have the option for using a more traditional > authority; > > http:///widget-instance/c13c6f30-ce25-11e0-9572-0800200c9a66/index.html > > And obviously, in those cases, whether access is opened up to those > widgets from outside the device is up to the implementers, carriers > (where relevant), or (where I hope we get to eventually) user-defined > access control policies. But it does create some interesting > possibilities! > > Mark. >
Re: [widgets] Killing file:// of evil (widget URI ready for pub)
On Fri, Sep 23, 2011 at 12:41 PM, Marcos Caceres wrote: >> On Thu, Sep 22, 2011 at 7:16 PM, Marcos Caceres >> mailto:marcosscace...@gmail.com)> wrote: >> Well, this is progress, but it seems the only difference now between >> widget: and http: is the authority. And if that's the case, then >> instead of (from your example); >> >> widget://c13c6f30-ce25-11e0-9572-0800200c9a66/index.html >> >> why not go with this? >> >> http://c13c6f30-ce25-11e0-9572-0800200c9a66.localhost/index.html > That might totally work:) The spec just needs to sandbox the request so apps > don't request resources from each other (i.e., I just hope it's not hard to > implement a kind of restricted-local-http server that widget:// tries to be… > hopefully you get what I mean here: requests/response is instance specific, > except where this could be used with postMessage… Also, I was worried about > muddying-up the two "protocols", even if they are both http. > > Another minor nit is that some runtimes already implement widget:// … but > then again, they also implement http, so it might all be ok. Might have a > crack at trying to implement this on Android. That's great to hear, Marcos! I'll look for it in the market 8-) FWIW - I should have mentioned this before - I wouldn't recommend requiring the use of ".localhost", just mention it as one option that implementers might consider. For devices with their own IPs or DNS names, they should also have the option for using a more traditional authority; http:///widget-instance/c13c6f30-ce25-11e0-9572-0800200c9a66/index.html And obviously, in those cases, whether access is opened up to those widgets from outside the device is up to the implementers, carriers (where relevant), or (where I hope we get to eventually) user-defined access control policies. But it does create some interesting possibilities! Mark.
Re: [widgets] Killing file:// of evil (widget URI ready for pub)
On Friday, September 23, 2011 at 6:26 PM, Mark Baker wrote: > On Thu, Sep 22, 2011 at 7:16 PM, Marcos Caceres > mailto:marcosscace...@gmail.com)> wrote: > Well, this is progress, but it seems the only difference now between > widget: and http: is the authority. And if that's the case, then > instead of (from your example); > > widget://c13c6f30-ce25-11e0-9572-0800200c9a66/index.html > > why not go with this? > > http://c13c6f30-ce25-11e0-9572-0800200c9a66.localhost/index.html That might totally work:) The spec just needs to sandbox the request so apps don't request resources from each other (i.e., I just hope it's not hard to implement a kind of restricted-local-http server that widget:// tries to be… hopefully you get what I mean here: requests/response is instance specific, except where this could be used with postMessage… Also, I was worried about muddying-up the two "protocols", even if they are both http. Another minor nit is that some runtimes already implement widget:// … but then again, they also implement http, so it might all be ok. Might have a crack at trying to implement this on Android.
Re: [widgets] Killing file:// of evil (widget URI ready for pub)
On Thu, Sep 22, 2011 at 7:16 PM, Marcos Caceres wrote: > I've updated the Widget URI scheme spec, and it's now ready for publication > as a new WD. > > What's new? I completely rewrote it. Now defines a dereferencing model that > fakes HTTP responses (so hopefully now will work with JQuery mobile + XHR). > > New abstract: > > The widget URI scheme spec defines the widget URI scheme and rules for > dereferencing a widget URI, which can be used to address resources inside a > package (e.g., a [Widgets] package or similarly packaged application). The > dereferencing model relies on HTTP semantics to return resources in a manner > akin to a HTTP GET request. Doing so allows this URI scheme to be used with > other technologies that rely on HTTP responses to function as intended, such > as [XMLHTTPRequest]. > > As always, comments welcomed. Well, this is progress, but it seems the only difference now between widget: and http: is the authority. And if that's the case, then instead of (from your example); widget://c13c6f30-ce25-11e0-9572-0800200c9a66/index.html why not go with this? http://c13c6f30-ce25-11e0-9572-0800200c9a66.localhost/index.html Mark.
Re: [widgets] Killing file:// of evil (widget URI ready for pub)
Marcos Caceres wrote: I've updated the Widget URI scheme spec, and it's now ready for publication as a new WD. Link for others is: http://dev.w3.org/2006/waf/widgets-uri What's new? I completely rewrote it. Now defines a dereferencing model that fakes HTTP responses (so hopefully now will work with JQuery mobile + XHR). This has some fairly wide-reaching applications so thanks! As always, comments welcomed Some quick comments from first reading: 1. I wonder if the spec should also cover 'Relative URI Reference Resolution' as per the previous spec? Some examples for that would also be useful. 2. In the spec, the term 'synthesizing' is not defined. What does this section mean? 3. Do we need to be explicit on the mapping of widget uri components to window.location? Thanks, Rich
[widgets] Killing file:// of evil (widget URI ready for pub)
I've updated the Widget URI scheme spec, and it's now ready for publication as a new WD. What's new? I completely rewrote it. Now defines a dereferencing model that fakes HTTP responses (so hopefully now will work with JQuery mobile + XHR). New abstract: The widget URI scheme spec defines the widget URI scheme and rules for dereferencing a widget URI, which can be used to address resources inside a package (e.g., a [Widgets] package or similarly packaged application). The dereferencing model relies on HTTP semantics to return resources in a manner akin to a HTTP GET request. Doing so allows this URI scheme to be used with other technologies that rely on HTTP responses to function as intended, such as [XMLHTTPRequest]. As always, comments welcomed. Will probably sit on it for 2 weeks and then move it to LC. Kind regards, Marcos