On Tue, Sep 17, 2013 at 7:48 AM, Daniel Bevenius < daniel.bevenius(a)gmail.com&gt; wrote: > We have been discussing the possibility of adding batch notifications > support to our SimplePush and UnifiedPush Server. The use case for this > would be when doing a selective send using a category, or a broadcast, and > instead of sending a number of individual HTTP PUT notifications, a single > HTTP PUT notification could be sent. > That's a good idea. When I first start playing with SPS I thought sending PUTs was working this way so for me it's a quite natural "enhancement"

> When sending a notification an endpoint that looks something like this is > used: > > https://localhost:7777/update/7linbl5LD9XwCMDfwMeM4vLV8yIwY8Kem32lG2igDng... > > The suggestion for sending batch notifications might work by sending a > HTTP PUT but only using: > https://localhost:7777/update > In this case the body of the PUT request must be a valid json in the > following format: > { > "version":"1", > > "pushEndpoints":["R32EU3Ct3PuHpEJZbeFQH0JWt_ERUtC4fxox44isNINyWDwatnJ1l1thxQyI1M4-IGvwX3AexkaDiMKpeh3P327MeOm809f9LcCdLw562nOcxxMLmMrhNI4ey4TlQ1mi", > > "J_hIZkdLfKZpiwgpQ68QsPPlljnDGBbmPwAwGoe_6mE7ZBaKmebqf1mCDy_c9zII8CyaFC5t9BsGeUSU0nylToQgBKYdV4DFj3zdcpCMnxIHsSpX8Zx9DAjWCv7nfAJz"] > } > The version is pretty much the same as when sending a normal notification > except that it is in json format instead of simply 'version=1'. > The pushEndpoints is an array of channel endpoints. The format of these > could be different for different SimplePush Server implementations so they > are simple strings and the server implementation will know how to interpret > them. > > Since batch notifications are outside of the SimplePush specification > this would only work with our implementation and that will complicate > things for the clients, like the UnifiedPush Server for example. It would > have to distinguish between our SImplePush implementation and others. > Is that something in which we could contribute back to Mozilla or at least discuss with us if this could be added to the specs ?

> Another issue that came up while discussing this is the question if this > opens up for denial of service attacks where an attacker could send one > batch notification with a long list of pushEndpoints to try to keep the > server busy. At the moment, for an attacker to do the same thing he/she > would have to send individual request which would be easier to notice and > defend against as there would be a high volume of HTTP traffic. > Should be nice if we had a security expert in the team ... oh wait ... ;) > > Thoughts? > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

-- qmx (mobile) On 17/09/2013, at 03:53, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > Regarding 'contributing back', not sure if our Java code would be helpful for their (Go?) Server. I think he meant contributing back spec-wise ;)

_______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Would be nice if instead of funny jokes, I got something real in jiras :) Plaintext doesn't compile Sebastien Blanc wrote: > Should be nice if we had a security expert in the team ... oh wait ... > ;) -- abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hi, JR from Mozilla here. We've kicked bulk processing around for a while, really, but have had a few issues we needed to deal with first. Ultimately, bulk processing originally came down to two things: 1) User Privacy. This is a bit less of a concern if a system uses the token hashing, since the UAID and CHID are encoded. It's a problem if there's no token hashing because there's meta information leakage that happens, and that could cause problems. 2) Griefing attacks. Bad guys who want to disrupt the system could send blocks of bad data that the servers would have to spin up and check, which could go into the thousands of records. Yeah, it's possible to do this with traditional ones, but it's more of a pain in the patoot for the griefers because they have to spin up a new connection for each bad item they want to send. 3) Traffic shaping Ideally, endpoints are completely opaque. That gives servers the ability to send some UAIDs to a completely different cluster by specifying a different hostname or other mechanism. Generally, i've found that if you let users disassemble something like an endpoint, there be dragons. Now, since time stands still for no requirement specification, things have changed a bit since the very early discussions. I like the proposed solution of passing a JSON blob to /update. What I'd suggest is the following: 1) blob is limited to some size. I'd recommend something like a 1MB, since that should be able to hold around 8738 tokens. That should be enough to handle most loads (except something like eBay or twitter, but I'm betting those are special cases anyway.) 2) three strikes and you're out. This is something that I'm actually debating pretty hard about. Really it's the number. There needs be some point where the server says, "this is crap" and drops everything. Pretty easy to do if a token doesn't decode, but more tricky when you've got 1 out of n UAIDs failing (for non-hashed tokens). What also makes this hard is that you don't want to tell a hacker that they're succeeding, so we can't give information back to the App Server. Thoughts? -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-simplepush-Batch-n... Sent from the aerogear-dev mailing list archive at Nabble.com. _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev