On 09/07/2012 21:45, Lucas Adamski wrote:
On Jul 9, 2012, at 12:09 PM, Antonio Manuel Amaya Calvo wrote:
To make things more similar to how web pages normally work, we could allow
pages from app://developer.com/ to make network requests to
http://developer.com. I.e. the app would be allowed to open XMLHttpRequest
connections to http://developer.com/ <http://developer.com/.>myapi.cgi without
requesting any special privileges. Likewise <img>s and <video>s loaded from
http://developer.com would not be considered cross-origin for example for
the purposes of tainting when drawn into a <canvas>. This way most of the
code which would work for a website would work in a packaged app, except
that the packaged app would have to ensure to use absolute URLs when
wanting to connect to the website.
I agree with everything before this paragraph but... the whole point of
reviewing the application in the first place is to ensure that the
application the user is about to trust is... well, trustworthy, for lack
of a better word. And the users are going to trust the application
because they think that somebody has reviewed the application. And all
of this goes out of the window if we let the application change what it
shows to the user without any kind of review. If, going for the easy
example here, the application has a login page with an image background,
the developer --or anyone that compromises his server-- can change that
log page to resemble whatever page they wish.
That's no different to any other page on the internet, you could say,
and it's true. But this applications are going to have access to a wide
range of abilities, because they're trusted. And even if sometime a
'trusted UI' is provided (something that informs the user that hey, this
application you're interacting with is trusted) they'll be marked as
trusted. So they should behave better than a random web page you found
on the internet.
So for the time being, and unless we can figure a way to add untrusted
content to a trusted base without losing "trustiness", I would say that
for an application to be trusted all its content has to be trusted...
and that if we allow external content (which might make sense for a
video player, for example) then the places where external content can be
shown are monitored and factored in the application review.
Almost all apps load data of the web. If anything its rare to have
apps that don't. Some of those apps load data only from a single
domain, but most of them load data from multiple sources (developer
server for help and other resources, ad servers for monetization, 3rd
party content and services like twitter, flickr, Facebook, etc).
We should keep data and code separate when discussing the security
model. Apps should be able to load data from anywhere; but code
importing (including CSS) is strictly limited to assets included in
the package. Dynamic code creation/injection is mitigated by a
required CSP policy.
Yes and no. The problem is that the barrier between data and code is
diffuse... is a background image on a logging page considered data?
Because I'm pretty sure that I can write a single HTML/CSS/JS that
seems like either a Facebook logging page or a Bank of America logging
page just by changing the background image.
I think that any blank statement such as we can just allow loading
resources from the developer web server isn't going to work... on both
sides. On one hand, it can make a trusted app untrusted (even more so
since we don't even force https as per Jonas description), and on the
other hand for some apps (media consuming apps for example) restricting
its data sources to just the developer site is kinda silly too.
Antonio
Lucas.
--
Antonio Manuel Amaya Calvo_/ / _ /Security&Trust on N&S
email: [email protected] / _ _/ ( / Telefonica I+D
Tlf.: +34-91.312.98.95 _/ _/ \__/ D. Ramón de la Cruz 82
Fax : 28006 Madrid, SPAIN
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
nuestra política de envío y recepción de correo electrónico en el enlace
situado más abajo.
This message is intended exclusively for its addressee. We only send and
receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
