Make explicit apps behind a registration wall should not be accepted

[vitorgalvao]

@rolandwalker has expressed concerns about such casks, and even removed some. I’m considering @ndr-qef agrees with the policy, since he merged the mentioned commits.

I’m also very much in agreement, and while I do not think the required comment for urls on domains different than homepage should be documented necessarily (since maintainers have to manually check them, anyway), I do think a policy of not accepting links only available behind paywalls should.

Two questions need to be answered, if this is to be accepted:

1. Should this only apply in cases where url is on a different domain than homepage? This is important because as mentioned in the first linked comment, there may be licensing conditions that need to be satisfied.
2. If a maintainer goes through the trouble of verifying the download url, even if on a different domain than the homepage (by creating a dummy account, for example), should it then be included? This is irrelevant if the answer to the previous point is negative.

Pinging @caskroom/maintainers.

[rolandwalker]

Theoretically a registration wall can be independent from licensing. In the cases above I was concerned about the licensing, had no data, and couldn't get the data without registering.

When a maintainer can verify the url and/or license, regardless of the domain, I see no problem with accepting the Cask. If no maintainer takes an interest in creating an account, I see no problem with refusing the Cask.

But that doesn't really help with your reasonable proposal to improve the docs.

[phinze]

I must be missing a step here. How would a download URL behind a paywall ever work in a Cask?

[rolandwalker]

Really a registration wall rather than paywall.

Users submit them, and the Cask installations work, but then we notice them when updating the Cask.

Generally we've been removing them when noticed, and Vitor is proposing to document a policy.

[vitorgalvao]

But that doesn't really help with your reasonable proposal to improve the docs.

Well, it actually does.

When a maintainer can verify the url and/or license, regardless of the domain, I see no problem with accepting the Cask.

This would then mean we keep going as we are and don’t need extra documentation. My main concern are s3 urls and the like, since I’m not entirely sure how they work, in terms of setting one up. My question would be: let’s say mixture’s developers decide to abandon s3 altogether, deleting their accounts, and serving the download directly from the website. Would it then be possible for a third party to create an s3 bucket recreating the same url with a malicious app? If that’s possible it might be a concern, since a previously verified link can cease to be at any time. Not that that can’t happen with links outside registration walls, but the latter are way easier to catch.

So we should likely pick one of two rules:

1. Every url is allowed, as long as it’s verified by a maintainer when it’s added, and every time it’s modified (#{version} will come in really handy, to make this bearable)¹. If they require a license to be accepted, we should link to it².
2. No urls behind registration walls are allowed, from different domains than the corresponding website.

---

¹ Yes, they can still be compromised like in the exposed hypothetical scenario, but let’s be honest: every cask can fall to this, even the ones where url is from the same domain as homepage if the domain expires and is taken by a malicious third party. We have to draw the line somewhere — if we go too far back, there would be no homebrew-cask.

² Do these really matter? If you’re allowing your file to be downloaded via curl without any protection, and are only obscuring it behind a registration page, you’re likely not achieving much. Unless the license for that software is on that page, which might pose a bit of a problem. In those cases, perhaps a caveat like this would suffice, since there’s not really another reasonable way to present such licenses to users.

[vitorgalvao]

Just found a relevant case while verifying an unrelated PR. That app needs you to accept its terms before downloading yet it doesn’t care if you download it directly. Presenting dmg agreements seems completely reasonable (and I’d say mandatory) to me. Keeping track of website agreements in every cask does not. Just look at the url for the agreement of that download — http://www.yworks.com/en/products_download.php?file=yEd-3.14_with-JRE8.dmg. It’s version-specific, the cask would need to change the page with every update. Not that #{version} couldn’t help with that as well, but it’s starting to get crazy.

This to say that in regards to the previous comment, I propose we ignore website agreements for now in possibility (rule) 1, and come back to it later.

[alebcay]

For the record, there are a number of somewhat "popular" apps currently in the Cask repo that are structured similarly (off the top of my head, I can think of google-chrome and android-studio). Similar to the case with yed, the installation payload of Chrome is still directly downloadable. Even worse for us, the dmg doesn't contain the license. Also, I believe all java packages require the user to accept the Oracle license before downloading begins (although I think the license is probably presented once again further along in the installation in java's case).

[tapeinosyne]

As @rolandwalker and @vitorgalvao said, we may be unable to verify licenses and URLs behind registration walls. I tend to err on the side of exclusion: it is not viable to manage dummy accounts for the purpose of assessment, and users can always setup their own taps.

[phinze]

This would then mean we keep going as we are and don’t need extra documentation. My main concern are s3 urls and the like, since I’m not entirely sure how they work, in terms of setting one up. My question would be: let’s say mixture’s developers decide to abandon s3 altogether, deleting their accounts, and serving the download directly from the website. Would it then be possible for a third party to create an s3 bucket recreating the same url with a malicious app?

Yep this is definitely possible. Though I don't know how much more likely it is than an app changing domain names, which has the same implications. As you say, the key is in how difficult it is for a maintainer to verify.

For the purposes of this thread, it sounds like we have some rough consensus around adding something like this to our policy/docs:

To protect our users, we the maintainers of homebrew-cask make our best efforts
to verify that Casks include legitimate published download URLs. For that reason,
we cannot accept Casks where the official download URL is hidden behind a
registration wall.

Does that sound reasonable to everybody? If so we can close this thread and spin up new ones for any other outstanding conversations.

[vitorgalvao]

@phinze To that policy I’d add a specific note about urls being from a different host than the homepage¹:

To protect our users, we the maintainers of homebrew-cask make our best efforts
to verify that Casks include legitimate published download URLs. For that reason,
we cannot accept Casks where the download URL is simultaneously located
on a different host than the app’s website and hidden behind a registration wall.

This distinction is important, as your phrasing suggests a “no” to my question 1, while this suggests a “yes”. Whichever we choose, I just want to be sure we’re on the same page regarding that.

There’s also the case of already verified casks — what do we do with those? Do we remove them to agree with the policy, or do we keep them? There are likely some popular apps, there (titanium-studio.rb), and it would be a shame to lose them, even if users make a tap for them², specially since they’re verified as trustworthy and are unlikely to change. On the other hand, we should not pick and chose based on if a maintainer felt like creating a dummy account or happens to use the software; we should be consistent.

I have a new proposal, then, that I think could solve the whole issue in a flash, without losing much time (or casks). We simply expand the reach of caskroom/unofficial. We already use it as our “officially supported but use at your own risk” tap, which is exactly the use case, here. We’ve already expanded it to include not only unofficial builds, but builds of dubious origin, like forum posts. We add a new line to the documentation, move the casks, remove the comment, and we’re done.

In a few minutes we’d have the problem solved in a clear way, ready for future and current submissions, without forcing multiple users to create multiple taps.

---

¹Also removed the word “officially”.

² They’d lose the big community behind the official repos helping to keep them up-to-date.

[phinze]

Ah right - because when the URL and the app/company share a domain, we can make a reasonable assumption of the URL's validity even if we can't make our way to a page with a link. +1

Your proposal of shoving all apps of this nature into caskroom/unofficial sounds perfect to me! Shall we make it so? :rocket: :guitar:

[vitorgalvao]

Done in https://github.com/caskroom/homebrew-cask/pull/8748 and https://github.com/caskroom/homebrew-unofficial/pull/36. Waiting review and opinions.

[alebcay]

Sounds great to me, @vitorgalvao.

[tapeinosyne]

We have a good consensus on relegating affected Casks to caskroom/unofficial. #8748 documents this policy.