The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 30 Issue 23

Thursday 6 April 2017

Contents

The future of the open Internet—and our way of life—is in your hands
Quincy Larson
Tim Berners Lee plots radical overhaul
PGN
Encryption and the Press Clause
D. Victoria Baranetsky
Trust vs Trustworthy?
Stef Aupers
Russia Is Trying to Copy China's Approach to Internet Censorship
Slate
20-year-old command & control server for Russian hackers
WiReD via Badi Irshid
Inside the Hunt for Russia's Most Notorious Hacker
WiReD
A scramble at Cisco exposes uncomfortable truths about U.S. cyberdefense
WiReD
Huge repository of documents obtained under FOIA
Governmentattic via Don Gilman
How Hackers Hijacked a Bank's Entire Online Operation
WiReD
Hackers Are Emptying ATMs With a Single Drilled Hole and $15 Worth of Gear
WiReD
Microsoft says it's blocking Windows 7, 8 patches on latest AMD, Intel chips
PC World
How Garadget Avenged a One-Star Review With Digital Sabotage
The Atlantic
Another sex toy trivially hacked
Pentestpartners
$14M Initiative to Fight Fake News Includes Facebook, Mozilla
PCMag
Hate speech and fake news—follow the money!
Lauren Weinstein
Fake News Publishers Are Still Earning Money From Major Ad Networks
Buzzfeed
Re: UK government says Apple cannot get away with encryption
Chris Drewe
Re: Risks from falsified Data
Robert P. Schaefer
Info on RISKS (comp.risks)

The future of the open Internet—and our way of life—is in your hands (Quincy Larson)

Dewayne Hendricks <dewayne@warpspeed.com>
Mon, Mar 27, 2017 at 5:28 PM
Quincy Larson, Medium, 16 Mar 2017
<https://medium.freecodecamp.com/inside-the-invisible-war-for-the-open-internet-dd31a29a3f08>

There are a lot of scary things happening these days, but here's what keeps
me up late at night. A handful of corporations are turning our open Internet
into this:

These corporations want to lock down the Internet and give us access to
nothing more than a few walled gardens. They want to burn down the Library
of Alexandria and replace it with a magazine rack.

Why? Because they'll make more money that way.

This may sound like a conspiracy theory, but this process is moving forward
at an alarming rate.

History is repeating itself.

So far, the story of the Internet has followed the same tragic narrative
that's befallen other information technologies over the past 160 years:

  * the telegram
  * the telephone
  * cinema
  * radio
  * television

Each of these had roughly the same story arc:

  * Inventors discovered the technology.
  * Hobbyists pioneered the applications of that technology, and
    popularized it.
  * Corporations took notice. They commercialized the technology,
    refined it, and scaled it.
  * Once the corporations were powerful enough, they tricked the government
    into helping them lock the technology down. They installed themselves
    as natural monopolies.
  * After a long period of stagnation, a new technology emerged to disrupt
    the old one. Sometimes this would dislodging the old monopoly. But
    sometimes it would only further solidify them.

This loop has repeated itself so many times that Tim Wu (the Harvard law
professor who coined the term Net Neutrality) has a name for it: The Cycle.
“History shows a typical progression of information technologies, from
somebody's hobby to somebody's industry; from jury-rigged contraption to
slick production marvel; from a freely accessible channel to one strictly
controlled by a single corporation or cartel—from open to closed
system.''

And right now, we're in step 4 the open Internet's narrative. We're
surrounded by monopolies.

The problem is that we've been in step 4 for decades now. And there's no
step 5 in sight. The creative destruction that the Economist Joseph
Schumpeter first observed in the early 1900s has yet to materialize.

The Internet, it seems, is special. It's the ultimate information technology
-- capable of supplanting the telegram, telephone, radio, cinema,
television, and much more—and there's no clear way to disrupt it.

But the war for the commanding heights of the Internet is far from over.
There are many players on this global chess board. Governments. Telecom
monopolies. Internet giants like Google and Facebook. NGOs. Startups.
Hackers. And—most importantly—you.


Tim Berners Lee plots radical overhaul

