[asterisk-gui] interface to list of providers

[bkruse]

The whole idea behind this is that we _can_ push updates of Service 
Providers.

We will test this internally, but it is better than the alternative 
(having a provider that
does not work when they are certified to work)

Not to mention this will rarely happen.

As far as the remote thing, it is an equiv of a "wget", what about when 
you go to sites
and you see "request pages from analytics.google.com", or requesting 
advertising
javascript files. If you are worried about javascript security, and your 
overall security,
there are much better, and more vulnerable, places to start at.

-bk

Pari Nannapaneni wrote:
>> Not to get into semantics:
>>
>> The obvious fact is that the local page gets information from a remote
>> page. For the purpose of usage statistics, maybe even a simple data file
>> or an image would do the same.
>>     
>
> Sure, i think having discussions about any security/privacy concerns are always a good thing.
>
>   
>> This still does not address the original issue.
>> Also note that the URL should be HTTPS or use some other equivalent
>> messure to protect from DNS spoofs and such.
>>     
>
> It is a HTTPS URL with a valid SSL cert.
>
> thanks,
> -Pari
>
>
> ----- Original Message -----
> From: "Tzafrir Cohen" <tzafrir.cohen at xorcom.com>
> To: asterisk-gui at lists.digium.com
> Sent: Thursday, August 28, 2008 1:11:28 PM GMT -06:00 US/Canada Central
> Subject: Re: [asterisk-gui] interface to list of providers
>
> On Thu, Aug 28, 2008 at 08:40:45AM -0500, Pari Nannapaneni wrote:
>   
>> Hi Tzafrir,
>>
>>     
>>> 1. Privacy implications
>>> Every time I use this configuration page, it reports home. 
>>>       
>> "reports home" would be kind of a strong word.
>>
>> I would agree with what you said,
>>  [A] if there is 'a banner-Ad script served from a 3rd party website" in the gui
>>  [B] if the gui had some third party scripts like "google analytics"
>>  [C] if the script is a mashup 
>>      I don't think this really qualifies as a 'mashup', as there is NOWAY the script
>>      can read any of your cookies set by other websites. 
>>      - Unless you are embedding the gui in someother website via an iframe.
>>  [D] if the script served is obfuscated using some javascript obfuscator
>>  [E] OR if the script makes any XMLhttprequest to Digium or some other website.
>>
>> Its straight forward javascript file, like the rest of the scripts in the GUI.
>>     
>
> Not to get into semantics:
>
> The obvious fact is that the local page gets information from a remote
> page. For the purpose of usage statistics, maybe even a simple data file
> or an image would do the same.
>
> A quick grep before posting this message showed me that this was the
> only case of such a "remote" content.
>
> It also means that part of the functionality is not available if the
> system has no internet access (or is behind a very strict firewall).
>
>   
>> The only difference being that it is loaded from a different URL,
>> and the GUI tells the same to the user and loads the script only after 
>> taking a confirmation from the user.
>>
>> Yes, the webserver's log file will contain a bunch of IP addresses which requested the js file,
>> but thats like saying "i won't use VOIP because the person on the other end might know my IP address".
>>
>>
>>     
>>> 2. Untested code
>>> This feature means I run a whole bunch of javascript code from a remote
>>> site. Later on some modifications in that page may break my page and I
>>> would not even be aware of that.
>>>       
>> We will see what we can do about this.
>>
>> Right now, the providers file is on a different svn repository.
>> I will see if there is a way to somehow move the providers script file 
>> into the gui repository,
>> so that any changes made to the file would be public.
>>     
>
> This still does not address the original issue.
> Also note that the URL should be HTTPS or use some other equivalent
> messure to protect from DNS spoofs and such.
>
>