Huh, that's a pretty interesting request. And it makes sense to me. I've enabled it on my RSS feed. I wanted to see if I could add my blog feed to it to test but when I went to do so I had to install a Chrome extension on your app to do it. All right, if someone wants my blog for whatever reason that badly, they can now do it.
This seems to really reason through only the happy path, ignoring bad actors, and there'll always be bad actors.
True, but the bad actors can defeat any security mechanism you put in place with a proxy, or a copy'n'paste, so the downside risk is pointless worrying about. The upside of allowing traffic is that your content that you presumably want people to read can be read by more people. For all but the most popular blogs that's probably a net benefit.
If a malicious website wanted to copy a blog's website to put ads on it, they already can just copy it outside of the browser on their end, which has the "benefit" of preventing the original blog from taking the post down.
CORS also doesn't prevent a popular website with a personal vendetta[0] against a blogger from DDOSing the blog with their visitors, since CORS doesn't block requests from being sent.
For a purely static website, there shouldn't be any risk from enabling CORS.
To be fair, they do explain their motivation. It's an in-browser RSS reader, so it's fetching the RSS feed directly without a proxy server. There's not much risk since the content is public and non-credentialed. The bigger risk is misconfiguring CORS and inadvertently exposing other paths with the wildcard.
Um, no? the most popular RSS reader back when RSS readers were a thing was Google's. It was a website. And why not. Like other websites, you can log in from any device that has a browser and immediately pick up where you left off, including work machines where you aren't allowed to install native apps.
Hey folks, I'm the developer working on Blogs Are Back. WakaTime has me clocked in at over 900 hours on this project so far...
If CORS weren't an issue, it could've been done in 1/10th of that time. But if that were the case, there would've already been tons of web-based RSS readers available.
Anyway, the goal of this project is to help foster interest in indie blogs and help a bit with discovery. Feel free to submit your blog if you'd like!
If anyone has any questions, I'd be happy to answer them.
In my opinion, that’s a bigger problem than CORS. Proxyless web feed reader is a lost cause, you’re wasting your time because only a small minority are ever going to support it. But that opacity and transition nonsense gratuitously slows down page loading for everyone, and hides content completely for those that aren’t running JS.
(What I would also like to know is: how come this is the third time I’ve seen exactly this—each block of content having this exact style attribute—in the past month, when I don’t remember encountering exactly it before?)
The entire web app is JS based. It's a requirement I'm ok with.
And to answer your question, you're seeing that kind of styling so frequently because it's likely part of Framer Motion, an extremely popular animation library
Hey, this is very interesting! As someone working on an extension that works as an ActivityPub client, I don't have to deal with CORS issues so much (most servers configure CORS properly, and the extension can bypass CORS issues anyway) but I just spent a good chunk of my weekend working on a proxy that could deal with Mastodon's "authorized fetch".
So, basically, any URI that I need to resolve goes tries first to fetch directly and it falls back to making the request through the proxy if I get any type of authentication error.
Huh, that's a pretty interesting request. And it makes sense to me. I've enabled it on my RSS feed. I wanted to see if I could add my blog feed to it to test but when I went to do so I had to install a Chrome extension on your app to do it. All right, if someone wants my blog for whatever reason that badly, they can now do it.
This feels like such a weird ask?
Why would anyone do this, so their content can be easily read elsewhere potentially with a load of ads surrounding it?
This seems to really reason through only the happy path, ignoring bad actors, and there'll always be bad actors.
This seems to really reason through only the happy path, ignoring bad actors, and there'll always be bad actors.
True, but the bad actors can defeat any security mechanism you put in place with a proxy, or a copy'n'paste, so the downside risk is pointless worrying about. The upside of allowing traffic is that your content that you presumably want people to read can be read by more people. For all but the most popular blogs that's probably a net benefit.
If a malicious website wanted to copy a blog's website to put ads on it, they already can just copy it outside of the browser on their end, which has the "benefit" of preventing the original blog from taking the post down.
CORS also doesn't prevent a popular website with a personal vendetta[0] against a blogger from DDOSing the blog with their visitors, since CORS doesn't block requests from being sent.
For a purely static website, there shouldn't be any risk from enabling CORS.
[0]: https://news.ycombinator.com/item?id=46624740
To be fair, they do explain their motivation. It's an in-browser RSS reader, so it's fetching the RSS feed directly without a proxy server. There's not much risk since the content is public and non-credentialed. The bigger risk is misconfiguring CORS and inadvertently exposing other paths with the wildcard.
Also, why would an RSS reader be a website? An application installed on your PC is superior in every way.
Um, no? the most popular RSS reader back when RSS readers were a thing was Google's. It was a website. And why not. Like other websites, you can log in from any device that has a browser and immediately pick up where you left off, including work machines where you aren't allowed to install native apps.
Hey folks, I'm the developer working on Blogs Are Back. WakaTime has me clocked in at over 900 hours on this project so far...
If CORS weren't an issue, it could've been done in 1/10th of that time. But if that were the case, there would've already been tons of web-based RSS readers available.
Anyway, the goal of this project is to help foster interest in indie blogs and help a bit with discovery. Feel free to submit your blog if you'd like!
If anyone has any questions, I'd be happy to answer them.
> style="opacity:0;transform:translateY(20px)"
In my opinion, that’s a bigger problem than CORS. Proxyless web feed reader is a lost cause, you’re wasting your time because only a small minority are ever going to support it. But that opacity and transition nonsense gratuitously slows down page loading for everyone, and hides content completely for those that aren’t running JS.
(What I would also like to know is: how come this is the third time I’ve seen exactly this—each block of content having this exact style attribute—in the past month, when I don’t remember encountering exactly it before?)
The entire web app is JS based. It's a requirement I'm ok with.
And to answer your question, you're seeing that kind of styling so frequently because it's likely part of Framer Motion, an extremely popular animation library
https://www.npmjs.com/package/framer-motion https://www.npmjs.com/package/motion
Hey, this is very interesting! As someone working on an extension that works as an ActivityPub client, I don't have to deal with CORS issues so much (most servers configure CORS properly, and the extension can bypass CORS issues anyway) but I just spent a good chunk of my weekend working on a proxy that could deal with Mastodon's "authorized fetch".
So, basically, any URI that I need to resolve goes tries first to fetch directly and it falls back to making the request through the proxy if I get any type of authentication error.