Provide rename support for blocklisted apps

RESOLVED WONTFIX

Status

Firefox OS
General
P4
enhancement
RESOLVED WONTFIX
5 years ago
2 months ago

People

(Reporter: robhudson, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [blocked on platform])

(Reporter)

Description

5 years ago
We should also consider whether the blocklist package's manifest should update the name to match that of the app being blocklisted so the user sees that this is an update and accepts it. Or whether we should keep something like "Blocklisted by Mozilla" as the app.name and assure the mini-manifest name and package manifest name match (for device side verification). I'm not sure which is preferable.

Also see bug 817624.
CCing David and Jonas.  David - do you have a preference?  Jonas - is there a technical reason to do one over the other?
Blocks: 777048
(Reporter)

Comment 2

5 years ago
I was curious if we also show the release notes in the update UI? If so, we may want to update the release notes to say something about this being blocked and not let the dev change it, which they currently are able to do.
No longer blocks: 777048
(Reporter)

Comment 3

5 years ago
https://github.com/mozilla/zamboni/commit/44039db 

This fixes the mini-manifest to point to the signed blocklist package. Until I hear one way or another the name will be "Blocklisted by Mozilla". I'll leave this open for now.
I think we might reject the package if it tries to change the application name. I'm pretty sure we do that for hosted apps as to prevent them from phising the user by renaming themselves to "Bank of America" or some such.

I'm not sure that we yet do the same thing for packaged apps, but if we don't we likely should.

So to keep on the safe side, I would say that we should use the name of the blocked app in the blocklist package.
Jumping in and excuse my ignorance.  If I understand correctly, it seems that we are 'tricking' users into updating an app to a special blocklist app in order to disable it?  

If that is correct, putting on my user hat, I would want to be protected but want to be protected knowingly.   I wouldn't update something if I saw the words "Blocklisted by Mozilla" as it sets off all sorts of warnings in my head that I probably shouldn't download it, even though we want them to.  I also wouldn't want to be, in a way, fooled into updating by claiming its the app name and then having it blocked.


Can we do some combination - "App Name -  Mozilla Security Update"? (not sure of exact words).  


The idea of using the release notes for an update is a good one, and it would be good if a user could preview release notes before they download". And we could have a release note that says that the app was blocklisted for reason X and, for your protection, please update it.   Is that possible?

Longer term, though not currently an option in FFOS, we should use push messages to send control messages and to disable apps and notify the user.
We don't currently show the release notes anywhere, so feel free to leave those as whatever you want.
(Reporter)

Comment 7

