<div dir="ltr">Hi JR, <div><br></div><div>and thanks for the input on this!</div><div><br></div><div>I had not thought about user privacy with regards to the endpoints as I was sort of blinded by that we now encode the UAID and CHID. Would it be an option to mandate this in the specification?</div>
<div><br></div><div>1) <span style="font-family:arial,sans-serif;font-size:13px">blob is limited to some size</span></div>
<div>1MB sounds like good limit. </div><div><br></div><div>2) <span style="font-family:arial,sans-serif;font-size:13px">three strikes and you're out.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">How about just leaving the number up to the specific implementation and perhaps let the specification can just recommend a value.</span></div>
<div><font face="arial, sans-serif">So basically this means that it is possible for an honest client to send a batch of notifications, but for some reason 3 are invalid and this would cause the batch to fail, and the App Server would not know about the failure.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Regarding traffic shaping I don't really have any input on that as we only support a single instance as it stands today. We hope to get this work started shortly though.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">I think this all sounds good and it would be nice to try this out and see how it works in practice too. </font></div><div><font face="arial, sans-serif">How about we add the size limit of the batch notification and the "three strikes and you're out" limit to AGPUSH-338[1] and see how this works in conjunction with the UnifiedPush Server?</font></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">[1] </span><font face="arial, sans-serif"><a href="https://issues.jboss.org/browse/AGPUSH-338">https://issues.jboss.org/browse/AGPUSH-338</a></font></div><div>
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 18 September 2013 19:01, jr <span dir="ltr"><<a href="mailto:jrconlin@gmail.com" target="_blank">jrconlin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
JR from Mozilla here.<br>
<br>
We've kicked bulk processing around for a while, really, but have had a few<br>
issues we needed to deal with first. Ultimately, bulk processing originally<br>
came down to two things:<br>
<br>
1) User Privacy.<br>
This is a bit less of a concern if a system uses the token hashing, since<br>
the UAID and CHID are encoded. It's a problem if there's no token hashing<br>
because there's meta information leakage that happens, and that could cause<br>
problems.<br>
<br>
2) Griefing attacks.<br>
Bad guys who want to disrupt the system could send blocks of bad data that<br>
the servers would have to spin up and check, which could go into the<br>
thousands of records. Yeah, it's possible to do this with traditional ones,<br>
but it's more of a pain in the patoot for the griefers because they have to<br>
spin up a new connection for each bad item they want to send.<br>
<br>
3) Traffic shaping<br>
Ideally, endpoints are completely opaque. That gives servers the ability to<br>
send some UAIDs to a completely different cluster by specifying a different<br>
hostname or other mechanism. Generally, i've found that if you let users<br>
disassemble something like an endpoint, there be dragons.<br>
<br>
Now, since time stands still for no requirement specification, things have<br>
changed a bit since the very early discussions. I like the proposed solution<br>
of passing a JSON blob to /update. What I'd suggest is the following:<br>
<br>
1) blob is limited to some size. I'd recommend something like a 1MB, since<br>
that should be able to hold around 8738 tokens. That should be enough to<br>
handle most loads (except something like eBay or twitter, but I'm betting<br>
those are special cases anyway.)<br>
<br>
2) three strikes and you're out. This is something that I'm actually<br>
debating pretty hard about. Really it's the number. There needs be some<br>
point where the server says, "this is crap" and drops everything. Pretty<br>
easy to do if a token doesn't decode, but more tricky when you've got 1 out<br>
of n UAIDs failing (for non-hashed tokens). What also makes this hard is<br>
that you don't want to tell a hacker that they're succeeding, so we can't<br>
give information back to the App Server.<br>
<br>
Thoughts?<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-simplepush-Batch-notifications-tp4701p4770.html" target="_blank">http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-simplepush-Batch-notifications-tp4701p4770.html</a><br>
Sent from the aerogear-dev mailing list archive at Nabble.com.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</div></div></blockquote></div><br></div>