Hacker News Reader

Comment by mrnotcrazy | Hacker News Reader

Could you expand on this more? It's not clear to me what this is implying.

https://en.wikipedia.org/wiki/Room_641A

Does the NSA even have the ability to monitor all AI traffic like this? Wouldn’t that require tons of data centers that there literally hasn’t been time to build yet? I really have no idea, maybe the asymmetry of the compute required to monitor is way lower than the compute required to serve inference?

it's fair to say they do and have for ages... it's not that hard to assume a well trusted TLS cert is under their control.

What does having a "well trusted TLS cert" enable for them in this case, exactly?

Having a magical cert doesn't mean you can just intercept everything.

On the contrary, it lets you MITM encrypted communications by swapping the website's original certificate for the "well trusted TLS cert"

No, it doesn't. HSTS and other methods prevent this from happening.

HSTS doesn't protect you from this at all. It only requires HTTPS, which a spoofed-but-trusted cert passes just fine.

No mainstream browser (or any browser?) is doing cert pinning.

What "other methods" are there that are deployed and actually in use?

Transparency logs. It's mandatory for a cert to be in CT logs for browsers to trust it. Those are public, if this was happening, someone would have noticed already.

https://en.wikipedia.org/wiki/Tempora

https://en.wikipedia.org/wiki/Utah_Data_Center

grep is pretty fast

I dont think it requires a lot. I think of them as data hoarders more than anything else. It doesnt seem out of their capabilities to store a ton of chats. Maybe they're having scaling problems with the increased data rates they're hoarding and it led to an outage.

"AI Traffic" is just traffic. If the infrastructure exists to monitor/buffer traffic (it does) then this can be monitored as well. Whether this hiccup was due to them hitting their limits briefly (or turning it on, or etc) who knows.

I bet it's even negligible traffic compared to e.g. Netflix or YouTube. Even a 'huge' context window is nothing compared to the random library of a basic Web page.

Not once you de-dup.

https://en.wikipedia.org/wiki/Utah_Data_Center

Traffic doesn’t need to be routed through it though, just tee’d to it,

In the context of arbitrary line-level traffic, sure. But we're talking about robust reverse proxies here if this _is_ what's going on, again, not a fiber tap inside a closet. In that case, there's no such thing as tee'ing to it.

Worth mentioning that this room takes a split from the main feed and is not in the path of traffic. Whatever is in this room could go down and it would not cause an outage.

And if the hypothetical splitter is the thing that breaks? Then it would break main traffic too.

Interestingly, fiber signals can be split passively[1] (without a transducer), which should be extremely reliable. No idea what technology this kind of application would use though.

[1] https://en.wikipedia.org/wiki/Fiber-optic_splitter

We don't know the architecture of this hypothetical spy splitter tho in the current case. It can be less covert and more of a complicated config, etc.

How often does the entire west coast of the U.S. lose Internet connectivity to the entire continent of Asia? That gives you a constraint on how often that type of failure actually occurs.

It would be weird for the Mandatory NSA Logging Program to be synchronous with serving customer traffic, but-

There is No Such Thing

being done by No Such Agency.

https://en.wikipedia.org/wiki/33_Thomas_Street

https://theintercept.com/2016/11/16/the-nsas-spy-hub-in-new-...

This is the building from Control and the fact that 1. it's a real building and 2. it's an actual spy building is even crazier to me:

https://control.fandom.com/wiki/Oldest_House

https://en.wikipedia.org/wiki/Control_(video_game)

To give you an idea just how much phone traffic was being routed through that building, they had a major power failure at that site and it took down most of the north eastern US's phone network:

On September 17, 1991, management failure, power equipment failure, and human error combined to disable AT&T's central office switch at 33 Thomas. More than five million calls were blocked, and the Federal Aviation Administration private lines were also interrupted, disrupting air traffic control to 398 airports serving most of the northeastern United States.

Think snowden.

Sharepoint is the cause of the outages?

Reply on news.ycombinator.com