Friday, May 4, 2018

Apple: My request for all the data it had on me was eye-opening →

Jefferson Graham for USA Today:

It took eight days for my data to arrive from Apple, from a European office that is handling the privacy requests. After making the request, the iPhone maker first asked for my street address, phone number, the serial number of the iPhone, and other personal information before releasing it. This compares to Google and Facebook’s data dump. They asked no questions, and the results arrived swiftly-Facebook within minutes, and Google within hours.

Apple’s file on me took longer but was lightweight – a testimony, according to the company, of how little it collects and stores on its individual users.

And:

What Apple didn’t share with me is all the questions I’ve asked the Siri personal digital assistant, queries it gathers to make the artificial intelligence smarter.

The company says the data wouldn’t tell an individual user anything, since it’s not associated with him or her. Your Siri requests – “Show me how to get to PF Chang’s,” or “What year was Steve Jobs born?” go back to Apple – but it uses a random identifier to mask your identity. So a Siri search for the closest Chipotle restaurant will only tell Apple that a user requested the data, but not associate it with me.

There are people out there who hate Apple products and services, but damn if their privacy stance isn’t world-leading. There’s absolutely no debating that fact.

Monday, April 30, 2018

Privacy Policy updates are trendy

There’s a silver lining in the aftermath of the Facebook/Cambridge Analytica fiasco: everyone and their mother are updating privacy policies right now. Go ahead, check your inbox; I bet you have quite a few. Maybe it’s a bit marketing fluff, but the optimist in me hopes there is good intention.

Just in the past few weeks, I’ve received emails in regards to privacy policy updates from Twitter, Periscope, Roku, Plex, Airbnb, and Etsy. In fact, the following exchange I had with Matt Birchler from Birchtree in relation to a privacy policy update from BookBub prompted me to write this post.

Privacy is becoming increasingly more of a common thread amongst the general public, and is therefore a trendy thing to support. But that’s how things really get done on the Internet though, isn’t it? Hopefully the trend will help enable real change across Internet services and companies, like the encryption of traffic end-to-end. Hell, even the thought of insecure traffic should be a distant memory in the next few years.

One thing is for sure: companies can no longer cry innocence or näiveté for failing to protect the data of their users. Let’s hold them to it.

Friday, April 20, 2018

Google’s support of RCS without end-to-end encryption is irresponsible

Dieter Bohn from The Verge has an exclusive look at Google’s upcoming ‘Chat’ app and its use of Rich Communication Services (RCS). Together, they are the company’s latest attempt to solve the dumpster fire that is text messaging on Android.

RCS is a protocol backed by wireless carriers, and Google is the latest enabler. Here’s why I think it’s irresponsible.

Chat app and Rich Communication Services

Dieter:

Now, the company is doing something different. Instead of bringing a better app to the table, it’s trying to change the rules of the texting game, on a global scale. Google has been quietly corralling every major cellphone carrier on the planet into adopting technology to replace SMS. It’s going to be called “Chat,” and it’s based on a standard called the “Universal Profile for Rich Communication Services.” SMS is the default that everybody has to fall back to, and so Google’s goal is to make that default texting experience on an Android phone as good as other modern messaging apps.

Maybe the app will have more feature parity with iMessage, and that would be great for Android users. But what good is it when you factor in the following?

  1. The traffic path is no different than SMS. It goes phone > carrier > phone. We all know how much carriers love our data, and how easily it can be accessed or even subpoenaed.
  2. Also like SMS, RCS traffic is not encrypted end-to-end.

The above points are the largest problems with all of this. In a day and age where data breaches and the selling or mishandling of personal data are sadly commonplace, unencrypted traffic is simply irresponsible. Public awareness of security and privacy are more at the forefront and can only increase.

Why not replicate iMessage?

As Dieter talks about, Google also has self-imposed limitations because of Android’s openness. You see, they won’t go all in on a purely in-house messaging service (like iMessage), because every text would have to route through them. In essence, Google isn’t empowered to replicate iMessage because they share the Android ecosystem. Whereas Apple is the Apple ecosystem.

One of the major complaints about Apple is how closed off they are. Apparent here, the benefit is tighter integration within their ecosystem of apps, services, and hardware.

Dieter also thinks Apple will adopt RCS, but I don’t see them backing it for a couple reasons:

  1. Aside from lackluster encryption, it competes too directly with iMessage on a feature level.
  2. iMessage is a huge reason people don’t switch to Android.
  3. The entire protocol would have to be encrypted end-to-end and supported by all other manufacturers and their messaging apps. Sure, Apple supports (unencrypted) SMS right now, but only out of necessity and precedence.

I don’t see Apple replacing SMS or introducing RCS simply for the sake of iMessage-like features without the security.

If anything, this further cements iMessage as the texting king.

Update for clarity: my case is essentially for end-to-end encryption, so I made a couple small edits to make it clearer.

Friday, April 13, 2018

Chrome and Firefox will support a new standard for password-free logins →

Russel Brandom for The Verge:

Web browsers are building a new way for you to log in, announced today by the W3C and FIDO Alliance standards bodies. Called WebAuthn, the new open standard is currently supported in the latest version of Firefox, and will be supported in upcoming versions of Chrome and Edge slated for release in the next few months.

