End-to-End Encryption | Hacker News Reader

End-to-End Encryption

blog.pushbullet.com

46 pointsDaveWalk11 comments

I was excited about this for a moment, since I was a big fan of Pushbullet before they decided to "evolve" into a messaging app.

I used it simply to send links between my phone/browser and to occasionally send a link via SMS. I would have happily paid for this functionality.

In a recent update, it became impossible to send SMS from the browser without also syncing your entire SMS history (images included) to their server without end-to-end encryption, so I nuked my account.

I just signed up again to test this out, and I didn't get very far before I realized they are still storing all my MMS images on their server un-encrypted.

Here's one from my SMS history: https://dl.pushbulletusercontent.com/KWevdTT0b4Fe92yukWHDKlo...

I just "cleared my history" and deleted my account and the link still works, so we'll have to see how long my data stays on their server. I'm going to assume indefinitely :(.

Note that when a service says "we have now enabled [feature X] for ... SMS", without also explicitly specifying MMS, then they probably haven't done MMS.

Although SMS and MMS are presented similarly on devices, they're actually two wildly separate technologies and that difference usually bubbles up into how gateways handle them, translating to "update SMS handling" and "update MMS handling" usually being relegated to two different sprints.

Seems like semantics, since MMS are synced by turning on "SMS Sync" in their app. I'm fairly technologically savvy, and I made the assumption anything going through the "SMS Sync" would be encrypted.

I got burnt by that and now all of the photos in my MMS, including some that the people who sent would prefer not ever be public, are unencrypted on a server somewhere... probably in perpetuity.

That's on me, I took the risk... just wanted to inform others.

I definitely won't be trying PB again.

Who exactly is getting behind using a closed-source service where a main developer can't understand the benefits of end-to-encryption, nor how it actually works? -> https://www.reddit.com/r/Android/comments/3bplym/hey_randroi...

Same as WhatsApp+Axolotl. Is it implemented properly? Is it flawed on purpose?

iMessage? What's stopping Apple from simply inserting new keys? They completely control the infrastructure and implementation.

Both a very big false sense of security, as is PushBullet's E2E.

To note is that 1) the encryption is not set by default, 2) it is closed source, and 3) it's a VC-backed company without an option for users to pay for the service.

Reddit thread https://www.reddit.com/r/Android/comments/3gl2yj

NO encryption for custom data send to yourself or to others! Read the blogpost carefully.

Pushbullet now supports end-to-end encryption for Notification Mirroring, Universal copy & paste, and SMS.

An interesting note, thanks. I thought they would start with the most popular use cases...but clearly they support others -- pushing URLs, files, pictures, etc.

So it's: Password -> KDF -> Key+Plaintext -> AES-CGM.

Better than nothing, but just that isn't very secure. It's not safe to use the same key indefinitely.

It's good to see Pushbullet release such an important feature as part of the standard product. I've seen many other products stuff encryption and other important security features into the premium/enterprise package under a "consumers don't care about this" mentality...

Yes, and according to the reddit post downthread, the dev came around from not understanding the utility of encrypting everything to deploying it across the app. I wonder if that has something to do with it not being behind a "premium" package...

Reply on news.ycombinator.com