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

[Daniel Narvaez]

It implies more. Several web APIs uses the origin. For example IndexedDB,
XMLHttpRequest, WebSocket...

In this context it seems like same-origin should be generally non
problematic, assuming you can/want to trust activities... One might decide
to upload data for all the other activities somewhere public, for example.
But that's currently true also for Sugar on Linux, which I guess is why
Lionel is not worried about it.

LocalStorage and IndexedDB are an exception, they are problematic beyhond
just security because you are going to get conflicts between data stored by
different activities unless you namespace.

There might be other APIs that are problematic, I'm not sure and it's sort
of difficult to figure out without a document detailing which APIs uses
origin and how :/ Probably someone with more web hacking experience than me
would know better.


On 15 November 2013 00:44, Gonzalo Odiard <gonzalo at laptop.org> wrote:

> Let me understand this, when you talk about single-origin or
> multiple-origin,
> is only related to the LocalStorage access or imply something more?
>
> Gonzalo
>
>
>
>
> On Thu, Nov 14, 2013 at 7:50 PM, Daniel Narvaez <dwnarvaez at gmail.com>wrote:
>
>> Re server side. It would be necessary only with multi-origin. If you go
>> with single-origin there is no point.
>>
>> I'm honestly undecided between single and multi origin. I think multi
>> origin would be doing it right, but then I don't have a realistic way to
>> implement it that I'm really happy with. So...
>>
>> In any case I think it's more important to write a few cool activities
>> and have an UX we can proudly demo on Web/Android at the moment. I brought
>> up these issues because I think they are pretty fundamental and we should
>> be conscious of the approach we are taking but... we don't necessarily need
>> to find the perfect solution for them now.
>>
>> On Thursday, 14 November 2013, Lionel Laské wrote:
>>
>>>
>>> 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.
>>> 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 ..
>>>>
>>>
>>>
>>
>> --
>> Daniel Narvaez
>>
>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>


-- 
Daniel Narvaez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20131115/7618631e/attachment.html>