Security/Reviews/MobileJavaAddOns: Difference between revisions

no edit summary
(Created page with "{{SecReviewInfo |SecReview name=Mobile-APIs for Java Code in Addons |SecReview target=<bugzilla> { "id":"805436" } </bugzilla> }} {{SecReview}} {{SecReviewActionStatus |SecRe...")
 
No edit summary
 
Line 6: Line 6:
}
}
</bugzilla>
</bugzilla>
blog post by kats: https://staktrace.com/spout/entry.php?id=778
}}
{{SecReview
|SecReview feature goal=* 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
|SecReview alt solutions=* 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?
|SecReview 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
}}
}}
{{SecReview}}
{{SecReviewActionStatus
{{SecReviewActionStatus
|SecReview action item status=None
|SecReview action item status=None
}}
}}
Related to CTypes JNI - Which still needs review (Wes)
Product has not made a decision about this feature explicitely
canmove, Confirmed users, Bureaucrats and Sysops emeriti
2,776

edits