From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass smtp.mailfrom=lang.hm; dkim=fail; arc=none (Message is not ARC signed); dmarc=none Received: from mail.lang.hm (wsip-70-167-213-146.ph.ph.cox.net [70.167.213.146]) by mail.toke.dk (Postfix) with ESMTPS id 88C87727F96 for ; Wed, 01 Oct 2025 23:22:32 +0200 (CEST) Received: from [10.2.2.53] (unknown [10.2.2.53]) by mail.lang.hm (Postfix) with ESMTP id 5A51320AE84; Wed, 1 Oct 2025 14:22:31 -0700 (PDT) Date: Wed, 1 Oct 2025 14:22:26 -0700 (PDT) From: David Lang To: "Livingood, Jason" cc: Frantisek Borsik , Dave Taht via Starlink In-Reply-To: Message-ID: References: MIME-Version: 1.0 Message-ID-Hash: ULI2LIY7JATIEIZLDEEVOWRTWWW4A3OK X-Message-ID-Hash: ULI2LIY7JATIEIZLDEEVOWRTWWW4A3OK X-MailFrom: david@lang.hm X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252; format=flowed X-Content-Filtered-By: Mailman/MimeDel 3.3.10 X-Mailman-Version: 3.3.10 Precedence: list Subject: [Starlink] Re: Lost in Space: The Limits of Geolocation in a Satellite-Connected World (new article from Geoff Huston) List-Id: "Starlink has bufferbloat. Bad." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Livingood, Jason wrote: > Related reminder that the IAB is holding a workshop on IP Geolocation =96= with statements of interested due at the end of this week. For more info: > https://www.iab.org/announcements/call-for-papers-iab-workshop-on-ip-addr= ess-geolocation-ip-geo/ > > Call for Papers: IAB Workshop on IP Address Geolocation (ip-geo) > 17 Jul 2025, 6:42 p.m. > This workshop aims to understand the current use cases for publishing, di= scovering, and consuming IP address geolocation data. > Workshop Description > This workshop aims to understand the current use cases for publishing, di= scovering, and consuming IP address geolocation data ('IP-geo' hereafter). = It will also explore areas for improvement, both in ways to update or repla= ce IP geolocation mechanisms, and to consider mechanisms that satisfy the u= se cases without relying on IP addresses. > The IAB seeks short position papers on the topics listed below. This list= is non-exhaustive and should be interpreted broadly. > > * Today's Use Cases: How is IP-geo data used today? In particular, wha= t are the root challenges, technical needs, or business needs that IP-geo d= ata is being leveraged to address? > * Gaps and Problems: What are gaps or problems with the current approa= ches being used by industry? Are there preferences for particular file type= s? How effective are current approaches? What are the impacts on user priva= cy? > * Future Opportunities: If we re-designed technical solutions to addre= ss the motivating use cases, what would those solutions look like? Are ther= e alternative approaches that can avoid the gaps and problems we have today= ? Is there value in conveying other information in addition to or instead o= f geography, such as type of last mile network connection? If I were attending and had the power to do so, I would add a discussion on= how=20 much geolocation is needed and what other approaches are for example: If you are using a mobile device (with an app or browser), you have access = to=20 the location from the device (either GPS or lower accuracy) If you are using Starlink, it has a GPS in it, make it's location available= on=20 it's local network and have a way for computers/devices/browsers to query t= he=20 local network for a location. At that point, just about all that remains is traditional fixed location=20 services (wired or wireless), and they can leverage a similar approach to w= hat I=20 outline for starlink, a service on their local router that provides locatio= n=20 information for things on the network. Now, if you are not just trying to provide geo-based services, but instead = analyze IP data in logs to get geo info, this won't help, but (recognizing = the=20 security limitations of asking the user to provide their location), I think= it=20 would be both more useful for consumers, and better overall to explicitly p= ass=20 location information rather than try to reverse engineer it from the IP=20 addresses. David Lang