"Peter G. Neumann" <neumann@csl.sri.com>
Tue, 4 Apr 2017 14:18:24 PDT
"On the better web Berners-Lee envisions, users control where their data is
stored and how it's accessed. For example, social networks would still run
in the cloud. But you could store your data locally. Alternately, you could
choose a different cloud server run by a company or community you trust. You
might have different servers for different types of information -” for
health and fitness data, say -” that is completely separate from the one
you use for financial records."

https://www.wired.com/2017/04/tim-berners-lee-inventor-web-plots-radical-overhaul-creation/

  [Dave Farber noted a related BBC item: Web inventor Sir Tim Berners-Lee
  slams UK and US net plans]
  http://www.bbc.com/news/technology-39490324


Encryption and the Press Clause (D. Victoria Baranetsky)

"Peter G. Neumann" <neumann@csl.sri.com>
Tue, 4 Apr 2017 12:46:06 PDT
D. Victoria Baranetsky, JIPEL <http://jipel.law.nyu.edu/>, 3 Apr 2017
Encryption and the Press Clause
The NYU Journal of Intellectual Property & Entertainment Law
JIPEL Vol. 6 “ No. 2
http://jipel.law.nyu.edu/vol-6-no-2-1-baranetsky/

Almost twenty years ago, a hostile debate over whether government could
regulate encryption—later named the Crypto Wars—seized the country. At
the center of this debate stirred one simple question: is encryption
protected speech? This issue touched all branches of government percolating
from Congress, to the President, and eventually to the federal courts. In a
waterfall of cases, several United States Court of Appeals appeared to reach
a consensus that encryption was protected speech under the First Amendment,
and with that the Crypto Wars appeared to be over, until now.

Nearly twenty years later, the Crypto Wars have returned. Following recent
mass shootings, law enforcement has once again questioned the legal
protection for encryption and tried to implement backdoor techniques to
access messages sent over encrypted channels. In the case, Apple v. FBI, the
agency tried to compel Apple to grant access to the iPhone of a San
Bernardino shooter. The case was never decided, but the legal arguments
briefed before the court were essentially the same as they were two decades
prior. Apple and amici supporting the company argued that encryption was
protected speech.

While these arguments remain convincing, circumstances have changed in ways
that should be reflected in the legal doctrines that lawyers use.  Unlike
twenty years ago, today surveillance is ubiquitous, and the need for
encryption is no longer felt by a seldom few. Encryption has become
necessary for even the most basic exchange of information given that most
Americans share “nearly every aspect of their lives—from the mundane to
the intimate'' over the Internet, as stated in a recent Supreme Court
opinion.*

Given these developments, lawyers might consider a new justification under
the Press Clause. In addition to the many doctrinal concerns that exist with
protection under the Speech Clause, the Press Clause is normatively and
descriptively more accurate at protecting encryption as a tool for secure
communication without fear of government surveillance.  This Article
outlines that framework by examining the historical and theoretical
transformation of the Press Clause since its inception.

* Riley v. California, 134 S. Ct. 2473, 2490 (2014).


Trust vs Trustworthy? (Stef Aupers)

"Peter G. Neumann" <neumann@csl.sri.com>
Mon, 3 Apr 2017 15:41:21 PDT
'Trust no one': Modernization, paranoia, and conspiracy culture
Stef Aupers, Erasmus University, The Netherlands
European Journal of Communication 27(1) 22-34, 2012
http://journals.sagepub.com/doi/pdf/10.1177/0267323111433566

Abstract

Popular conspiracy theories, like those about JFK, the attacks of 9/11, the
death of Princess Diana or the swine flu vaccination, are generally depicted
in the social sciences as pathological, irrational and, essentially,
anti-modern. In this contribution it is instead argued that conspiracy
culture is a radical and generalized manifestation of distrust that is
embedded in the cultural logic of modernity and, ultimately, produced by
processes of modernization.  In particular, epistemological doubts about the
validity of scientific knowledge claims, ontological insecurity about
rationalized social systems like the state, multinationals, and the media;
and a relentless 'will to believe' in a disenchanted world—already
acknowledged by Adorno, Durkheim, Marx, and Weber—nowadays motivate a
massive turn to conspiracy culture in the West.

  [Thanks to Dan Geer for spotting this one.  PGN]


