Hacker News Reader

Comment by marktolson | Hacker News Reader

What if outline.com simply did a GET request on the source from the browser, stripped out paywalls and ads and served the content from the source server. Is that still copyright infringement?

View on HN

That's basically what Brave does - web browser with a built-in adblocker. Or, for that matter, Chrome with any adblocking extension. It's not illegal, but it's not exactly popular with webmasters, and they're within their rights to block access to these browsers. In practice it tends to evolve into a cat-and-mouse game where adblockers block the ads, websites try to detect the adblockers and show you a pop-up encouraging you to turn off the adblocker, adblockers try to block the pop-ups, and so on.

Brave does more than that: https://news.ycombinator.com/item?id=18734999

Adblock Plus should fork its own web browser with built-in Acceptable Ads whitelisting. It'd be more honest than Brave.

Acceptable Ads is anything but honest. They take money to whitelist ads. Including ads from Taboola, one of the worst ad network. https://www.businessinsider.fr/us/google-microsoft-amazon-ta...

Now, I'm not a user of Acceptable Ads, but I don't think either their specific policy of taking money to whitelist AA-compliant ads from large companies, or having that policy apply to entities that have otherwise scummy ads is necessarily dishonest.

- Taboola ads are scummy

- Acceptable Ads is not supposed to allow scummy ads

- Taboola paid to get their ads accepted

- Acceptable Ads is dishonest

If you google a bit, you'll find that the ads that get whitelisted under Acceptable Ads are nothing different from the normal Taboola bullshit. In fact, the whitelist is quite simple: They allow the whole taboola network to operate.

Webmasters hate it when you do this but there’s nothing they can do to stop you

Yep, it's one secret technique they don't want you to know about.

That sounds like Reader View. I don’t think copyright law requires rendering the entire webpage exactly as the server requests.

I see no difference between visiting a webpage with a browser or through a program which modifies the content prior to delivery. That's exactly what any a browser plugin does.

The big difference is that if the program is run on the server of somebody else, it needs rights for redistribution (copyright) for the redistributor server, which is a different entity than you (who is running the local program).

Exactly, people want to make this a simple case (outline is really just a browser by a different name) but copyright isn't a bright line domain: intent matters and outline is just re-hosting other peoples content for broad consumption.

This would be true for every switch on the route.

Those have an implied license by the copyright holder.

Those don't modify or cache the content, only serve it to the user which the publisher approved serving it to, and increasingly with HTTPS they can't even see it. Moreover, the publisher is implicitly accepting that by being on the Internet.

Of course a lot of content is cached along the route, for frequent access urls.

Not by network hardware, which is the context of this discussion.

It's also not the type of activity being discussed, which is unauthorized caching: a content provider who uses a CDN is doing so intentionally and while shared local proxies are increasingly uncommon they also respect the Cache-Control headers set by the source — see e.g. https://redbot.org/?uri=https%3A%2F%2Fwww.wsj.com — so again there's the distinguishing factor of authorization.

I'm absolutely foggy about the specifics, but I wasn't talking about CDN, rather about the ISP-side.

Because this is disallowed by CORS/single origin policy

I think the OP stated a "what if", ie "What if CORS didn't exist?" I also think you could argue "What if outline loaded articles in an iframe?" (and at the same time "what if same-origin policy wasn't a thing?") If it was technologically possible, would it be infringing?

> If it was technologically possible

It's actually pretty easy, you can start chrome with --disable-web-security flag [1]

> I also think you could argue "What if outline loaded articles in an iframe?"

I'm sure this would be legal as it's equivalent to loading the site in a tab. The parent site wouldn't be able to manipulate any of the content/ads/paywalls/functionality, and the content site gets the full hit.

[1] https://stackoverflow.com/questions/3102819/disable-same-ori...

> The parent site wouldn't be able to manipulate any of the content/ads/paywalls/functionality

What? What do we disable CORS for if not to allow Javascript from one domain manipulate content in an iframe of an other domain? Am I missing something?

Disabling CORS would allow you to make straight requests to foreign content from your site and manipulate the responses exactly as though they came from your own servers - no iframe needed. CORS does not disable iframe sandboxing.

CORS is just a security feature, it does not imply anything about copyright or terms of use.

The DMCA ties the two by prohibiting users of copyrighted works from circumventing technological protection measures. It could be argued that bypassing CORS applies.

CORS isn't a technological protection like a DRM and isn't design as such, it's purely a security measure, by default you don't even specify it. Browsers are free to ignore them as they wish (but with increased security risks of course).

I agree. CORS is something my user agent does to protect me. It has nothing to do with the upstream site; I could easily browse it with a user agent that doesn't support CORS and nothing would break. CORS is just some annotations that lets my user agent determine "hey these scripts might be up to something shady". It is not a copy-protection mechanism by any means.

Yeah, but my point is what was being suggested is physically impossible with CORS in place, so it does imply something about what is in the realm of possibility.

CORS is really just a security for embeded pages and elements. It's not intended and cannot enforce usage restrictions/rights since it requires the client (browesr) to honor the setting. If I wget a page and strip the text from it, I'm not embeding the page in any manner so CORS is irrelevant. The current 'aggrement' for respecting copyright (wether it would hold up in court even with a TOS is beyond my knowledge) is robots.txt which, I'll admit is pretty dated and a very poor solution for dynamic pages and still requires client .

The best solution for copyright/paywall enforcement is to roll your own. If the request doesn't have the required cookie to access the full article, don't respond with the full page. This works very well for dealing with sites such as outline.com .

Sites like outline.com would be really interesting/usefull if they allowed you to upload your login cookies so that they could get paywalled articles and still strip the ads.

> If the request doesn't have the required cookie to access the full article, don't respond with the full page

The way outline.com works is by loading the article unsuspiciously once from their server, then serving it any number of times from their infrastructure. How would this stop that from happening?

Yes, it is. It's a form of republication, and as such, protected under copyright law. The difference between a third-party server side solution and client-side solutions is easy to see: client-side solutions don't redistribute.

Reply on news.ycombinator.com