Live data from Hacker News

Claude's API now supports CORS requests, enabling client-side applications

simonwillison.net

11–20 of 173 posts

Re: Claude's API now supports CORS requests, enabling client-side applications

#12
post #8

Earlier quoted context omitted.

Unless it's the client's keys. Or keys obtained on the client's behalf.

Even using the client's keys it would be a good idea to give a disclaimer that their key may be stored (If that is the case) and can be accessible through nefarious means. People are very susceptible to phishing attempts etc. and this sort of business model (where you have the client supply the key and store it through the browser is a slippery slope.

Yes, it’s like storing passwords.

Re: Claude's API now supports CORS requests, enabling client-side applications

#15
post #8

Earlier quoted context omitted.

Unless it's the client's keys. Or keys obtained on the client's behalf.

Even using the client's keys it would be a good idea to give a disclaimer that their key may be stored (If that is the case) and can be accessible through nefarious means. People are very susceptible to phishing attempts etc. and this sort of business model (where you have the client supply the key and store it through the browser is a slippery slope.

Let's not train users to do things that are generally unsafe.

"We detected fraud on your account. Click here to secure your account."

"Copy and paste your secret into this box, you can trust us not to look at it."

Re: Claude's API now supports CORS requests, enabling client-side applications

#16

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…

Interesting; I've build a similar application for assisting with the translation of localization files (mozilla's project fluent) and for the same reason as well.

I build this stuff for fun; and because I needed something like it. I don't expect to be making money of it so I want to minimize operational overhead and hassle. So it suits me to not have to build and run an application server for this; even though I'm well capable of building such a thing.

It's available here: fluent-ai.jillesvangurp.com if people want to play with this. It uses openai in the browser and probably can work pretty easily with claude as well. Bring your own key. It's all open source if people want to play with this.

Re: Claude's API now supports CORS requests, enabling client-side applications

#17

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…

Could ads even support such AI heavy use cases?

I'm kind of out of touch with current AI API pricing and ad revenues, so i'm curious how the economics work out.

Re: Claude's API now supports CORS requests, enabling client-side applications

#18
post #9

> I must strongly advise against making direct API calls from a browser, as it exposes your API key and violates best practices for API security. Hilarious that even the LLM warned against this

Bit of an odd warning though, considering how half the internet works. I suppose the warning is missing some context. It is a bad idea to give your API key directly to web services you don't know or trust. For those situations, OAuth with fine-grained scopes would be more suitable.

If it is just your own web app, and you have an input for a key, I don't really see the issue.

Re: Claude's API now supports CORS requests, enabling client-side applications

#19
post #4

The "dangerous" part of "anthropic-dangerous-direct-browser-access" is because you should never expose API keys in client code.

Unless it's the client's keys. Or keys obtained on the client's behalf.

Generally speaking that is what OAuth should be used for with clearly defined scopes and insights in what apps are making use of the API through your account. Not an API key with full access and no limitations.

With openAI and other providers, I know you can limit the budget for a key, but that is still a pretty broad scope you are left with.

Re: Claude's API now supports CORS requests, enabling client-side applications

#20

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…

Could ads even support such AI heavy use cases? I'm kind of out of touch with current AI API pricing and ad revenues, so i'm curious how the economics work out.

[deleted]
Post reply on HN