On Mon, Aug 29, 2016 at 09:29:23AM +0200, Florian Schmaus wrote:
> On 29.08.2016 05:29, Sam Whited wrote:
> > On Sun, Aug 28, 2016 at 2:53 PM, Mathieu Pasquet
> > wrote:
> >> Two years late, but can we deprecate it XEP-0138 now, lest someones
> >> comes along and
On 29.08.2016 05:29, Sam Whited wrote:
> On Sun, Aug 28, 2016 at 2:53 PM, Mathieu Pasquet
> wrote:
>> Two years late, but can we deprecate it XEP-0138 now, lest someones
>> comes along and implements/enables it in their client?
>
> Though I'm aware of the security risks,
On Sun, Aug 28, 2016 at 2:53 PM, Mathieu Pasquet wrote:
> Two years late, but can we deprecate it XEP-0138 now, lest someones
> comes along and implements/enables it in their client?
Though I'm aware of the security risks, stream compression is still
useful, and may even
On Tue, Oct 14, 2014 at 02:48:42PM +0200, Thijs Alkemade wrote:
>
> On 9 okt. 2014, at 17:06, Peter Saint-Andre - wrote:
>
> > On 10/9/14, 7:59 AM, Thijs Alkemade wrote:
> >> Hello all,
> >>
> >> Stream compression is insecure, that was shown with CRIME and BREACH and
> >>
On 9 okt. 2014, at 17:06, Peter Saint-Andre - yet pe...@andyet.net wrote:
On 10/9/14, 7:59 AM, Thijs Alkemade wrote:
Hello all,
Stream compression is insecure, that was shown with CRIME and BREACH and the
situation for XMPP isn't much different [1]. I think we should look at the
easiest
Hello all,
Stream compression is insecure, that was shown with CRIME and BREACH and the
situation for XMPP isn't much different [1]. I think we should look at the
easiest way to deprecate XEP-0138 and move to something better.
Using a full flush (in zlib terms) after every stanza would solve the
On 10/9/14, 7:59 AM, Thijs Alkemade wrote:
Hello all,
Stream compression is insecure, that was shown with CRIME and BREACH and the
situation for XMPP isn't much different [1]. I think we should look at the
easiest way to deprecate XEP-0138 and move to something better.
Using a full flush (in