Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Privacy Pass Authentication for Kagi Search

blog.kagi.com

Post reply on HN
Print view View original

341–350 of 359 posts

Re: Privacy Pass Authentication for Kagi Search

#341

Post by lunr »

perdomon wrote: post #330
jabroni_salad wrote: post #309

Earlier quoted context omitted.

Here is a case for 'not google': https://i.imgur.com/PQNm1Yc.png I want a search engine to return useful results. Right now, google has been captured by revenue generating results. It wouldn't be so bad if useful results were making money, but that doesn't seem to be the case.

Yeah, those results are ass. Do you happen to have the Kagi equivalent of the search? I’m curious to see how they compare.

https://i.imgur.com/PWVGzCi.png

Image is of the first two pages of results side by side if a "page" is a "fold" in my browser window.

Re: Privacy Pass Authentication for Kagi Search

#342

Post by stephen_cagle »

mayneack wrote: post #126
perdomon wrote: post #119

Can someone make a case for Kagi? I'm using Google + Claude for all my websearch needs. I don't feel like there's a gap there, but maybe that's because I've never experienced anything better and can't imagine it? I do value privacy, but I wouldn't pay extra for more private search results. I might pay extra for __better__ search results, but that's hard to measure. Just curious if anyone has had a legitimately great…

For me the killer kagi feature is that I can manually up and down weight domains in results. I can "pin" and always get wikipedia results or "block" and never get pintrest or raise or lower as needed. Brave search has a similar feature, but they only seem to support "block" not "lower", which is what I use a lot more often. https://kagi.com/stats?stat=leaderboard

Ditto, for me is that I can take the damn geekforgeeks and facebook to "lower". Raise the python official docs since that is most of the time what I want.

Re: Privacy Pass Authentication for Kagi Search

#343

Post by Confiks »

ignoramous wrote: post #284
aryonoco wrote: post #137

Earlier quoted context omitted.

And that's why Kagi has simultaneously rolled out their service availability on tor: http://kagi2pv5bdcxxqla5itjzje2cgdccuwept5ub6patvmvn3qgmgjd6... Tor has its flaws and criticisms, but it's really not on Kagi to fix them. With the combination of tor and their privacy pass, Kagi has gone further in allowing their paid users access to their services than anyone else. Disclaimer: Not associated with Kagi in anyway oth…

