8 ms·

I would point out that this will likely be used 99% of the time by people who want to charge for access to content... that they don't themselves own. If you've

by derefr 2y ago

I would point out that this will likely be used 99% of the time by people who want to charge for access to content... that they don't themselves own. If you've ever wandered the skeevier parts of the internet (the parts that a teenager not yet experienced at writing search queries might find themselves on if they were trying to e.g. download a software crack/keygen), then you'll frequently find that the pages you land are run by middle-men trying to grab some margin for themselves. You'll see sites that pretend to be e.g. a torrent tracker or direct-download website, but where all the links actually are indirected by a service like Adfly — a service that interstitials those links with pages full of ads, which pay out to the person who created the links. And these links often don't even go anywhere after the interstitial; the sites make money off of people hoping the site will work and therefore trying the links at least a few times before giving up. (This "dark pattern" of an Adfly link pointing at nothing, or at another Adfly link ad-infinitum, is so prevalent that most adblockers just block adf.ly altogether, since an adf.ly link almost never takes the user anywhere useful but is just stealing their attention to no end.) That's not exactly the parallel here — but I think that's a dark pattern that everyone here has experienced at least once. The pattern that is applicable here, is another one used by these same skeevy sites: the "unlock the Download button below by clicking the link above and filling out a survey" pattern. In theory, some of those might even work. (I've been curious and tried a few times, and I've never seen one that actually ever unlocks the Download button. Maybe because I'm not willing to disable my ad-blocker for the "survey"...) But this service seems perfectly positioned to be used by people building that exact scummy flow. "Go through stupid revenue-for-me-generating process A, and I'll give you the password required to follow link B." (Where link B likely isn't even to something the person themselves owns / has any right to be making money on, but just something they found hosted somewhere else and SEO MITMed themselves in front of.) --- I would note that anyone that actually wants to charge for their own original content these days... would likely use a platform that both hosts the content and protects it behind a paywall. Gumroad, for example, or Patreon. (Or OnlyFans, even.) Unlike a link-redirection service, these platforms protect the content to ensure that only the people who pay for it will be able to access it — people can't just bypass it by sharing the redirected-to link. (They can re-upload a download somewhere, but that's a much higher barrier to most people, e.g. on mobile.)

derefr 2y ago
Tangent: I would note that a "password protect an arbitrary link" service could actually be made into a "thin, just-in-time" form of one of these services... by not being a redirect service, but rather being a dynamic, fixed-URL-prefix-route reverse-proxy service. Hypothetical design: 1. you generate a password-protected link for a base URL https://origin.example.com/foo https://origin.example.com/foo — this gives you a generated link https://abc123.link-protector.example.com/ https://abc123.link-protector.example.com/ (where abc123 is the generated-link ID.) 2. All *.link-protector.example.com subdomains CNAME to a single service. 3. This service's backend is an auth-protected reverse-proxy. On each request, it checks for an auth cookie unique to the subdomain. 4. If the auth cookie is good (signed by the backend, non-expired), then you take the happy path, where all paths on the subdomain will proxy-rewrite to paths under the original path /foo of the original domain. 5. If you don't present a good auth cookie, then all paths on the proxy subdomain instead redirect to a special /proxy-cgi/auth route, that has an auth system mounted to it. On successful auth, that auth system backend sets the cookie for the subdomain, and then redirects you back to the original path you requested. (Note that the distinct subdomains per link are necessary here, to stop a malicious user of the service from stealing the cookie of a sibling proxy. You could avoid this by only using one auth cookie for the base domain, and then having every request look up the userID from that auth cookie to map it to a set of links that userID has been authed for — but that's a lot more expensive architecturally than this sort of "the LB can figure it out on its own" design.) With this hypothetical design, at least the protection wouldn't just strip itself off each time someone fills out the password. Re-sharing the base URL — or any other URL navigated to on the same site! — would just result in the person who receives it also needing to know the password. I still doubt there's be many use-cases for such a service compared to a vertically-integrated platform like Gumroad/Patreon. People who want to sell the resource would likely still much prefer to use those, rather than stringing individual components together. But I suppose that a password-protected reverse-proxy service would at least let you e.g. turn a public-but-anonymous resource (e.g. a page on a Pastebin-alike) into a members-only resource for a group. (Even better for that use-case, though, would be if the reverse-proxy service allowed not only password-based sharing, but invite-based or group-based sharing, where link viewers must SSO-authenticate to the reverse-proxy. This would be like Google's BeyondCorp Identity-Aware Proxy, but for stuff outside your GCP VPC, and with one-click setup.)

by derefr 2y ago

derefr 2y ago

Tangent: I would note that a "password protect an arbitrary link" service could actually be made into a "thin, just-in-time" form of one of these services... by not being a redirect service, but rather being a dynamic, fixed-URL-prefix-route reverse-proxy service. Hypothetical design: 1. you generate a password-protected link for a base URL https://origin.example.com/foo https://origin.example.com/foo — this gives you a generated link https://abc123.link-protector.example.com/ https://abc123.link-protector.example.com/ (where abc123 is the generated-link ID.) 2. All *.link-protector.example.com subdomains CNAME to a single service. 3. This service's backend is an auth-protected reverse-proxy. On each request, it checks for an auth cookie unique to the subdomain. 4. If the auth cookie is good (signed by the backend, non-expired), then you take the happy path, where all paths on the subdomain will proxy-rewrite to paths under the original path /foo of the original domain. 5. If you don't present a good auth cookie, then all paths on the proxy subdomain instead redirect to a special /proxy-cgi/auth route, that has an auth system mounted to it. On successful auth, that auth system backend sets the cookie for the subdomain, and then redirects you back to the original path you requested. (Note that the distinct subdomains per link are necessary here, to stop a malicious user of the service from stealing the cookie of a sibling proxy. You could avoid this by only using one auth cookie for the base domain, and then having every request look up the userID from that auth cookie to map it to a set of links that userID has been authed for — but that's a lot more expensive architecturally than this sort of "the LB can figure it out on its own" design.) With this hypothetical design, at least the protection wouldn't just strip itself off each time someone fills out the password. Re-sharing the base URL — or any other URL navigated to on the same site! — would just result in the person who receives it also needing to know the password. I still doubt there's be many use-cases for such a service compared to a vertically-integrated platform like Gumroad/Patreon. People who want to sell the resource would likely still much prefer to use those, rather than stringing individual components together. But I suppose that a password-protected reverse-proxy service would at least let you e.g. turn a public-but-anonymous resource (e.g. a page on a Pastebin-alike) into a members-only resource for a group. (Even better for that use-case, though, would be if the reverse-proxy service allowed not only password-based sharing, but invite-based or group-based sharing, where link viewers must SSO-authenticate to the reverse-proxy. This would be like Google's BeyondCorp Identity-Aware Proxy, but for stuff outside your GCP VPC, and with one-click setup.)