tallytarik

This article is somewhat misleading.

The court only ruled that "OpenAI" is descriptive. It did not rule that it can never be registered.

A descriptive trademark can still be registered with evidence that the mark has become distinctive through use -- that is, that "OpenAI" is known to the general public to refer to their company, rather than simply describing a type of AI.

It appears OpenAI have already made that submission separately:

The Board of Appeal also stated that, once the contested decision has become final, the proceedings will resume for the purposes of examining the applicant’s alternative claim based on Article 7(3) of Regulation 2017/1001, relating to distinctive character acquired through use.

This sort of rejection is quite common. You can overcome the objection by submitting evidence that your mark has acquired distinctiveness through use. So there will be plenty of trademarks that seem generic/descriptive that have gone through that process.

edit: I originally thought that’s what was being rejected here. It’s not. The court only ruled that “OpenAI” is descriptive. Separately, OpenAI have also submitted evidence of acquired distinctiveness, which will be decided in due course by the trademark office.

docker-rollout also works well: https://github.com/wowu/docker-rollout

The readme covers connection draining with Traefik which should solve one of the issues the author mentions

Phrasing like “Honestly?” and “It’s not just [x], it’s [y]” multiple times

Every list is a set of 3, and most lists have a bolded intro phrase, one even has the famous slopperific emojis

We’re still waiting on a solution for https://www.cloudflarestatus.com/incidents/391rky29892m (which actually started a month earlier than the incident reports)

In the meantime, as you say, we’re now going through and evaluating other vendors for each component that CF provides - which is both unfortunate, and a frustrating use of time, as CF’s services “just worked” very well for a very long time.

Yes this is clearly verbatim output from an LLM.

But it's perfect HN bait, really. The title is spicy enough that folks will comment without reading the article (more so than usual), and so it survives a bit longer before being flagged as slop.

Yes. The over-use of bold in the intro (hell, in the first sentence) is a good hint.

All of it aligns with https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing

Maybe the images were made by hand.

It’s entirely written by an LLM.

Great post and a great little tool. Some of my experience using these techniques in production:

1. Trilateration mostly doesn't work with internet routing, unlike GPS. Other commenters have covered this in more detail. So the approach described here - to take the closest single measurement - is often the best you can do without prior data. This means you need a crazy high distribution of nodes across cities to get useful data at scale. We run our own servers and also sponsor Globalping and use RIPE Atlas for some measurements (I work for a geo data provider), yet even with thousands of available probes, we can only accurately infer latency-based location for IPs very close to those probes.

2. As such, latency/traceroute measurements are most useful for verifying existing location data. That means for the vast majority of IP space, we rely on having something to compare against.

3. Traceroute hops are good; the caveat being that you're geolocating a router. RIPE IPmap already locates most public routers with good precision.

4. Overall these techniques work quite well for infrastructure and server IP addresses but less so for eyeball networks.

https://ping.sx is also a nice comparison tool

Much of the internet still does not support IPv6, so most providers will give you an IPv4 address. In fact only a few providers even support IPv6 at all.

Even with IPv6 it's not a huge problem. With a few samples we can know that a provider is operating in a given /64 or /48 or even /32 space, and can assign a confidence level that the range is used for VPNs.

Working on improving the data pipeline for https://iplocate.io - an IP intelligence service I've worked on since 2017. A couple of recent focuses:

1. VPN and proxy detection. We already track dozens of providers, but we can do better here. There's also a bunch of metadata we collect as part of this process which we don't currently surface, so I'm looking at what else we can bring to our databases and free API.

2. Better detail and evidence on how we build and test our own geolocation database, which we create from scratch. There's been a recent trend of misinformation about geo accuracy, including from some other providers, so I want to better explain the accuracy (and inaccuracy) of various techniques, our policy for when we prefer certain data, and so on.

(Open to partnerships for any folks looking for a new provider!)

It won’t end up in our proxy detection database, but we track hosting provider ranges separately: https://www.iplocate.io/data/hosting-providers/

