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

Received on Monday, 26 September 2011 19:28:12 UTC