script inclusion in storage-first and some other random thoughts

[Michiel de Jong]

hi!

i just had a couple of thoughts about how we're now using the launch
parameters 'storage_root=' and 'storage_api=' in the storage-first [1]
scenario.

first of all, a bit of a technicality - but if we will add more
services than just remotestorage (for instance sockethub [2]) then it
would make sense to namespace the launch parameters by the service
they relate to. Also, remoteStorage.js should then have an option to
leave the access_token parameter accessible to potential other
libraries, related to the other services made available to the app at
launch time.

and second, i was thinking, once you give launch parameters, you could
also tell the app to include a script that lives on the storage. This
would move the API between app and storage provider up a bit (a "part"
of the storage provider would be included in the app in the form of a
script include when it loads).

In the app-first scenario you could do a similar thing where a script
is hosted at a location that is advertised in webfinger, and then
since the included script would be doing same-origin xhr, you would
not need CORS. You would probably still use bearer tokens to make sure
each app only accesses what it's allowed to access.

I don't think this would be a good idea, because the security
implications seem quite mirky. For instance, an attacker could post a
malicious link to an app you trust, that has a malicious script
include, and you could no longer trust the app purely based on what
you see in your address bar, you would have to be careful where you
launch it from. To some extent this is actually already true: you
could be following a link to an app, expecting to log in app-first,
and then find "Oh, i was still logged in", whereas really the link
included malicious storage provider details, and will start receiving
data from the app which you think is going to your storage.

In general, apart from being able to support legacy browsers, i see no
advantage of this technique over current one. If you see
remoteStorage.js as a shim that polyfills (imaginary) missing
browser/device capabilities, then it might make sense, because the API
of those browser capabilities would have to be defined anyway, and so
you would need to standardize only one API definition instead of two.
But i don't think we're there yet, and i think there certainly is a
need for the remotestorage spec as a standard cross-origin restful
storage API.

Also, I think the fact that we define the API at the wire level is one
of the strong points. It's a natural bottleneck, and leaves the app
developer free to fork remoteStorage.js and change its functionality.
All other Backend-as-a-Service (BaaS) libraries i know of require the
app to include a script at publish-time, from one domain that is
central to that BaaS platform, and then define the API at the level of
where the app accesses the included library. The main unique
difference between remotestorage and other BaaS platforms is, i think,
that it links the app and the storage only at run-time, and not at
publish-time.

This leads to several pros and cons that make it unique: the user
needs to provide her own backend, and cannot use the app if she
doesn't have one. otoh, the app has no say in which backend the user
chooses (freedom of server provider choice, independent of app choice,
which was always our central goal). Another unique point i think is
that we organize data and access to it per module, and not per app.
This means more control to the user over her choice of app, because in
other BaaS platforms, even though the app publisher is not the hosting
provider, data still gets locked into apps.

So all in all i think we made the right choices. I will separate the
definition of the cross-origin API and of the storage-first app-launch
process into two specs. i'm not sure whether we should keep the
app-first scenario (which implies the whole webfinger+OAuth part) as
required, or just say an app should provide a manifest that can be
drag-dropped onto a storage-first dashboard.

Ciao,
Michiel

[1] http://lanyrd.com/2012/unhosted/sygwp/
[2] http://lanyrd.com/2012/unhosted/sygxb/ (with apologies for the quality)

[Thad Guidry]

That 'script include' puts me on the worry fence as a possible vector for injection.

--
-Thad
http://www.freebase.com/view/en/thad_guidry

[Melvin Carvalho]

On 15 November 2012 15:52, Thad Guidry <thadg...@gmail.com> wrote:

That 'script include' puts me on the worry fence as a possible vector for injection.

Good point, tho Michiel did mention that above.

In the RWW we are thinking about this problem as well.

One way to consider a script is just another app/agent that does things for you.  It may sit on the same server as your data store (for zero latency), in which case the auth is usually done via unix/apache or the same abstaction should be able to run in, say, a cluster, on your freedombox, or over the whole web.
 

--
-Thad
http://www.freebase.com/view/en/thad_guidry

--