Mozilla Add-ons Community Blog
Categories: builder developers jetpack mobile sdk

Jetpack Project: weekly update for December 18, 2012

2 responses

Project News

  • We released 1.12 last Tuesday, but there was no weekly update here due to a particularly busy week at an Add-ons Work Week last week.
  • Even better, despite some major differences introduced in SDK 1.12, Piotr was able to get Builder updated to support 1.12 last Wednesday.
  • Today’s Jetpack meeting was the last meeting of 2012! In fact, there will not be another meeting until Tuesday, January 8th, 2013.

Quick Stats

Note: the stats above are based on the queries I linked to for each item. If you have suggestions on how these queries might be made more accurate,please comment below. Stats generated at 2012-12-18 09:13:09 PST

Meeting Brief

  • SDK: high priority bugs, Per-Window Private Browsing, module versioning in the loader and 404s in the docs.
  • The tree is orange, but GitGutter for ST2 is awesome!

Full minutes are available here:
https://wiki.mozilla.org/Jetpack/Weekly_Meeting/2012-12-18#Minutes

2 comments on “Jetpack Project: weekly update for December 18, 2012”

  1. Brett Zamir wrote on

    WITH USER PERMISSION (and subject to their security preferences), through my addon AsYouWish, https://github.com/brettz9/asyouwish , I am providing to regular websites full wrapped access to the SDK require() APIs. As a result, I am interested to know whether you could make clear in the documentation some of the security implications of the SDK APIs ideally in some distinct part of each API’s page?

    A user might be willing to give clipboard permissions, for example, if they know it can only read or set their clipboard, but not willing to give access to the browser preferences API (esp. dangerous since my addon is using preferences to store the user’s security preferences). I’d like to know for other APIs their potential security implications, and I think this information ought to be useful for addon reviewers, etc. as well.

    Some APIs appear they could even be exposed without any security concerns (base64 and URL?), but I’d hesitate to make that assertion (or later revoke it) if the API might later become insecure.

    1. Jeff Griffiths wrote on

      Hi Brett,

      The security implications are that web content should not have access to these apis directly because these apis were never designed with this in mind. Your add-on is problematic because it circumvents the SDK’s security model. Remember, it is not the user we are afraid of in this scenario ( you can and should expose SDK apis to users ) but instead the web content, which could have any type of malicious code embedded into it that might target your add-on to escalate privileges.

      There is a reason why enablePrivilege was removed from the platform – it was a security problem. It’s hard for me to see your add-on except in a similar light.

      regards, Jeff