Tor has nothing to do with what GP said, which is, the flexibility offered by Kagi (to turn privacy pass on / off) is actually self defeating. If (even technical) users walk away thinking "why don't other platforms offer this", then that tells you all about the foot-gun that this flexibility brings. (Privacy Pass in fact doesn't make sense outside of an anonymizing transport, which makes the current announcement an e…

> Privacy Pass in fact doesn't make sense outside of an anonymizing transport

This kind of thinking is pervasive in the discussion of privacy enhancing technologies. It might not make sense against the most sophisticated attacker, but it lays the groundwork of a complex system that will be able to do so.

Allowing more users will provide herd privacy at the token generation phase. Searches being decoupled from user account primary key offers privacy in all kinds of scenario's, comparable with a browser private tab.

Re: Privacy Pass Authentication for Kagi Search

#344

Post by akimbostrawman »

kobieps wrote: post #336
akimbostrawman wrote: post #300

Earlier quoted context omitted.

Lightning is a meme. Imagine needing a sperate glued on system to be somewhat tolerable at the thing it was created for.

Calling it an experiment would be more accurate than declaring it has already failed.

I don't care for semantics. It's just one of numerous issues making btc unfit as a currency.

Re: Privacy Pass Authentication for Kagi Search

#345

Post by raphaelrobert »

abound wrote: post #322
alphabetter wrote: post #285

Earlier quoted context omitted.

Honestly, I think what TFA calls "Kagi’s implementation of Privacy Pass" is the integration of the feature into their server and clients, not the RFC (which they acknowledge), or the protocol implementation.

[I work at Kagi] Indeed, this is the intended interpretation of "Kagi's implementation of Privacy Pass" - we're talking about building out the server infrastructure, the UX, the browser extensions, the mobile applications, the Orion browser integration, the support and documentation, the Tor service, etc. The cryptography is obviously an extremely important piece, but it is far from the only piece. As other commenter…

Understood, and thanks for updating the blog post. The discussion in the comments was interesting, and I'd like to clarify a few points. From my side, there never were any doubts about licensing compliance. I picked MIT precisely so that folks can use the implementation without further obligations, I wanted the implementation to be as useful as possible. What startled me was the combination of a for-profit company writing a blog post about a new feature (that will likely further increase profit in the future), using my implementation as the core of the feature (and therefore likely save a bunch of money) and not giving any credit to either the IETF batched tokens draft or the implementation. Anyway, the blog post has been amended now – thanks for that. Case closed.

PS: If you want to go above and beyond, you can spell my last name right in the blog post – it's Robert, not Roberts.

Re: Privacy Pass Authentication for Kagi Search

#346

Post by freediver »

raphaelrobert wrote: post #345
abound wrote: post #322

Earlier quoted context omitted.

[I work at Kagi] Indeed, this is the intended interpretation of "Kagi's implementation of Privacy Pass" - we're talking about building out the server infrastructure, the UX, the browser extensions, the mobile applications, the Orion browser integration, the support and documentation, the Tor service, etc. The cryptography is obviously an extremely important piece, but it is far from the only piece. As other commenter…

Understood, and thanks for updating the blog post. The discussion in the comments was interesting, and I'd like to clarify a few points. From my side, there never were any doubts about licensing compliance. I picked MIT precisely so that folks can use the implementation without further obligations, I wanted the implementation to be as useful as possible. What startled me was the combination of a for-profit company wr…

> PS: If you want to go above and beyond, you can spell my last name right in the blog post – it's Robert, not Roberts.

That was on me, fixed!

Re: Privacy Pass Authentication for Kagi Search

#347

Post by catalypso »

codethief wrote: post #240
ghayes wrote: post #234

Earlier quoted context omitted.

Privacy Pass docs [0] cover this, but it is mostly referenced deeper in the paper. I believe the idea is that the tokens returned by the server are "unlinkable" to the (modified) tokens passed back by the client. So the server knows it passed back tokens A, B and C to some users, and later receives tokens X, Y and Z. It knows that X, Y and Z are valid, but not their correspondance to the tokens it issued. It uses ell…

After reading your comment I still didn't quite understand how the server couldn't just simply log the tokens A, B, C issued to user X. So I had a look at the website you linked: IIUC the key is that the tokens are actually generated by the user and the server never sees them (unblinded) before their first usage: > When an internet challenge is solved correctly by a user, Privacy Pass will generate a number of random…

> the tokens are actually generated by the user and the server never sees them (unblinded) before their first usage

Here is how I see it:

  1. The user generates a token/nonce => T

  2. The user blinds the token with secret blinding factor b => Blinded token TB = T*b

  3. The user sends the blinded token for signing. The server signs it and returns it to the user => Signed blinded token TBS = Sign(TB)

  4. The user unblinds the token (this does not break the signature) => Signed Unblinded token TS = TBS/b

  5. The user sends TS for its search query.
The server signed TB, then received TS. Even if it logged that TB = user, it cannot link TS to TB, because it does not know the blinding factor b. Thus, it cannot link the search query with TS to the user.

Re: Privacy Pass Authentication for Kagi Search

#348

Post by andelink »

prophesi wrote: post #313
joshuaturner wrote: post #202

Earlier quoted context omitted.

I remember the announcement for Orion but I haven't followed closely at all - any support for container proxies like in Firefox? Can't lose that feature

If you mean Firefox containers[0], the closest you'll get is Profiles[1] since Orion is based on WebKit. Its location in settings is different from the Safari docs, and that's the only difference in Orion's implementation as far as I can tell. You can't open a tab in a certain profile, instead each profile opens in its own window, which is a lot more cumbersome than Firefox containers. Arc, another Webkit-based brows…

Arc is based on Chromium not WebKit.

Re: Privacy Pass Authentication for Kagi Search

#349

Post by prophesi »

andelink wrote: post #348
prophesi wrote: post #313

Earlier quoted context omitted.

If you mean Firefox containers[0], the closest you'll get is Profiles[1] since Orion is based on WebKit. Its location in settings is different from the Safari docs, and that's the only difference in Orion's implementation as far as I can tell. You can't open a tab in a certain profile, instead each profile opens in its own window, which is a lot more cumbersome than Firefox containers. Arc, another Webkit-based brows…

Arc is based on Chromium not WebKit.

My bad, it's based on a fork of WebKit.
Post reply on HN