On Tue, Sep 9, 2014 at 6:21 PM, Marcos Caceres <mar...@marcosc.com> wrote:
> On September 9, 2014 at 9:10:27 PM, Jonas Sicking (jo...@sicking.cc) wrote:
>> On Tue, Sep 9, 2014 at 5:13 PM, Marcos Caceres wrote:
>> >> What about icons that need to change daily? E.g. for a calendaring site?
>> >
>> > This is scary, IMO. A hijacked site could have its icon replaced for a 
>> > bank's icon or something.
>> I dunno.
>> At least in FirefoxOS we found that we need to support applications
>> updating their icons as part of an update. So in our manifest
>> implementation, we check for updates of the manifest on a daily basis
>> and if the manifest has been updated to point to a new icon, we use
>> that new icon.
> I don't know if it makes any difference, but the process of updating 
> installed apps unusually involves notifying the user that updates are 
> available and the user taking explicit action to update the apps. Where 
> updates happen automatically, there is usually some kind of notification 
> and/or indicator that makes the user aware of what has changed.

That will long term not be the case in FirefoxOS. I can't speak for
other platforms, but I'll note that Chrome has always updated with no
notification to the user, Firefox has over time gotten fewer and fewer
notifications, and platforms like Android, iOS and Windows have been
moving towards more and more automatic updates with fewer and fewer

So my assumption is that we'll end up with updates being completely
transparent on many platforms. At least as default behavior.

> What I'm concerned about is the application updating the icon while the 
> application is running. Although it works fine for calendar, that seems 
> confusing to me.

What is your concern?

>> Applications do on a fairly regular basis release "visual updates",
>> and as part of that it's critical that they also update the
>> application icon.
> Yes, that makes total sense. My concern is more about a sneaky attack where 
> the app icon changes as the user switches from one app to another and then 
> back.

Why is the "changing back" part more concerning than the initial
change? Or am I misunderstanding you?

>> We do however not allow applications to change their names. For the
>> reason that you mention.
> Oddly, I don't see a problem with updating the name of an application in an 
> update. I don't have proof, but I would imagine most people look of icons and 
> take little notice of the name of apps on the home screen. Names are only 
> really relevant for searching.

I agree. However I've found forbidding updating icons a no-go. Not to
mention that since we support different icon files for different
render sizes and pixel densities, it's probably possible for an
attacker to hide a bank icon somewhere even without updates.

The reason we've locked down name and not icon was because that's all
that we could do. Not because it was safer from a security

>> I agree there's still a risk that just changing the icon means that
>> the user won't notice that the name doesn't match, however I don't
>> think disallowing icons to be updated is an option.
> Remember, we are talking about changing it in real time VS changing it from 
> an update while the application is (maybe?) shut down.

I'm more concerned about an app changing icon when it's *not* running
than when it is running. My concern is that the user launches an app
that they think is another app, either from the homescreen or from an
activity picker.

/ Jonas

Reply via email to