101–110 of 173 posts
It was about time. We definitely wasted a bunch of time making a server side arch for pretzelai.app because claude (unlike openai) didn't have dangerouslyAllowBrowser option. No idea why this took them so long
>> why this took them so long They were trying to have Claude code it up - but every time it got close to working, Claude would lose context and hallucinate and the code would break. Been there too many times with Good Ol' Claude.
Web security noob here. Why does CORS even exist? The fact that a website can’t make a request to another website unless that domain likes it is kind of insane to me. Everyone in the comments here is going on about how maybe the user’s API key gets leaked by a malicious application or whatever but, like, when I write software that isn’t in the browser I can just send a request to anyone without restrictions and as fa…
The canonical issue that CORS solves is:
1. I log into my bank. 2. I load an untrusted site. 3. That site does `POST https://mybank.example/transfer` to transfer my money to them.
This works because of the braindead decision to include the cookies obtained in step 1 in the request made in step 3.
But to avoid breaking the web they had to do this "gently". So they did the following:
1. Add the Origin: header so that sites could check for this problem. (opt-in protection) 2. Add CORS for as much as they could without breaking too many existing sites (opt-out protection).
If you are designing a site what you probably want to do is check the Origin header and just set `Access-Control-Allow-Origin: *` (which is better than mirroring the origin as it blocks automatically-added credentials like cookies).
This doesn't fully solve the problem due to the legacy compatibility carve-out in 2 (https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simpl...). But was unfortunately necessary to help hotfix existing sites that were vulnerable while avoiding breaking too much (in which case it would never ship). Notably this carve-out includes HTML POSTs! So if you use regular HTML forms on your site you still need to opt-in to proper protection.
These days most browser partition cookies by top-level origin anyways, so CORS is mostly obsolete. But you can't rely on that.
People will often tell you that CORS is about controlling which origins can see your content. That is mostly false. Because you can easily run a CORS proxy to access any publicly available content. What CORS does is simply prevent implicitly added authentication such as cookies and basic auth from being sent cross-domain by default (except for the carve out)
Web security noob here. Why does CORS even exist? The fact that a website can’t make a request to another website unless that domain likes it is kind of insane to me. Everyone in the comments here is going on about how maybe the user’s API key gets leaked by a malicious application or whatever but, like, when I write software that isn’t in the browser I can just send a request to anyone without restrictions and as fa…
Simple, if you have an iframe pointing to http://foo.test/deletesite.php , without cors that request will be done, with cookies and everything, without the user being aware of it.
Earlier quoted context omitted.
Simple, if you have an iframe pointing to http://foo.test/deletesite.php , without cors that request will be done, with cookies and everything, without the user being aware of it.
AFAIKR you don't need CORS for framing, or making cross origin GET or POST. You only need it to read the response of a cross origin request and setting certain request header and body etc. For example you can make a cross origin GET with an img tag, and a cross-origin POST with a form tag and some JavaScript.
Web security noob here. Why does CORS even exist? The fact that a website can’t make a request to another website unless that domain likes it is kind of insane to me. Everyone in the comments here is going on about how maybe the user’s API key gets leaked by a malicious application or whatever but, like, when I write software that isn’t in the browser I can just send a request to anyone without restrictions and as fa…
CORS - or specifically, not permitting cross-origin requests by default - is for preventing CSRF, cross-site request forgery. In particular if the user's credentials (cookies) are passed along with a request to a third party site, then the first party site can act as the user with the user's authority. In other words, evil.com could e.g. send emails on your behalf by making direct requests to your email provider's we…
CORS and the same origin policy don't protect against CSRF attacks by default, at least if we're using the standard definition of CSRF attacks.
An attacker can still "send emails on your behalf by making direct requests to your email provider's" HTTP API even with CORS and the same origin policy in their default settings, as long as your email provider doesn't implement CSRF protection (e.g. anti-CSRF token or Origin header checks). That's why all state-changing HTTP handlers need to implement CSRF protection.
I love making web apps where users bring their own keys. This approach combines the best of both worlds: the convenience of distributing executable files and the benefits of open source. So far, I have developed two web apps: 1. A live transcription and translation app that uses microphone input. This is useful for watching proprietary content and facilitating communication. 2. An app that translates SRT subtitles in…
I made https://github.com/pickledish/cardi as a kind of dynamoDB-based bookmark keeping tool in this style :) though I haven't worked on it in a couple of years.
Web security noob here. Why does CORS even exist? The fact that a website can’t make a request to another website unless that domain likes it is kind of insane to me. Everyone in the comments here is going on about how maybe the user’s API key gets leaked by a malicious application or whatever but, like, when I write software that isn’t in the browser I can just send a request to anyone without restrictions and as fa…
CORS is basically a backwards compatible hack to "fix" the bug that cookies are sent on third party requests by default. The canonical issue that CORS solves is: 1. I log into my bank. 2. I load an untrusted site. 3. That site does `POST https://mybank.example/transfer ` to transfer my money to them. This works because of the braindead decision to include the cookies obtained in step 1 in the request made in step 3.…
The canonical example you give for something CORS and the same origin policy protect against isn't even protected against by default (as you mention), because it requires additional opt-in protection from mybank.example . Why not use a canonical example that is protected against by default? Like evil.com reading all my emails by making a request to email.com ?
You describe CORS as blocking things. I think it's the same origin policy that blocks things, and CORS (Cross Origin Resource Sharing) unblocks things ("sharing"=unblocking).
Earlier quoted context omitted.
I don’t think it’s cheap because VC money is subsidizing losses on every token. It’s getting cheaper because models and infrastructure are becoming more efficient. And I really don’t think any of the AI API providers can “capture the whole market”. There are at least 3 of ballpark equal capability, so I don’t see how dramatically raising prices is compatible with dominant market share.
Even if the inference is getting cheaper, all the frontier companies are running massive losses building and serving it. That has to come back eventually, that's just how capitalism works. Just remember that Netflix didn't start really jacking up the price till after the other players entered the streaming war, when they were pioneers it was dirt cheap. The existence of Disney+ didn't stop them at all.
Dell was never able to jack up its prices, even when it was dominant in the market, because people would just go to another vendor. I think OpenAI is closer to a Dell than a Netflix.
Earlier quoted context omitted.
CORS is basically a backwards compatible hack to "fix" the bug that cookies are sent on third party requests by default. The canonical issue that CORS solves is: 1. I log into my bank. 2. I load an untrusted site. 3. That site does `POST https://mybank.example/transfer ` to transfer my money to them. This works because of the braindead decision to include the cookies obtained in step 1 in the request made in step 3.…
I agree with how you describe the behavior, but the terminology you use differs from how I understand things. The canonical example you give for something CORS and the same origin policy protect against isn't even protected against by default (as you mention), because it requires additional opt-in protection from mybank.example . Why not use a canonical example that is protected against by default? Like evil.com read…
> Why not use a canonical example that is protected against by default?
I think demonstrating how full of holes the default policy is is a great way to emphasis that you should not rely on the default protections. It is a huge hack and you should put into place proper protections if your site uses any form of implicit credentials.
> You describe CORS as blocking things. I think it's the same origin policy that blocks things
CORS and the same origin policy are the same thing, two sides of the same coin. They express what is allow and what isn't. CORS is a configuration layer for the same origin policy, allowing you to change the default policy.
Earlier quoted context omitted.
CORS is designed to protect the server data. It's a tool that gives servers a control mechanism to tell browsers "who can access my data". Imagine that your banking website used a standard JSON+REST API with cookie based authentication to trigger & validate a transaction request. When a request to `fetch` or XMLHTTPRequest is made from ANY site, the browser will still populate cookies for 3rd party sites. So without…
> When a request to `fetch` or XMLHTTPRequest is made from ANY site, the browser will still populate cookies for 3rd party sites. I think this is the problem here? Just send the request without cookies if CORS doesn't allow it. (I also think third-party cookies were a mistake in general, and it would be a good thing if they were removed. There were some plans but well, Google.)
The problem is how will the browser know whether CORS would allow it or not? It could send a preflight, yes. In the current rules that's only done for complex requests, not simple requests. You seem to be suggesting preflights be sent for all requests. That would balloon the number of requests, adding RTTs, slowing down page loads.
E.g. if example.com embeds an image from imgur.com and the browser happens to have a cookie in the imgur.com cookie jar, should the browser send a preflight request first to decide whether to attach cookies to the request or not? That preflight would slow down the page load. In the current rules, the cookies are simply attached, with no preflight required for that type (simple) of request.