There are plenty of VPN and proxy detection services, either as a service (API) or downloadable database, which are surprisingly comprehensive. Disclaimer: I’ve run one since 2017. Years on, our primary data source is literally holding dozens of subscriptions to every commercial provider we can find, and enumerating the exit node IP addresses they use.

There are also other methods, like using zmap/zgrab to probe for servers that respond to VPN software handshakes, which can in theory be run against the entire IP space. (this also highlights non-commercial VPNs which are not generally the target of our detection, so we use this sparingly)

It will never cover every VPN or proxy in existence, but it gets pretty close.

Most of these providers are in fact open about the fact that these locations are “virtual”, so it’s misleading to say they don’t match where they claim to be.

There is however an interesting question about how VPNs should be considered from a geolocation perspective.

Should they record where the exit server is located, or the country claimed by the VPN (even if this is a “virtual” location)? In my view there is useful information in where the user wanted to be located in the latter case, which you lose if you only ever report the location of servers.

(disclaimer: I run a competing service. we currently provide the VPN reported locations because the majority of our customers expect it to work that way, as well as clearly flagging them as VPNs)

Working on improving the data pipeline for https://iplocate.io - an IP intelligence service I've worked on since 2017.

Recent focus has been on geolocation accuracy, and in particular being able to share more data about why we say a resource is in a certain place.

Lots of folks seem to be interested in this data, and there's very little out there. Most other industry players don't talk about their methodology, and those that do aren't overly honest about how X or Y strategy actually leads to a given prediction, or the realistic scale or inaccuracies of a given strategy, and so on. So this is an area I'm very interested in at the moment and I'm confident we can do better in. And it's overall a fascinating data challenge!

Our government has been paying Deloitte & co. to produce slop for years before AI was being used to generate said slop.

Can we get a refund for all of the others too?

ISPs have no obligation, although the ubiquity of sites and apps relying on IP geolocation mean that ISPs are incentivized to provide correct info these days.

I run a geolocation service, and over the years we've seen more and more ISPs providing official geofeeds. The majority of medium-large ISPs in the US now provide a geofeed, for example. But there's still an ongoing problem in geofeeds being up-to-date, and users being assigned to a correct 'pool' etc.

Mobile IPs are similar but are still certainly the most difficult (relative lack of geofeeds or other accurate data across providers)

I thought this was going to be an analysis of articles that are clearly AI-generated.

I feel like that’s an increasing ratio of top posts, and they’re usually an instant skip for me. Would be interested in some data to see if that’s true.

G2, Sourceforge (yes, that one), and Gartner’s Capterra/GetApp/SoftwareAdvice all have the same business plan: charge vendors $x,xxx+ per month to outrank other vendors in their made up categories.

Of course, you can technically list for free.

But look! For the low low price of $x,xxx per month, now you can show one of 40 tailor-made award icons on your site!

Or, unlock the privilege of showing “user reviews” from our site on your site! (of course if you had managed to get reviews independently, you’re not allowed to use the widget without paying)

Don’t have reviews? Ah, I forgot to mention. The $x,xxx plan also comes with “review generation” — we’ll pay users to write reviews for you!

Oh, and on an unrelated note, the $x,xxx plan just also happens to unlock dofollow links across each of those 40 made up categories, which all rank highly in google. And the $xx,xxx plan means that - user ratings aside - you can end up at the top of those categories.

It’s hard to describe it other than the author says: a grift. Seeing those logos on other companies sites are now a huge turn off to me personally, and I haven’t yet capitulated for my own SaaS, but I suspect this isn’t the feeling of the execs they seek to target. Or maybe it is, and it’s just the price of doing business.

I've tried variations of this. I find it will often cause it to include cringey bullshit phrases like:

"Here's your brutally honest answer–just the hard truth, no fluff: [...]"

I don't know whether that's better or worse than the fake flattery.

SEEKING FREELANCER | Remote | Integration Engineers, Content Writers

