[Jsprintsetup] Security Idea

Dimitar Angelov mitko at edabg.com
Thu Feb 10 13:20:11 PST 2011


Hi Guillaume,

This is perfect!

You are absolutely right to follow standards and FF design principle.
Here I missed enough knowledge about "notification" and "permission 
manager".
I also have some doubt about url patterns for two reasons:
1. End User knowledge
2. Performance
I'm accept idea for domain level protection, but I have some dimness about:
1. How to treat local access like file:///d:/temp/New12.html
2. How to treat different protocols like "http" and "https"
For example If I want to allow only access from secured connection.
May be domain/subdomain information need to be extended.

I have also think about Allow,Deny order (like Apache access) but leave 
at this moment by reasons of simplicity for End User.
I always think for End User for user who is using web app is his 
professional subject area and don't have technical knowledge.

New method askUserPermissions(callback) is also nice idea!
I accept fully, but have some dimness, how to implement and is this 
security approved.

I have attached last work version of the extension which is too 
incomplete to commit in repository.
There are also implemented new features about properly handling paper 
sizes on different platforms which are almost complete and need 
additional testing.

Regards,

Dimitar Angelov


On 10.2.2011 г. 18:42, Guillaume Crico wrote:
> Hi,
>
> I knew that my permission "level" suggestion may be too "complicated".
>
> I began to work with the "notification" and "permission manager", and I
> think you should consider this way.
>
> @see:
> https://developer.mozilla.org/en/XUL/notificationbox
> https://developer.mozilla.org/en/Code_snippets/Alerts_and_Notifications#Using_notification_box
>
> https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIPermissionManager
>
> http://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsIPermissionManager.idl
>
>
> We won't have "pattern in URLs" with the PermissionManager, but only
> testExactPermission/testPermission (eg. domain/domainAndSubDomains).
> There is integrated "Permission expires at end of session" option in the
> PermissionManager.
>
> I'm not a fan of the "url pattern" idea (even if I also thought about
> this in the the first time).
> My reason is: "Most of (every?) standardized web security related
> specification is based on the Same Origin Policy"...
> And as you know... Sticking to standards is often a... good idea...
>
> Are you sure about the "enable access from all URLs".
> What about the "Deny,Allow" rule processing order?
>
>
>
> What do you think about my API change proposal:
> jsPrintSetup.askUserPermissions(callback)
>
> You may notice that I removed the level argument...
> The callback would be call with a simple boolean "authorisation" argument:
> true: "yes, kill some more trees..."
> false: "no, ink's too expensive"
>
> I think that handling "script blocking" to order web developer to have
> "permission asking on object access" (like the stuff around
> "window.open()") is really complicated!
> The "async" principle should be "explicit" (just like any piece of code ;).
>
> Could "real users" (eg. Intranet developer for most, i'm pretty sure of
> that) could give there opinion about this api break?
>
> The typical change for existing code would be:
> if (window.jsPrintSetup) {// who do not perform this test?
> //print a nice cartoon to the printer...
> }
>
> to:
> if (window.jsPrintSetup) {
> jsPrintSetup.askUserPermissions(function(){
> //print a funnier cartoon to the printer...
> });
> }
>
>
>
>
>  > If you want I can send working version of the extension.
> Yes, of course!
> Is the mozdev CVS still the official devel repository?
> (I need to install a CVS client, and to try to remind how it works...
> personnaly I'm using SVN...)
>
>
>
> Here is some code I began to write in the js component (it works, but is
> not useful alone!):
>
> askUserPermissions: function (callback) {
> //@todo read stored permissions for current host
> //@todo allow,deny processing order???
> //@todo if in "black list" :if (typeof callback !== 'function') {
> callback(false); return; }
> //@todo if in "white list" :if (typeof callback !== 'function') {
> callback(true); return; }
>
> // if not enough permissions, ask using notification...
> try {
> var win = this.getWindow();
> var notificationBox = win.getNotificationBox(win.content);
>
> // store the callback, needed???
> /*
> var callbackClosure = function (level) {
> if (typeof callback === 'function') {
> callback(level);
> }
> }
> */
> //@todo register the callback for use with the
> jsprintsetupNotificationOptions menu items
>
> var buttons = [{
> label: 'Options', //@todo use locale property
> accessKey: 'O', //@todo use locale property
> //popup: "jsprintsetupNotificationOptions",//@todo the questions in this
> menu... Need an overlay? or can be built on demand?
> callback: null
> }];
>
> var notification = notificationBox.appendNotification(
> 'This web site wants to cutomize print settings...', //@todo use locale
> property
> 'jsprintsetup-askpermission',
> 'chrome://browser/skin/Info.png',
> notificationBox.PRIORITY_WARNING_MEDIUM,
> buttons
> );
>
>
> return;
>
> } catch (e) {
> throw e; // rethrow for debugging...
> }
>
> // if we reach this point, no permission allowed...
> if (typeof callback === 'function') {
> callback(false);
> }
> }
>
>
> Regards,
> Guillaume Crico
>
>
>
>
> Le 09/02/2011 17:32, Dimitar Angelov a écrit :
>  > Hi!
>  >
>  > Great Work!
>  >
>  > We are now working by this and have done some work to the moment but
> is not in final phase.
>  > Our idea is closer to your idea, but is little different.
>  > +---- jsPrintSetup Options ----------------------------+
>  > | |
>  > | +- Security Mode ----------------------------------+ |
>  > | | [ ] enable access from all URLs | |
>  > | | [*] prompt for URL if is not in white/black list | |
>  > | | [ ] enable acess ONLY from enabled URLs | |
>  > | +--------------------------------------------------+ |
>  > | |
>  > | +-----------+------------+ |
>  > | |White List | Black List | |
>  > | |-----------+--------------------------------------+ |
>  > | | http:\\some.com\url +---------+ | |
>  > | | https:\\other.com\dow | Add | | |
>  > | | +---------+ | |
>  > | | +---------+ | |
>  > | | | Edit | | |
>  > | | +---------+ | |
>  > | | +---------+ | |
>  > | | | Remove | | |
>  > | | +---------+ | |
>  > | +--------------------------------------------------+ |
>  > +------------------------------------------------------+
>  > The main difference is protection on URL level not on domain level
> (only). We have also permit pattern in URLs to give more flexibility.
>  > Other difference is level of access. We have not think about
> implement detailed level of access for two main reasons:
>  > 1. End user (user who is using web application) have not enough
> knowledge to get right decision about level.
>  > 2. Some features can be overlapped by functionality and will be
> difficult to distinguished.
>  >
>  > About popup dialog it is very nice and I can add some little thing:
>  > 1. It is possible to add option "Temporary enable for session" (I'm
> not fully sure that is easy, but I have idea how to do).
>  > 2. If we accept idea to use URL instead of domains have to be
> extended with features about add URL or part of URL. Something like Add
> URL, Add Domain Only or Custom (Edit URL).
>  >
>  > About "Print Done" notification this is good idea and can be
> implemented.
>  > Locale is also very important and we will be happy if you help to add
> French locale.
>  >
>  > We are waiting for comments about our implementation to the moment,
> because it is very important to have more ideas to be more useful.
>  >
>  > If you want I can send working version of the extension.
>  >
>  > Regards,
>  >
>  > Dimitar Angelov
>  >
>  > On 09.2.2011 г. 14:21, Guillaume Crico wrote:
>  >> Hi !
>  >>
>  >> Has anybody started the "security manager" implementation?
>  >>
>  >> I'm sure that everybody would agree the /"trust this site" idea/.
>  >>
>  >> Here is a more precise proposition...
>  >>
>  >> The extension options dialog would mimic the "Popup authoridation
> dialog".
>  >> (@seechrome://browser/content/preferences/permissions.xul)
>  >>
>  >> +---------------------------------------------------------+
>  >> | Allow domain: |
>  >> | _______________________________________________________ +
>  >> | Allow |
>  >> | |
>  >> +---------------------------------------------------------+
>  >> | +-----------------------------------------------------+ |
>  >> | | Domain | State | |
>  >> | +-----------------------------------------------------+ |
>  >> | |www.example.com | Allow (level...) | |
>  >> | | ad.badguy.com | Deny | |
>  >> | | | | |
>  >> | | | | |
>  >> | | | | |
>  >> | +-----------------------------------------------------+ |
>  >> | Delete domain | Delete all domains |
>  >> | |
>  >> | |
>  >> | [x] Ask for permissions when needded |
>  >> | |
>  >> | Close |
>  >> +---------------------------------------------------------+
>  >>
>  >>
>  >>
>  >> We should add a method to the component:
>  >> jsPrintSetup.askUserPermissions(level, callback)
>  >>
>  >> where level is a mask of :
>  >> - kAllowSetup: allow setting margin/headers/footers...
>  >> - kAllowPrinters: allow getting printers list and setting the printer
>  >> - kAllowSilentPrint : allow silent print (requires kAllowPrinters?)
>  >> - kAllowSaveGlobalSettings : (BUT IN FACT I THINK WE SHOULD DROP
> THIS FEATURE!)
>  >> - kAllowAll: kAllowSetup& kAllowPrinters& kAllowSilentPrint&
> kAllowSaveGlobalSettings
>  >> - kAllowNone: 0
>  >>
>  >>
>  >> Every access to the component methods should be wrapped with a
> permission check, throwing an exception when there is no enougth
> permissions.
>  >> The web site script author is responsible for error handling...
>  >> (I think that is it simpler for everyone, because if we ask "on
> demand", we will have troubles with async execution...)
>  >>
>  >> When a web site calls jsPrintSetup.askUserPermissions(), the browser
> shows a non-intrusive dialog (just like for popups):
>  >>
>  >>
> +-------------------------------------------------------------------------+
>  >> | This web site want to customize your printer settings. | Options x |
>  >>
> +-------------------------------------------------------------------------+
>  >>
>  >> The "x" close button is an alias for "Deny once", see below.
>  >> Of course, if the domain is already in the prefs list, the dialog is
> not displayed (unless the permission level is not enought).
>  >>
>  >> The options button display the following menu:
>  >>
>  >> +-------------------------------------+
>  >> | Allow once forwww.example.com |
>  >> | Always allow forwww.example.com |
>  >> | Deny once forwww.example.com |
>  >> | Always deny forwww.example.com |
>  >> | |
>  >> | What are the risks... |
>  >> | Modify JSPrintSetup options... |
>  >> | Do not display this message anymore |
>  >> +-------------------------------------+
>  >>
>  >> "Allow once" => add to prefs list with "allow" state
>  >> "Always deny" => add to prefs list with deny" state
>  >> "What are the risks..." => maybe we should give some explanations
> about the potential threats?
>  >> "Do not display this message anymore" => like unchecking "Ask for
> permissions when needded" in options
>  >>
>  >>
>  >> The callback provided to jsPrintSetup.askUserPermissions() would
> then be called with the argument "level": the permission level (kAllow*
> mask) given by the user.
>  >> If the user have denied (once or always), the level is kAllowNone (0).
>  >> If the user gave the permission "once", the level is the same that
> the argument provided to jsPrintSetup.askUserPermissions().
>  >> If the domain in in the prefs list, the level is the one stored in
> prefs.
>  >>
>  >>
>  >>
>  >> I think that we should display a "Print done" notification when the
> silent printing is invoked.
>  >> (As a user, even if I trust a site, I would appriciate a little
> "monitoring"!)
>  >> What do you think of this?
>  >>
>  >>
>  >> There is some useful code to implement this in:
>  >> - browser.jar/content/browser/preferences/permissionsutils.js
>  >> - browser.jar/content/browser/preferences/permissions.xul
>  >> - browser.jar/content/browser/preferences/permissions.js
>  >>
>  >>
>  >>
>  >> Any volunteers?
>  >>
>  >> I can do some of the work, but I would need testers.
>  >> I have no skills in FF4.0 extensions dev. Anybody has advice to give?
>  >>
>  >>
>  >> Note: We also have to localize, because we're going to have userland
> messages!
>  >> (I can do French locales...)
>  >>
>  >> Regards,
>  >> Guillaume
>  >>
>  >>
>  >>
>  >>> Thank you for the suggestion!
>  >>>
>  >>> It Is important to implement this security concern indeed.
>  >>> We have planned to implement management of enabled URL-s which can use
>  >>> JSPrintSetup, but it is yet as idea level.
>  >>> But you are fully right we have to implement this in short time.
>  >>>
>  >>> Regards,
>  >>>
>  >>> Dimitar
>  >>>
>  >>> cod3master wrote:
>  >>> >/ I like jsprintsetup a lot, but I have a security concern.
>  >>> />/
>  >>> />/ the addon should ask, if a site want's to access jsprintsetup,
> because
>  >>> />/ if a lot of people use jsprintsetup you can be sure that there
>  >>> />/ will be some advertising autoprints on webppages.
>  >>> />/
>  >>> />/ the function should be like the geolocation function of firefox
> 3.5, it
>  >>> />/ should have the option "trust this site" and save the setting
> permanently.
>  >>> />/ in that way jsprintsetup can't be misused.
>  >>> />/
>  >>> />/ i hope you can implement a function like that, because this
> will surely
>  >>> />/ help the distribution of the addon, and maybe to be integrated
>  >>> />/ completely in a future
>  >>> />/ firefox release :-)
>  >>> />/
>  >>> />/ thanks
>  >>> />/ GT/
>  >> /
>  >> /
>  >>
>  >
>  > _______________________________________________
>  > Jsprintsetup mailing list
>  > Jsprintsetup at mozdev.org
>  > https://www.mozdev.org/mailman/listinfo/jsprintsetup
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jsprintsetup-0.8.3.xpi
Type: application/x-xpinstall
Size: 25593 bytes
Desc: not available
URL: <http://www.mozdev.org/pipermail/jsprintsetup/attachments/20110210/717cccee/attachment-0001.bin>


More information about the Jsprintsetup mailing list