Russia Is Trying to Copy China's Approach to Internet Censorship (Slate)

Lauren Weinstein <lauren@vortex.com>
Tue, 4 Apr 2017 11:19:47 -0700
NNSquad
http://www.slate.com/articles/technology/future_tense/2017/04/russia_is_trying_to_copy_china_s_internet_censorship.html

  This is part of a larger story. Just a few years ago, Russians had a
  mostly free Internet. Now, Russian authorities would like to imitate
  China's model of Internet control. They are unlikely to succeed. The
  Kremlin will find that once you give people Internet freedom, it's not so
  easy to completely take it away.


20-year-old command & control server for Russian hackers (WiReD)

Badi Irshid <badi@riseup.net>
April 4, 2017 at 3:57:14 PM EDT
https://www.wired.com/2017/04/russian-hackers-used-backdoor-two-decades/


Inside the Hunt for Russia's Most Notorious Hacker (WiReD)

Monty Solomon <monty@roscom.com>
Wed, 5 Apr 2017 00:06:29 -0400
https://www.wired.com/2017/03/russian-hacker-spy-botnet


A scramble at Cisco exposes uncomfortable truths about U.S. cyberdefense (WiReD)

Gabe Goldberg <gabe@gabegold.com>
Tue, 4 Apr 2017 22:20:33 -0400
When WikiLeaks founder Julian Assange disclosed earlier this month that his
anti-secrecy group had obtained CIA tools for hacking into technology
products made by U.S. companies, security engineers at Cisco Systems
(CSCO.O) swung into action.

The Wikileaks documents described how the Central Intelligence Agency had
learned more than a year ago how to exploit flaws in Cisco's widely used
Internet switches, which direct electronic traffic, to enable eavesdropping.

Senior Cisco managers immediately reassigned staff from other projects to
figure out how the CIA hacking tricks worked, so they could help customers
patch their systems and prevent criminal hackers or spies from using the
same methods, three employees told Reuters on condition of anonymity.

The Cisco engineers worked around the clock for days to analyze the means of
attack, create fixes, and craft a stopgap warning about a security risk
affecting more than 300 different products, said the employees, who had
direct knowledge of the effort.

That a major U.S. company had to rely on WikiLeaks to learn about security
problems well-known to U.S. intelligence agencies underscores concerns
expressed by dozens of current and former U.S. intelligence and security
officials about the government's approach to cybersecurity.

http://mobile.reuters.com/article/idUSKBN17013U


Huge repository of documents obtained under FOIA

Don Gilman <txaggiese@gmail.com>
Wed, 5 Apr 2017 10:54:27 -0500
http://www.governmentattic.org/

[FOIA = U.S. Freedom of Information Act]


How Hackers Hijacked a Bank's Entire Online Operation

Gabe Goldberg <gabe@gabegold.com>
Tue, 4 Apr 2017 22:16:32 -0400
The traditional model of hacking a bank isn't so different from the
old-fashioned method of robbing one. Thieves get in, get the goods, and get
out. But one enterprising group of hackers targeting a Brazilian bank seems
to have taken a more comprehensive and devious approach: One weekend
afternoon, they rerouted all of the bank's online customers to perfectly
reconstructed fakes of the bank's properties, where the marks obediently
handed over their account information.

https://www.wired.com/2017/04/hackers-hijacked-banks-entire-online-operation/

Gabriel Goldberg, Computers and Publishing, Inc.       gabe@gabegold.com
3401 Silver Maple Place, Falls Church, VA 22042           (703) 204-0433


Hackers Are Emptying ATMs With a Single Drilled Hole and $15 Worth of Gear

Gabe Goldberg <gabe@gabegold.com>
Mon, 3 Apr 2017 22:25:03 -0400
  [This is the item reported by krebsonsecurity in RISKS-30.22, Why I always
  tug on the ATM.  But it is clever enough that I'm happy to include Gabe's
  posting as well.  PGN]

Not so long ago, enterprising thieves who wanted to steal the entire
contents of an ATM had to blow it up. Today, a more discreet sort of
cash-machine burglar can walk away with an ATM's stash and leave behind only
a tell-tale three-inch hole in its front panel.