5 years ago
(In reply to Jonas Sicking (:sicking) from comment #4)
> I think we might reject the package if it tries to change the application
> name. I'm pretty sure we do that for hosted apps as to prevent them from
> phising the user by renaming themselves to "Bank of America" or some such.
> 
> I'm not sure that we yet do the same thing for packaged apps, but if we
> don't we likely should.

Bug 814136 will verify the app ID, which we will have in this blocklisted zip file.

I've seen some code [1] that compares the mini-manifest to the package manifest, which should be a match here too.

[1] https://hg.mozilla.org/mozilla-central/file/38407b98003b/dom/apps/src/AppsUtils.jsm#l277
(Reporter)

Comment 8

5 years ago
(In reply to David Bialer [:dbialer] from comment #5)
> Jumping in and excuse my ignorance.  If I understand correctly, it seems
> that we are 'tricking' users into updating an app to a special blocklist app
> in order to disable it?

Yes, that is true.

> If that is correct, putting on my user hat, I would want to be protected but
> want to be protected knowingly.   I wouldn't update something if I saw the
> words "Blocklisted by Mozilla" as it sets off all sorts of warnings in my
> head that I probably shouldn't download it, even though we want them to.  I
> also wouldn't want to be, in a way, fooled into updating by claiming its the
> app name and then having it blocked.
> 
> Can we do some combination - "App Name -  Mozilla Security Update"? (not
> sure of exact words).

Yes, that's possible. Right now we're copying a static zip file, injecting the "ids.json" file, then signing it. This change would also require us to edit the manifest.webapp file inside the zip to say something like the above.

> The idea of using the release notes for an update is a good one, and it
> would be good if a user could preview release notes before they download".
> And we could have a release note that says that the app was blocklisted for
> reason X and, for your protection, please update it.   Is that possible?

It's possible on our side. The reviewer or admin doing the blocklisting could add that text and we serve it with the mini-manifest. We're already serving the release notes but currently not using it so this could be there and not editable by the app developer. We'd need UI changes device side for this to be displayed.

> Longer term, though not currently an option in FFOS, we should use push
> messages to send control messages and to disable apps and notify the user.

Longer term, too, I don't think this is the ideal way to handle blocklisting.
(In reply to Rob Hudson [:robhudson] from comment #7)
> Bug 814136 will verify the app ID, which we will have in this blocklisted
> zip file.
> 
> I've seen some code [1] that compares the mini-manifest to the package
> manifest, which should be a match here too.
> 
> [1]
> https://hg.mozilla.org/mozilla-central/file/38407b98003b/dom/apps/src/
> AppsUtils.jsm#l277

Consider the following scenario.

1. User goes to untrusted website.
2. Website offers to install "hellokitty" app.
3. User accepts.
4. A week passes.
5. App signals that it has an update available.
6. User accepts update of this and 5 other apps.
7. App is now called "Bank of America".
8. User wants to do some banking.
9. User clicks on "Bank of America" and enters bank username and password.
10. Profit.

I thought we already had a check that prevented this from happening. But I can't see one right now. I filed bug 826555

In the meantime, I think we should avoid changing the application name, to be on the safe side.
(Reporter)

Comment 10

5 years ago
If bug 826555 is implemented, I'll need to keep the app name exactly the same as the last version. And depending on how it's implemented, I may also have to consider keeping the locales and default_locale the same.

If it ends up being WONTFIX'd, we can do "{app_name} - Mozilla Security Update". But we should still probably be sensitive to locales and default_locale so the app name doesn't switch locales on the user.

As it is currently implemented until one of the above is done, the app will say "Blocklisted by Mozilla".

(Kicking to next weeks milestone)
Target Milestone: 2013-01-03 → 2013-01-10
Ok, it sounds like we'll have to wait on this bug then?
Depends on: 826555
Target Milestone: 2013-01-10 → 2013-01-17
(Reporter)

Comment 12

5 years ago
The plan is to let reviewers review name changes via the standard file viewer and diffing tools. On new version approval, we'll update the name that shows up on Marketplace.

Bumping to next week. Closely related to bug 828737 and will use from that patch once committed.
Target Milestone: 2013-01-17 → 2013-01-24
(Reporter)

Comment 13

5 years ago
(In reply to Rob Hudson [:robhudson] from comment #12)
> The plan is to let reviewers review name changes via the standard file
> viewer and diffing tools. On new version approval, we'll update the name
> that shows up on Marketplace.
> 
> Bumping to next week. Closely related to bug 828737 and will use from that
> patch once committed.

That comment was intended for bug 828738.
(Reporter)

Comment 14

5 years ago
Based on what happened in bug 826555, a name change after blocklisting will not show up on device. But will the name change show up in the Update UI?

If it shows in the Update UI, it seems like it might still be worthwhile to update the mini-manifest (and package manifest name so verification passes) so the user sees the "App Name - Mozilla Security Update" in the UI. I'm not sure if FxOS checks the mini-manifest against the current name prior to showing the update UI, however.  Asking for clarification from Jonas.
Flags: needinfo?(jonas)
The changed name shouldn't be showing up anywhere. I suspect that is already the case.
Flags: needinfo?(jonas)
It doesn't really matter much what we do on the marketplace side. I don't think the user will see a difference either way.

When updating an app and the update contains an app with a different name, we currently don't display the new name anywhere. Neither in the update UI, or on the homescreen after the app has been updated. We always use the name that was used at install time.

The only thing that might get affected is if the user changes locale while the app is blocked. There might be some edge cases where if locales were added between the time of the last update, and when we download the blocklist update, and the user then switching languages on the device while the app is blocklisted. In this case it's possible that the user will get the "Blocklisted by Mozilla" name.

This feels very unlikely to happen. But the downside is that if it does happen the user will get stuck with that name even once we publish a new update which unblocklists the app. Which would be unfortunate.


So I don't think doing anything in particular here is important. But there is a very small risk that the user gets a poor user experience. Though technically it's a device-side bug if that's the case.


In the long term all of these problems will go away and we will permit renaming apps. For signed apps we'd likely simply rename the app without asking the user. Once we get there, it's probably better that the blocklist-name contains the real app name, such as "<appname> blocklisted by Mozilla" since otherwise the user might get confused where their app disappeared to.


In general, I think it's better that we mess around with the icon of the app to indicate that it's been blocklisted, and leave the name as the real name of the app.
The last two paragraphs doesn't really apply right now though, and we can change the naming policies once we get to the point of actually supporting renames.
(Reporter)

Comment 18

5 years ago
Given comment 16, I'm going to remove this from any milestone and wait for app rename support on device to happen.
Assignee: robhudson.mozbugs → nobody
Target Milestone: 2013-01-24 → ---

Updated

5 years ago
Component: Consumer Pages → General
Whiteboard: [blocked on platform]
Is there a bug we can block this on?
Severity: normal → enhancement
Priority: -- → P4

Comment 20

4 years ago
Moving over to firefox OS to provide rename support.
Component: General → General
Product: Marketplace → Firefox OS
Summary: Blocklisted app's manifest should point to signed copy of blocklist package → Provide rename support for blocklisted apps
Version: 1.0 → unspecified

Comment 21

2 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.