5 ms·

Why isn't this achieved client side?

• kevincox 4y ago
  CORS makes this difficult. For non-CORS enabled sites you would need to use a server-side proxy. But at that point why not do the filtering on the server to avoid transferring unnecessary data?
  • lucb1e 4y ago
    > For non-CORS enabled sites 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.
    • kevincox 4y ago
      CORS was a hacky fix to a bad design that we are still paying for. But backwards compatibility is nice I guess.
      • lucb1e 4y ago
        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 malware industry). But I can see how you could see it another way indeed
        • kevincox 4y ago
          But you can access other domain's data! You just need to proxy via the server. 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.
• a2128 4y ago
  It can be, Firefox and some other browsers have a built-in reader view. This website is useful regardless for sharing articles with people who don't know about reader view or whose browsers don't support it