Built-in positioning of network traces is relatively recent in mobile network equipment and dedicated probes.
If that happened more than 5-6 years ago, it would sound even less likely. Most telcos never bothered doing the processing needed to position raw events based on timing advances. They'd simply offload that to third party companies. These solution providers aren't crazy, they don't touch data that isn't already anonymized. It's even less probable that a random employee would have access to the multiple datasets needed to piece someone's personal data together.
Are you in a small company where most people wear lots of hats, or in a big company that has siloed off groups? Am guessing it's more of the big company approach that silos things off?
So what you’re saying is if you were secretly a psycho and wanted to stalk your ex-girlfriend, you work at a Telco and basically have access to the tools to do it?
So putting aside the fact you’re a reasonable person, anyone who works themselves up to a similar seniority and job description in a Telco as you, could in fact do exactly what the article is saying is an issue for the victims.
Stalker terrorises woman, she reports it, nothing happens, stalker kills her. Queue hand wringing.
It’s played out a lot of times, in a lot of places, I don’t know why everyone here is so cynical.
Even in pretty dysfunctional countries, or pro-business ones like the US, where nothing like the GDPR exists, telcos management have a strong interest in not letting just any rank and file employee spy on subscribers.
Most breaches are not in the interests of management, but they happen anyway as management wants to save money or doesn't understand how it could happen.
> And obviously, a simple email to the data governance and privacy office would be taken extremely seriously.
What is this based on? I used to work for a data governance and privacy vendor that supplied data for audits. Tons and tons of customers asked us to fudge their data.
This is after the Delve scandal, where the hottest tech compliance company was completely fraudulent and numerous other hot tech companies also had completely fraudulent audits.
> 50M+ subs operator, at least 10 employees can have both location and CRM data, I guess it's pretty typical.
This shouldn't be the case anywhere in Europe or regions with similar laws. And we have a lot less than 50M subscribers.
Anyway, there's really nothing that justifies having access to both. If you work on network quality and need enriched traces, personal data is completely useless. Most business cases don't even need stable, let alone clear IMSI. Very few people will need to look at a clear MSISDN for troubleshooting, and if you do things properly they shouldn't get blanket access to terabytes of daily telemetry.
Aggregated CRM data can be useful to more high-level business cases, nothing that can be used to identify someone personally. Our data governance office doesn't even let us correlate anonymized and GDPR compliant data that we buy from third parties when the IDs are too stable, as it'd be fairly easy to match raw network traces.
> so you do have access :)
No I don't. Sometimes people move to different teams you know, and access to datasets I had in the past is mutually exclusive with some that I do have now.
> correct for LI, not for emergency.
If people that can see E112 payloads with GNSS locations exist, then I don't know they are, but I'm sure they can't have access to stuff relevant to the discussion here. On the network telemetry side, our job is monitoring and quality assurance. Anyway this kind of data is too sparse to be abused by a stalker.
you are close to a system in a way that those guardrails are clear and present; the story is from the point of view of a victim, and it is possible that they were indeed a victim. Therefore the means of the stalking is not known at all via this story, but somehow, something did occur. It is not surprising on either side, and they do not necessarily contradict each other IMHO
I'm specifically talking about the technical aspect. Even with non-existent separation of concerns, and abysmal practices related to data governance which would be breaking the law in most of the developed world, the story sounds like bullshit. Extracting points of interest and reconstructing paths from raw network telemetry isn't trivial.
The likelihood a random employee could run a quick SQL join to stalk someone based on their name is zero.
I'm glad to hear that your random telco's governance and influence has spread around the entire world to every other telco.
FYI: from the fact it's hard (not impossible) to see the data mentioned and it's possible (not guaranteed) that the caught offender would be punished is a VERY long way to "you lie".
Theirs was anecdata, yours is anecdata but you're additionally rude.
Ah, I remember back in the day when "trust me I work in a telco and this is just dumb" people were really really silent after the room 641a stuff got leaked.
So now the random ex-boyfriend has access to the same tools as 3 letter agencies, got it.
If you live in a country where you cannot trust law enforcement then there isn't much your telco can do. But specifically, these surveillance tools are not available to us.
Their internal IT infrastructure runs self-hosted OSS wherever possible. I don't think cal.rs is a toy project, they know the perils and headaches of doing open source.
I think it's fine. GitHub Copilot is popular as ever, especially in companies that have enterprise tier subscriptions. Plans for personal use pretty good too, pricing is competitive. The VS Code integration and agentic features aren't bad either.
Developer tools live in their own space. And I assume most devs don't really care that "Copilot" started to show up everywhere, especially in MS365 products. At least I don't. Conversely, do non-technical people care where the term comes from, and now means "LLM integration" in a bunch of MS products?
I think it's better that Google going through Bard, Gemini, IDX, Firebase Studio, Antigravity, ...
After that, and IBM losing interest, Apple did hire a few competent people (including contributors to Netty and Akka) to build the Swift Server Workgroup.
But I don't know why I'd pick Swift on the server when Rust is better in almost every dimension, with a thriving and more community-driven ecosystem.
I think it's not about that but about dogfooding Swift on the server. Apple uses Go, Java etc for a lot of its server components and refused to invest in hiring people that would extend the ecosystem for server Swift.
It certainly doesn't help, but among big tech, Apple is not the only company where teams are siloed and independent. Microsoft has people writing Java or Go instead of C# too.
I assume the server side usage is not zero, but not enough to reach a critical mass, you're probably right there.
Sorry I have to defend my pride here a little bit. When I joined my previous company, the entire company was on Java 8. When I left every app in every team there was up-to-date on the latest LTS release at the time, 17. I assisted many teams in upgrading their Java, Spring, etc, and inspired even more.
I would argue that I'm one of the last people who you could blame for most companies being many Java versions behind...
So what's the issue then? You'd be able to bring other teams to current versions of Java and frameworks, which have all been using virtual threads for the past 3 years.
Voting is definitely not a small domain in a direct democracy, and many Swiss citizens abroad don't receive paper ballots early enough to mail them back in time.
> But somehow Kotlin managed to stay "not too complex", unlike Scala.
It's not really true anymore, Kotlin has slowly absorbed most of the same features and ideas even though they're sometimes pretty half-baked, and it's even less principled than the current Scala ecosystem. JetBrains also wants to make Kotlin target every platform under the sun.
At this point, the only notable difference are HKTs and Scala's metaprogramming abilities. Kotlin stuck to a compiler plugin exposing a standard interface (kotlinx.serialization) for compile-time codegen. Scala can do things like deriving an HTTP client from an OpenAPI specification on the fly, by the LSP backend.
Not to the same extent. Scala.JS and Kotlin.JS are somewhat comparable, other targets not so much. There was no serious attempt at making Scala target mobile devices, even during the window of opportunity with Scala on Android.
> even during the window of opportunity with Scala on Android.
I don't understand this. You can run any pure Java jar on Android, pretty sure you can do that with Scala too? It's not exactly a "different platform" in terms of programming language. Sure it needs tooling and specific libraries, but that's higher level than the programming language.
Jetbrains is doing interop with Swift (Kotlin -> ObjC -> Swift and more recently Kotlin -> C -> Swift), which Scala never did. But I don't really see how this is relevant in this conversation.
You can run Scala on Android and it's been done but it never worked well nor was given priority. Which is understandable as the commercial entities behind Scala already struggle to build the ecosystem and tooling in spaces where the language shines.
For instance the Android runtime has chronically lagged behind mainline JVM bytecode versions, iirc once Scala started to emit Java 8 bytecode, Android was stuck on Java 6.
Kotlin had other obvious advantages on Android like its thin standard library or the inlining of higher-order functions.
reply