[HN Gopher] Claude's API now supports CORS requests, enabling cl...
___________________________________________________________________
Claude's API now supports CORS requests, enabling client-side
applications
Author : simonw
Score : 331 points
Date : 2024-08-23 03:05 UTC (19 hours ago)
(HTM) web link (simonwillison.net)
(TXT) w3m dump (simonwillison.net)
| yuz wrote:
| Maybe for internal development, but definitely not for a user-
| facing app. Making less impactful of a change. But still nice
| Kiro wrote:
| I'm thinking it enables apps where users can bring their own
| keys without exposing it to my server.
| Yodel0914 wrote:
| That's what I've done for my chatgpt UI - I store the API key
| and any other user config in local storage.
| OccamsMirror wrote:
| That's the only good use of this but I bet people will end up
| leaking their keys being stupid with it.
| TeMPOraL wrote:
| That's on them though. It's nice to have an _option_ where
| the third party app just provides its value-add, instead of
| insisting on being the first party.
| panarky wrote:
| The "dangerous" part of "anthropic-dangerous-direct-browser-
| access" is because you should never expose API keys in client
| code.
| unglaublich wrote:
| Unless it's the client's keys.
|
| Or keys obtained on the client's behalf.
| ozfive wrote:
| 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.
| skybrian wrote:
| Yes, it's like storing passwords.
| TeMPOraL wrote:
| Yes. It's as bad as using password managers.
|
| Wait.
| skybrian wrote:
| From an application developer's perspective, the nice
| thing about using a passkey with a browser cookie is that
| you don't have to store anything sensitive. You're only
| guarding access to your own app with meaningless numbers.
| If your app doesn't store _other_ sensitive data, the
| blast radius is small. There are still denial of service
| attacks to worry about where an attacker can use network
| or compute to run up your bill.
|
| What are we guarding when building an app that uses a
| cloud API that costs money? Access to more compute
| resources. Probably a lot more than the app itself ever
| uses. It raises the stakes a bit. Still, in monetary
| terms, you're operating a vending machine that the user
| puts money into.
|
| Maybe there could be some kind of protocol and workflow
| to securely buy a dollar of compute time from an AI
| vendor?
|
| If they send some of the money to the app developer's
| account, it's starting to sound like an app store or
| micropayments system.
| panarky wrote:
| 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."
| creesch wrote:
| 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.
| jillesvangurp wrote:
| Do OpenAI and Claude support OAuth? I don't think they do
| (except for simple bearer tokens on API calls).
| simonw wrote:
| They don't - which is a shame, I'd love to be able to
| bounce a user through an OAuth flow and then make API
| calls using their token such that their activity is
| billed to them directly.
| creesch wrote:
| They don't, but they probably should imho. I was just
| talking about best practices in general.
| TeMPOraL wrote:
| OAuth is nice when you're making an interactive in-browser
| SaaS. Sucks for just about any other application, in
| particular anything that may run headless.
|
| Thankfully, OpenAI and the like offer actual APIs I can use
| for software and automation I write. And it is my right,
| both as a user and a developer, to let someone else write
| the software I'll use with my keys. It's up to me to decide
| if I trust that software, and suffer the consequences of a
| mistake. It's like the most basic way of using software,
| and I appreciate when I can use it like that, without
| having anyone insert themselves in the middle to help me
| stay "more secure".
| creesch wrote:
| Mate, the context is that Claude now supports CORS. We
| _are_ talking about in-browser use.
| TeMPOraL wrote:
| Sure, but people are suggesting OpenAI and Anthropic
| should use OAuth _instead of_ API keys. It hardly makes
| sense to provide both for the same functionality.
|
| Also CORS is a PITA. Even for personal use, a browser is
| the most convenient environment to develop some helper
| tools and scripts, and it's also the only environment
| that - until now - could not be used with those APIs. The
| solution here definitely isn't moving from API keys to
| OAuth.
| creesch wrote:
| > Sure, but people are suggesting OpenAI and Anthropic
| should use OAuth instead of API keys.
|
| No, they should offer it. As for the majority of
| webbrowser based use cases, it is a more appropriate
| solution.
| apitman wrote:
| I don't think there's any reason to draw such a hard
| distinction between API keys and OAuth2 tokens. Either
| can be a subset of the other.
|
| In a well-designed OAuth2 flow, the user should be able
| to select fine-grained permissions if they want to. You
| should be offering that same level of control for API
| keys. I don't see why they can't share almost all the
| same infrastructure. The main different is the API calls
| needed for OAuth2, but it's a huge value add.
|
| You can still let people generate keys if they want to,
| but a well-implemented OAuth2 deployment is superior even
| in headless cases. Rather than having to click through
| the dashboard generating and copypasting keys, I can
| enter a short OAuth2 code in the CLI and be off to the
| races. Plus you get all the security benefits of token
| rotation, etc.
| jdenning wrote:
| > 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
| creesch wrote:
| 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.
| jillesvangurp wrote:
| Depends how you do this. If you allow users to configure their
| own key, they basically end up using https to communicate the
| API key directly to the party that issued it. Not much of a
| risk of leakage there and very common with e.g. browser and
| editor extensions written in javascript. In a browser, you need
| the server to be setting CORS headers for this to work.
|
| Provisioning some key to your users so they can then pass it on
| via a client side API call would indeed be more risky. Don't do
| that. But if it's their own key it's all fine.
| axegon_ wrote:
| I see three problems with this:
|
| 1. From a product perspective, this is like going to a
| restaurant to get dinner but having to bring your own kitchen
| utensils, food and cooking your dinner yourself.
|
| 2. Anything running in a browser is inherently insecure -
| what's the guarantee that the site where you're pasting your
| key doesn't have some incredibly stupid security flaw and
| your key gets leaked?
|
| 3. Even if there are no vulnerabilities, you're still pasting
| your code in a random form somewhere on the web. All it takes
| is an ajax call or a websocket and someone, somewhere has
| your key.
| simonw wrote:
| This is true: you do have to trust the site author that you
| are pasting your key into not to steal it.
|
| For my https://tools.simonwillison.net/haiku thing I
| deliberately kept the code as simple as possible: if you
| know basic JavaScript you can view source and confirm that
| your key is not being stolen.
|
| The code is also open source, so you can run a copy on your
| own hosting if you want to.
|
| If you don't trust that then I guess you don't get to use
| my tool to write haikus about your dog!
|
| As for usability: obviously if you want your thing to be
| used by people who don't know how to pay for their own API
| key you should use a different solution.
|
| I mainly want to ship cool demos that are trivial to host
| and that other people can try out without bankrupting me,
| so I'm really excited about this.
| CuriouslyC wrote:
| I might be biased, but I think there's room for a service
| that can make BYOK frictionless. Best of both worlds,
| unless you're a money sucking corporation trying to turn
| a purchase once product into a subscription service
| because late stage capitalism.
| swah wrote:
| Focused gaze peers out, Framed by thoughtful, steady
| eyes, Seeking new insights.
|
| A brushing moment, Simple tools, focused rituals,
| Cleansing, renewing.
|
| Stark white cylinder, Held aloft, its purpose clear,
| Clean and functional.
|
| Analog timepiece, Held in a steady hand's grasp, Marking
| life's rhythm.
| TheCapeGreek wrote:
| Also from the product side, if you're making client side
| requests with users' own keys, doesn't that also mean that
| your LLM prompts are visible to the user if they just
| inspect their network requests?
|
| If your app is largely just a wrapper around a neat prompt,
| it means I can just go and copy the prompt and use it
| myself and save the fees on your app.
|
| Your app has to _really_ be a valuable UX wrap over the
| calls in that case, or catering to a nontechnical audience.
| TeMPOraL wrote:
| > _Your app has to really be a valuable UX wrap over the
| calls in that case, or catering to a nontechnical
| audience._
|
| There is space on the market for such apps, too. Lots of
| space, in fact, as the idea of making software _tools_
| instead of _toys_ seems to be forgotten. "Bicycle for
| the mind" got stolen some years ago, and it's time to get
| it back.
|
| And frankly, an app that's "largely just a wrapper around
| a neat prompt", is something I consider to fall somewhere
| between Fischer-Price copycat toy and a direct scam. It's
| definitely not a tool empowering people, if it can be
| replaced with "paste this into ChatGPT config" (or "paste
| this into this more configurable bring-your-own-key
| frontend for ChatGPT").
| TheCapeGreek wrote:
| >It's definitely not a tool empowering people
|
| I agree. My point is that as a business the only moat
| they'd have is to not do client side requests, in order
| to hide the prompt.
| TeMPOraL wrote:
| Sure, but this approach also has a lot of benefits, and
| there's a market segment that _really appreciates those
| features_ , one that you likely aren't even serving right
| now, and which you could capture nearly for free by just
| adding a form field that stores an API key client-side and
| forwards it to requests to the API vendor. No operations
| costs for you at all.
| danw1979 wrote:
| Your analogy in 1. sounds off to me. It's definitely like
| bringing your own food, but the already well equipped
| kitchen and chefs will prepare it for you.
| afiodorov wrote:
| 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 into various languages.
|
| I opt for the "bring your own keys" model for two main reasons:
|
| 1. Low maintenance: As a professional software developer, I
| already maintain a lot of software, and the last thing I want is
| to maintain my side projects. My goal is to write and distribute
| these apps so they continue working without requiring constant
| attention from me.
|
| 2. Low cost: This model allows me to distribute the apps without
| ads. By having users provide their own keys, I can keep
| operational costs down and avoid the need for monetization
| through advertising.
|
| This approach enables me to create and share useful tools while
| keeping both my maintenance burden and user costs to a minimum.
| jillesvangurp wrote:
| 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.
| KeplerBoy wrote:
| 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.
| InsideOutSanta wrote:
| Yes, we're now at an inflection point where this is starting
| to become possible. gpt-4o mini costs $0.15 per 1 million
| input tokens, and $0.60 per 1 million output. This is cheap
| enough that it can, at least in some cases, be funded by ad
| impressions.
|
| Of course, the implications here are mixed. If you want to
| build an ad-supported tool that actually helps people, that's
| great. But it also means it now makes clear financial sense
| to fill the web with AI-generated garbage with the assumption
| that that ad impressions will pay for it.
| hhh wrote:
| This is also pricing for customers, not what it actually
| costs to run.
| InsideOutSanta wrote:
| Yes, but that's what's relevant, right? If I create a
| service, I don't really care if OpenAI makes a killing or
| is subsidizing my cost with venture capital, what matters
| to me is how much I pay to OpenAI, and how much revenue
| my service generates.
| KeplerBoy wrote:
| It's relevant as far as the providers of said LLM
| inference could always swoop in, undercut you and take
| your business if they feel like it. But they could do
| that anyways, no matter if they do it at a profit or not.
| newswasboring wrote:
| This assumes the service developer adds no value to this
| process. Because otherwise its like saying nVidia can
| swoop in on EA's business.
|
| Edit: s/App/service.
| Vinnl wrote:
| Another implication is that you're dependent on it
| remaining cheap enough. You risk VC money running out and
| them having to jack up prices, or them doing so because
| they managed to capture the whole market.
| brookst wrote:
| 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.
| CuriouslyC wrote:
| 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.
| InsideOutSanta wrote:
| One major difference is that Netflix has a monopoly on
| much of its content, but LLMs are fungible.
|
| 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.
| pzo wrote:
| if new models won't require to have significantly better
| hardware then I think eventually many cases will be run
| on locally. Currently you have macbook pro with even
| 128GB RAM - of course almost nobody has it but those
| hardware will be mainstream common in ~5 years. You
| already can have ollama - you just need to have
| equivalent preinstalled by Microsoft/Apple/Google on
| their all new devices - again most likely this will
| happen in <5 years.
| bboygravity wrote:
| I do the same now for a firefox extension I wrote (automatic
| form-filler that works way way better than anything else out
| there).
|
| So it's also "bring your own keys" but then how do you monetize
| at all?
|
| I personally don't like "bring your own keys" at all from a
| user-friendlyness perspective. It means that you exclude the
| vast majority of potential users, because they don't know what
| that even means. Even "create an account" is more user
| friendly.
| dvdkon wrote:
| "Bring your own keys" can mean a "log in with OpenAI" button.
| Having users navigate through a third party's arcane dev
| portal isn't a good experience, but that third party can make
| it painless for users if they so choose.
| TeMPOraL wrote:
| They don't; OpenAI maintains a separation between "general
| population" ChatGPT Frontend and the LLM API on purpose.
| It's arguably a good purpose.
|
| And the issue should really be inverted: it's not about
| excluding less technically savvy users - it's about
| recognizing a market niche of more sophisticated users,
| that really want that feature, can likely pay more for it,
| give you word-of-mouth marketing for free if you execute
| well. It's a niche so underserved that you don't even have
| to compete with scammers and shovelware all that much.
| afiodorov wrote:
| I absolutely think that OpenAI or Anthropic should provide
| such integration. It's very similar to how Apple Pay
| centralises your subscriptions and makes payments secure
| and simple. Would be nice if AI labs had an equivalent
| portal where each authorized app gets its own key and I can
| cancel any time and control my spending. Finally that might
| enable some kind of monetisation if OpenAI or Anthropic
| give developers a cut, e.g. 10% mark-up that goes to the
| authorized app.
| vineyardmike wrote:
| > Finally that might enable some kind of monetisation if
| OpenAI or Anthropic give developers a cut, e.g. 10% mark-
| up that goes to the authorized app.
|
| I was totally against you until this, but it's an
| interesting idea. Its still early, but seems like OpenAI
| hasn't succeeded any more to be broad consumer product
| past the core Chat experience. Building an AI OAuth
| platform would be an interesting way to be sticky and
| avoid being a commodity. But it'd give developers more
| leverage vs their custom-GPT product, and it'd shift
| charging per-use for an API to "unlimited" per month for
| a single subscription fee.
|
| Generally, a product shouldn't tie themselves to an API
| provider (eg OpenAI) when it could've been an
| implementation detail. If you hide the actual API from
| users, you can swap it for cheaper or better ones as the
| market evolves. If you give up the account access to a
| providers OAuth, and you give up control over that
| implementation, you risk being really stuck to a market
| loser and no direct relationship with users.
|
| Getting paid for it though.... That would be an
| interesting twist. But I'm not sure it'd make sense as
| anything but a bulk discount. The problem is that it
| doesn't make sense to pay a developer to use your paid
| product, unless you get a relationship with the end users
| like Google Search defaults in browsers. But again, it
| doesn't make sense to give OpenAI that relationship if
| you don't have to.
| TeMPOraL wrote:
| > _So it 's also "bring your own keys" but then how do you
| monetize at all?_
|
| TypingMind.com is a "bring you own API key" (obviously, being
| a LLM frontend), that's also successfully monetizing users.
| The secret is that _it 's actually a very good product_;
| until recently, it was far ahead of the official tools (I
| mean, they had plugins for like half a year before OpenAI
| started talking about "GPTs"), so paying for the license
| feels worth it (definitely was, when TypingMind was strictly
| better than ChatGPT Plus subscription).
|
| It's also _not a subscription_ - another reason "bring your
| own keys" apps are interesting, because you likely already
| have a paid subscription with the API vendor; adding another
| one on top of that needs some good justification.
|
| Anyway, "bring your own key" users are a different market
| from general audience, and unlike the latter, it isn't
| already saturated with fly-by-night garbage and scam
| extensions, so you can both charge more for that feature, and
| have smaller costs marketing it.
| pzo wrote:
| I think with some good UX that people suggested in
| different post (such as OAuth etc) it could work even with
| non tech savy users. Similar deals happens very often e.g.
| when you are renting or leasing a car you still have to pay
| yourself for gas. Same with renting long term for
| accomodation you pay utilities yourself.
| vineyardmike wrote:
| > So it's also "bring your own keys" but then how do you
| monetize at all?
|
| Why do you need to monetize? The original comment you replied
| to talked about making something for the world and sharing
| it. They said they didn't want to maintain it, they didn't
| want to be obligated to care for it. You can't make that
| choice if people are paying you (or at least shouldn't...).
|
| I don't understand the BYOx use case for a monetized product.
| If you're BYO api, you're essentially missing the opportunity
| to monetize a spread on API requests. The more a customer
| uses your product (because it's good), the more you'd make.
| That's the best case scenario because it means everyone is
| finding value.
| purple-leafy wrote:
| > Why do you need to monetise?
|
| Some people, myself included, are trying to earn a living
| creating software that helps people in some way. Just like
| any other physical or digital service, it's fair to charge
| for a useful tool
|
| > I don't understand BYOx use case for monetised product
|
| In my case, BYO keys turns out way cheaper for the end
| user. For instance my tool calls an LLM API. If I were to
| host the keys myself, I'd be charged $X for Y calls.
|
| By getting the user to bring their own key, in my case the
| user easily fits into the free tier of the LLM (Gemini in
| my case) so the product costs me $0 to run, and I just
| charge a small service fee for me having created the
| product.
|
| This allows me to keep building useful tools, some free (7
| of 8 projects so far) and some paid (1 of 8)
| CuriouslyC wrote:
| BYOK frees application developers from being inference
| resellers and enables generous free tiers where you convert
| users because they love your app and want advanced
| functionality, not because it has a 7 day free trial then
| they can't use it anymore.
|
| Also, subscriptions are a garbage business model from the
| user perspective, it's literally a dark pattern. They make
| sense for things with recurring costs to provide, but for
| instance, I should be able to buy a copy of Cursor and plug
| my key in and use it forever, and only shell out if I want
| upgrades. It's a subscription service because they're
| trying to bleed their users dry, and I'm sick of it.
| purple-leafy wrote:
| Bring your own keys to minimise costs, you can still charge a
| subscription or one off charge for the base service if it's a
| SaaS extension or similar
| BrandiATMuhkuh wrote:
| What's the name of the extension. I was looking for something
| like this recently
| purple-leafy wrote:
| I do the same, I make chrome extensions and my most recent
| extension uses a byo api key model for calls to an LLM.
|
| Means I can offer the service for free and not worry about
| hosting keys, serving ads, and storing users keys in a db.
| Everything can be done client side.
|
| Good to hear I'm not alone in the endeavour, what software are
| you building?
| afiodorov wrote:
| I made two one-page react apps
|
| https://www.livetranslate.net/
|
| https://www.subsgpt.com/
|
| Second one is more refined but both are functional.
|
| I was pleasantly surprised somebody made a YouTube tutorial
| in Japanese about the latter
| https://www.youtube.com/watch?v=8gAkvZYayEc - feels like
| retro internet where people share things on their personal
| webpages.
|
| Curiously the first one also landed me a contracting
| opportunity for a company that wanted to add live captions to
| their product and we went live with my help.
|
| I also made a decentralized twitter dapp ages ago but AI apps
| definitely have had more interest.
| slowmotiony wrote:
| Do you think it would be possible to attach other language
| SRTs in the context? For example when translating English
| to Polish, the LLM has no idea whether the lines are spoken
| by a man or a woman, so the polish translation will be very
| confusing. However, if I could give the model both English
| and French subtitles, the gendered words from French would
| let the model avoid the confusion and the polish
| translation could be much more accurate. Does that make
| sense?
| shaneos wrote:
| I offer both in https://kidzfun.art. If you're non-technical,
| you can buy packs of 100 images and it uses my key to access
| Dall-E, or you can provide your own key and pay nothing to me.
| The vast majority of users go the simpler way, but it's a nice
| bonus for technical users to just reuse their own key. The
| difference with your approach is that I store an encrypted copy
| server side as I do all the AI generation on the server.
| alex_suzuki wrote:
| I don't understand why you're being downvoted. I think this
| is a reasonable approach. If you want convenience, you pay
| for it - otherwise it's BYOK.
| diggan wrote:
| Not saying it isn't reasonable, but I'm guessing people
| might downvote because of storing secrets server-side
| rather than passing them on from the frontend and saving
| them there instead. People get worried as soon as secrets
| are stored anywhere :)
| samstave wrote:
| I think the biggest issue is that the _vast_ majority of
| all Internet Users, including 'techies' really dont
| understand Secretes, Security, risks, non-risks etc...
|
| I think that What HN (the site) is actually lacking is
| any kind of formal education [section] on the state of
| tech. Esp. given how much of SV tech zeitgeist flows
| through the frontpage of HN and the folks in its orbit -
| HN is missing out on a service that _could_ look like a
| "tech News podcast" where Khan Acadamy meets
| OpenCourseware CS level snippets...
|
| As an example - there have been a flurry of tools and
| launches and shows to HN recently that if there was a 15
| minute video explaining the TechLego - and you could
| watch all these announcements and little educational doo-
| dads for the various tech componentry and tooling being
| shown here - a scrappy motivated modern version of
| 20-year-old [Every Grey HNer] could build wonders with...
|
| We need to give people a solid grasp of all these
| concepts and issues, best practice, and the WHY we think
| the way we think about things such as secrets, auth,
| security. (the boring layer in OSI for most)
| Jarwain wrote:
| Yesyesyesyesyes I didn't realize how badly this is needed
| and how much I would like to work on this until you
| brought it up.
|
| It's wild how much useful information flows through the
| HN Zeitgeist! I singlehandedly attribute my career
| success/position to keeping up with it all
| 1234letshaveatw wrote:
| I think it was probably the gratuitous inclusion of the url
| waprin wrote:
| It wasn't gratuitous at all and the "self-promotion
| police" are an insufferable plague on this website.
| nfriedly wrote:
| I put together https://nfriedly.github.io/contributor-
| locations/ a while back, which has the same idea except that
| the access token is optional. GitHub's API provides a small
| number of request without one, but adding an API key will
| enable it to do more.
| huijzer wrote:
| Yes I couldn't agree more. I wish there was more support for
| this; like for example a system where users can be sure that
| the key cannot be stolen by the app.
| perpil wrote:
| Another benefit of BYOK is it simplifies the implementation.
| You don't need to spend as much time protecting against the
| attack vector where they rack up a big bill against your key.
| pickledish wrote:
| Yeah, I also love this style of web app, for the same reasons
| you note!
|
| 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.
| apitman wrote:
| The UX could be so much better and more secure. This type of
| use case is a perfect fit for OAuth2.
|
| Current UX:
|
| 1. User hits your app
|
| 2. You tell them to go to Anthropic and generate an API key.
| You'll probably need to give them instructions on how to do so,
| which will become outdated over time as Anthropic makes changes
| to their website.
|
| 3. User goes to Anthropic and generates an API key
|
| 4. User manually navigates back to your app and pastes the key
|
| OAuth2 UX:
|
| 1. You redirect the user to Anthropic
|
| 2. The user approves your app getting access
|
| 3. Anthropic redirects the user back to you and your app starts
| working.
|
| For the life of me I don't understand why orgs don't implement
| OAuth2 for basically everything. Yes it is more complicated on
| the developer side, but that's for good security reasons. And
| it isn't _that_ bad, and well worth the moderate time
| investment.
| spyspy wrote:
| Devs here often don't even really understand JWT tokens as
| evidenced by the hundreds-of-comments deep arguments I've
| witnessed over them.
| apitman wrote:
| JWTs are orthogonal to OAuth2. Tokens in OAuth2 are opaque
| to the client applications. JWTs are one way to do it,
| though with significant tradeoffs.
| tsimionescu wrote:
| You have to remember that dev time is always at a premium.
| Even if it takes one week to build OAuth2 support, that's one
| week delay on other features. It's always a matter of
| priorities.
| jameshart wrote:
| Sure but the alternative we are talking about here is
| encouraging developers to paste their API keys into random
| web pages.
|
| I don't think we should accept the argument that since
| implementing a respectable authorization scheme might take
| a bit of effort, it's okay for sites to ask users to just
| hand over their password.
| serjester wrote:
| While this is nice, I don't think the dangers are discussed
| enough. A user has no guarantee their key isn't just being sent
| to some malicious third party. Normalizing this seems dangerous
| because it only takes a couple bad actors.
|
| Sure you could try to get people to issue / delete keys every
| time they use an online app but it seems unlikely most users
| will do that.
| 6510 wrote:
| The browser doesn't need to facilitate this.
|
| They could generate an application specific key. Could do
| that every time one uses the application by forwarding though
| the website issuing the key and back.
|
| I want government id to work like that. You authorize the
| website on the .gov then the website only gets a key, no
| further information. The only thing to knows about the key is
| that each citizen gets to generate one key for each
| [registered] domain.
| pzo wrote:
| probably not a good idea for your government to know their
| each citizen what kind of websites uses. However there are
| similar idea currently in some crypto projects that trying
| to solve it to make it distributed, so that if you e.g.
| like gambling the government won't know about it but
| website that provide gambling services can still check that
| you are from non banned countries and adult without any
| more detailed KYC
| 6510 wrote:
| > A live transcription and translation app that uses microphone
| input. This is useful for watching proprietary content and
| facilitating communication.
|
| It would be funny to transcribe someones speech, improve the
| grammar and play it back in their own voice.
| bilater wrote:
| I love this pattern as well, but as some comments have pointed
| out, there is a pitfall of security risk (you don't know where
| your API key is going). I think it would be really cool if more
| services let you cap API key usage, so it's almost like a
| virtual credit card number. I could then put in API keys to
| sites without worrying and knowing that at most, I can lose,
| say, $10 or something.
| simonw wrote:
| This is absolutely the thing I most want: it should be
| trivially easy to create a dedicated API key with e.g. a $5
| maximum spend that I can share with a "bring your own key"
| tool.
|
| Being able to issue those via an OAuth flow as opposed to
| copy-and-paste would be nice, but the fundamental thing I
| want is per-app spending limits.
| tabgram wrote:
| Obviously you aware, but let me still say it: openrouter is
| for me a trivially easy way to create dedicated keys with
| max limit https://openrouter.ai/credits or am I missing
| something?
| bilater wrote:
| oh this is interesting thanks for linking gonna check em
| out
| jameshart wrote:
| This is pretty much exactly what an oauth2 flow is. You
| generate a single-use-specific token and constrain it with
| the limited permissions you choose. If a site wants to offer
| an oauth token flow where users can put a time or credit
| usage limit on the token they absolutely can do so.
| ianbicking wrote:
| OpenRouter.ai does this pretty well. It has a pretty reasonable
| flow. It supports enough free models that you can do at least
| _something_ without a person having to pay anything (even if
| quality is a bit iffy). They have user-set spending limits, and
| each key is bound to the service. Their privacy policies seem
| decent.
|
| The other option is Gemini, which has enough free credits to
| really be free for any small app. Unfortunately you can't use
| that through OpenRouter, you need your own developer account to
| be able to take advantage of Gemini's free offering.
| mattrighetti wrote:
| I've always thought this would be a cool thing to offer, one
| thing that I've asked myself though is why should I trust you
| to use my key? Who guarantees that you're not going to abuse it
| or use it in an inefficient way?
|
| I'm unfamiliar with how these keys are priced but I guess they
| still use number of tokens that you input? What happens if one
| day your software has a bug that sends 1k tokens multiple times
| and I get charged for it because I've used my key?
|
| Note that this is not a complaint and I would definitely love a
| "bring my key to use for free" tier, just a legitimate question
| that I asked myself from time to time.
|
| On the other hand, I trust you very much in doing your best
| work to avoid any bug like the one I've presented above and
| squeeze every little penny out of your key to maximise
| earnings.
|
| Finally, how do you make people entrust you with their keys?
| saagarjha wrote:
| 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 far as I can tell the world
| has not ended. Why is the browser any different?
| barrkel wrote:
| 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 web interface.
| saagarjha wrote:
| Ok but like why would you pass cookies along
| easton wrote:
| Because in the 90s/early 2000s someone thought it was a
| good idea to send cookies for the given site along with all
| requests (probably a good move, since it would stink to
| have to tell the browser somehow to explicitly send a
| cookie for every request, even ones initiated outside of
| JS).
|
| You could say that sites instead must prescribe a "send-
| cookies-when-requests-are-from-this-site" header, but
| that's kind of the same thing as CORS.
| dceddia wrote:
| Just to add to the sibling comment - you don't get a choice
| to pass cookies or not, the browser just includes them
| automatically.
| Thorrez wrote:
| That's not really correct.
|
| 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.
| tommica wrote:
| 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.
| EE84M3i wrote:
| 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.
| Thorrez wrote:
| You're correct.
| Thorrez wrote:
| That attack you mention is a CSRF attack. CORS doesn't really
| protect against that. That exact attack you mention is
| possible if foo.test doesn't implement CSRF protection. CORS
| doesn't automatically provide CSRF protection.
| eejjjj82 wrote:
| 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 CORS, then someone might be able to create a landing
| page, which in the background triggers a `fetch` or `ajax`
| request to your bank's transaction endpoint. For 99.999% of
| people this wouldn't be effective because they are probably not
| a customer of this bank and are not logged in at the time of
| the request. But for some very tiny fraction of users, the
| browser would be tricked into populating the Cookie header from
| a previously created session in a different tab and would send
| this request.
|
| The Origin header in the CORS preflight is a signal from the
| server to the browser that 'yes, this request is safe for you
| to construct'. This way the browser doesn't let the malicious
| web page "trick it" in the first place to send the bad request.
|
| https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
| notpushkin wrote:
| > 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.)
| diggan wrote:
| > I think this is the problem here? Just send the request
| without cookies if CORS doesn't allow it.
|
| Yup, very obviously a problem and it's why we got CORS :)
| But just because it's a problem, doesn't mean we can remove
| it from all browsers and call it a day, it'll break huge
| parts of the internet.
|
| So in true internet engineering fashion we do what we
| always do, pile yet another layer on top of the stack to
| fix some issues from the previous layer (and add some more
| complications for the next (future) layer).
| Thorrez wrote:
| >Just send the request without cookies if CORS doesn't
| allow it.
|
| 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.
| notpushkin wrote:
| Simple requests could still work without preflight. What
| I suggest is, complex requests (e.g. fetch()) that don't
| require cookies (e. g. using credentials: "omit" [1])
| shouldn't preflight either.
|
| [1]: https://developer.mozilla.org/en-
| US/docs/Web/API/Fetch_API/U...
|
| By the way, the default fetch `credentials` value ("same-
| origin") doesn't send cookies to third-party websites
| either. Why CORS still applies here is a mystery to me.
|
| Edit: some requests can work without preflight, but there
| are some absurd limitations (GET/POST only, and request
| body can't be a JSON): https://developer.mozilla.org/en-
| US/docs/Web/HTTP/CORS#simpl...
|
| And to clarify, my point here is: I think CORS is a
| security theater. The only part that really helps is
| Access-Control-Allow-Credentials (and that's only because
| third-party cookies are still a thing).
| Thorrez wrote:
| >So without CORS, then someone might be able to create a
| landing page, which in the background triggers a `fetch` or
| `ajax` request to your bank's transaction endpoint. For
| 99.999% of people this wouldn't be effective because they are
| probably not a customer of this bank and are not logged in at
| the time of the request. But for some very tiny fraction of
| users, the browser would be tricked into populating the
| Cookie header from a previously created session in a
| different tab and would send this request.
|
| Are you talking about an attack where the attacker tries to
| control the victim's bank account by initiating a transfer?
| That's a CSRF attack. CORS and the same origin policy don't
| prevent that attack by default. The browser will still send
| the request the request populating the cookie. The same
| origin policy will prevent the evil site from reading the
| response, not from making the request. To protect against
| this attack the bank needs to implement CSRF protection (e.g.
| checking the Origin header).
| treve wrote:
| This is mostly correct, but one thing that's worth pointing
| out is that CORS doesn't protect anything, but it 'loosens'
| the protection that the browser has by default. The S in CORS
| stands for sharing, not security.
| BrandoElFollito wrote:
| There is a good explanation here:
| https://stackoverflow.com/a/29167709/903011
| breck wrote:
| A soldier gets back from the front and gets a job in IT
| moderating internet comments.
|
| A few months later he calls his CO and asks to be sent back to
| the front.
|
| The CO asks "why would you want to do that?"
|
| He replies, "there's a lot less fear over there."
| TeMPOraL wrote:
| You get downvoted, but that's pretty much spot on. I've
| wasted many days of my life trying to navigate around
| security in the browser and HTTPS everything, mostly
| unsuccessfully, and I only see increasingly insane lock-downs
| appearing as time goes on.
|
| It feels like that the only mode of use of a computer that's
| allowed by security-minded folks is being a company selling
| shit on-line, or a customer of one. Try anything like making
| a simple browser UI to use some internal API, even on
| localhost, and you quickly end up running your own
| certificate authority, CORS proxy and having to buy a domain.
|
| I mean, the very concept that the only right way to do HTTPS
| for _internal_ tools is to have a _public_ certificate on a
| _public_ Internet domain, thus having to pay third parties
| _and_ leaking information via certificate transparency logs,
| is _insane_ when you 're just doing your own stuff on your
| own LAN, and need to use a browser (entirely locally) or
| touch anything on the Internet.
| Thorrez wrote:
| >The fact that a website can't make a request to another
| website unless that domain like it
|
| That's wrong. Any website can make a request to any other
| website. The same origin policy will prevent READING the
| response, not making the request. This is to prevent evil.com
| from making a request to email.com and reading all your emails.
|
| CORS was invented as a way to partially disable the same origin
| policy for websites that want to allow their responses to be
| read by other sites. Note that CORS is a way to disable
| blocking. Most people think CORS blocks things, but that's a
| misconception. The same origin policy blocks things, and CORS
| can partially disable it. CORS = Cross Origin Resource Sharing.
| The Sharing refers to how it disables blocking.
|
| (This is a slight simplification, because I'm ignoring complex
| CORS.)
| kevincox wrote:
| 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.
|
| 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 <form> 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)
| Thorrez wrote:
| 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 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).
| kevincox wrote:
| It is protected by if the request uses JSON or similar. The
| point is still that this is the target problem that it is
| trying to address.
|
| > 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.
| simonw wrote:
| Lots of replies here talking about cookies and CSRF, but a
| bigger concern in my opinion is intranets.
|
| If you work somewhere with a network access based intranet you
| might have eg a private wiki at https://wiki.internal-corp/
|
| Without CORS, anyone from your company visiting a malicious
| external website could have data stolen from that "private"
| intranet site using fetch()
| apitman wrote:
| CORS exists to keep us humble. The first time you think you
| understand it, your journey has only just begun.
| thiht wrote:
| There are always some mild arguments that CORS is better that
| nothing, but honestly your intuition is right, CORS is absolute
| nonsense.
| londons_explore wrote:
| > if you embed your API key in your client code, anyone with
| access to that site can steal your API key and use it to make
| requests on your behalf.
|
| Great. Anyone know a search engine to find these 'free usage'
| keys?
| notpushkin wrote:
| I think https://publicwww.com/ could do the trick?
| _pdp_ wrote:
| I don't see this being a problem in situations where a customer /
| user can bring their own keys. The actions happens on the client-
| side and as long as the device or the website are not compromised
| it is all good.
|
| However, this is definitely increasing the attack surface where a
| developer may decide for whatever reason to use production keys
| client-side without proxying the requests as they would normally
| do. I can see this being done out of convenience and performance
| reasons not taking into account security considerations.
| vdfs wrote:
| Also, this was always possible using a simple proxy that
| directly send requests to their API
| riquito wrote:
| > as long as the device or the website are not compromised it
| is all good
|
| But that is THE problem. You are making yourself a huge target.
| The more users you have the most likely someone will attempt to
| hack you to use all those keys. The "client side" point is moot
| because the code that uses those keys comes from the server,
| once that's compromised all hell is loose.
| ikekkdcjkfke wrote:
| Notnpossible to generate a limitee key in 2024?
| me551ah wrote:
| For the use case of user bringing their own keys, oAuth is a much
| better solution. Some developer is going to hardcode their actual
| keys on the frontend and find out the hard way. OAuth is a more
| dumb-proof solution
| judevector wrote:
| Great to see CORS support added! This will make integrating
| Claude's API into client-side apps much smoother.
| wonderfuly wrote:
| I'm really glad to see this. Last week, when I upgraded the
| Anthropic TypeScript SDK from 0.23.0 to 0.26.0, my browser
| extension (chathub.gg) broke because they completely banned the
| use of this SDK in browsers!
| ramonverse wrote:
| 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
| samstave wrote:
| >> _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.
| meiraleal wrote:
| funny but this proves that claude is now good for code?
| farco12 wrote:
| I can say from using the chat interface, Claude 3.5 is a
| top tier model for coding tasks. I used ChatGPT Pro
| previously, but I really find the experience of using
| Claude much more enjoyable overall.
| GaggiX wrote:
| Claude 3.5 Sonnet is best model at coding.
| samstave wrote:
| Ive been coding with claude pro an app for the past month
| and While claude is amazing - it loses context pretty darn
| quick - and its ultra frustrating - look at my post history
| where I have written about it in some detail.
|
| When I have the energy I should write up a detailed
| response - but I feel that I have experienced a lot of
| nefarious with Claude and how it operates.
| e12e wrote:
| > It's fine for internal tools exposed to trusted users,
|
| No, not really?
|
| > or you can implement a "bring your own API key" pattern where
| users supply their own key to use with your client-side app.
|
| This is a valid use-case, even if it breeds unsafe patterns (just
| allow random site/code on the internet impersonate you and spend
| money on your behalf).
|
| But it's not really _worse_ than how 3rd party integrations
| generally do that anyway.
| rvnx wrote:
| They could do a system where you can create one API key with a
| budget for a site, and that's it, that would be enough, but
| until they have that budget system, it's not really a good
| approach
| simonw wrote:
| Why isn't it OK for internal tools with trusted users?
|
| It's functionally the same as saying "hey coworker, here's an
| API key you can use, it's billed to the company".
| e12e wrote:
| I suppose - my general reaction is that use of such magic api
| keys are difficult to audit, revoke etc - and there's the
| constant risk they will leak.
| ripped_britches wrote:
| I'm not sure why they don't support JWTs so we can mint limited
| user-specific keys instead of exposing the master key
|
| Supabase is a great example of how to use claims to give safe
| client side access
| jasondigitized wrote:
| This would unlock so many interesting use cases and protect the
| developer from getting a huge bill. Let me basically resell
| your API and abstract away any complexity to the end user. I'll
| charge use some % markup on top of what I pay Claude.
| MeetingsBrowser wrote:
| How are people using the Claude API as individuals?
|
| Officially, individuals are not allowed to use the API.
|
| https://support.anthropic.com/en/articles/8987200-can-i-use-...
| buildbot wrote:
| Everyone's their own Sole Proprietorship?
| LeoPanthera wrote:
| Huh! That's a surprise. Especially as OpenAI has no problem
| with it.
| MitchellCash wrote:
| I'm going to out myself, but you just do it anyway...
| simonw wrote:
| I asked someone at Anthropic about it and it turned out to be a
| stale page, it's updated now and says:
|
| "Yes, individuals and hobbyists are welcome to use the
| Anthropic API."
| orenlindsey wrote:
| I mean, you could have just made a quick proxy with a little
| express server to get around this anyways. But I shouldn't be
| complaining, it's good that they did this.
|
| Edit: of course, I just realized that people may not want their
| api key being sent to your server.
| allanren wrote:
| Claude is growing strong with these new features
| hagope wrote:
| Anthropic and all the AI vendors need to implement "Login with
| ___" allowing users to trust sites to use their own AI resources,
| similar to how Dropbox allows 3rd party access to the User's
| storage. Most users don't want to bother with generating and
| loading API keys, nor can they manage it safely.
| pzo wrote:
| Agree. I wish OpenRouter did something like that so that we can
| have only 1 vendor and app can decide themself what AI API want
| to use. Then user don't need to have digital wallets topped up
| with money for 3+ different AI vendors. Basically you want to
| have something similar to crypto wallet that you can easily
| fill with money and authorize apps.
___________________________________________________________________
(page generated 2024-08-23 23:02 UTC)