61–65 of 65 posts
I saw "generate clutter..." in the title and thought "why would I want to generate clutter?" I know it's a minor point but I'd go "Remove clutter, ads and trackers from any article" for a stronger initial proposition.
The two sites I tried this on still had ads showing and where was rendered entirely unreadable.
I dont think that is really a critique. The task is exceedingly difficult. If it works in a lot of sites that is a victory
Is the source code available anywhere?
Earlier quoted context omitted.
The prompt comes up from auto detecting an email address/mailto in the link. You should be able to right click and "Copy Email Address".
The point is more that I don't want to use email for feedback.
Earlier quoted context omitted.
CORS was a hacky fix to a bad design that we are still paying for. But backwards compatibility is nice I guess.
I've always seen it as a feature that you can't access data from outside your own sandbox, kind of the killer thing that made the internet so useful for so many things without worrying about other sites being able to access your domain's data. Now copied to newer OSes and the reason why I trust my mom on Android a thousand times more than on Windows (or Linux, if it had had enough market share to have a serious malwa…
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.