Installation changes - new security defaults, without lock-in
We are always worried about users' security at Opera, and of course this applies to extensions as well. There are no cast-iron guarantees, but we do a code review on extensions submitted to us, we think carefully about the security implications of capabilities we allow for extensions, and we're on the lookout for what users and developers do and how to make it work better for them.
One part of this is making the normal installation go through addons.opera.com by default. Here is what we are planning...
One part of this is making the normal installation go through addons.opera.com by default. Here is what we are planning...
We know there are many extensions hosted on third-party sites (although it is impossible to know how many). We don't want to make it impossible to do this, because there are good reasons why people choose it. Inside Opera we ourselves have extensions designed to improve the efficiency of working with internal systems. We are not able to make these public, so they are hosted on intranet servers.
At the same time, a simple dialog about security that lets a user click to install malware isn't enough protection for the average user. Both anecdotal evidence and formal studies continually report that many users will simply accept whatever risk they don't understand, and even if it applies to a minority it is still a lot of actual people at risk. And we have found people trying to use the power of Opera's extensions framework as a vehicle to construct malware.
So we are going to change the default procedure to install extensions. For users who understand the risks we will require explicitly white-listing sites before you can install extensions from them. By default, addons.opera.com will be whitelisted. We will also maintain developer mode - dragging a config.xml from an unzipped extension, so testing and prototyping is easy.
We're letting you know the direction we are going to avoid surprises, and will keep you informed as we implement the changes in the browser. We understand that this could be inconvenient for some, but we think this is the best compromise we can make between maintaining an open platform that leaves you in control, and offering the level of security that Opera users expect (and which we want them to continue to enjoy).
Readers' comments 20
Left under the original article, as archived.
About this article
| Published in | Add-ons blog |
|---|---|
| Date | June 22, 2012 |
| Author | Charles McCathieNevile |
| Tags | developers, security, moderation, catalog |
| Original | Internet Archive |
ZotlanFriday, June 22, 2012 12:04:40 PM
So even if you only really trust that one extension from the site (because someone you trust recommended it to you for example) you'd never get a warning for extensions from that site again.
Remco LantingFriday, June 22, 2012 1:09:46 PM
The point not followed is "No external JavaScript is allowed. All JavaScript code must be contained in the extension. External APIs are ok"
Also the remote file included includes another file, which is minified, thereby violating "We must be able to review the code in a reasonable manner. Code shouldn't be obfuscated. Binary code is not ok."
If things like this make it on the trusted site, how will more nag-screens help people?
And the point Zotlan makes is a big one. Trusting *one* extension is something very different than trusting every extension from a single domain. Hosting an extension on my.opera.com servers with it's millions of users, trusting my.opera.com (or files.myopera.com) is giving *way* too much trust to a domain where people can upload stuff at will.
XenoAntaresFriday, June 22, 2012 1:14:25 PM
A less simplistic approach would consist of a two opera:config flags, let's call them
• AddonsDontAskIfWhitelisted = 0|1
• AddonsAllowFromForeignSources = 0|1
• and a whitelist,
all of which would be solely configurable by the "educated user" via opera:config.
That way following scenarios are possible:
By default, only allow addons from addon.opera.com. You might want to show an explanation and refer the user to addons.opera.com, if he tries to install an addon hosted elsewhere.
Ask for permission (and possibly warn) if trying to install from whitelisted.site, install smooth as ever from addons.opera.com.
Willingly install from whitelisted.site and addons.opera.com. (This may be useful for administrated installs in institutions or companies.)
Install quietly from addons.opera.com, ask/warn depending on AddonsDontAskIfWhitelisted installing from whitelisted.site, warn upon installation attempt via unknown site.
May sound overly complicated, but it is not. Less so for a user who does not want to configure: he is save, sound and happy, hopefully. ;)
tl;dr
Have a whitelist and two flags, one regulating whether being asked regarding whitelisted sources, one whether to allow unknown/foreign hosts upon acknowledging.
ChrisFriday, June 22, 2012 1:17:20 PM
Originally posted by remcolanting:
Your point being? If Opera Software wants to allow exceptions, they are free to do so. Just because random extensions being uploaded must follow specific rules doesn't mean that Opera Software can't be more lenient with partners, customers, etc.
Because they will have to actively do something to be infected.
So? If you trust that domain, you trust it. If you don't, you don't add the extension.
XenoAntaresFriday, June 22, 2012 1:20:49 PM
Originally posted by Slamdex:
The whole story here is about not trusting the user behind that keyboard – you didn't get that, did you?
ZotlanFriday, June 22, 2012 1:24:36 PM
Originally posted by Slamdex:
If there are many different uploaders and no code review, as on my.opera for instance, it makes no sense to trust the entire domain, just because you trust one user.
QuHnoFriday, June 22, 2012 2:12:05 PM
Originally posted by Zotlan:
It would be nice to have a section for extensions in development or debugging, something like a beta corner, with a speed up review like "there are 2 or 3 lines changed, seems to be still OK." but with a big warning, that this is a not fully tested extension and a link to the stable version.
Depending on how the "nag screen" is done, the repetitive warning could become annoying for beta testers - sometimes I uploaded changed versions to my private server for the beta testers every hour ...
BTW:
When you are on it:
Some extensions submit information to foreign pages like Google. A clear indicator that the extension is doing that and to which page would be welcome.
I am thinking about extensions like this or this which basically send documents to Google for doing the conversion stuff...
ZotlanFriday, June 22, 2012 2:16:47 PM
Originally posted by QuHno:
That's a good point, same goes for extensions that use external scripts (such as yslow, mentioned above).
JimFriday, June 22, 2012 2:18:54 PM
QuHnoFriday, June 22, 2012 3:12:54 PM
Originally posted by toyotabedzrock:
They still are, but that is not so much because of security restrictions but more because of a lack of APIs, which will for sure be corrected in the near future, if I read the latest announcements right.
I for sure don't want to have a malicious extension because of too lax security restrictions like afaik there already have been for Chrome and Firefox.
MyOpera team, please fix this!Friday, June 22, 2012 4:01:06 PM
Originally posted by QuHno:
I'ad have to agree with toyotabedzrock. Which latest announcements are you referring to? Since Opera came into the extension game so late, I wanted (expected) an all-out sprint forward to catch up. It feels more like a brisk walk thus far.rseilerFriday, June 22, 2012 4:21:18 PM
ZotlanFriday, June 22, 2012 5:09:24 PM
Originally posted by fearphage:
I assume he means this (http://dev.opera.com/articles/view/new-extension-apis-screenshot-resource-loader-url-filter/). Of course, as per usual, there's no knowing when these improvements will make it into a final.
JanGenMonday, June 25, 2012 1:02:42 PM
Originally posted by QuHno:
+10, there should be a privacy warning.
Why not auto-add all urls of the <access origin=> elements in the config.xml to the installation dialogue, so it's clear with urls are contacted. Also, mention those on the extension detail pages, (maybe all external url found in the js files)
Originally posted by XAntares:
That user is always untrusted, the point here is protecting the ignorant and naive, which unfortunately never can be done by asking permission, people will click whatever they see. Maybe the whitelist is an effective childlock, although I agree on as large domain, once whitelisted it's not effective anymore.
Better is that a user should whitelist all urls that are requested by the extension IMHO. Can't you autorun an extension on Opera Watir, to index potential risks (i.e. all external requests), (leak info to external urls, collect info in widget preferences and leak after an extension update, what other harm can an extension do at the moment)
Originally posted by toyotabedzrock:
I agree, my most powerful Opera extension is the old way: wget by extending the menu, and passing urls to bash scripts which call wget with different parameters.
Will menu actions and passing urls to other applications be added to the API in the near future?
Rafael LuikMonday, June 25, 2012 11:56:09 PM
But there are extensions in your catalog that are simply shortcuts to webpages, the developers can use this page to redirect users to malware at any time...
JanGenWednesday, June 27, 2012 12:05:39 PM
QuHnoThursday, June 28, 2012 6:08:42 AM
Originally posted by JanGen:
Already possible with the plain old buttons. I did so for e.g. printing.
You can pack a whole load of Javascript into the buttons too and such replace several of the extensions by a simple button you can place everywhere.
Drawback: Some of the extensions API stuff won't work in buttons.
Benefits: Some things are possible with buttons that are not possible with extensions.
The installation is as easy as with extensions.
btw: Where is the official Opera buttons catalog or the official Opera menus catalog or the official Opera toolbars catalog?
ZotlanThursday, June 28, 2012 7:52:48 AM
Originally posted by QuHno:
There is an official page with toolbar setups (http://my.opera.com/community/customize/setups/) but it's pretty ancient. I believe the official button page was built around the same time as the official UserJS page
QuHnoThursday, June 28, 2012 2:33:53 PM
Originally posted by Zotlan:
right
... and the upload is disabled since about that time too
JanGenFriday, July 13, 2012 12:46:06 PM
Originally posted by QuHno:
Yeah, that's why I'm missing it in the extensions.
The developer briefcase is just updated stuff from functionality that was available in buttons and menu's. It's cleaner and easier to install.
I wanna write an extension that will open my bookmarked banking site in a new clean profile Opera window, (since private tabs are not private) every time a open the url, or at least in a private tab.
Doesn't seem possible right now. I can do it with a menu option by passing the url to a bash script which will open opera with a new temp profile, but then I haver to choose that manually in the contextmenu.
But this is all a bit `off-topic`.