IPLocate is on a mission to provide developers with reliable, affordable, and easy-to-use IP address intelligence - geolocation, threat data, network information and more.

We're looking for engineers to write SDKs and integrations to use our APIs with popular programming languages, frameworks, and tools. We would prefer to work with multiple folks who are experts in their respective language/framework rather than a single engineer to write 20 integrations, so we'd love to hear about your experience.

We're also looking for content writers to help write practical tutorials, step-by-step guides, and real-world use cases for our website and blog, and for publication elsewhere (e.g. Medium, Dev.to).

Details and contact links: https://www.iplocate.io/build-for-iplocate

(We've recently launched this page as an open offer to interested folks. Get in touch with your details and we're happy to formalize an offer.)

And nowadays we have

  Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36

LLMs seem to use them at a rate far higher than the average person, same with the words “delve” and “robust” (and many others)

Additionally, rare hallucinations in Voice Mode persist with this update, resulting in unintended sounds resembling ads, gibberish, or background music.

This would be really funny if it weren’t real life.

I remember seeing this technique in a video by Sebastian Lague: https://youtu.be/sLqXFF8mlEU?t=787

Really cool

You can look up the AS and other info, like detected proxies or VPNs, using the form on https://iplocate.io/what-is-my-ip (disclaimer: I've run this service since 2017).

If they come from a consistent AS, you can block the AS. If they're using a proxy or VPN, you could try blocking those. If you don't expect to get traffic from hosting providers, you can block where `asn.type == 'hosting'`.

We self-host nominatim as part of the iplocate.io pipeline. It works great, but the requirements are pretty heavy for something to host casually.

An in-between for OP could be something like opencagedata.com, which is still a third-party API but an order of magnitude less expensive than Google. (not affiliated but have previously explored the service)

Working on expanding https://iplocate.io - an IP geolocation and threat data service I've worked on since 2017.

I've found it really satisfying to solve the data challenges that come along the way, from "where on earth could this data come from" to collecting, storing, parsing, validating and serving constantly. It's also - by nature - something that's never going to be "done". There's always something to improve. I love it!

We now offer more types of data (ASN/whois, proxy/threat detection, so on) than most other providers, more accurate and more frequently updated, at a tenth of the cost, which is something I'm really happy about.

For anyone interested, you can make 1,000 requests day free, or reach out if you have an open source/public interest project for an unlimited key or access to the data.

I'd also love to hear any suggestions for additional data types to add.

This looks similar to iplocate.io, which I’ve run since 2017. There are also plenty of others.

Free and unlimited is going to be a tough deal to maintain forever if it gets popular. Good luck!

Feel free to reach out if there’s anything I could help with

This is an interesting point and in my view, there is no clear answer here.

Here's an example: https://ipinfo.io/172.224.238.32

This IP is actually in Ontario, which you can easily verify with a ping measurement. But it is announced as being in Calgary by Apple's iCloud Relay geofeed (https://mask-api.icloud.com/egress-ip-ranges.csv).

Why? Because the intent of iCloud Relay is to obscure a user's IP address while still providing a roughly accurate location, specifically so that geolocation-based services still work as expected. For that to work, they need to provide 'fake data' in this geofeed so that they have pools of addresses covering thousands of cities around the world, AND they need geolocation providers to accept this.

ipinfo accepts this, even though it's wrong. So do we. After all, geofeeds were supposed to provide a public geolocation database, the idea being that the network operator should be trusted to have the best information. We could provide the 'real' location, but if 9 providers say an IP address is in X and 1 provider says it's in Y, and Y is correct, you may just be frustrating end users of the network.

But where is the line? I'm not sure, and it's hard to say who has the balance right here.

We try to mitigate this by providing extra data like whether the address is a hosting or relay provider - for free, unlike others :) Some future addition could be to provide additional accuracy or source information, or even a 'reported' vs 'measured' location.

We're working through this and hope to get to the right answer over time. Thanks for raising this. :)