On 11/07/2012 17:09, Lucas Adamski wrote:
On Jul 10, 2012, at 1:54 AM, Antonio Manuel Amaya Calvo wrote:
If I were happy to accept risks that the developer takes (or to trust
unknown or known developers) then I would not need the concept of
'trusted apps'. Just installed apps would suffice.
And I think that all that's a significant part of the user interface
should be restricted to local content. That is, content that's installed
with the application, that has been examined by the reviewer, and that
requires a new certification/signature cycle to be changed. I don't want
it downloaded from anywhere on the Internet and that includes the
developer server. After all, we're certifying applications because we
don't trust developers in the first place.
The security model cannot, and will not, remove all risk from
trustedapps. Especially around spoofing. That is why trusted apps have a review
> process. But preventing background images changes is not feasible
> programmatically without crazy tainting… how do you tell where
> the image came from? Its trivial to launder origins.
Yep... and that's why I wanted all the images that form the application
UI (buttons, backgrounds for forms, menu images...) to be supplied on
the signed zip.
Many apps may stream the background image for a server for theming
> purposes. For example, if I want to build a calendar app that loads
> images from Flickr based upon some set of tags, why should that be
> prohibited? This is a restriction that Firefox itself doesn't enforce
> (hence http://www.getpersonas.com/en-US/).
Personas let you replace the background... but don't let you replace the
icons of the URL bar for example. So I can't design (thankfully) a
persona where I get a locked padlock when a http URL is loaded. OR when
a https URL with an invalid certificate is loaded.
But lets assume we get a 'trusted' web browser replacement, and we don't
force that essential UI parts (like the icons shown to the user) are
stored locally. Instead, the browser uses
http://myserver.com/locked_padlock.jgp
and
http://myserver.com/unlocked_padlock.jgp
for the images.
The review could show that indeed the correct icon is shown when you go
to an http or https page. And that could last till 5 minutes after the
zip is signed to mark the application as trusted.
That kind of things should be, must be locally loaded. Otherwise, we're
giving trust where trust is undue.
What the trusted part adds to this attack is context. A trusted app gets
access to more interesting privileges and thus the attacker can have
more context information about when to execute the attack. Not to
mention that I used to want a trusted UI, if you remember. Something
that informed the user when he was interacting with a window that the
owner application for that window was trusted or not. Now, if the UI is
hijackable, that makes that idea (the trusted UI) into a horrible one.
Trusted UI != all interactions are trustworthy. Far from it. Trusted
UI == specific interactions are trustworthy, and can be differentiated
from all other interactions.
I was less ambitious, or more :) I just wanted the UI to reflect whether
I was interacting with a certified, trusted app, installed or web app.
In any case, and from Jonas' answer I think we basically agree that the
UI is part of the application, that includes the images on the UI, and
thus they have to be controlled.
I didn't get that from his email. :)
Lucas.
And thus we're back to arguing :)
Best regards,
Antonio
________________________________
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
