[Sugar-devel] A prototype of SugarWeb / SugarAndroid - Technical questions

[Manuel Quiñones]

2013/11/14 Lionel Laské <lionel at olpc-france.org>:
>
> My answer is: we should go to simplicity.
>
> Regarding the one or many origin. I think, one is better. It allow sharing
> LocalStorage between activities which simplify a lot.

Imagine two activities that store a color in localStorage.  If they
use the same key "color", one activity will override the value of the
other.  This is a major concern.  Same origin policy has more security
issues than this one.

> Security is not an issue, I don't see any risk of hack here :-) We should
> just indicate naming rules to avoid collision.
> Regarding running of activities, my idea was that new activities should be
> deployed locally (no remote execution). By the way, it don't forbid us to
> have a cloud view in the journal where remote activities could be listed
> then retrieve and deploy locally.
>
> Regarding client/server approach, I'm agree for Sugar on Linux but I don't
> understand why we need the same approach for Sugar Android and Sugar Web.
> Once again Sugar Web should be able to work alone without depending on
> server. So Sugar Android will not need to integrate a server neither depend
> to be connected. The lower the prerequisites is, the better it will be easy
> to port it on any platform (from a browser to Android, iOS, Windows 8...
> :-).
> To say it differently: if the server side is here only because a multi-layer
> architecture is better but there is no real need to have a server side, we
> should do without server side.
>
> Regarding API to access to the device, because nothing standard exist in
> web, we have to wait and just ignore it. For Android, we could use PhoneGap
> API that allow to do everything (Camera, Compass, Geolocation, ...).
>
> Do I miss something ?
>
>              Lionel.
>
>
>
>
> 2013/11/14 Manuel Quiñones <manuq at laptop.org>
>>
>> 2013/11/14 Daniel Narvaez <dwnarvaez at gmail.com>:
>> > Hi Manuel,
>> >
>> > current lack of standardization aside, there is another pretty
>> > fundamental
>> > security related issue here, that we probably need to make a conscious
>> > decision about.
>> >
>> > Those kind of API are usually associated to the web browser's web
>> > application frameworks, often requiring certain permissions. Thus the
>> > application launcher (and installer) are implemented in the browser
>> > itself,
>> > not in the content. So to get a Sugar like launcher (and "window"
>> > manager)
>> > you would need to patch or customize the web browser. That makes it
>> > harder
>> > to run Sugar, you need to install an application rather just going to a
>> > website, and I'm not too convinced we have resources to develop it
>> > anyway.
>> >
>> > Another possibility for us would be to this kind of stuff server side,
>> > at
>> > least when it's not hardware related (settings, journal etc). That
>> > doesn't
>> > make the security issue go away, but maybe there are ways we can provide
>> > that security through the normal client/server interaction.
>> >
>> > The situation of the various Sugars we have been discussing is pretty
>> > different in this regard
>> >
>> > * Sugar on Linux. We actually control the launcher there, though WebKit
>> > doesn't have a web application framework we can use. When these API will
>> > standardized I suppose we could hope generic support for one will be
>> > added.
>> > For now, one has been implemented in Chrome, so on an higher layer that
>> > we
>> > can't use.
>> > * Sugar on Android. If we wanted I guess we could add support for these
>> > an
>> > API in the native wrapper. The implementation would be on us though.
>> > * Sugar on a Web site. Well, there is no web application launcher by
>> > definition there.
>> >
>> > My feeling is that the most pragmatic approach would be to implement
>> > settings, datastore and similar APIs on the server. We can either use
>> > the
>> > current websocket protocol or implement something more web friendly as
>> > it as
>> > been suggested (for example http POST to store files). On Linux we can
>> > run
>> > the server locally. Sugar on Android is just a wrapper loading Sugar on
>> > a
>> > Web site from the remote server.
>> >
>> > That said I don't think there is a perfect solution given our resources
>> > and
>> > honestly I'm not really sure which of the realistic options is the best
>> > one.
>>
>> Absolutely.  I don't have the answer too.
>>
>> In the long term, I think we should keep an eye at mozilla's WebAPI.
>> They are the ones doing a complete web OS. But for a current,
>> realistic approach, I agree that a server might suffice for the non
>> hardware settings.
>>
>> --
>> .. manuq ..
>
>



-- 
.. manuq ..