Facebook plans to integrate its messaging services on Instagram, WhatsApp and Facebook Messenger.
While all three will remain stand-alone apps, at a much deeper level they will be linked so messages can travel between the different services.
Facebook told the BBC it was at the start of a “long process”.
The plan was first reported in the New York Times and is believed to be a personal project of Facebook founder Mark Zuckerberg.
Once complete, the merger would mean that a Facebook user could communicate directly with someone who only has a WhatsApp account. This is currently impossible as the applications
have no common core.
The work to merge the three elements has already begun, reported the NYT, and is expected to be completed by the end of 2019 or early next year.
…
Facebook-looking-dodgy in the news again this week (previously) with the news that they plan to integrate Instagram and WhatsApp
into their central platform. They’re selling the upsides of this, such as that Facebook and WhatsApp users will be able to communicate with one another without switching to a different
tool, but privacy advocates are
understandably concerned: compared to Facebook, WhatsApp provides a reasonable level of anonymity. It also seems likely that this move may be an effort to preempt antitrust suits
forcing Facebook’s property portfolio to be kept separate.
But even without those concerns, there are smaller but just-as-real, more-insidious privacy risks from this integration. With a very minor change to their terms and conditions about the
use of the WhatsApp app Facebook can start performing even more-sophisticated big-data mining on the types of interpersonal relationships that they’re known to enjoy (let’s not forget
that this is the company whose app will, left-unchecked, mine your mobile phone book to find friends-in-common that you have with other people, even if that friend-in-common doesn’t
use Facebook!). With WhatsApp’s treasure trove of metadata, Facebook can determine who you talk to and, from where, and with what frequency: by technical necessity, none of this
metadata is protected by WhatsApp’s end-to-end encryption. Similarly, they can determine what “groups” you participate in. This easily supports the “shadow profiles” they maintain which
tell them far more about your life and interests than your mere Facebook profile alone does.
I for one will be watching WhatsApp with care and dropping it if it looks likely to “turn evil”. It’s not as though there aren’t (arguably better) alternatives, such as Signal (which I already use as my primary mobile text messaging system) and Riot.
An open source checklist of resources designed to improve your online privacy and security. Check things off to keep track as you go.
…
I’m pretty impressed with this resource. It’s a little US-centric and I would have put the suggestions into a different order, but many of the ideas on it are very good and are
presented in a way that makes them accessible to a wide audience.
German chat platform Knuddels.de (“Cuddles”) has been fined €20,000 for storing user passwords in plain text (no hash at all? Come on, people, it’s 2018).
The data of Knuddels users was copied and published by malefactors in July. In September, someone emailed the company warning them that user data had been published at Pastebin (only
8,000 members affected) and Mega.nz (a much bigger breach). The company duly notified its users and the Baden-Württemberg data protection authority.
…
Interesting stuff: this German region’s equivalent of the ICO applied a fine to this app for failing to hash
passwords, describing them as personal information that was inadequately protected following their theft. That’s interesting because it sets a German, and to a lesser extend a European,
precedent that plaintext passwords can be considered personal information and therefore allowing the (significant) weight of the GDPR to be applied to their misuse.
Did you install EFF’s brilliant Privacy Badger or any other smart HTTP Cookie management tool? Or did you simply pick the privacy preference in your browser that ignores
all third-party cookies? Did many websites you visit annoy you with permission-to-use-cookies pop-ups because of European legislation?
Guess what, it’s all been useless.
Hamburg university researchers have examined closely how web browsers implement
so-called TLS session resumption and how the top million popular websites make use of that feature. They found that 80% of websites make a correct use, unsuitable for tracking
repeat visitors — just resuming an existing session within the last ten minutes.
Unfortunately though, Google is present on 80% of these websites in form of Analytics, Fonts or other third-party inclusions. And among 10% of sites that do not respect reasonable
resumption times, Google sticks out as one of the most greedy ones — it allows for a web browser to stay offline for over a day, and still be recognized as the same web browser the
next day. Considering that it is nearly impossible to surf the web without accessing some Google content, this means that Google can track all your surfing habits without any need for
HTTP Cookies!
As Facebook isn’t as pervasively present in all of the web, it went even further. It is enough for you to visit any website bearing a Like button every second day to allow Facebook to
profile you, even if you never dreamt of logging into that service. Could it be our researchers just caught these companies with their hands deep in the cookie jar (pun intended)? For how long have they been
collecting user data this way?
…
Somewhat conspiracy-theory-like take on an actual, real privacy issue: the fact that TLS makes tracking pretty easy even
without cookies. If you thought my 301-based cookieless tracking was clever, this is cleverer. And harder to detect, to boot.
For a philosopher, Helen Nissenbaum is a surprisingly active participant in shaping how we collect,
use, and protect personal data. Nissenbaum, who earned her PhD from Stanford, is a professor of information science at Cornell Tech, New York City, where she focuses on the
intersection of politics, ethics, and values in technology and digital media — the hard stuff. Her framework for understanding digital privacy has deeply influenced
real-world policy.
In addition to several books and countless papers, she’s also coauthored privacy plug-ins for web browsers including TrackMeNot, AdNauseum, and Adnostic. Nissenbaum views these pieces
of code as small efforts at rationalizing a marketplace where opaque consent agreements give consumers little bargaining power against data collectors as they extract as much
information, and value from this information, as they can. Meanwhile, these practices offer an indefinite value proposition to consumers while compromising the integrity of digital
media, social institutions, and individual security.
For over a decade, civil libertarians have been fighting government mass surveillance of innocent Americans over the Internet. We’ve just lost an important battle. On January 18,
President Trump signed the renewal of Section 702, domestic mass surveillance became effectively a permanent part of US law. Section 702 was initially passed in 2008, as an…
Do you have permission for those third-party scripts?
Enforcement of the European Union’s General Data Protection Regulation is coming very, very soon. Look busy. This regulation is not
limited to companies based in the EU—it applies to any service anywhere in the world that can be used by citizens of the EU.
…
Jeremy Keith raises some interesting points: when informed consent is required to track an individual, who is responsible for getting your users to “consent” to being
tracked with Google Analytics and similar site-spanning tools? You? Google? Nobody? I’ve spent the weekend talking through only a handful of the woolly edges of the GDPR, especially regarding the liabilities of different companies (potentially not all of which are based in the EU) who are complicit in
the collection of data on the same individuals but who have access to that data in different forms.
It’s complicated, yo. For the time being, I’m making sure that companies for which I have responsibility err on the “safe” side of any fuzzy lines, but I’m sure that others won’t.
This site maintains a table cross-referencing the most popular “secure” messaging apps (WhatsApp, Signal, Skype etc.) against their security features, so that you can make an informed
decision.
The tl;dr is, of course, what I’ve been saying all along: use Signal! (at least until Riot is more
mature…)
hen I was very young, before I was on the internet — even before the internet was really a thing you could “go on” — I would dial into BBSs (bulletin board systems). BBSs were kind of
like private, micro-internets that people set up in their
houses. You had to use a dial-up modem to connect to them, and the people who were in charge of these networks (usually just some random technology enthusiast) could shut them off or
boot you at any time. I got booted a lot when I was kid, because I was curious and annoying and all the things I am today but way less savvy about it. Once a guy who ran a BBS called
my house to complain to my mother that her son had been snooping around in places he wasn’t supposed to go — I don’t remember what I was after, but I’m sure he had a very good reason
to be angry.
Here’s why I mention this: What I was doing online, in a virtual space, had real-world repercussions. It was real. What I was doing was real. That guy who complained about me was
real. And I realize now that I never treated or experienced the internet like some other thing — as if the physical world were “real” and what happened on the internet was something
less. That was where my real life was. That’s where I was, as a person.
The internet was the most real thing to me that I’d ever had in my life, before my wife and my daughter; my job, my house, my things. Its existence helped to form the basis of my
worldview, my politics, my obsessions. It gave me tools to talk and create in ways that would have been impossible in another age. But it was never not reality. I wish the rest of the
world had always seen it this way…
In the speech in which she committed to keep governing despite calls to stand down, the prime minister made reference to extending powers for the security services. Those powers –
which include regulation of the internet and forcing internet companies to let spies read everyone’s private communications – were a key part of the Conservative campaign, which failed to
score a majority in the House of Commons.
As you’re no-doubt aware, Home Secretary Theresa May is probably going to get her way with her “snooper’s
charter” by capitalising on events in Paris (even though that makes no sense), and before long, people working for
law enforcement will be able to read your Internet usage history without so much as a warrant (or, to put it as the UN’s privacy chief put it, it’s “worse than scary”).
In a revelation that we should be thankful of as much as we’re terrified by, our government does not understand how the Internet works. And that’s why it’s really easy for
somebody with only a modicum of geekery to almost-completely hide their online activities from observation by their government and simultaneously from hackers. Here’s a device that I
built the other weekend, and below I’ll tell you how to do it yourself (and how it keeps you safe online from a variety of threats, as well as potentially giving you certain other
advantages online):
I call it “Iceland”, for reasons that will become clear later. But a more-descriptive name would be a “Raspberry Pi VPN Hotspot”. Here’s what you’ll need if you want to build one:
A Raspberry Pi Model B (or later) – you can get these from less than £30 online and it’ll come with an SD card that’ll let it boot Raspbian, which is the Linux
distribution I’ve used in my example: there’s no reason you couldn’t use another one if you’re familiar with it
A USB WiFi dongle that supports “access point” mode – I’m using an Edimax one that cost me under a fiver – but it took a little hacking to make it work – I’ve heard
that Panda and RALink dongles are easier
A subscription to a VPN with OpenVPN support and at least one endpoint outside of the UK – I’m using VyprVPN because
I have a special offer, but there are lots of cheaper options: here’s a great article about
choosing one
A basic familiarity with a *nix command line, an elementary understanding of IP networking, and a spare 20 minutes.
From here on, this post gets pretty geeky. Unless you plan on building your own little box to encrypt all of your home’s WiFi traffic until it’s well out of the UK and
close-to-impossible to link to you personally (which you should!), then you probably ought to come back to it another time.
Here’s how it’s done:
1. Plug in, boot, and install some prerequisites
Plug the WiFi dongle into a USB port and connect the Ethernet port to your Internet router. Boot your Raspberry Pi into Raspbian (as described in the helpsheet that comes with
it), and run:
If, like me, you’re using an Edimax dongle, you need to do an extra couple of steps to make it work as an access point. Skip this bit if you’re using one of the other dongles I listed
or if you know better.
Get OpenVPN configuration files from your VPN provider: often these will be available under the iOS downloads. There’ll probably be one for each available endpoint. I chose the one for
Reyjkavik, because Iceland’s got moderately sensible privacy laws and I’m pretty confident that it would take judicial oversight for British law enforcement to collaborate with
Icelandic authorities on getting a wiretap in place, which is the kind of level of privacy I’m happy with. Copy your file to /etc/openvpn/openvpn.conf and edit it: you may find that you
need to put your VPN username and password into it to make it work.
sudo service openvpn start
You can now test your VPN’s working, if you like. I suggest connecting to the awesome icanhazip.com and asking it where you are (you can use your
favourite GeoIP website to tell you what country it thinks you’re in, based on that):
curl -4 icanhazip.com
Another option would be to check with a GeoIP service directly:
curl freegeoip.net/json/
4. Set up your firewall and restart the VPN connection
Unless your VPN provider gives you DNAT (and even if they do, if you’re paranoid), you should set up a firewall to allow only outgoing connections to be established, and then restart
your VPN connection:
sudo iptables -A INPUT -i tun0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A INPUT -i tun0 -j DROP
sudo sh -c "iptables-save > /etc/iptables.nat.vpn.secure"
sudo sh -c "echo 'up iptables-restore < /etc/iptables.nat.vpn.secure' >> /etc/network/interfaces"
sudo service openvpn restart
5. Configure your WiFi hotspot
Configure bind as your DNS server, caching responses on behalf of Google’s DNS servers, or another DNS server that you trust. Alternatively, you can just configure your DHCP clients to
use Google’s DNS servers directly, but caching will probably improve your performance overall. To do this, add a forwarder to /etc/bind/named.conf.options:
forwarders {
8.8.8.8;
8.8.4.4;
};
Restart bind, and make sure it loads on boot:
sudo service bind9 restart
sudo update-rc.d bind9 enable
Edit /etc/udhcpd.conf. As a minimum, you should have a configuration along these lines (you might need to tweak your IP address assignments to fit with your local network – the “router”
and “dns” settings should be set to the IP address you’ll give to your Raspberry Pi):
start 192.168.0.2
end 192.168.0.254
interface wlan0
remaining yes
opt dns 192.168.0.1
option subnet 255.255.255.0
opt router 192.168.0.1
option lease 864000 # 10 days
Enable DHCP by uncommenting (remove the hash!) the following line in /etc/default/udhcpd:
#DHCPD_ENABLED="yes"
Set a static IP address on your Raspberry Pi in the same subnet as you configured above (but not between the start and end of the DHCP list):
sudo ifconfig wlan0 192.168.0.1
And edit your /etc/network/interfaces file to configure it to retain this on reboot (you’ll need to use tabs, not spaces, for indentation):
Right – onto hostapd, the fiddliest of the tools you’ll have to configure. Create or edit /etc/hostapd/hostapd.conf as follows, but substitute in your own SSID, hotspot password, and
channel (to minimise interference, which can slow your network down, I recommend using WiFi scanner tool on your mobile to find which channels your neighbours aren’t using, and
use one of those – you should probably avoid the channel your normal WiFi uses, too, so you don’t slow your own connection down with crosstalk):
Hook up this configuration by editing /etc/default/hostapd:
DAEMON_CONF="/etc/hostapd/hostapd.conf"
Fire up the hotspot, and make sure it runs on reboot:
sudo service hostapd start
sudo service udhcpd start
sudo update-rc.d hostapd enable
sudo update-rc.d udhcpd enable
Finally, set up NAT so that people connecting to your new hotspot are fowarded through the IP tunnel of your VPN connection:
sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
sudo sh -c "echo net.ipv4.ip_forward=1 >> /etc/sysctl.conf"
sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
sudo sh -c "iptables-save > /etc/iptables.nat.vpn.secure"
6. Give it a go!
Connect to your new WiFi hotspot, and go to your favourite GeoIP service. Or, if your VPN endpoint gives you access to geographically-limited services, give those a go (you’d be amazed
how different the Netflix catalogues are in different parts of the world). And give me a shout if you need any help or if you have any clever ideas about how this magic little box can
be improved.
MALAYSIA will not ask Google Earth to blur images of the country’s military facilities to avoid terrorist attacks. Defence Minister Datuk Seri Najib Razak said doing so would
indirectly pin-point their location anyway.
“The difference in, or lack of, pixelation of images of the military facilities compared to the surrounding areas will make it easy for visual identification.” In his written reply to
Datuk Dr James Dawos Mamit (BN-Mambong), Najib said the images were provided worldwide commercially.
Last week I was talking to Alexander Dutton about an idea that we had to implement cookie-like behaviour using browser caching. As I first mentioned last year, new laws are coming into force across Europe that will require
websites to ask for your consent before they store cookies on your computer.
Regardless of their necessity, these laws are badly-defined and ill thought-out, and there’s been a significant lack of information to support web managers in understanding and
implementing the required changes.
To illustrate one of the ambiguities in the law, I’ve implemented a tool which tracks site visitors almost as effectively as cookies (or similar technologies such as Flash Objects or
Local Storage), but which must necessarily fall into one of the larger grey areas. My tool abuses the way that “permanent” (301) HTTP redirects are cached by web browsers.
[callout][button link=”http://c301.scatmania.org/” align=”right” size=”medium” color=”green”]See Demo Site[/button]You can try out my implementation for yourself. Click on the button to
see the sample site, then close down all of your browser windows (or even restart your computer) and come back and try again: the site will recognise you and show you the same random
number as it did the first time around, as well as identifying when your first visit was.[/callout]
Here’s how it works, in brief:
A user visits the website.
The website contains a <script> tag, pointing at a URL where the user’s browser will find some Javascript.
The user’s browser requests the Javascript file.
The server generates a random unique identifier for this user.
The server uses a HTTP 301 response to tell the browser “this Javascript can be found at a different web address,” and provides an address that contains the new unique identifier.
The user’s browser requests the new document (e.g. /javascripts/tracking/123456789.js, if the user’s unique ID was 123456789).
The resulting Javascript is generated dynamically to automatically contain the ID in a variable, which can then be used for tracking purposes.
Subsequent requests to the server, even after closing the browser, skip steps 3 through 5, because the user’s browser will cache the 301 and re-use the unique web
address associated with that individual user.
Compared to conventional cookie-based tracking (e.g. Google Analytics), this approach:
Is more-fragile (clearing the cache is a more-common user operation than clearing cookies, and a “force refresh” may, in some browsers, result in a new tracking ID
being issued).
Is less-blockable using contemporary privacy tools, including the W3C’s
proposed one: it won’t be spotted by any cookie-cleaners or privacy filters that I’m aware of: it won’t penetrate incognito mode or other browser “privacy modes”, though.
Moreover, this technique falls into a slight legal grey area. It would certainly be against the spirit of the law to use this technique for tracking purposes (although it
would be trivial to implement even an advanced solution which “proxied” requests, using a database to associate conventional cookies with unique IDs, through to Google Analytics or a
similar solution). However, it’s hard to legislate against the use of HTTP 301s, which are an even more-fundamental and required part of the web than cookies are. Also, and for the same
reasons, it’s significantly harder to detect and block this technique than it is conventional tracking cookies. However, the technique is somewhat brittle and it would be necessary to
put up with a reduced “cookie lifespan” if you used it for real.
[callout][button link=”http://c301.scatmania.org/” align=”right” size=”medium” color=”green”]See Demo Site[/button] [button link=”https://gist.github.com/avapoet/5318224″ align=”right”
size=”medium” color=”orange”]Download Code[/button] Please try out the demo, or download the source code (Ruby/Sinatra) and see for yourself how this technique works.[/callout]
Note that I am not a lawyer, so I can’t make a statement about the legality (or not) of this approach to tracking. I would suspect that if you were somehow caught doing
it without the consent of your users, you’d be just as guilty as if you used a conventional approach. However, it’s certainly a technically-interesting approach that might have
applications in areas of legitimate tracking, too.
Update: The demo site is down, but I’ve update the download code link so that it still works.
This week, I was reading the new EU legislation [PDF]
which relates to, among other things, the way that websites are allowed to use HTTP cookies (and similar technologies) to track their users. The Information Commissioner’s Office has released a statement to ask website owners to review
their processes in advance of the legislation coming into effect later this month, but for those of you who like the big-print edition with pictures, here’s the short of it:
From 26th May, a website must not give you a cookie unless it’s either (a) an essential (and implied) part of the functionality of the site, or (b) you have opted-in to it.
This is a stark change from the previous “so long as you allow opt-outs, it’s okay” thinking of earlier legislation, and large organisations (you know, like the one I now work for) in particular are having to sit up and pay attention: after all, they’re the
ones that people are going to try to sue.
The legislation is surprisingly woolly on some quite important questions. Like… who has liability for ensuring that a user has opted-in to third-party cookies (e.g. Google Analytics)?
Is this up to the web site owner or to the third party? What about when a site represents companies both in and outside the EU? And so on.
…not what I was looking for: just more circular and woolly thinking. But I did find that the ICO themselves does not comply with the guidance that they themselves give. Upon
arriving at their site – and having never been asked for my consent – I quickly found myself issued with five different cookies (with lifespans of up to two years!). I checked their
privacy policy, and found a mention of the Google Analytics cookie they use, but no indication about the others (presumably they’re not only “opt-out”, but also “secret”). What gives,
guys?
Honestly: I’m tempted to assume that only this guy has the right approach. I’m all in favour of better
cookie law, but can’t we wait until after the technological side (in web browsers) is implemented before we have to fix all of our websites? Personally, I
thought that P3P policies (remember when those were all the rage?) had a
lot of potential, properly-implemented, because they genuinely put the power into the hands of the users. The specification wasn’t perfect, but if it had have been, we
wouldn’t be in the mess we are now. Perhaps it’s time to dig it up, fix it, and then somehow explain it to the politicians.