New FBI Documents Provide Details on Government's Surveillance Spyware | Hacker News Reader

New FBI Documents Provide Details on Government's Surveillance Spyware

eff.org

66 pointsgrellas12 comments

Eventually, the FBI seems to have sought a legal opinion on the proper use of the tool, both from the Office of General Counsel and from the National Security Law Branch, and ultimately, the agency seems to have settled on a "two-step request" process for CIPAV deployments -- a search warrant to authorize intrusion into the computer, and then a subsequent Pen/Trap order to authorize the surveillance done by the spyware.

For now, but hopefully they don't circumvent the need for such procedures as this, and the growing talk of requests by the Administration for developers to add "back-doors" into all software is really a horrible direction for things to take in the US, if you care about privacy. Orwellian things like this are really upsetting, especially when the government is so blatant about it.

Well, if they were circumspect, it would be harder to know what's really going on. I'm fine with blatant. :P

I think the article proves that the above-board way (warrant for intrusion, warrant for monitoring, exploiting criminals' stupidity rather than demanding we all be made less secure) works -- demands for back doors and such are just a power grab, one that would come at a very high price.

They don't need back doors if they can just get warrants in this way. Aboveboard, paperwise, and less risk of PR blowback (defunding).

So how do they execute the warrant without either a back door or a working exploit?

They do, but the chit-chat until now has been about low-level hooks exploited for direct investigation, but from the article it appears to use stuff like browser extensions that cause the computer to report. We and the article are all assuming what might be going on, but from the sounds of it even the procedure here doesn't appear to be foolproof, say if a person has their software all up to date or uses lynx or something. One thing that seems for sure is that sniffing at the switch hasn't been enough for them, perhaps because of existing warrant limitations. It also appears that law enforcement is going to continue pushing for more and more abilities under the law than what they ever have at present.

Hence the need for a fully encrypted Internet. Turn the Internet into a 100% secure and wire-proof network. That's the only way to deal with these thugs.

Confused: how is this different from the legion of other spyware/viruses I have to defend against?

Re-branded 'Back Orifice'?

How seriously should I be concerned as a Linux user. (Who uses likely lots of binary blobs)

With regard to the current, warrant-backed intrusion method: the default configurations of most Linux distros are far more secure than the default configuration of any version of Windows. Keep up with your browser updates, don't run anything you don't trust, and you should be fine.

With regard to the possibility of back doors in future software...

Hackers, as a culture, are pretty anti-Big-Brother -- I can't imagine any of us voluntarily distributing back-doored packages. If we distributed compromised code, one of our peers would catch it before too long in the case of any but the most obscure packages. The thing is... when might it not be voluntary?

As far as American courts are concerned, source code is speech, compiled binaries are not. So, the government could conceivably force distributors of binary software to comply with a back-door policy, but they could not restrict the distribution of uncompromised source code. (This is why source-based distros can distribute things like DVD-decrypting software, while binary distros leave you to acquire it elsewhere: the distribution of source code is unrestricted.)

The only binaries on my laptop I haven't compiled myself are my video driver (I'm giving you dirty looks, NVIDIA) and the blob for my wifi driver (I'm giving you dirty looks, FCC). I'd like to get rid of both of them -- I'd absolutely pay more for a decent video chipset that didn't require closed-source anything. The wifi blob is the fault of the FCC -- no one in the US can legally distribute wireless hardware that could have its frequency usage changed by the owner. Many wifi cards get reverse engineered at some point, making the binary blob unnecessary, but manufacturers are legally prohibited from aiding in the process of creating completely open-source drivers.

Compromised source code coming from a tool's creator is both unlikely, and hard to pull off for long. Compromised binaries are more likely, but there are plenty of distros not based in the US which would have more leverage in resisting such demands (of course we don't know what their own countries are requiring of them). Getting source code with an "added" back-door (i.e. from a third party rather than the code's maintainers) is easy to avoid if you only use signed code -- make sure to watch for packages that stupidly download code for their dependencies during build without checking signatures instead of using what's already on your system.

As for those drivers with binary blobs -- until consumers become more resistant to using them, they aren't going anywhere.

IIRC, ath5k does not need a binary HAL any longer. There is also the madwifi-free branch which has the HAL in source form.

Reply on news.ycombinator.com