Security/Reviews/MobileJavaAddOns

From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.

Item Reviewed

Mobile-APIs for Java Code in Addons
Target
   
     Full Query    
ID Summary Priority Status
805436 SecReview: Mobile - support / provide APIs for Java Code in Addons -- RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

blog post by kats: https://staktrace.com/spout/entry.php?id=778
The given value "
   
     Full Query    
ID Summary Priority Status
805436 SecReview: Mobile - support / provide APIs for Java Code in Addons -- RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

blog post by kats: https://staktrace.com/spout/entry.php?id=778" contains strip markers and therefore it cannot be parsed sufficiently.

Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

What solutions/approaches were considered other than the proposed solution?

  • no Java, thus no add-ons
  • How about creating APIs for other processes to interact with fennec?
    • No advantage in this over JS only and more work
    • Except that you can use the android perm. model to restrict things even more

Why was this solution chosen?

  • parity with desktop
    • is jetpack/SDK/FUEL type APIs an option?

Why was this solution chosen?

`

Any security threats already considered in the design and why?

`

Threat Brainstorming

  • Do we really want parity with desktop? Currently all sorts of bad things happen on desktop that we neatly sidestep due to the restrictions of fennec.
    • This could potentially mean that we provide a route for malware that's not there currently - (chrome XSS == any API access that we've requested)
  • Bypass security for things like camera access where Java code can silently open the camera while JS code will have to use getUserMedia and will have to go through a dialog for user approval
  • Possibility to download remote code to local filesystem and execute it
  • Have we thought about how this might impact on review procedures for addons?
    • We wouldn't be able to review binary only-stuff
  • Property "SecReview feature goal" (as page type) with input value "* Allow addons to run Java code on native Fennec
      • currnetly cannot interact with the UI
      • android style Java archive
    • blog post: https://staktrace.com/spout/entry.php?id=778" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
    • Property "SecReview alt solutions" (as page type) with input value "* no Java, thus no add-ons
    • How about creating APIs for other processes to interact with fennec?
      • No advantage in this over JS only and more work
      • Except that you can use the android perm. model to restrict things even more

    Why was this solution chosen?

    • parity with desktop
      • is jetpack/SDK/FUEL type APIs an option?" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
      • Property "SecReview threat brainstorming" (as page type) with input value "* Do we really want parity with desktop? Currently all sorts of bad things happen on desktop that we neatly sidestep due to the restrictions of fennec.
      • This could potentially mean that we provide a route for malware that's not there currently - (chrome XSS == any API access that we've requested)
    • Bypass security for things like camera access where Java code can silently open the camera while JS code will have to use getUserMedia and will have to go through a dialog for user approval
    • Possibility to download remote code to local filesystem and execute it
    • Have we thought about how this might impact on review procedures for addons?
      • We wouldn't be able to review binary only-stuff" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.

Action Items

Action Item Status None
Release Target `
Action Items
'

Related to CTypes JNI - Which still needs review (Wes) Product has not made a decision about this feature explicitely