Kagi is still partnered with Yandex[0], but they removed a list of sources they used. When asked if the list could be restored, Vladimir Prelovac replied "Is there any particular reason you are asking for this? More context will help us better understand the need."[1]
The only people morally responsible for committing atrocities are those who commit them. Shall we hold the farmers who grow food that Russian leaders consume morally culpable for those leaders’ actions? I’m dead serious. You cannot in good faith actually argue that everyone is indirectly morally culpable for any action that is “enabled” by something they do.
Like freedom of expression, neutral objective search is too important to poison with identity politics and virtue signaling.
Or they just don’t want to deal with the bad faith actors with overly amplified internet voices cherrypicking Kagi as the next innocent product to torpedo because they aren’t virtuous enough. You can’t win against crazy people in a mob.
It's not hypocritical to set the bar at a given place, like an ongoing war of territorial expansion and child abduction run by an autocrat that won't be replaced until his death. One with near complete popular support.
Are you talking about the United States? Like, yes, the Russian regime is awful, but how are you looking around at the the world and not applying the same standards to the US?
Can we just stop at the "yes the Russian regime (and oligarchy and substantial popular support) is awful" part? Because that is really all you need to reasonably boycott Yandex. Is it good to be ideologically consistent? Absolutely! Is it required? Not if you're aiming to reduce the amount of evil in the world.
Redirecting discussion about Russia's shittiness to a criticism of the US is a dumb propaganda tactic that a lot of people here are engaging in. And many others are swallowing. I'm happy to talk about the US or NATO or Israel, just not with the partisans who for some reason assume I fully support any of the above.
No, you can’t without being a hypocrite. It sure is convenient to take a moral stance when it has no real impact on your life and just throws others under the bus. But try applying your morality consistently and you will find it’s effectively impossible. So ultimately you’re just picking issues to complain about based on the current political climate, not actually taking a fundamental principled moral stance on an issue—you’re not making the world a better place.
Add to that the value that good search provides humanity, even Ukrainians and Russians against the war, and it’s not even obvious that boycotting a company that does a minuscule amount of business with a Russian company is doing more good than harm. So you’re arguably actually perpetuating harm more than reducing it.
It contributes to the Russian economy and oligarchy, both are key drivers of the invasion. People like you love to say Ukraine won't win the war as if the end of the war is going to be on the battlefield.
The point is, if you boycott Yandex because of Russia, then in order to be morally consistent, you should also boycott Google and Bing. At that point, what search engines do you have left?
I was pretty explicit about saying that moral consistency is better but there is a valid position that is inconsistent but still aims to reduce human suffering.
And that handwaves the equivalence of the US and Russia as well as their relationships with corporations.
You are literally living through a fascist takeover of the United States, and said corporations are happily participating as long as they get a share of the pie.
I know that HN is an American website, and it is difficult for people in America to view the US negatively, but outside the US you will find a lot of people that don't really see much difference between Russia attacking Ukraine, and the US bombing the living fuck out of Afghanistan and Iraq, or the complete support that US (and its corporations!) have been providing to Israel in its genocide in Gaza.
It is okay to want to boycott one and not the other, but one cannot then turn around and scold others for not engaging in that boycott on a moral basis.
> is difficult for people in America to view the US negatively
You really gotta see past stereotypes and reductive takes. The absence of criticism of the US in a discussion about two different countries doesn't implicitly mean "Amurica o7".
> you will find a lot of people that don't really see much difference between Russia attacking Ukraine, and the US bombing the living fuck out of Afghanistan and Iraq...
Those people need to look a little deeper than "these are/were both voluntary wars". If someone is unwilling to engage beyond the shallowest possible academic level, it's not worth the effort.
> one cannot then turn around and scold others for not engaging in that boycott on a moral basis.
My intent was to defend the people engaging in the boycott. I don't recall scolding people for not participating but perhaps that was implied somewhere. Certainly I have not shied away from condemning Kagi/Yandex/Russia but it's not the same as saying "you should too". In fact, one of my main points has been that ideological inconsistency is okay of not great.
There have been times when I loved and times when I absolutely hated Yandex. That being said, I am not going to disown everything associated with Russia. Also they are distancing themselves. It's far from perfect but the more independent indexes the better even if you disagree with those particular indexes.
I wonder how much of the advantages from kagi are due to their yandex backend.
For example, I recently tried to search for a text string from ao3 and google, bing, brave, qwant, ... all return no results, while yandex and by extension kagi found it in the first search result.
I think they are referring to this changelog item:
> Our image search became even better with the inclusion of two more sources: Yandex Image Search (widely recognized as one of best image search services) and Openverse (vast collection of openly licensed images). Kagi is doing the hard work so that you don't have to.
You need some U.K.-specific knowledge, which is that CEEFAX went off air in 2012. If you see a screenshot of genuine CEEFAX (not one of the several modern things that pretend to be teletext) it will be from before 2012, possibly from long before as it was a service embedded in analogue PAL broadcasts that was capturable as page text (with all of the control characters) by BBC Micro users (who had bought the Acorn "Teletext Adapter") as long ago as the early 1980s.
Totally normal for PHP software, and that's a primary reason of why PHP apps have such a bad security reputation. Note:
- The application code itself and system configs are modifiable by the web handler itself. This is needed to allow web-based "setup.php" to work, but also means that any sort of RCE is immediately "fatal" - no need for kernel/sandbox exploit, if you can get PHP to execute remote code you can backdoor existing files as much as you want.
- The "logs", "tmp", "config" etc.. directories are co-located with code directory. This allows easy install via unzip, but means that the code directory must be kept accessible while operation. It's not easy to lock it down if you want to prevent possible backdoors from previous options.
Those install methods have been embraced by PHP community and make exploits so much easier. That's why you always hear about "php backdoors" and not about "go backdoors" or "django backdoors" - with other languages, you version-upgrade (possibly automatically) and things work and exploits disappear. With PHP, you version upgrade .. by extracting the new zip over the same location. If you were hacked, this basically keeps all the hacks in place.
Kinda weird to see this from some self-claimed "security professionals" though, I thought they'd know better :)
I kinda understood I was missing "something" when I commented but I haven't used any PHP for over a decade and honestly it looked very well you said the rest... Thanks for the clarification. Very unfamiliar with modern PHP.
What did you think you had missed? I'm not understanding
> but I haven't used any PHP for over a decade
This isn't modern PHP, this is the traditional installation method that I used also a decade ago. The only thing that could be older about it is to have a web-cron instead of a proper system cron line. Modern PHP dependency installation is to basically curl|bash something on the host system (composer iirc) rather than load in the code under the web server's user and running the install from there, as this repository suggests. Not that the parent comment is wrong about the risks that still exist in being able to dynamically pull third-party code this way and hosting secrets under the webroot
Correct, this isn't modern PHP. We aimed to keep overall code dependencies around ~10, and with modern frameworks this number would be multiplied heavily.
The instructions aren't all that unusual for PHP software, especially those that target shared hosting, but are unusual compared to most other software.
> Download a zip file and extract it "where you want it installed on your web server"
The requirements mention apache with mod_rewrite enabled, so "your web server" is a bit vague. It wouldn't work with e.g. `python -m http.server 8000`. Also, most software comes bundled with its own web server nowadays but I know this is just how PHP is.
Huh, so anyone who can access my web server can access the installation script? Why isn't this a command line script, a config file, or at least something bound to localhost?
> After the successful installation, delete the install/ directory and its contents.
Couldn't this have been automated? Am I subject to security issues if I don't do this? I don't have to manually delete anything when installing any other software.
I'll side with you here. This gives attackers a huge window of time in which to compromise your service and configure it the way they want it configured.
Wut? That can't have been a chance visit from a crawler unless maybe you linked it within those 3 seconds of creating the subdomain and the crawler visited the page it was linked from in that same second, or you/someone linked to it (in preparation) before it existed and bots were already constantly trying
Where did you "create" this subdomain, do you mean the vhost in the webserver configuration or making an A record in the DNS configuration at e.g. your registrar? Because it seems to me that either:
- Your computer's DNS queries are being logged and any unknown domains immediately get crawled, be it with malicious or white-hat intent, or
- Whatever method you created that subdomain by is being logged (by whoever owns it, or by them e.g. having AXFR enabled accidentally for example) and immediately got crawled with whichever intent
I can re-do the test on my side if you want to figure out what part of your process is leaky, assuming you can reproduce it in the first place (to within a few standard deviations of those three seconds at least; like if the next time is 40 seconds I'll call it 'same' but if it's 4 days then the 3 seconds were a lottery ticket -- not that I'd bet on those odds to deploy important software, but generally speaking about how aggressive-or-not the web is nowadays)
Consensus from friends after I posted that is that attackers monitor the Let's Encrypt transparency logs and pounce on new entries the moment they're created. Here I was using Caddy, which by default uses LE to create a cert on any hosts you define.
I can definitely reproduce this. It shocked me so much that I tried a few times:
1. Create a new random hostname in DNS.
2. `tail -f` the webserver logs.
3. Define an entry for that hostname and reload the server (or do whatever your webserver requires to generate a Let's Encrypt certificate).
Thanks! CT logs do explain it. So it's not actually the DNS entry or vhost, but the sharing of the new domain in a well-known place. That's making a lot more sense to me! I can see how that happens unwittingly though
We also use CT logs at work to discover subdomains that customers forgot about and may host vulnerable software at (if such broad checks are in the scope that the customer contracted us to check)
Yep, that’s right. And I guarantee, like would bet my retirement savings on it, that someone today has counted on security through obscurity and not realized their new website was compromised a few seconds after they launched it for the first time ever. “I just registered example.com. No one’s ever even heard of it! I’ll just have to clean it up before announcing it”, not realizing they announced it when they turned the server on.
I had a similar fun experience when I was generating UUID subdomains and was shocked to see traffic in the logs before ever sharing the URL. I've since switched to a wildcard certificate but regardless, you can't really trust the hostname to be secret because of SNI and all that.
That would’ve been quite the surprise! I was initially shocked enough when @ and www were getting hammered. A fully random hostname would’ve dazzled me for a bit.
> Huh, so anyone who can access my web server can access the installation script?
"Obviously", the server should not be accessible from the public Internet while you're still doing setup. I assume it should still behind a firewall and you're accessing it by VPN. Only after you're happy with all the configuration and have the security locked down tight would you publish it to the world. Right?
This requires running the install scripts with your shell permissions rather than with the webserver's permissions, if I'm not mistaken. I could see why one might prefer the other way, even if shared hosting is less common nowadays and shells more often an option
Honestly. When I was a kid 20 years ago backpacking around i was worried about this. Now I'm also worried about it but honestly there aren't very many issues. I've had temporary passports issued, cancelled cards, new phones setup on "new sims". One thing I did carry back then was keys. I don't anymore. The rest is just so easy to replace these days. My laptop is insured and so is my work one.
Organizations never prepare for a crisis until there is a crisis. It just doesn't happen. The cost of preparing for a crisis is always higher than the probability-weighted cost of the crisis itself, even if the potential impact is bankruptcy, because the probability is always so low. The only organizations that prepare for crises are those whose sole purpose is to prepare for crises.
Regulators can also impose certain preparedness obligations on organizations, like power grid black start capability (the government or system operator pays generators a monthly fee to have more expensive equipment that's capable of black-starting).
