

New FBI Documents Provide Details on Government's Surveillance Spyware - grellas
https://www.eff.org/deeplinks/2011/04/CIPAV_Post

======
martincmartin
_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._

~~~
defroost
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.

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

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

~~~
rhizome
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.

------
dendory
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.

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

------
chopsueyar
Re-branded 'Back Orifice'?

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

~~~
HedgeMage
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.

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

