Oh, I see. Yes, that would make sense. So we would just leave the
original link in there, right?

Ethan

On Tue, Aug 31, 2010 at 8:12 PM, Richard Hirsch <[email protected]> wrote:
> I agree with the solution of just removing those links that originate in 
> pools.
>
> D.
>
> On 8/31/10, Vassil Dichev <[email protected]> wrote:
>> OK, I think this is a worse example, because there are many ways to
>> find a list of URLs in a wiki (which were generally just not designed
>> with privacy/security in mind).
>>
>> If you're willing to sacrifice convenience for security, the easiest
>> change is not to parse URLs in messages in pools- it will appear as
>> normal text, not as a hyperlink. The next thing we can do is set up a
>> different type of URL which doesn't take you to the shortened URL, but
>> directly to the target URL.
>>
>> If one really insists on shortening URLs in pools, then there must be
>> one set of shortened URLs per pool. I don't think anyone will claim
>> that this idea makes sense.
>>
>> Vassil
>>
>>
>> On Tue, Aug 31, 2010 at 11:35 AM, Ethan Jewett <[email protected]> wrote:
>>> I agree in theory with your assessment of the google docs situation,
>>> but I still think we're violating the expectation of security around
>>> pools.
>>>
>>> Take another example: An HR department is using a secure wiki to
>>> discuss and organize an upcoming layoff. The wiki page is titled
>>> "October layoff planning" and the URL is
>>> https://hrwiki.corp.internal/October-layoff-planning. Someone posts
>>> this URL to the layoff-planning pool on esme (the same group of people
>>> with access to the wiki page) and a bunch of people in the pool click
>>> on it. Suddenly, the upcoming layoff has been announced to every esme
>>> user in the corporation. Whoops!
>>>
>>> The point is, maybe that private information shouldn't be in the URL,
>>> but a lot of applications do this whether or not it is a good idea. I
>>> think we need to take that reality into account and change the way
>>> this works to avoid the possibility of these scenarios.
>>>
>>> Ethan
>>>
>>> On Tuesday, August 31, 2010, Vassil Dichev <[email protected]> wrote:
>>>> Ethan, this defeats the purpose of having an URL shortener and it only
>>>> gives you a false sense of security. Read my previous mail.
>>>>
>>>> Links have no notion of a pool. A link could come from messages in
>>>> different pools or it might not be clicked "inside a message" at all.
>>>>
>>>> Let me know what you think.
>>>>
>>>> Vassil
>>>>
>>>>
>>>> On Tue, Aug 31, 2010 at 9:44 AM, Ethan Jewett <[email protected]> wrote:
>>>>> [Changed subject to start a new thread. Was: "New issues - a couple of
>>>>> blockers for 1.1 release"]
>>>>>
>>>>> That's correct. The "Popular messages" functionality just keeps a
>>>>> counter of how many times a message has been resent. If you look at
>>>>> the UserActor.scala, lines 197 & 198, you'll see that the statistic
>>>>> "ResendStat" is incremented when a message is resent, but only if the
>>>>> message is not in a pool. Then when we want to find out what the most
>>>>> popular messages are, we ask the PopStatsActor - for example in the
>>>>> "popular" method of UserSnip.scala - line 213.
>>>>>
>>>>> On the other hand, the "LinkClicked is incremented in UrlStore.scala -
>>>>> line 40. Here there is never a check to see if the link came from a
>>>>> message in a pool. (This counter is used in the "links" method in
>>>>> UserSnip.scala, after the "popular" method.)
>>>>>
>>>>> I think we need to check if a link came from a pool before
>>>>> incrementing the counter, but in order to do this we need to record
>>>>> what pool a link belonged to, so I think we need to make pool part of
>>>>> the key of the UrlStore object and then populate this field when a new
>>>>> link is created.
>>>>>
>>>>> Ethan
>>>>>
>>>>> On Tue, Aug 31, 2010 at 8:11 AM, Imtiaz Ahmed H E <[email protected]>
>>>>> 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" <[email protected]>
>>>>>> To: <[email protected]>
>>>>>> 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 <[email protected]>
>>>>>> 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"
>>>>>>> <[email protected]>
>>>>>>> To: <
>>>
>>
>

Reply via email to