[aerogear-dev] Beyond SimplePush's simplicity

[JR Conlin]

Heh, even that can be tricky. Generally, people will get encryption
wrong. Plus, the encrypted data block will (at least ideally) be an
indecipherable bunch of random bytes. That means that the server should
not be able to read it, or confirm that the data was actually encrypted.
Sadly, this means that someone could "encrypt" with ROT13 and the server
couldn't really verify. Then there's the problem of key distribution,
which is an absolute nightmare to do properly.

The reason that we have version (and I'll be honest, I kinda fought that
for a pretty long time too) is because it's the very least amount of
meaningful data that can be exchanged between two parties via a third
without too many issues.

I'm not a lawyer, nor do I play one on TV, nor do I even pretend to
understand international law, but I can tell you that various global
government agencies can require networks to provide anything from data
dumps to "pen registry" devices (a device that records all data
exchanges), often under orders to not disclose the fact that these
devices have occurred. For some sites, that's just the cost of doing
business, but also explains why the paranoid prefer sites like SpiderOak
(which does a fantastic job making damn sure that they can't read your
data at all).

I'll also be honest, for Mozilla, not handling data is VERY cost
effective. Not dealing with data makes things scale amazingly well for
astoundingly little, so we're doubly inclined to make data "someone
else's problem".

Ultimately, though, our customers are the ones that make the decision
about whether or not Data is worth all this. They've pretty much said
that they want data. We're trying  to balance that within the WebPush
protocol, and by making data optional and disposable within SimplePush. 
(Again, nothing 100% there, we're still debating it internally.) It's
also possible to do secure data exchange between parties using zero
knowledge key exchanges via things like JPAKE, but customer acceptance
of that sort of thing can be difficult.

Still, more brains == better things, so if there's a brilliant, as yet
undiscovered solution out there, it's definitely worth thinking about.

On 2014/10/20 7:18 AM, Lukáš Fryč wrote:
> You are right, guys, with storing the messages, we are hitting the
> security implications that I didn't think about.
>
> Right now they have to be handled by third-party providers, but in
> this case, we would need to encrypt data, pass certification, etc,
> that is rather a target for internal infrastructure than a cloud service.
>
> We could probably come with an encryption model that would allow only
> given SimplePush retrieve the message, involving client's private key
> and version number, but question is whether that is worth the trouble
> and complexity.
>
> On Mon, Oct 20, 2014 at 4:03 PM, jr conlin <jrconlin at gmail.com
> <mailto:jrconlin at gmail.com>> wrote:
>
>     FYI, Officially, the predecessor for SimplePush will be WebPush,
>     https://datatracker.ietf.org/wg/webpush/charter/
>     which runs on top of HTTP2
>     http://http2.github.io/
>
>     Unofficially, data is kind of a pain in the patootie, but obviously
>     really handy to have. There are security and privacy issues a-plenty
>     when dealing with data storage (HIPPA & subpoenas come to mind in the
>     US.) Internally, we're kicking around the idea of allowing data,
>     but not
>     allowing storage, (so a device would only get data if it was actively
>     connected. If it was offline, it would only get the version number
>     update when it reconnected).
>
>     I'm also interested in what y'all come up with.
>
>     On 10/20/2014 4:58 AM, Lukáš Fryč wrote:
>     > Hey guys,
>     >
>     > I'm working on a demo of UPS pushing to iOS, Android, Windows,
>     as well
>     > as Firefox OS using our Cordova plugin.
>     >
>     > But as you know, with FFOS it is not that simple - since SimplePush
>     > protocol allows to transfer just incremental versions, we are
>     not able
>     > to deliver any interesting message.
>     >
>     > UnifiedPush Server could be a correct place where we unify and
>     shield
>     > our users from this limitation:
>     >
>     >
>     > my idea is storing the message on UPS under the SimplePush endpoint
>     > URL. Once the message with version reaches the client, he would
>     > contact UPS to retrieve this message under a key ( pushEndpoint,
>     > version ).
>     >
>     > The messages could have default built-in TTL to allow periodic
>     cleanup.
>     >
>     > What do you think?
>     >
>     >
>     > Cheers,
>     >
>     > ~ Lukas
>     >
>     >
>     > _______________________________________________
>     > aerogear-dev mailing list
>     > aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>     _______________________________________________
>     aerogear-dev mailing list
>     aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141020/7a31fa5e/attachment.html