esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vassil Dichev <vdic...@apache.org>
Subject Re: New issues - a couple of blockers for 1.1 release
Date Tue, 31 Aug 2010 07:08:37 GMT
Hi Imtiaz,

Sorry for the delay in getting into this conversation.

Popularity statistics are only collected for messages in the public
pool, period. This is because there are always people who might not be
in a pool and who might be able to see a message in the top popular
ones- this shouldn't happen.

Links are different. Since ESME has a built-in URL shortener, as soon
as the message is parsed, the link is checked in the list of
registered URLs and if it matches, it's shortened version is used. If
the link is not found, a shortened version is generated.

The problem here is that links are completely decoupled from the
message. You might access the link without clicking on it in a
message- someone might have forwarded you that link. Furthermore, the
same identical shortened link will be found in many messages if it
points to the same URL.

This causes another problem with pools- what if a link is found both
in a message in a pool and in a public message? Do we collect stats
for it? Do we collect only stats from clicks on a public message? How
can you distinguish them if they point to the same thing? There is no
way to tell currently.

Initiallly when I implemented popularity statistics, I thought this
might be a problem, however Google Docs has a more serious security
problem and you will *not* be protected if ESME doesn't show the link
in the popularity stats. It is all too easy for the link to leak
somewhere or get sniffed over the network, as the URL in the HTTP
request is not encrypted. See this link for more info:

http://www.google.com/support/forum/p/Google%20Docs/thread?tid=4bf934caf4de8f2d&hl=en

Eventually I formed the opinion that it is the responsibility of the
link destination itself to provide some sort of authentication if it
really wants to be serious about security. Sensitive info in the URL
will never be secure.

I'm not sure this is the answer you expected, but we must take this in
consideration before deciding how to solve the problem- and whether
it's worth it to be solved at all. One possible solution would be not
to shorten links in any pool, but I'm not sure it gives us any more
security than we currently have.

Vassil


On Tue, Aug 31, 2010 at 9:11 AM, Imtiaz Ahmed H E <in.imtiaz@gmail.com> wrote:
> In the home when I type in a message sharing it with one pool and click
> resend it does not show up in Popular Messages. But if the message is public
> it shows up on resend in Popular Pessages.
>
> Can you explain. Haven't gotten to Popular Links yet.
>
> Imtiaz
>
> ----- Original Message ----- From: "Ethan Jewett" <esjewett@gmail.com>
> To: <esme-dev@incubator.apache.org>
> Sent: Tuesday, August 31, 2010 11:37 AM
> Subject: Re: New issues - a couple of blockers for 1.1 release
>
>
> Hi,
>
> The issue doesn't happen with Popular Messages, only with Popular Links.
>
> I need to look into the implementation, but I have a feeling the
> Popular Links issue is going to be a headache. I believe that for a
> given link there is no way to tell what message it shows up in, which
> would make it impossible to tell if it is a link from a pooled message
> or not. We may have to modify the data model for storing links to flag
> the ones that started out in a pooled message...
>
> Regarding Pubsubhubbub, as Dick said, there's no hurry. I don't think
> I'll be working on it over the next couple of weeks.
>
> Thanks for all your efforts!
>
> Ethan
>
> On Tue, Aug 31, 2010 at 4:20 AM, Imtiaz Ahmed H E <in.imtiaz@gmail.com>
> wrote:
>>
>> Re https://issues.apache.org/jira/browse/ESME-267
>>
>> I haven't tried this but plan to fix it right away.
>>
>> Tell me, is it only the links showing up in 'Popular Links' or is that a
>> problem with the message itself also showing up in 'PopularMessages'
>>
>> Looks like I'll never get going with pubsubhubub ! First there was Dick's
>> Release Planning mail with the pending 1.1 issues and now here are some
>> more. Plan to get going after all 1.1 ending issues are resolved.
>>
>> However, Ethan it was your issue originally and if you feel you want to
>> take
>> it back again to push it to closure faster or something please do,
>> otherwise
>> I'll re-start on it once 1.1 is done...
>>
>> Imtiaz
>>
>> ----- Original Message ----- From: "Richard Hirsch"
>> <hirsch.dick@gmail.com>
>> To: <esme-dev@incubator.apache.org>
>> Sent: Monday, August 30, 2010 12:00 AM
>> Subject: Re: New issues - a couple of blockers for 1.1 release
>>
>>
>>> On Sun, Aug 29, 2010 at 7:59 PM, Ethan Jewett <esjewett@gmail.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I've created a few new issues in the Jira based on my testing of the
>>>> latest Stax deployment as well as some local testing. I see a couple
>>>> of them as blockers of the 1.1 release (ESME-266 is definitely
>>>> debatable, but I'm pretty adamant about ESME-267 as it's a real
>>>> security issue):
>>>>
>>>> ESME-266 - https://issues.apache.org/jira/browse/ESME-266 - Some
>>>> RSS/Atom feeds don't work properly. Normally I would have pushed this
>>>> to the backlog, but it makes it so that we can't import Twitter feeds,
>>>> which I think is pretty important.
>>>
>>> +1
>>>
>>>>
>>>> ESME-267 - https://issues.apache.org/jira/browse/ESME-267 - "Links
>>>> from messages in pools show up in "Popular links" for users that are
>>>> not in the pool" - I put an example into the ticket of why this is a
>>>> big problem
>>>
>>> +1 - have you tried to see if resending messages in pools has the same
>>> problem?
>>>
>>>>
>>>> ESME-268 - https://issues.apache.org/jira/browse/ESME-268 - User
>>>> should not be offered the option to "resend" his/her own messages.
>>>> This is assigned to release 1.2 as I don't believe it is a major
>>>> issue. If it is fixed before Dick tags release 1.1, then I'm in favor
>>>> of including it.
>>>
>>> I agree as well
>>>
>>>
>>> Thanks for checking for bugs. I'm sure after we create a RC and people
>>> start testing we will probably find more bugs.
>>>>
>>>> Ethan
>>>>
>>
>>
>
>

Mime
View raw message