WebAuthn has been working its way toward W3C approval for nearly two years, but today marks the first major announcement of browser support. Apple has not commented on Safari support for WebAuthn, although the company is part of the working group that developed the standard.

Today’s announcement the latest step in a years-long effort to move users away from passwords and toward more secure login methods like biometrics and USB tokens. The system is already in place on major services like Google and Facebook, where you can log in using a Yubikey token built to the FIDO standard.

I’m beginning to hate passwords, even with password managers. I look forward to the day in which authentication works just like magic (securely, of course). This sounds like a good step.

Wednesday, January 10, 2018

High Sierra App Store preferences can be accessed with any password →

Joe Rossignol for MacRumors:

A bug report submitted on Open Radar this week reveals a security vulnerability in the current version of macOS High Sierra that allows the App Store menu in System Preferences to be unlocked with any password.

And:

As mentioned in the radar, System Preferences does not accept an incorrect password with a non-administrator account. We also weren’t able to unlock any other System Preferences menus with an incorrect password.

We’re unable to reproduce the issue on the third or fourth betas of macOS High Sierra 10.13.3, suggesting Apple has fixed the security vulnerability in the upcoming release. However, the update currently remains in testing.

Apple has really been dropping the ball with these breaches lately. Though App Store preferences are not as concerning as say, access to the whole system, the reality is still unacceptable.

Wednesday, November 29, 2017

Apple releases major security fix for macOS High Sierra →

Apple has released macOS High Sierra Security Update 2017-001 to address the embarrassing security hole discovered yesterday. Funnily referred to as # IAmRoot on Twitter, the exploit allowed anyone to obtain the highest level of access to your Mac by using the built-in root account without a password. Most vulnerable to physical access, others on Twitter discovered it allowed for remote exploitation as well.

If you’re running a Mac with High Sierra, update immiediately via the App Store.

Apple released the following statement:

Security is a top priority for every Apple product, and regrettably we stumbled with this release of macOS.

When our security engineers became aware of the issue Tuesday afternoon, we immediately began working on an update that closes the security hole. This morning, as of 8 a.m., the update is available for download, and starting later today it will be automatically installed on all systems running the latest version (10.13.1) of macOS High Sierra.

We greatly regret this error and we apologize to all Mac users, both for releasing with this vulnerability and for the concern it has caused. Our customers deserve better. We are auditing our development processes to help prevent this from happening again.

This is an insanely-quick response from Apple, and that is fantastic. However, this never, ever should have happened to begin with. There’s no other word for it than ‘embarrassing’. An increasingly large amount of Apple’s value proposition is their stock as the privacy and security company. After a while, issues like these can begin to hurt their credibility.

I think it’s clear Apple really needs to institute a bug bounty program for Mac, like they have done for iOS. The Mac product line as a whole has been seen as neglected by pros over the past couple years, so huge missteps like this only add insult to injury. If Apple doesn’t want folks to think of Mac as the red-headed step-child, they need to start doing a much better job.

Sunday, November 5, 2017

Fake WhatsApp on Google Play Store downloaded by over one million →

Swati Khandelwal for The Hacker News:

Yesterday some users spotted a fake version of the most popular WhatsApp messaging app for Android on the official Google Play Store that has already tricked more than one million users into downloading it.

The app maker added a Unicode character space after the actual WhatsApp Inc. name, which in computer code reads WhatsApp+Inc%C2%A0.

However, this hidden character space at the end of the WhatsApp Inc. would be easily invisible to an average Android user browsing Google Play Store, allowing this dodgy version of the app to masquerade as a product of WhatsApp Inc.

According to Redditors, who first spotted this fake app on Friday, the app was not a chat app; instead, it served Android users with advertisements to download other apps.

What a total shit show. Google removed the app from the Play Store, but not before it was downloaded by one million people. Think about how damaging this could be to the WhatsApp brand. I also wonder how vulnerable this makes Google to a lawsuit.

Google has touted advanced malware scanning as a feature of Android 8.0 Oreo, dubbed Google Play Protect. That’s nice and all, but this protection should be baked in to the Play Store for everyone, not only for operating systems with a .2% market share. Turns out the often-complained about walled garden that is Apple’s App Store has its benefits.

Monday, October 16, 2017

Why you shouldn’t worry about the Krack WPA2 flaw →

Kevin Beaumont for Double Pulsar:

So there’s a new Wi-Fi attack. In the media it is being presented as a flaw in WPA protocol which isn’t fixable. This isn’t true.

  • It is patchable, both client and server (Wi-Fi) side.
  • Linux patches are available now. Linux distributions should have it very shortly.
  • The attack realistically doesn’t work against Windows or iOS devices. The Group vuln is there, but it’s not near enough to actually do anything of interest.
  • There is currently no publicly available code out there to attack this in the real world — you would need an incredibly high skill set and to be at the Wi-Fi base station to attack this.
  • Android is the issue, which is why the research paper concentrates on it. The issue with Android is people largely don’t patch.

Good points here. As a matter of fact, I patched my Ubiquiti UniFi access points this morning to protect against the vulnerability. Patches will trickle down to consumer devices in due time, I’m sure.