https://www.wired.com/2017/04/hackers-emptying-atms-drill-15-worth-gear/


Microsoft says it's blocking Windows 7, 8 patches on latest AMD, Intel chips

Gabe Goldberg <gabe@gabegold.com>
Tue, 4 Apr 2017 22:22:16 -0400
Microsoft hasn't altered its earlier position, but it all seems a little
harsh.

http://www.pcworld.com/article/3181814/windows/microsoft-says-its-blocking-windows-7-8-patches-on-latest-amd-intel-chips.html


How Garadget Avenged a One-Star Review With Digital Sabotage (The Atlantic)

Monty Solomon <monty@roscom.com>
Thu, 6 Apr 2017 00:34:00 -0400
https://www.theatlantic.com/technology/archive/2017/04/garadget-sabotage/521937/


Another sex toy trivially hacked

Henry Baker <hbaker1@pipeline.com>
Tue, 04 Apr 2017 09:09:20 -0700
FYI—No, this isn't another April 1st joke or a SNL skit, because you just
can't make this stuff up.

"the early version of the Sky Viper [quadcopter drone] cam control app was
partly written by the same guys who wrote the dildo app code"

(Follow the link to see the console dumps and code snippets.)

https://www.pentestpartners.com/blog/vulnerable-wi-fi-dildo-camera-endoscope-yes-really/

Blog: Internet Of Things
Vulnerable Wi-Fi dildo camera endoscope.  Yes really
Beau du Jour 03 Apr 2017

Sometimes, our jaws hit the floor.  We see some pretty bad things in IoT
security, but this has to take the biscuit.  After the WeVibe lawsuit and
settlement, we started looking at the security of IoT sex toys again.

A few questions:

* Is there any reason a vibrator should also be a Wi-Fi access point?
* What about a vibrator which has an endoscope camera in the end of it?
* Should that vibrator also contain hidden functionality to connect itself
  to Skype?
* To save videos automatically to a network file share?
* Or send pictures in emails?
* What about if it has code injection in its web interface?

Well, that's the Svakom Siime Eye, a vibrator endoscope.  Yes, this thing
exists.

It is a pretty normal, slightly awkwardly-shaped vibrator with a camera in
the end.  It costs $250.  But, more relevant than the novelty/enjoyment
value of the product and its price, is what it's running, how we hacked it,
and why it's an interesting case of another IoT device produced without much
care or attention.

First Impressions

The Siime Eye normal use-case is in conjunction with an iPhone or Android
app.  You turn it on, connect to its AP (SSID "Siime Eye") with the default
password ("88888888"), open the app, then 'insert' it.  The app itself is
limited: You can view the live video stream, take pictures or videos and
save them to your device.  Everything you'd expect from a camera/vibrator, I
guess.

The Android app looks a bit like this:

With names like "wingedcamlib" and "skyviper", it looks a lot like libraries
in here were written with drones in mind.

We had a chat with the guys at Sky Viper (who make awesome drone cameras
BTW) who were as surprised as us to find their brand name in mobile app code
that runs an IoT dildo.  They suspect that the early version of the Sky
Viper cam control app was partly written by the same guys who wrote the
dildo app code.

That's not everything we can get out of the app though: The "com.SiimeEye"
source includes some hard-coded credentials, and a hard-coded IP address and
port.

There's an account called "admin", with a blank password.

On connecting to the Siime Eye AP with a laptop, we can try the server at
192.168.1.1:80.  An authentication box pops up, prompting for a username and
password.

It looks a lot like Basic authentication, and the admin:[blank] credentials
work.

So, it's trivial to connect to the AP and auth to the web interface.

Remember, the credentials are hard-coded in the official app, so any user
wanting to use the Siime Eye the official way will never change these
credentials.  If you can get onto the wireless AP, you'll have instant
access to everything on this web application.  It allows multiple concurrent
connections too, without any fuss at all.

THAT WEB APP SERVES THE VIDEO FROM THE CAMERA!  OMG!

Oh, and being a Wi-Fi AP means you can find users too...

