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)
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 dist...@acm.org (mailto:dist...@acm.org) wrote: On Fri, Sep 23, 2011 at 12:41 PM, Marcos Caceres w...@marcosc.com (mailto:w...@marcosc.com) wrote: On Thu, Sep 22, 2011 at 7:16 PM, Marcos Caceres marcosscace...@gmail.com (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://device-name-or-ip/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 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 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 Mon, Sep 26, 2011 at 10:43 AM, Marcos Caceres marcosscace...@gmail.com 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 Mon, Sep 26, 2011 at 5:26 PM, Mark Baker dist...@acm.org wrote: On Mon, Sep 26, 2011 at 10:43 AM, Marcos Caceres marcosscace...@gmail.com 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)
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)
Marcos Caceres wrote: I've updated the Widget URI scheme spec, and it's now ready for publication as a new WD. Link for others is: http://dev.w3.org/2006/waf/widgets-uri What's new? I completely rewrote it. Now defines a dereferencing model that fakes HTTP responses (so hopefully now will work with JQuery mobile + XHR). This has some fairly wide-reaching applications so thanks! As always, comments welcomed Some quick comments from first reading: 1. I wonder if the spec should also cover 'Relative URI Reference Resolution' as per the previous spec? Some examples for that would also be useful. 2. In the spec, the term 'synthesizing' is not defined. What does this section mean? 3. Do we need to be explicit on the mapping of widget uri components to window.location? Thanks, Rich
Re: [widgets] Killing file:// of evil (widget URI ready for pub)
On Thu, Sep 22, 2011 at 7:16 PM, Marcos Caceres marcosscace...@gmail.com 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)
On Friday, September 23, 2011 at 6:26 PM, Mark Baker wrote: On Thu, Sep 22, 2011 at 7:16 PM, Marcos Caceres marcosscace...@gmail.com (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 Fri, Sep 23, 2011 at 12:41 PM, Marcos Caceres w...@marcosc.com wrote: On Thu, Sep 22, 2011 at 7:16 PM, Marcos Caceres marcosscace...@gmail.com (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://device-name-or-ip/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 dist...@acm.org wrote: On Fri, Sep 23, 2011 at 12:41 PM, Marcos Caceres w...@marcosc.com wrote: On Thu, Sep 22, 2011 at 7:16 PM, Marcos Caceres marcosscace...@gmail.com (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://device-name-or-ip/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.
