Homebrew-cask: Dealing with unofficial apps with official-looking names
Ping @caskroom/maintainers.
New rule proposal inspired by https://github.com/caskroom/homebrew-cask/pull/39706 and https://github.com/caskroom/homebrew-cask/pull/39707.
If a service has no official app and a third-party makes one, that app will always be treated as a fork (i.e. have the vendor prefix) if the name is used without permission and makes the app look official. If the vendor name still makes the app look official, then an -unofficial suffix is to be added instead.
This is to protect users from using something they think is officially approved but is not.
Examples:
protonmailwould be renamed toprotonmail-desktop-protonmail, but since that is still ambiguous, it would be renamedprotonmail-unofficialinstead.pocket-castswas renamedmortenjust-pocketcasts
Personal examples:
- Fog is an unofficial app for https://overcast.fm/. Neither the name nor the icon make it look official in any way.
- appear.in is an unofficial app for https://appear.in/. Both the name and the icon make it look official but not only do I have permission to use them both, I also have an agreement with them to retire my app if they ever decide to make one. I’ve also seen them recommend my app on Twitter occasionally. In that sense, my app is somewhat officially unofficially.
Naturally, feel free to disagree.
vitorgalvao
All 14 comments
I don't think it should be our responsibility to highlight that something is unofficial. Users should know what they are installing, and if there is no official alternative, I doubt this will be helpful to anyone.
reitermarkus
on 17 Oct 2017
@reitermarkus That goes in line with not a discoverability service, yes. However, this change also has the practical benefit of reducing renaming events.
vitorgalvao
on 17 Oct 2017
However, this change also has the practical benefit of reducing renaming events.
Looking at the last three years, how many instances of that have we had?
I just skimmed the output of git --no-pager log --name-status --diff-filter=R --since=2014-10 and could not find an instance of this other than pocket-casts. I may have overlooked one or ten but by all means they don’t seem to abound.
I like the idea behind this PR. That said, in addition to the point @reitermarkus has already made, I feel the gain may not be worth the potential UX cost.
claui
on 17 Oct 2017
This is to protect users from using something they think is officially approved but is not.
I agree with your proposal for adding the vendor fork name or -unofficial, I think it is a good idea.
miccal
on 18 Oct 2017
To summon an extreme example: one day, brew cask install is going to install malicious code to users’ systems. (I believe it’s not really a question of _if,_ but _when_ and _in which Cask_ it’s going to happen.)
Assuming this happens with the -unofficial policy in place: will we be able to provide answers to the question, asked in good faith, “Why have the maintainers never marked this as unofficial?”
To be fair, that question could come up regardless of this PR; however, the argument:
users are expected to have reasonable knowledge about the apps they’re installing
appears much stronger to me today than it’s going to be under the -unofficial policy.
This brings me to the following question:
Under the new policy, what can we do to establish up front that the burden of due diligence remains, and will continue to remain, with the user at all times?
claui
on 18 Oct 2017
To summon an extreme example: one day, brew cask install is going to install malicious code to users’ systems. (I believe it’s not really a question of if, but when and in which Cask it’s going to happen.)
commitay
on 18 Oct 2017
I’ve always been a proponent of not a discoverability service, so it may seem weird that I support this change, but I do see value in it.
I don’t think there’s a usability cost on this one. On the contrary, users occasionally grill us on tokens not being descriptive enough according to their expectations (case in point, we eventually relaxed one of the token reference rules for CloudApp). As such, I think users would embrace this policy rather than eschew it.
We also have another rule of this type, for apps with malware.
Also important, this policy does not invalidate not a discoverability service. Meaning users are still expected to know what they are installing. Having said that (how I enjoy that bit!), I do agree that it may weaken the message.
This decision would be made easier if people didn’t just take official names for unofficial apps without permission (I doubt that’s even legal).
For those who disagree (@claui and @reitermarkus), since there are two parts to the rule (part 1: always add a vendor prefix; part 2: add unofficial when the prefix is ambiguous), do you disagree with both parts, or just one of them?
I’m less firm on the part 2, but the protonmail cask does make me uneasy (for the reason given by @commitay). If we don’t go ahead with the policy change, I’d still rather not merge that one.
vitorgalvao
on 18 Oct 2017
it may seem weird that I support this change, but I do see value in it.
I feel it has _significant_ value.
I don’t think there’s a usability cost on this one.
Maybe I’m overestimating the impact. I was imagining brew cask list with odd vendor name prefixes all over the place, breaking sorting orders and all. (protonmail is a good example where the change wouldn’t hurt.)
do you disagree with both parts, or just one of them?
I’m fine with the general idea behind the first part (“always add a vendor prefix”). What I’d suggest is that we relax the rule a little.
that app will always be treated as a fork
Is the “always” qualifier going to confuse users into having unrealistic expectations?
There are many potential obstacles for us to meet the obligation: for example, not all service providers can easily be identified; likewise, not all app vendors can be identified; with open source, vendor names are often ambiguous, or they change over time; also, it can be difficult or even impossible for a maintainer to tell whether a party has the permission to use a name or not.
I’d have better peace of mind if the wording felt less mandatory: The app will always be treated as a fork _if we happen to be aware of any evidence that points to non-endorsement._
will always be treated as a fork (i.e. have the vendor prefix)
The second half of this clause should be enough to get the message across. Let’s lose the “treat as a fork” part.
If [condition], [then] that app will [get the fork treatment] if [other condition].
We should replace the “if” conditional sandwich with a composite clause:
_“if [condition] and [other condition], [then …]”._
if the name is used without permission and makes the app look official
Can we generalize this to “if something suggests the service provider may not endorse the app?”
If the vendor name still makes the app look official, then an -unofficial suffix is to be added instead.
Why not have the liberty to choose one or the other (on a case-by-case basis)?
tl;dr I suggest that we soften up the rule just a little:
If a service has 1. no official app and 2. a third-party makes one, and 3. we know or suspect that the service provider may not endorse the app, then the token can’t have a name that suggests endorsement. If this affects your app name, fix it by doing one of the following: a) prepend the service name with the app vendor’s name, e. g.
srvrio→acmeapps-srvrio; or b) append-unofficialto the app name.
claui
on 18 Oct 2017
I’m all for removing the “always” from the rule. That way we’d still try to do it always but not overpromise when we don’t. I also agree with the rest of the post.
Except with the final wording that makes it seem like adding the vendor prefix or the -unofficial suffix is a user choice. There I think it should follow the original idea, for a few reasons:
- Predictability. We want the rule (like all others) to be mostly consistent with few exceptions. There’s a reason we have such a strict token reference — its predictability prevents duplicates.
- Adding a vendor prefix is already common, as it’s needed for other cases (forks and conflicts). Simply expanding the rule causes the least disruption.
- Reducing the number of
-unofficialapps to the bare minimum. It should be a reserved exception, like-app.
vitorgalvao
on 18 Oct 2017
There I think it should follow the original idea, for a few reasons:
[…]
I think those are all strong arguments. Convinced.
claui
on 18 Oct 2017
@reitermarkus Are you fine with the latest conclusions?
vitorgalvao
on 22 Oct 2017
@reitermarkus Ping
commitay
on 5 Nov 2017
Yes, I'm fine with this on a best effort basis.
reitermarkus
on 6 Nov 2017
Changed the labels. All that’s left to do now is add this to the documentation and close the issue.
vitorgalvao
on 6 Nov 2017
Related issues
tycm
·
3Comments
mmoehring
·
3Comments
CoolTomatos
·
3Comments
akashlevy
·
3Comments
florianletsch
·
3Comments
Most helpful comment
I’m all for removing the “always” from the rule. That way we’d still try to do it always but not overpromise when we don’t. I also agree with the rest of the post.
Except with the final wording that makes it seem like adding the vendor prefix or the
-unofficialsuffix is a user choice. There I think it should follow the original idea, for a few reasons:-unofficialapps to the bare minimum. It should be a reserved exception, like-app.