[DISCUSS] Add abstraction layer for WebKit1/2 apis

[samdroid-apps]

Sugar and activities use WebKit to display content in many places.
Unfortunatly, while the world moves to WebKit2, some Sugar devices
can not come to the party. Namely, the XOs. Therefore, it may be
advantageous to add an abstraction layer to support both platforms.

This abstraction layer is basically the WebKit2 api. This is what
we want for the future - so we can remove the abstraction layer
when we drop WebKit1 support.

Please Discuss

Is this the right way to do it? Is it even good to support something as insecure as WebKit1? Is there any hope of getting WebKit2 on any of the XOs?

[davelab6]

The xo-1 seems unlikely to me to ever support webkit2 because the js jit needs hardcore engineering to work on its processor

[samdroid-apps]

Hum, that's bad.

Some of the webkit1 compat code is very dodgy. Maybe it would be better if the XO packager just included a patch to revert the WebKit2 port in sugarlabs/sugar? @quozl, would that be an acceptable solution?

[quozl]

Thanks for asking, I wasn't subscribed until mentioned.

the js jit needs hardcore engineering to work on its processor

I'm not planning any hardcore engineering to backport WebKit2 to AMD Geode; no idea how big a job it would be; willing to help anybody who starts it. We don't make any models with the AMD Geode at the moment.

if the XO packager just included a patch to revert the WebKit2 port in sugarlabs/sugar?

I'm already forked because of changes that you or Sugar Labs don't want. Cost of maintaining my OLPC Fedora 18 fork will go up over time, but I was hopeful of being able to handle it. This change will be a step in that cost. If you want to reduce the cost, work to make the revert as small as possible. If you want to increase the cost, make the revert as large and invasive as possible. It really depends on whether you have users for whom the next release is interesting.

I'll maintain a separate fork for my Ubuntu 16.04 and later builds, in which a move to WebKit2 will be easy as pie.

[davelab6]

I'm already forked because of changes that you or Sugar Labs don't want.

I would like to see the delta between Sugar Labs and OLPC's private forks reduced, because the majority of Sugar uses are getting Sugar from OLPC, and I want to develop for those users. How big is the delta, and who in Sugar Labs was objecting to those changes, and are they still involved?

[davelab6]

Maybe it would be better if [@quozl] just included a patch to revert the WebKit2 port in sugarlabs/sugar?

I really don't like this approach, because it means SL is abandoning support for XO-1s, while 100,000s of kids still use XO-1s.

[quozl]

SL is abandoning support for XO-1s, while 100,000s of kids still use XO-1s.

Given the size, language preferences and skills shown by Sugar Labs developers, it is hard to imagine it supporting the XO-1 software stack in entirety, especially against a rapidly changing upstream distribution. 😀

[davelab6]

Given the size, language preferences and skills shown by Sugar Labs developers,

I think there are today about a dozen active smalltime contributors, who tend not to have long experience, and prefer scripting languages like Python and JavaScript. Do you agree?

it is hard to imagine it supporting the XO-1 software stack in entirety, especially against a rapidly changing upstream distribution.

I don't expect those dozen people to support the entire XO-1 stack; but I expect us to make Python/JavaScript that runs on the XO-1 stack that you maintain.

[quozl]

I think there are today about a dozen active smalltime contributors, who tend not to have long experience, and prefer scripting languages like Python and JavaScript. Do you agree?

Yes; your contributors seem very comfortable in these languages and associated tools.

I don't expect those dozen people to support the entire XO-1 stack; but I expect us to make Python/JavaScript that runs on the XO-1 stack that you maintain.

Thanks, good to hear. I wish I had the resources to bring that stack a little more up to date, but that's out of my control.

[davelab6]

I wish I had the resources to bring that stack a little more up to date, but that's out of my control.

What kind of resources would you need?

On @samdroid-apps 's original topic:

Sugar and activities use WebKit to display content in many places.
Unfortunately, while the world moves to WebKit2, some Sugar devices
can not come to the party. Namely, the XOs. Therefore, it may be
advantageous to add an abstraction layer to support both platforms.

This abstraction layer is basically the WebKit2 api. This is what
we want for the future - so we can remove the abstraction layer
when we drop WebKit1 support.

Is this the right way to do it?

I don't think we should have a goal of dropping WebKit1 support until 2020.

But I think abstracting away the difference between WebKit 1 and 2 sounds good, so that Activities don't have to think about it.

Is it even good to support something as insecure as WebKit1?

XO-1s need a web browser engine, and this is the best we can get, so yes, I think so; there is a LOT of stale and insecure software on any XO-1, even running the latest OLPC OS distro, and there's nothing that can be done about that. I don't think inherent insecurity should be a concern of ours.

[samdroid-apps]

How fast does an XO run when you have shell popped on it? How many of
these vulnerabilities are being exploited in the wild? Comically long
list of security bugs: https://webkitgtk.org/security/WSA-2015-0002.html

On Mon, Jul 11, 2016 at 2:25 PM, Dave Crossland
notifications@github.com wrote:

I wish I had the resources to bring that stack a little more up to
date, but that's out of my control.

What kind of resources would you need?

On @samdroid-apps 's original topic:

Sugar and activities use WebKit to display content in many places.
Unfortunately, while the world moves to WebKit2, some Sugar devices
can not come to the party. Namely, the XOs. Therefore, it may be
advantageous to add an abstraction layer to support both platforms.

This abstraction layer is basically the WebKit2 api. This is what
we want for the future - so we can remove the abstraction layer
when we drop WebKit1 support.

Is this the right way to do it?

I don't think we should have a goal of dropping WebKit1 support until
2020.

But I think abstracting away the difference between WebKit 1 and 2
sounds good, so that Activities don't have to think about it.

Is it even good to support something as insecure as WebKit1?

XO-1s need a web browser engine, and this is the best we can get, so
yes, I think so; there is a LOT of stale and insecure software on any
XO-1, even running the latest OLPC OS distro, and there's nothing
that can be done about that. I don't think inherent insecurity should
be a concern of ours.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[davelab6]

On 11 July 2016 at 00:31, Sam notifications@github.com wrote:

How fast does an XO run when you have shell popped on it?

(I don't understand what you mean :)

How many of
these vulnerabilities are being exploited in the wild? Comically long
list of security bugs: https://webkitgtk.org/security/WSA-2015-0002.html

I'm well aware that webkit1 is insecure. But what else can XO-1 users use?

[tony37]

According to this discussion: https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/
It would appear possible to 'turn-off' the most computationally intensive compilation tricks. While the javascript might run slower, it wouldn't be slower than the present code.

[davelab6]

@tony37 great find! :)

[samdroid-apps]

Ok, so I will go the easy route and do not include an abstraction layer in Sugar. Sugar can be ported the WebKit2, and the patch can be reverted when it is packages for the XO?

Is that ok?

[samdroid-apps]

Ok, I have updated the sugar patch, and this one is no longer relevant.