Show HN: Web0.cc – Generate clutter, ad and tracker free article pages to share (web0.cc)
I recently observed that majority of my family members and friends are not using ad blockers and reader mode
for reasons suck as lack of knowledge about plugins & laziness.
So their online reading experience is not pleasant as a result very less amount of them read anything including what i share.
Its an attempt to give them clutter, tracker & ad free reading experience right off the bat.
64 comments
[ 3.1 ms ] story [ 127 ms ] threadJust some feedback for you here, instead.
I will definitely try to improve the library or find another way to support the mentioned website.
Thanks for the feedback.
I think this is a good tool to share articles with not tech savy parents who cant distinguish between ads and real content.
Honest question, Would you enjoy reading articles from archive.is on your mobile phone?
as far as i remember, its not mobile-friendly.
But I can agree that it doesn't render mobile-friendly websites by default.
Here's an opinion article from the Times, seems to work fine:
https://web0.cc/a/zTHtZFEXci
Suggestion for web0: include the final part of the URL in the new URL, so you can at least make a guess as to what it is. Include a GUID at the end if you need to disambiguate.
Do you mean like this https://web0.cc/a/zTHtZFEXci?url=https://www.nytimes.com/202...
https://web0.cc/a/zTHtZFEXci?url=https://haxx0r.c0m
I was thinking more along the lines of
https://web0.cc/a/opinion/english-literature-study-zTHtZFEXc...
Of course it doesn't actually grant you security.
What if your original link with the `url=` refused to load if the target didn't match the query parameter? That would actually make it secure, no?
Which is essentially every website, as CORS underpins how the web works. Only if there is a public API for a given site, would it be possible to do otherwise. And then you'd usually still need URL to API mapping, plus any further API sign up stuff that may or may not be required for simple GETs.
But backwards compatibility is nice I guess.
But I can see how you could see it another way indeed
As I understand it the main "bug" that CORS fixes is that cookies were sent by default on cross-domain requests. This basically means that APIs were always authenticated no matter what site you were on. The funny thing is that browsers are stopping this cross-domain cookies anyways by adding domain isolation to prevent tracking. So this main feature of CORS is becoming obsolete. I wish that domain isolation was the initial fix (at least by default) but at the time it was thought that this backwards incompatibility wasn't worth it, so CORS is what we got.
There is one other feature of CORS which is network perspective. However it isn't an effective solution anyways due to domain rebinding attacks. So it is a best-effort mitigation at best. Blocking basically all client-side application use (RSS readers, API exporers, URL previews in chat apps ...) by default seems like a really high price to pay for this minor mitigation. A better approach would probably be browsers just blocking requests from public sites to internal IPs by default. That would actually be reliable (as long as you aren't abusing public IP space for your private services), block requests that aren't CORS protected (like form posts!) and would avoid the huge cost of CORS.
As it is if you want to do stuff client side you need to set up a CORS-stripping proxy server which is really annoying and creates a dependency on your service. At the end of the day CORS is a hacky mitigation for the braindead choice to send cross-site cookies by default. If you want real security you should protect your API via a real technical measure, not just hoping the the browser will block requests.
I know it's a minor point but I'd go "Remove clutter, ads and trackers from any article" for a stronger initial proposition.
I miss hyphens.
[1] https://en.wikipedia.org/wiki/Garden-path_sentence
> Generate pages free of ads, trackers and other clutter.
Put the major purpose in the first two words.
[edit - otoh it doesn't generate pages really but generates versions of existing pages]
"Share any link with ads and tracking removed."
Rationale:
Sharing = most important verb/subject. Followed by the subject (links)
Ads and tracking - people know what ads are, they might know what tracking implies. trackers may be more abstract.
Clutter - removed this word. What does clutter mean in this context?
First of all thank you all for the feedback & suggestions.
I think these all are good suggestions. I will pick one for sure
Faculty cannot detect the use of "AI". We have much about that. But neither can "tech" companies.
As for the submission, unlike archive.is, archive.ph, etc. web0.cc does not require Javascript, it does not require the user to solve a CAPTCHA, it does not insist on EDNS0 (ECS),^1 and it does not connect to the following third party URLs
https://www.google.com/recaptcha/api.js?onload=onloadCallbac...
https://www.google.com/webmasters/tools/ping?sitemap=https:/...
https://a.publir.com/platform/1100.js
https://a.publir.com/sellers.json
https://a.publir.com/ads-txt/505/ads.txt
https://top-fwz1.mail.ru/js/code.js
1. Including disabling the use of Cloudflare DNS. Even when a user is not using EDNS0, archive.ph still collects the user's IP address using DNS. For example,
Further, archive.ph does not seem to work with archive.org. Web0.cc seems to work:https://web.archive.org/web/20230313185743if_/https://web0.c...
https://web0.cc/a/e-cYg2rJ8Q
https://arstechnica.com/science/2023/03/floating-solar-panel...
Thanks for finding the bug.
Then people don't need to copy the url, go to web0.cc, paste it and submit.
Also maybe if the refresh can be reliably done after a few seconds then you could make the page refresh itself automatically (it's not difficult for the user but it's one less thing to handle). You could tweak the refresh time by how busy your site is.
>> Nice. How about creating a bookmarklet to make it super easy to share a web0.cc link from the current page?
Sure, i will do it
>> Also maybe if the refresh can be reliably done after a few seconds then you could make the page refresh itself automatically (it's not difficult for the user but it's one less thing to handle). You could tweak the refresh time by how busy your site is.
Thats a good feature but it involves JS and for some reasons i decided not to put JS on the client side.
Actually, you don’t need JS. The simplest mechanism is probably:
https://en.m.wikipedia.org/wiki/Meta_refresh
(Both HTML tag and HTTP header routes would probably work)
How'd you build it? I built something vaguely similar (but generating epub) using Mercury Parser.
What's the short of why manual refresh is needed?
Given that it now has queueing, server-side processing, and forever-links, clearly there's computing power and storage behind it. What will this cost to run? Would I not risk ads being shown when we start to use this frequently?
There are 2 caveats:
* There are broken HTML files that somehow still work with a browser.
* There are web pages that rely on javascript even for the main text.
Thanks for sharing.
There wont be much we could do If its behind captchas.
Thanks for giving it a try.
CL= Content Length WP= Average Word Length (i used 5) WPM = Words per min, reading speed (i used 180)
not perfect but good enough.
Thanks breck for giving the app a try
[1] https://www.wired.com/story/the-electron-is-having-a-magneti...
[0]: https://www.cnn.com/2023/03/13/business/svb-employees-angry-... , https://web0.cc/a/8ev_GjUcz-
[1]: https://deadcells.fandom.com/wiki/Promenade_of_the_Condemned , https://web0.cc/a/tymsJ3ZIH0