On 09/06/2013 02:57 PM, Marc Deslauriers wrote: > On 13-09-06 11:02 AM, Alexandre Abreu wrote: >> 3. I was wondering if for those packages and given the specific nature of >> webapps and the associated security risks (spoofing, phishing etc), we would >> be >> able to bypass some sort of review process that would be a bit more >> restricted >> than the one (if any) for other apps. At the moment, the APP_ID specific >> profile >> would prevent any local data capture etc. > > I'm not quite sure what that means. You want to bypass the regular review > process, or you want it to be more restricted than the one for other apps? > Seems > to me webapps are going to require more review than regular apps. Allowing > anyone to upload a facebook webapp that contains javascript that can steal a > user's credentials, either deliberately or inadvertently by breaking the > browser's same-origin policy would be bad. How many people are going to upload > different versions of the facebook webapp? >
I think some of this is handled by the webapps being isolated from each other. We should honor same-origin and all standard browser web protections, but I don't know if the injected javascript would be able to subvert that or not. Adding Chris Coulson to the CC. As for different people uploading different versions of the facebook app, that was part of what I was getting at when I brought up phishing in the wiki. I think we can make this a point for appstore policy/procedures and can automate this to an extent since we already have namespace checks in the appstore. For webapps it would be possible to extend those to also match the url. Ie, we redflag under various conditions. Eg for a google calendar app (https://www.google.com/calendar): 1. appstore developer must have an email address with @google.com 2. maintainer field in click package must have an email address with @google.com 3. package name in manifest must be com.google.... 4. package name in DEBIAN/control must match that in manifest 5. Url in .desktop file must be a subdomain of google.com Obviously, we can refine these. '5' requires parsing the Exec line of the .desktop file. We can do that and we can verify that the .desktop file contains all the necessary flags in the automated reviews. Might be better to add an X-Ubuntu-WebAppURL (or something) and have upstart-app-launch/click desktop hooks construct the proper Exec line based on it though. We kinda do this for qmlscene, but for webapps we could do a lot more. However, these checks don't work perfectly. For example, facebook gives out email addresses in its toplevel domain (eg, random.u...@facebook.com) and obviously random.u...@facebook.com doesn't represent facebook. The review scripts have already identified a couple of these types of domains and any matching them could be flagged for manual review. We can build this up as we see more and more apps. -- Jamie Strandboge http://www.ubuntu.com/
signature.asc
Description: OpenPGP digital signature
-- Mailing list: https://launchpad.net/~ubuntu-appstore-developers Post to : ubuntu-appstore-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers More help : https://help.launchpad.net/ListHelp