This part surprised us the most—using Wi-Fi is logical, given the
bandwidth required to stream video, but most IoT devices would be configured
to operate as a Wi-Fi client, not an access point.  This choice was odd.

Geo-locating wireless vibrator users

Under normal use, the wireless AP name is also static.  That means we can
query a wardriving site like wigle.net, and find locations where a "Siime
Eye" might be.  Here's one seen in Tokyo:

That's bad enough, but what else could we do?  Could we get a root shell and
persistence?

Software

The web application is designed for administering a much more
general-purpose camera, one attached to a drone, for example.  We can do a
lot more here than the mobile app allows us to do.

There's some NFS settings, motion detection settings, and much more.  As we
often see in embedded device web interfaces, all settings requests get
processed by an array of .cgi files.  A lot of requests to change settings
are sent to /set_params.cgi.  All it does is returns JSON data indicating
success or failure.  Its sibling file, /get_params.cgi, sends back a lot of
configuration data in the response if you send it a GET request.  This
includes parameters like "skype_pwd", "smtp_pwd", "ddns_pwd".  From that, we
can assume that there's functionality in the Siime Eye to send emails,
change DNS settings, and even add a Skype account.

A typical response from one of the more banal .cgi files looks like this:

It seems like it's got a permissive Cross-Origin Resource Sharing (CORS)
policy, as it sends back the "Access-Control-Allow-Origin" header with a
wildcard value.  In theory, this would let us, or any browser which has
access to this web application, read the contents of any response from the
server.  The facility to read the response from another website is usually
restricted by browsers, and is an integral part of the "Same Origin Policy"
(SOP).  It's a restriction which means that malicious websites can't just
arbitrarily read your bank balance.

Ideally, the SOP also means that an arbitrary site can't see and
subsequently siphon off your IP camera video stream.  But if a server
specifies the "Access-Control-Allow-Origin" header with a wildcard value,
anyone from any website can read the response.  It makes the SOP useless.

So, I wrote a quick piece of JavaScript using XMLHttpRequest calls to try to
siphon data off the device.  However, weirdly, the browser kept complaining
about us breaking the SOP.  That wasn't what I was expecting; it required
some investigation.

After some digging, I found out the problem.  It turns out one of the
idiosyncrasies of CORS with XHR is that a pre-flight request with the
OPTIONS header is sent first, expecting the Access-Control-Allow-Origin
header in return.  But, the Siime Eye interprets OPTIONS as a RTSP request
and we get a standard RTSP response.

So you can't siphon data off it that way because the browser thinks you're
breaking the SOP; it's not getting the response it expects.  It also seems
that the RTSP protocol is running out of port 80 as well.

