Web Applications

New security model for widgets, Opera 10 and network="public"

By Hans S. Tømmerholt. Wednesday, 14. January 2009, 13:47:58

For Opera 10, we're introducing a new security model which among other things means that widgets don't have network access on by default. In order to enable network access for non-intranet sites, add a network attribute to the widget element in the config.xml of your widget with the value public.

<widget network="public">
...
</widget>

This will make your widget work as intended in Opera 10, but will not affect previous versions. Older browsers will simply ignore the network attribute and give your widget access as per the existing security model. We'll update the documentation with more details as we get closer to a release of Opera 10.

Note that this affects http://widgets.opera.com. If you submit a widget to us without the network attribute, the widget will probably not work in Opera 10. Consequently, your widget will not be approved for that version, and wont show up in the lists of widgets when people browse the site.

Slides from EuroPython08

Comments

Aux # 14. January 2009, 14:06

Will widgets be able to send XMLHTTPRequests to HTTPS? I'm currently working on one project which requires secured login. Inability to work with HTTPS will cause a lot of trouble for me...

Aux # 14. January 2009, 14:09

Another question is about Server Sent Events. Basically I'm working on a mupliplayer game running in a widget. There is one domain (if future may be multiply) and three ports: HTTP for insecure data (XHR access), HTTPS for logging in and other sensitive stuff (XHR access) and one for SSE. Will this combination work smoothly?

For_d # 14. January 2009, 15:25

You must enable access to any protocols other than http by adding this to the security section of the widget's config.xml.

http://dev.opera.com/articles/view/opera-widgets-security-model/

In the new model, https will be allowed as a protocol by default.

Aux # 14. January 2009, 15:34

OK, thanks!

mabdul # 14. January 2009, 15:51

Why giving the widget only access to the local part? for what is this good for? I mean if the author want something bad... that makes no sence for ME. can you explain it a bit more?

For_d # 15. January 2009, 12:01

@mabdul: I'm not sure I understand the question. If you don't specify anything in the network attribute, or omit it, your widget will have -no- network access. Local or otherwise.

mabdul # 15. January 2009, 16:59

and for what is that? if soembody want that the widget have access, he will uild taht into, if this shouldn't, the widget won't do it (and the widget won't do this also, because nothing is build into that sends data)

so what for is that?
I mean i hope you understand me: if the developer want the access he get the access, if he doesn't want, he won't build anything in...

_Grey_ # 15. January 2009, 20:12

@mabdul: My guess would be that widgets are harder to exploit if less widgets have 'useless' privileges, thus reducing the attack surface. Still, I'm not sure and I'd like to see an explanation from an expert, as well.

For_d # 16. January 2009, 11:26

First of all: There are use cases for widgets without network access. Storing different kinds of notes, clocks, games, etc.

The reason for the change is primarily to align ourselves better with the W3C, which are using an opt-in network model in their upcomming widgets spec.

Then, yes, the idea is to remove unnecessary access from those widgets that don't actually require it, reducing the risks from exploiting errors in these widgets. More so than trying to stop harmful widgets. The idea is that by requiring users to write network="public" to actually get access, devs will be lazy when they don't actually want that and omit it.

The change in architecture also allows us to develop some features down the line, which we'll get back to.