[Jsprintsetup] Security Idea

Dimitar Angelov mitko at edabg.com
Mon Mar 7 13:09:56 PST 2011


Hi Guillaume,

Thank you for French localization I have added.
I've also implemented catch of close notification button (it was not 
easy for me :-)).
New release is at 
http://downloads.mozdev.org/jsprintsetup/jsprintsetup-0.9.0beta2.xpi
I' have not clear idea about "Allow once" because of atomicity of some 
operations. For example user can allow to set top margin but disable 
bottom margin, which lead to inconsistent results. This is same as the 
problem to give permissions on different operations.

Any other valuable considerations and comments from you are welcome.

Regards,

Dimitar Angelov

On 24.2.2011 г. 11:16, Guillaume Crico wrote:
> Hi Dimitar,
>
> Great work!
> Feel free to add the attached french locales...
>
> I think about 2 little improvements:
> - An "Allow once" button in the notification bar...
> - The callbacks are not triggered when the user "close" the notification
> bar (wich means "Deny once"), or when a permission is set from the
> permission window opened from the notification bar.
>
> I'm sorry I don't have the time to investigate the component code this
> week, but if you want I can try to implement theses next week.
>
> Regards,
> Guillaume
>
>
>
> Le 21/02/2011 21:55, Dimitar Angelov a écrit :
>> Hi Guillaume,
>>
>> I'm happy to show our work :-)
>> We have implemented permissions (with some minor changes) and also
>> implemented FF 4.0 compatibility.
>> We will be thankful if you check implementation and evaluate it.
>> Now we next must explain new features in jsPrintSetup reference.
>>
>> You can download new version at:
>> http://downloads.mozdev.org/jsprintsetup/jsprintsetup-0.9.0.xpi
>> (new version is commited in CVS
>> http://jsprintsetup.mozdev.org/source.html)
>>
>> Any suggestions and comments are welcome!
>>
>> Regards,
>>
>> Dimitar Angelov
>>
>> PS: If ideas and logical model are right detailed testing is needed.
>>
>> On 13.2.2011 г. 15:15, Guillaume Crico wrote:
>>> Hi Dimitar,
>>>
>>>> I'm not sure only of that, is it correct to use FF permission manager
>>>> from our extension? Is it "frozen" as parameters of call?
>>> I don't know.
>>> The nsIPermissionManager interface is defined in the "netwerk" part of
>>> the toolkit.
>>> It seems that the interface is bunddled in the new/nextgen
>>> XPCOMUtils/Services API (with "perms" as service name).
>>> So I think that we can consider it as "frozen"/"ready tu use in
>>> extensions".
>>> You just have to choose a good name for the "permission.type", in order
>>> not to clash with others...
>>>
>>>
>>> For the "reusable"/"template like" permissions.xul window (and its
>>> "window arguments" magic), it is in the "browser" part of Mozilla.
>>> So it is more likely to change in theory (but it didn't change, even
>>> from FF3.x to FF4.0b11).
>>>
>>> The problem with permissions.xul is that you cannot use it directly as
>>> "optionsURL" in the install.rdf !
>>> <em:optionsURL>chrome://jsprintsetup/content/options.xul</em:optionsURL>
>>> and that you cannot add some other options aside the perms list (if you
>>> planned to add some).
>>>
>>> So you have to do (in your options.xul):
>>> +-------------------------------------+
>>> | [ ] An option |
>>> | [x] An other options |
>>> | |
>>> | |Manage permissions by website...| |
>>> +-------------------------------------+
>>> with the "Manage permissions..." button openning the permissions.xul
>>> window...
>>>
>>> But this is not so "unuseable" to have a "one more click" when using the
>>> "Extension options" path!
>>> As long as the "notification" system can open the permissions.xul in one
>>> click...
>>> (I started to write a options.xul by coping/pasting code from
>>> permissions.xul, and using permissions.js and permissionsUtils.js, but
>>> it's not a so good idea...)
>>>
>>>
>>> For the "file://" problem, the "anti-popup" handler do not allow to
>>> store permissions, but the "allow once" entry in the notification menu
>>> does work. I think you can do the same, or maybe add an option checkbox
>>> "Allow for local files" (and check this case against the users prefs in
>>> your code), if you really need to support local files.
>>>
>>> I understood that the "file://" protocol support is not a priority at
>>> all in the mozilla core!
>>> More likely they plan to drop/lock webapp featuresin the future for
>>> "local protocol", because of security issues!
>>> And I can understand this, even if personnaly I love "personnal html app
>>> in a single file".
>>> Imagine what a dblclick on an html attachment in a mail can do with a
>>> "non aware" user, if the file:// protocol has privileges...
>>> (If an "Always allow for this site" choice would add the html file
>>> directory, this would be the "temp/download" user dir, so every other
>>> temp files!)
>>>
>>>
>>> Regards,
>>> Guillaume Crico
>>>
>>>
>>> Le 13/02/2011 10:02, Dimitar Angelov a écrit :
>>>> Hi Guillaume,
>>>>
>>>> Thanks for the suggestions and spent time I think that I can do the
>>>> things and will inform you.
>>>> I have made additional research on FF permission manager as you
>>>> suggested in
>>>> - browser.jar/content/browser/preferences/permissionsutils.js
>>>> - browser.jar/content/browser/preferences/permissions.xul
>>>> - browser.jar/content/browser/preferences/permissions.js
>>>> I think that things may be done in very elegant manner if I use
>>>> permissions.xul to edit permissions. I also have made some experiments
>>>> and things look like to be possible. I'm not sure only of that, is it
>>>> correct to use FF permission manager from our extension? Is it
>>>> "frozen" as parameters of call?
>>>>
>>>> Thank you again for useful information!
>>>>
>>>> Regards,
>>>>
>>>> Dimitar Angelov
>>>>
>>>> On 13.2.2011 г. 01:59, Guillaume Crico wrote:
>>>>> Hi Dimitar,
>>>>>
>>>>> I am honored by your enthousiam for my suggestion!
>>>>> I did not have the time to test and read the "last version" of the
>>>>> extension you sent. Sorry.
>>>>>
>>>>> > 1. I don't know how permission manager treat local uri-s?
>>>>> I think (needs verification) that it's all domain based (eg.
>>>>> "uri.host").
>>>>> So you pointed an issue!
>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=204285
>>>>>
>>>>> > 2. Is it possible for manage permissions from FF permissions
>>>>> manager.
>>>>> Tools|Page Info|Permissions.
>>>>> I did not thought about it... It's a "must have"! (I hope it's easy)
>>>>> Did you notice that local uri-s do not have any "permissions tab" in
>>>>> "page info"?
>>>>>
>>>>> > 3. Are there any other tool to view and manage permissions to use
>>>>> for
>>>>> debuging.
>>>>> Permissions are stored in "permissions.sqlite", in the user profile
>>>>> directory.
>>>>> You can use your favorite sqlite GUI [*], or even a sqlite cli
>>>>> executable.
>>>>> [*] https://addons.mozilla.org/fr/firefox/addon/sqlite-manager/
>>>>>
>>>>>
>>>>> Regards,
>>>>> Guillaume Crico
>>>>>
>>>>> Le 12/02/2011 13:55, Dimitar Angelov a écrit :
>>>>> > Hi Guillaume,
>>>>> >
>>>>> > I want to add some thoughts to discuss after reading about
>>>>> nsIPermissionManager.
>>>>> >
>>>>> > From brief documentation and after looking at source code I have
>>>>> some
>>>>> conclusions (Please correct me if is wrong).
>>>>> > 1. Permission manager is global (for FF) storage for permissions for
>>>>> all components in FF.
>>>>> > 2. Permissions are on host level basis and permission type.
>>>>> > If different components in FF have different type of permissions
>>>>> over
>>>>> host they must use different "type" to distinguish.
>>>>> > For example popup manager use
>>>>> > PermissionManager.add('http://host.tld/some/path/script.php', 'Open
>>>>> Popup Windows', ALLOW_ACTION, EXPIRE_SESSION);
>>>>> > to allow popups from site host.tld for the session.
>>>>> > If jsPrintSetup want to use permission manager to add permision
>>>>> will be
>>>>> > PermissionManager.add('http://host.tld/some/path/script.php',
>>>>> 'jsPrintSetupAccess', ALLOW_ACTION, EXPIRE_NEVER);
>>>>> > which mean that for host.tld is allowed access to jsPrintSetup fot
>>>>> this session.
>>>>> > 3. Checking of permission is made by calling testPermission or
>>>>> testExactPermission for URI/permission type.
>>>>> > 4. If jsPrintSetup want to get list of current permissions
>>>>> (permission types specific for jsPrintSetup) there must be enumerated
>>>>> all permissions from permission manager and filter these for
>>>>> jsPrintSetup.
>>>>> > This must be used in jsPrintSetup options dialog.
>>>>> > 5. For removing host/permission type from permission manager must be
>>>>> user method remove(host, permission type). Where permission types are
>>>>> only permission types for jsPrintSetup.
>>>>> > removeAll is not applicable from this context.
>>>>> >
>>>>> > If we assume to use only one permission type for jsPrintSetup, for
>>>>> example "jsPrintSetup Print Management" the solution will be simple.
>>>>> >
>>>>> > I missed following to the moment:
>>>>> > 1. I don't know how permission manager treat local uri-s?
>>>>> > 2. Is it possible for manage permissions from FF permissions
>>>>> manager.
>>>>> Tools|Page Info|Permissions.
>>>>> > 3. Are there any other tool to view and manage permissions to use
>>>>> for
>>>>> debuging.
>>>>> >
>>>>> > If my concerns are correct I can implement this.
>>>>> >
>>>>> > Regards,
>>>>> >
>>>>> > Dimitar Angelov
>>>>> > _______________________________________________
>>>>> > Jsprintsetup mailing list
>>>>> > Jsprintsetup at mozdev.org
>>>>> > https://www.mozdev.org/mailman/listinfo/jsprintsetup
>>>>>
>>>>
>>>> _______________________________________________
>>>> Jsprintsetup mailing list
>>>> Jsprintsetup at mozdev.org
>>>> https://www.mozdev.org/mailman/listinfo/jsprintsetup
>>
>> _______________________________________________
>> Jsprintsetup mailing list
>> Jsprintsetup at mozdev.org
>> https://www.mozdev.org/mailman/listinfo/jsprintsetup
>



More information about the Jsprintsetup mailing list