All the .cgi files, however, do allow you to specify a JSONP callback in
every request, which means SOP is still useless.  JSONP lets you specify a
variable name, import the resulting JSON data as a script, and use it like
any other JSON data (https://en.wikipedia.org/wiki/JSONP).

So I wrote a small PoC to dump a load of information from the device using
JSONP, including a list of local Wi-Fi networks it can see, and the video
stream.  The video stream is "protected", in that you have to negotiate a
token before you can view it.  But using JSONP still means we can siphon it
off, with very little hassle.  You can see my code here.

https://github.com/pentestpartners/siime_root

But, that can't be everything that's wrong with this.  Time to start
Googling.

Hidden services

There wasn't anything too damning turning up just from some cursory poking
at the web interface.  So, after some light googling of some .cgi filenames,
I came across the Reecam developer documentation
(http://wiki.reecam.cn/CGI/Params).

Every .cgi file I came across on the Siime Eye, seemed to be documented on
the Reecam site.  The hardware MAC address points us towards Shenzhen Reecam
Tech Ltd.  It's pretty safe to say the software running on the Siime Eye was
developed by them.

I wanted to find the firmware, to get a sense of what was actually happening
in the background.  At this point I only had port 80 open, with a slightly
ropey but relatively robust-looking web interface.  I trawled through lots
of developer info on their site but, despite a lot of digging, I couldn't
actually find the firmware anywhere.

However, one parameter documented on the site, which I didn't come across
while initially testing the web interface was "telnetd".  Browsing to the
following link restarted the Siime Eye:

http://192.168.40.17/set_params.cgi?telnetd=1&save=1&reboot=1

When it came back up, telnet was available.  This seems like an easy win.
Default Mirai credentials and we're in, right?  Unfortunately it wasn't so
simple.

After hitting it with a wordlist for way too long, I gave up.  Nothing
seemed to be working, and there were no clues online about what the password
might be.

So, I had no firmware, no shell, and only a minor web interface issue.  The
next step had to be to dismantle it.

Hardware

The Siime runs off a Ralink RT5350F WiSoC which has a little MIPS processor
in it.  It's often used in things like Wi-Fi extenders, and it's relatively
robust.  It's also got Winbond W9825G6JH-6 SDRAM and a Winbond 25Q64FVSIG
flash chip, which holds the filesystem.

It also has some handy exposed UART pads, which are easy to clip onto.  I
connected with a BusPirate, trial and error'd the baud rate to 57600, and
got a nice stream of useless debug info.  I also got the same impenetrable
telnet login prompt, and a pretty restrictive uBoot shell.

No easy-wins here either.  I decided it was worth trying to dump the
firmware.  With some cheap eBay clips, a BusPirate, flashrom, and a Stanley
knife (to whittle down the cheap clips so they wouldn't nudge each other off
the chip), I managed to get a read off the Winbond 25Q64FVSIG chip.

The read took about 30mins, and gave a nice solid blob of firmware, which I
then binwalk'd out to a proper filesystem.

It was a Linux filesystem, predictably.  But there was no /etc/passwd, not
/etc/shadow; and only traces of an assumedly unused boot script which
attempted to load parameters from (nonexistent) NVRAM.  Lots of red herrings
and leftover scripts from previous incarnations of the Reecam firmware.

What I needed at this point was some sense of what was happening in the
system while it was running.  Rather than just indiscriminately grep
everything "just in case", I wanted a more distilled sense of the system; I
still needed a shell.

A Hybrid Approach

We left the laptop clipped onto the UART, and started probing the web
interface again.  This time, I noticed small debug messages from the web
application being directed to the UART stream.  It looked a lot like stderr
and stdout might just be echoed out for debugging purposes.

I returned to the NFS settings page.  "How else can you set up a Network
File Share other than by sending unsanitised parameters directly to the UNIX
'mount' command?", I thought.

A few minutes later, I found a command injection point, with all stdout and
stderr output getting sent to the UART stream on my other laptop.

Sending "192.168.1.1; ls -al; echo" and "192.168.1.1; cat /etc/passwd; echo"
as the "HOST/IP" parameter in the NFS settings resulted in mount errors, a
listing of the root filesystem and the contents of /etc/passwd.

Cracking the descrypt hash didn't go very well with a wordlist and light
brute-forcing.  But, as the web application was running as root, I wrote
myself into /etc/passwd as another root user and logged in over telnet.

In the end, cracking the hash wasn't even needed.  I checked out the running
processes and honed in on some custom system binaries: /bin/reecam and
/bin/camera.

Running strings on /bin/camera from the firmware dumped earlier, and
grepping for "root" spat out the hardcoded telnet password.

It's the slightly—but not entirely—secure: reecam4debug.

>From here's it's plain sailing.  We've got complete control over every
 inbuilt function in the Siime Eye, easy access to the video stream, a root
 shell and persistence on a dildo.

Video overview

http://www.youtube.com/watch?v=NdfD4Pod9ho

Conclusion

If there's no reason for a user to access relatively complex functionality
of a device, then there's no reason to expose it.  It's just too easy for an
attacker to leverage official, inbuilt functionality and the web application
weaknesses.

In this case, overexposure of system services means we could write a rogue
application, compel a user to connect our app to the device using the
default credentials, and then use the already-inbuilt functionality to
perform unsolicited actions on the device.  If we could get a user to
connect their device to their home Wi-Fi, we (or any website loaded within
the user's home network, in a JavaScript drive-by) could siphon all video
data, Wi-Fi passwords, and a list of local networks off it and send it
somewhere unsolicited.

Even without all that effort, if we can get anywhere near a Siime Eye and
crack into the Wi-Fi AP with a (most likely) weak or default password, we
can almost immediately get a root shell and a video stream.

If you're a user, change the Wi-Fi password to something complex and
long. And/or, try to get a response from Svakom—I didn't have much luck.
Disclosure timeline

24/12/2016—Svakom Informed about web interface issues.  No response.

09/01/2017—Follow-up email sent to ask for some kind of response.  No
  response.

09/02/2017—Svakon informed of further code injection issues & intention
  to write a blog post.  No response.

Since there was no response at all after three attempts at contact, the
decision was made to publish.


$14M Initiative to Fight Fake News Includes Facebook, Mozilla (PCMag)

"Dave Farber" <farber@gmail.com>
Tue, 4 Apr 2017 13:55:10 -0400
PCMag.com
http://www.pcmag.com/news/352820/14m-initiative-to-fight-fake-news-includes-facebook-mozill?utm_source=email&utm_campaign=whatsnewnow=utm_medium=title


Hate speech and fake news—follow the money!

Lauren Weinstein <lauren@vortex.com>
Tue, 4 Apr 2017 10:57:55 -0700
NNSquad
https://plus.google.com/+LaurenWeinstein/posts/HLdV23SLAaN

I am convinced that the massive rise in Internet hate speech—including on
YouTube in continuing conflict with Google's own terms of service—has
been largely driven by ad network-based monetization systems. We made hate
speech (and fake news) into profit centers. If we cut off the flow of income
to these sickies on our platforms, we'll be doing humanity a great
service. The hatemongers are of course still free to build their own
distribution platforms and obtain funding from their own minions—away
from decent people. The first amendment only applies to government actions
against speech, not to private/corporate actions to stuff these vile animals
back into their cages.


Fake News Publishers Are Still Earning Money From Major Ad Networks (Buzzfeed)

Lauren Weinstein <lauren@vortex.com>
Tue, 4 Apr 2017 08:59:02 -0700
NNSquad
https://www.buzzfeed.com/craigsilverman/fake-news-real-ads?utm_term=.mja7QVeKdG#.enaOGJNbMZ

  More than 60 websites publishing fake news are earning revenue from
  advertising networks and most of them are working with major networks such
  as Revcontent, Google AdSense, and Content.ad, according to a review by
  BuzzFeed News.  An additional analysis, conducted in partnership with a
  co-investigator on of the forthcoming project A Field Guide to Fake News,
  found several cases where fake news sites that were kicked out of one
  network simply moved to another in order to continue earning money. It
  shows that in spite of calls for the digital ad industry to crack down on
  fake news and fraud in its ecosystem, fake news publishers continue to
  find ways to earn money from major advertising networks.  The research
  also reveals that content-recommendation ad units, which provide ads made
  to look like real news headlines, were by far the most common ad format on
  the sites reviewed. But banner ads are still a factor: BuzzFeed News was
  served an ad for the Gap right next to a fabricated story about a sex
  offender pretending to be a woman in order to enter a washroom, and a
  false story about the pope.


Re: UK government says Apple cannot get away with encryption (RISKS-30.20)

Chris Drewe <e767pmk@yahoo.co.uk>
Tue, 04 Apr 2017 22:04:37 +0100
The irony here is that in countries with oppressive regimes, Internet
companies are praised for allowing people to communicate in secret to
maintain some degree of freedom and strike a blow against totalitarianism,
while in democratic Western countries Internet companies are lambasted for
allowing people to communicate in secret and thus threaten our freedom and
national security.

As ever, there's no shortage of impractical ideas, such as proposals to make
it a serious criminal offence to fail to decrypt an encrypted file or
message when demanded by the authorities (yeah, right).  While lots of
people seem to think that governments can solve any problem by passing laws,
there's the small matter that many of the companies and servers involved are
outside the UK, so either we'd have to get other countries to agree to
similar laws, or have a Chinese-style national firewall.


Re: Risks from falsified Data (RISKS-30.20,21)

"Robert P. Schaefer" <rps@mit.edu>
Tue, 4 Apr 2017 14:06:16 +0000
And of course, cryptology, with a weakened random number generator library:

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

Please report problems with the web pages to the maintainer