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 <distobj@acm.org (mailto:distobj@acm.org)> wrote:
>  
> > On Fri, Sep 23, 2011 at 12:41 PM, Marcos Caceres <w3c@marcosc.com (mailto:w3c@marcosc.com)> wrote:
> > > > On Thu, Sep 22, 2011 at 7:16 PM, Marcos Caceres
> > > > <marcosscaceres@gmail.com (mailto:marcosscaceres@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.

Received on Monday, 26 September 2011 12:04:27 UTC