I'd like to open an discussion about what the thoughts and positions the community would have on enabling some statistic collection on Joomla installs that the project can collect and tabulate.
We frequently have discussions on this and other lists about how we think or believe Joomla site users "use" Joomla. For example:
- Hosting Environment - Number of Installs - Number of Updates
And I'm sure, many other bits of data as well. I think most commonly is the "hosting environment" situation. Wherein, the CMS and Platform developers are continually discussing what users are doing "now days". A perfect example of this is the current discussion on whether we should retain MySQL support in CMS 3.0. Other examples could be:
- Server operating system - PHP version - Database Driver Used
And the lists goes on.
Perhaps rather than guessing and only getting feedback from developers, who probably have a much different usage and operating environment than the more-common Joomla user does, we can enable a utility that sends data back to a collection server. This of course would be optional to send, kept private, and not contain any sensitive server data to retain security.
*Possible Concerns* The idea has some very real and possibly idea-killing concerns that I have identified already, and I'm sure that there are more:
- Security - Privacy - Legal Ramifications - License Compliance (Not sure if this sort of functionality conflicts with the GPL)
*Possible Benefits* I see the benefits of this, assuming it can be done successfully navigating the above concerns, as solving a great deal of many problems and questions we have to ask ourselves when making changes. Specifically we can actually answer questions like "what version of PHP are users most commonly installing Joomla on?" or "Do users install using MySQL or MySQLi?".
Again, it's important to note that this would be an entirely *optional, opt-in* data collection program that administrators must enable, understanding what they are doing.
There are some examples of software that does this already. Many operating systems and browsers (chrome, firefox) do this. I think that it could be a valuable asset to the community.
I'd appreciate some thoughts on this. Thanks all for your time.
GPL has no relationship to this except that people who redistribute Joomla have the right to remove or add to or modify or study the functionality.
I think it would be a really great idea to add this even if just to start it is the environment that the initial install occurs in. Of course users should be able to opt out
To me database type and version, php version, and server would be the most important baseline pieces of information.
On Sunday, June 3, 2012 12:42:03 AM UTC-4, Chad Windnagle wrote:
> Hello JoomlaSphere:
> I'd like to open an discussion about what the thoughts and positions the > community would have on enabling some statistic collection on Joomla > installs that the project can collect and tabulate.
> We frequently have discussions on this and other lists about how we think > or believe Joomla site users "use" Joomla. For example:
> - Hosting Environment > - Number of Installs > - Number of Updates
> And I'm sure, many other bits of data as well. I think most commonly is > the "hosting environment" situation. Wherein, the CMS and Platform > developers are continually discussing what users are doing "now days". A > perfect example of this is the current discussion on whether we should > retain MySQL support in CMS 3.0. Other examples could be:
> - Server operating system > - PHP version > - Database Driver Used
> And the lists goes on.
> Perhaps rather than guessing and only getting feedback from developers, > who probably have a much different usage and operating environment than the > more-common Joomla user does, we can enable a utility that sends data back > to a collection server. This of course would be optional to send, kept > private, and not contain any sensitive server data to retain security.
> *Possible Concerns* > The idea has some very real and possibly idea-killing concerns that I have > identified already, and I'm sure that there are more:
> - Security > - Privacy > - Legal Ramifications > - License Compliance (Not sure if this sort of functionality conflicts > with the GPL)
> *Possible Benefits* > I see the benefits of this, assuming it can be done successfully > navigating the above concerns, as solving a great deal of many problems and > questions we have to ask ourselves when making changes. Specifically we can > actually answer questions like "what version of PHP are users most commonly > installing Joomla on?" or "Do users install using MySQL or MySQLi?".
> Again, it's important to note that this would be an entirely *optional, > opt-in* data collection program that administrators must enable, > understanding what they are doing.
> There are some examples of software that does this already. Many operating > systems and browsers (chrome, firefox) do this. I think that it could be a > valuable asset to the community.
> I'd appreciate some thoughts on this. Thanks all for your time.
I agree that collecting some stats would be very helpful. If possible,
it would be great to also get a snapshot each time people do an auto
update (again, of course with an opt in). It could be very useful for
example to know what extensions are being used in a site and what
version of Joomla is being used. Mark
On Sun, Jun 3, 2012 at 12:48 PM, elin <elin.war...@gmail.com> wrote:
> GPL has no relationship to this except that people who redistribute Joomla
> have the right to remove or add to or modify or study the functionality.
> I think it would be a really great idea to add this even if just to start it
> is the environment that the initial install occurs in. Of course users
> should be able to opt out
> To me database type and version, php version, and server would be the most
> important baseline pieces of information.
> Elin
> On Sunday, June 3, 2012 12:42:03 AM UTC-4, Chad Windnagle wrote:
>> Hello JoomlaSphere:
>> I'd like to open an discussion about what the thoughts and positions the
>> community would have on enabling some statistic collection on Joomla
>> installs that the project can collect and tabulate.
>> We frequently have discussions on this and other lists about how we think
>> or believe Joomla site users "use" Joomla. For example:
>> Hosting Environment
>> Number of Installs
>> Number of Updates
>> And I'm sure, many other bits of data as well. I think most commonly is
>> the "hosting environment" situation. Wherein, the CMS and Platform
>> developers are continually discussing what users are doing "now days". A
>> perfect example of this is the current discussion on whether we should
>> retain MySQL support in CMS 3.0. Other examples could be:
>> Server operating system
>> PHP version
>> Database Driver Used
>> And the lists goes on.
>> Perhaps rather than guessing and only getting feedback from developers,
>> who probably have a much different usage and operating environment than the
>> more-common Joomla user does, we can enable a utility that sends data back
>> to a collection server. This of course would be optional to send, kept
>> private, and not contain any sensitive server data to retain security.
>> Possible Concerns
>> The idea has some very real and possibly idea-killing concerns that I have
>> identified already, and I'm sure that there are more:
>> Security
>> Privacy
>> Legal Ramifications
>> License Compliance (Not sure if this sort of functionality conflicts with
>> the GPL)
>> Possible Benefits
>> I see the benefits of this, assuming it can be done successfully
>> navigating the above concerns, as solving a great deal of many problems and
>> questions we have to ask ourselves when making changes. Specifically we can
>> actually answer questions like "what version of PHP are users most commonly
>> installing Joomla on?" or "Do users install using MySQL or MySQLi?".
>> Again, it's important to note that this would be an entirely optional,
>> opt-in data collection program that administrators must enable,
>> understanding what they are doing.
>> There are some examples of software that does this already. Many operating
>> systems and browsers (chrome, firefox) do this. I think that it could be a
>> valuable asset to the community.
>> I'd appreciate some thoughts on this. Thanks all for your time.
> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cms+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
We had something similar in one version of Sobi2. We asked Sobi2 users to send (from backend) as an auto-generated XML file with the environment data. And then we published this data at: http://www.sigsiu.net/statistics/
Basically we needed these data to find out the best requirements for SobiPro at that time. But people keep asking us even today if we are going to repeat this action because many Joomla! users and developers are very interested in such statistics.
On Sunday, 3 June 2012 06:42:03 UTC+2, Chad Windnagle wrote:
> Hello JoomlaSphere:
> I'd like to open an discussion about what the thoughts and positions the > community would have on enabling some statistic collection on Joomla > installs that the project can collect and tabulate.
> We frequently have discussions on this and other lists about how we think > or believe Joomla site users "use" Joomla. For example:
> - Hosting Environment > - Number of Installs > - Number of Updates
> And I'm sure, many other bits of data as well. I think most commonly is > the "hosting environment" situation. Wherein, the CMS and Platform > developers are continually discussing what users are doing "now days". A > perfect example of this is the current discussion on whether we should > retain MySQL support in CMS 3.0. Other examples could be:
> - Server operating system > - PHP version > - Database Driver Used
> And the lists goes on.
> Perhaps rather than guessing and only getting feedback from developers, > who probably have a much different usage and operating environment than the > more-common Joomla user does, we can enable a utility that sends data back > to a collection server. This of course would be optional to send, kept > private, and not contain any sensitive server data to retain security.
> *Possible Concerns* > The idea has some very real and possibly idea-killing concerns that I have > identified already, and I'm sure that there are more:
> - Security > - Privacy > - Legal Ramifications > - License Compliance (Not sure if this sort of functionality conflicts > with the GPL)
> *Possible Benefits* > I see the benefits of this, assuming it can be done successfully > navigating the above concerns, as solving a great deal of many problems and > questions we have to ask ourselves when making changes. Specifically we can > actually answer questions like "what version of PHP are users most commonly > installing Joomla on?" or "Do users install using MySQL or MySQLi?".
> Again, it's important to note that this would be an entirely *optional, > opt-in* data collection program that administrators must enable, > understanding what they are doing.
> There are some examples of software that does this already. Many operating > systems and browsers (chrome, firefox) do this. I think that it could be a > valuable asset to the community.
> I'd appreciate some thoughts on this. Thanks all for your time.
For best practice this should be : 1. Entirely optional opt-in only 2. The data sent should be displayed to the user before it is sent and confirmation again required before it is sent 3. the explanation of how, where, when and why the data is being collected and who it will be used for MUST be in simple language and NOT legalese and of course translated into all languages 4. It must be completely anonymous (the latter condition might effect where in Joomla the data collection can take place ie the installation is not truly translated in many languages)
I think this is basically a good idea and is something that has been
suggested many times before. I'd like to suggest that people interested in
moving the idea forwards should form a working group that will
1. Define how it will work. Questions to be answered include how the
opt-in/out mechanism will work, what data will be gathered, how security
and privacy issues will be addressed, what infrastructure will be needed,
and so on.
2. Write the code for inclusion in Joomla.
3. Write the code that will gather the data and present the statistics.
This is not a trivial exercise but I do agree that it will be very
worthwhile if you can pull it off.
Chris.
On 4 June 2012 09:58, Radek Suski <suski.ra...@googlemail.com> wrote:
> We had something similar in one version of Sobi2.
> We asked Sobi2 users to send (from backend) as an auto-generated XML file
> with the environment data.
> And then we published this data at: http://www.sigsiu.net/statistics/
> Basically we needed these data to find out the best requirements
> for SobiPro at that time.
> But people keep asking us even today if we are going to repeat this action
> because many Joomla! users and developers are very interested in such
> statistics.
> So I think this is very good idea.
> Regards,
> Radek
> On Sunday, 3 June 2012 06:42:03 UTC+2, Chad Windnagle wrote:
>> Hello JoomlaSphere:
>> I'd like to open an discussion about what the thoughts and positions the
>> community would have on enabling some statistic collection on Joomla
>> installs that the project can collect and tabulate.
>> We frequently have discussions on this and other lists about how we think
>> or believe Joomla site users "use" Joomla. For example:
>> - Hosting Environment
>> - Number of Installs
>> - Number of Updates
>> And I'm sure, many other bits of data as well. I think most commonly is
>> the "hosting environment" situation. Wherein, the CMS and Platform
>> developers are continually discussing what users are doing "now days". A
>> perfect example of this is the current discussion on whether we should
>> retain MySQL support in CMS 3.0. Other examples could be:
>> - Server operating system
>> - PHP version
>> - Database Driver Used
>> And the lists goes on.
>> Perhaps rather than guessing and only getting feedback from developers,
>> who probably have a much different usage and operating environment than the
>> more-common Joomla user does, we can enable a utility that sends data back
>> to a collection server. This of course would be optional to send, kept
>> private, and not contain any sensitive server data to retain security.
>> *Possible Concerns*
>> The idea has some very real and possibly idea-killing concerns that I
>> have identified already, and I'm sure that there are more:
>> - Security
>> - Privacy
>> - Legal Ramifications
>> - License Compliance (Not sure if this sort of functionality
>> conflicts with the GPL)
>> *Possible Benefits*
>> I see the benefits of this, assuming it can be done successfully
>> navigating the above concerns, as solving a great deal of many problems and
>> questions we have to ask ourselves when making changes. Specifically we can
>> actually answer questions like "what version of PHP are users most commonly
>> installing Joomla on?" or "Do users install using MySQL or MySQLi?".
>> Again, it's important to note that this would be an entirely *optional,
>> opt-in* data collection program that administrators must enable,
>> understanding what they are doing.
>> There are some examples of software that does this already. Many
>> operating systems and browsers (chrome, firefox) do this. I think that it
>> could be a valuable asset to the community.
>> I'd appreciate some thoughts on this. Thanks all for your time.
> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cms+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
-- Chris Davenport
Joomla Leadership Team - Production Working Group
Joomla Documentation Coordinator
It would be also necessary to define which data we want to collect. For example available libraries which we normally not using but maybe we could (i.e Spell checkers etc)
On Monday, 4 June 2012 12:23:38 UTC+2, Chris Davenport wrote:
> I think this is basically a good idea and is something that has been > suggested many times before. I'd like to suggest that people interested in > moving the idea forwards should form a working group that will
> 1. Define how it will work. Questions to be answered include how the > opt-in/out mechanism will work, what data will be gathered, how security > and privacy issues will be addressed, what infrastructure will be needed, > and so on. > 2. Write the code for inclusion in Joomla. > 3. Write the code that will gather the data and present the statistics.
> This is not a trivial exercise but I do agree that it will be very > worthwhile if you can pull it off.
> Chris.
> On 4 June 2012 09:58, Radek Suski <suski.ra...@googlemail.com> wrote:
>> We had something similar in one version of Sobi2. >> We asked Sobi2 users to send (from backend) as an auto-generated XML file >> with the environment data. >> And then we published this data at: http://www.sigsiu.net/statistics/
>> Basically we needed these data to find out the best requirements >> for SobiPro at that time. >> But people keep asking us even today if we are going to repeat this >> action because many Joomla! users and developers are very interested in >> such statistics.
>> So I think this is very good idea.
>> Regards, >> Radek
>> On Sunday, 3 June 2012 06:42:03 UTC+2, Chad Windnagle wrote:
>>> Hello JoomlaSphere:
>>> I'd like to open an discussion about what the thoughts and positions the >>> community would have on enabling some statistic collection on Joomla >>> installs that the project can collect and tabulate.
>>> We frequently have discussions on this and other lists about how we >>> think or believe Joomla site users "use" Joomla. For example:
>>> - Hosting Environment >>> - Number of Installs >>> - Number of Updates
>>> And I'm sure, many other bits of data as well. I think most commonly is >>> the "hosting environment" situation. Wherein, the CMS and Platform >>> developers are continually discussing what users are doing "now days". A >>> perfect example of this is the current discussion on whether we should >>> retain MySQL support in CMS 3.0. Other examples could be:
>>> - Server operating system >>> - PHP version >>> - Database Driver Used
>>> And the lists goes on.
>>> Perhaps rather than guessing and only getting feedback from developers, >>> who probably have a much different usage and operating environment than the >>> more-common Joomla user does, we can enable a utility that sends data back >>> to a collection server. This of course would be optional to send, kept >>> private, and not contain any sensitive server data to retain security.
>>> *Possible Concerns* >>> The idea has some very real and possibly idea-killing concerns that I >>> have identified already, and I'm sure that there are more:
>>> - Security >>> - Privacy >>> - Legal Ramifications >>> - License Compliance (Not sure if this sort of functionality >>> conflicts with the GPL)
>>> *Possible Benefits* >>> I see the benefits of this, assuming it can be done successfully >>> navigating the above concerns, as solving a great deal of many problems and >>> questions we have to ask ourselves when making changes. Specifically we can >>> actually answer questions like "what version of PHP are users most commonly >>> installing Joomla on?" or "Do users install using MySQL or MySQLi?".
>>> Again, it's important to note that this would be an entirely *optional, >>> opt-in* data collection program that administrators must enable, >>> understanding what they are doing.
>>> There are some examples of software that does this already. Many >>> operating systems and browsers (chrome, firefox) do this. I think that it >>> could be a valuable asset to the community.
>>> I'd appreciate some thoughts on this. Thanks all for your time.
>> To post to this group, send an email to joomla-dev-cms@googlegroups.com. >> To unsubscribe from this group, send email to >> joomla-dev-cms+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> -- > Chris Davenport > Joomla Leadership Team - Production Working Group > Joomla Documentation Coordinator
As Brian's post indicates, privacy is a big concern here. Tagging individual servers with IDs seems like a slippery slope unless that server is tagged temporarily and, again, leaves the user and server completely anonymous.
Honestly, this feels a bit intrusive despite my personally wanting these statistics.
If any tracking, tagging, or identifying were done solely during installation (we may want to expand that in the future, but it sounds like that's a good start) that information could easily be removed on that final step of removing the installation directory. Obviously personally identifiable information wouldn't be collected at all to begin with.
On Monday, 4 June 2012 07:43:45 UTC-4, Vic Drover wrote:
> As Brian's post indicates, privacy is a big concern here. Tagging > individual servers with IDs seems like a slippery slope unless that server > is tagged temporarily and, again, leaves the user and server completely > anonymous.
> Honestly, this feels a bit intrusive despite my personally wanting these > statistics.
> Tagging individual servers with IDs seems like a slippery slope unless > that server is tagged temporarily and, again, leaves the user and server > completely anonymous.
This id was fully anonymous and cannot be back-followed. If you have better idea how to prevent duplicating reports from the same server/sites then let us know :)
If it's anonymous, that's the most important. But rather then considering them duplicate reports, perhaps this info would be good for understanding how many times a user installs on the same server as a rough measure of failure rate?
> Tagging individual servers with IDs seems like a slippery slope unless
>> that server is tagged temporarily and, again, leaves the user and server
>> completely anonymous.
> This id was fully anonymous and cannot be back-followed.
> If you have better idea how to prevent duplicating reports from the same
> server/sites then let us know :)
> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cms+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> For best practice this should be :
> 1. Entirely optional opt-in only
> 2. The data sent should be displayed to the user before it is sent and
> confirmation again required before it is sent
> 3. the explanation of how, where, when and why the data is being collected
> and who it will be used for MUST be in simple language and NOT legalese and
> of course translated into all languages
> 4. It must be completely anonymous
> (the latter condition might effect where in Joomla the data collection
> can take place ie the installation is not truly translated in many
> languages)
I totally agree with this. In my mind I was picturing displaying the exact
record data to the admin with the "send" button. This way they could review
the exact amount of data being sent, and if something came up they were
uncomfortable with they could cancel at any time.
@Radek, thanks for your comments. Actually your implementation of this on
SOBI has been my reference point for the idea so far, so I appreciate your
comments as you've actually done this!
As Brian's post indicates, privacy is a big concern here. Tagging
> individual servers with IDs seems like a slippery slope unless that server
> is tagged temporarily and, again, leaves the user and server completely
> anonymous.
Vic I totally agree with you--the problem is, I don't know how else to do
it. I was thinking of exactly what Radek posted, which is kind of a hashed
up tag of some sort. An idea that crossed my mind is perhaps the "secret"
param in the CMS config file.
The reason I think that this would be a nice-to-have is because then after
an install, if someone does an update we can re-check (with permission!)
and update the record. This would provide more metrics like, how many
people after their first install actually keep the site updated.
As far as backward-tracing, I don't think that will be possible. We won't
be checking or recording IPs that will allow us to "go back" and find where
that server is.
@Chad, can you explain what you mean by "kept private"? Are you suggesting
> that this data not be shared with everyone, or that it be anonymous?
Rethinking what I said here, "kept private" isn't really what I meant :D I *
do* think it's important to make this information available. Extension
developers, blog-post-writers, media, etc... all deserve access to this. I
think a front-end somewhere which allows people to report on the data would
be important.
By kept private I was trying to say that we would ensure that the reporting
servers would be kept private, anonymous, and untraceable.
On Mon, Jun 4, 2012 at 8:16 AM, Matt Thomas <m...@betweenbrain.com> wrote:
> This sounds like a great idea to me as well. There's no doubt that the
> more information we have to base decisions on is better.
> Some sort of random unique ID to prevent duplicate reports is fully
> understandable, especially if it can't be traced back to the originator.
> I fully agree with Brian's points, especially that the data sent should
> be displayed to the user before it is sent.
> @Chad, can you explain what you mean by "kept private"? Are you
> suggesting that this data not be shared with everyone, or that it be
> anonymous?
> On Mon, Jun 4, 2012 at 7:58 AM, Radek Suski <suski.ra...@googlemail.com>wrote:
>> Tagging individual servers with IDs seems like a slippery slope unless
>>> that server is tagged temporarily and, again, leaves the user and server
>>> completely anonymous.
>> This id was fully anonymous and cannot be back-followed.
>> If you have better idea how to prevent duplicating reports from the same
>> server/sites then let us know :)
>> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
>> To unsubscribe from this group, send email to
>> joomla-dev-cms+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cms+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
Great idea. That would give us a precise picture, plus people not
participating can only blame to themselves that their config is not
taken in account in future support.
While I agree with Brian, I wouldn't make the privacy issue a big one
in this case.
The upgrades-checker would typically be a good place to give back only
the information that truly matters but that doesn't really affect
privacy of users:
1) joomla version (actually, it's implicitely given back already!)
2) PHP version
3) Database type and version
4) identification by IP address (that's already the case) since you
want to track servers evolution.
Advantage would be that there is already the upgrade checker, that it
already has a service, and that there would be a single point of
service and of decision, and that 2 out of the basic 4 infos are
already disclosed there. Plus it's a good incentive: "Want service ?
ok, then please help us improve it"
Additionally, depending on PHP and SQL versions, not only Joomla
itself, but also extensions providers would get same info, and could
serve specific upgrades or NOT depending on the versions. Thus admin
would not discover AFTER upgrade that he doesn't match new pre-
requisites, but BEFORE upgrade.....
Plus, it's super-easy to add the missing info there.
To maintain better anonymity, perhaps identification could be through a hash of unique variables associated with the installation…just an idea. An IP Address is not exactly anonymous.
Data collection can be a touchy subject and all of the points Brian made are good ones. Scott
On Tue, Jun 5, 2012 at 4:30 PM, Scoop <imscoo...@gmail.com> wrote:
> To maintain better anonymity, perhaps identification could be through a
> hash of unique variables associated with the installation…just an idea. An
> IP Address is not exactly anonymous.
> Data collection can be a touchy subject and all of the points Brian made
> are good ones.
> Scott
> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cms+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
Just to reiterate, my original post doesn't suggest storing an IP address.
The idea is to be anonymous / nontracable. If you check Radek's post you'll
see an example of a hashed index that is anonymous.
That said, I think that the hash needs to come from the "client" (the
server / Joomla Instance) sending the information. This means we can update
the record later. If we don't have some sort of unique (unique doesn't mean
traceable) identifier, we can't look at things again later when the Joomla
Instance is installing an upgrade.
In fact, with this requirement using an IP address would be a bad idea
because in the case where several Joomla instances are from the same server
and IP address, there would be some data integrity issues. So most
definitely, the IP address idea is out (and was never really "in").
> Totally agreed. The Ip adress should not be stored imho. That's
> backtrackable and could lead to information disclosure.
> Daniele Rosario
> On Tue, Jun 5, 2012 at 4:30 PM, Scoop <imscoo...@gmail.com> wrote:
>> To maintain better anonymity, perhaps identification could be through a
>> hash of unique variables associated with the installation…just an idea. An
>> IP Address is not exactly anonymous.
>> Data collection can be a touchy subject and all of the points Brian made
>> are good ones.
>> Scott
>> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
>> To unsubscribe from this group, send email to
>> joomla-dev-cms+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cms+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
I think it's fine -- and a good idea to use the IP address as one of the "variables" I mentioned to be hashed (it was intentionally plural). But I think you're right that alone, it's not sufficiently unique.
On Tuesday, June 5, 2012 10:39:38 AM UTC-4, Chad Windnagle wrote:
> Just to reiterate, my original post doesn't suggest storing an IP address. > The idea is to be anonymous / nontracable. If you check Radek's post you'll > see an example of a hashed index that is anonymous.
> That said, I think that the hash needs to come from the "client" (the > server / Joomla Instance) sending the information. This means we can update > the record later. If we don't have some sort of unique (unique doesn't mean > traceable) identifier, we can't look at things again later when the Joomla > Instance is installing an upgrade.
> In fact, with this requirement using an IP address would be a bad idea > because in the case where several Joomla instances are from the same server > and IP address, there would be some data integrity issues. So most > definitely, the IP address idea is out (and was never really "in").
> On Tue, Jun 5, 2012 at 10:33 AM, Daniele Rosario wrote:
>> Totally agreed. The Ip adress should not be stored imho. That's >> backtrackable and could lead to information disclosure.
>> Daniele Rosario
>> On Tue, Jun 5, 2012 at 4:30 PM, Scoop wrote:
>>> To maintain better anonymity, perhaps identification could be through a >>> hash of unique variables associated with the installation…just an idea. An >>> IP Address is not exactly anonymous.
>>> Data collection can be a touchy subject and all of the points Brian made >>> are good ones. >>> Scott
>>> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
>>> To unsubscribe from this group, send email to >>> joomla-dev-cms+unsubscribe@googlegroups.com.
>>> For more options, visit this group at >>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> -- >> You received this message because you are subscribed to the Google Groups >> "Joomla! CMS Development" group.
>> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
>> To unsubscribe from this group, send email to >> joomla-dev-cms+unsubscribe@googlegroups.com.
>> For more options, visit this group at >> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
On Tuesday, 5 June 2012 17:22:22 UTC+2, Scoop wrote:
> I think it's fine -- and a good idea to use the IP address as one of the > "variables" I mentioned to be hashed (it was intentionally plural). But I > think you're right that alone, it's not sufficiently unique.
> Scott
> On Tuesday, June 5, 2012 10:39:38 AM UTC-4, Chad Windnagle wrote:
>> Just to reiterate, my original post doesn't suggest storing an IP >> address. The idea is to be anonymous / nontracable. If you check Radek's >> post you'll see an example of a hashed index that is anonymous.
>> That said, I think that the hash needs to come from the "client" (the >> server / Joomla Instance) sending the information. This means we can update >> the record later. If we don't have some sort of unique (unique doesn't mean >> traceable) identifier, we can't look at things again later when the Joomla >> Instance is installing an upgrade.
>> In fact, with this requirement using an IP address would be a bad idea >> because in the case where several Joomla instances are from the same server >> and IP address, there would be some data integrity issues. So most >> definitely, the IP address idea is out (and was never really "in").
>> On Tue, Jun 5, 2012 at 10:33 AM, Daniele Rosario wrote:
>>> Totally agreed. The Ip adress should not be stored imho. That's >>> backtrackable and could lead to information disclosure.
>>> Daniele Rosario
>>> On Tue, Jun 5, 2012 at 4:30 PM, Scoop wrote:
>>>> To maintain better anonymity, perhaps identification could be through a >>>> hash of unique variables associated with the installation…just an idea. An >>>> IP Address is not exactly anonymous.
>>>> Data collection can be a touchy subject and all of the points Brian >>>> made are good ones. >>>> Scott
>>>> To post to this group, send an email to joomla-dev-cms@googlegroups.com
>>>> .
>>>> To unsubscribe from this group, send email to >>>> joomla-dev-cms+unsubscribe@googlegroups.com.
>>>> For more options, visit this group at >>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Joomla! CMS Development" group.
>>> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
>>> To unsubscribe from this group, send email to >>> joomla-dev-cms+unsubscribe@googlegroups.com.
>>> For more options, visit this group at >>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> IP Address + Live Site URL -> md5 :)
> I think it's unique enough and not possible to track back.
> Regards,
> Radek
> On Tuesday, 5 June 2012 17:22:22 UTC+2, Scoop wrote:
>> I think it's fine -- and a good idea to use the IP address as one of the
>> "variables" I mentioned to be hashed (it was intentionally plural). But I
>> think you're right that alone, it's not sufficiently unique.
>> Scott
>> On Tuesday, June 5, 2012 10:39:38 AM UTC-4, Chad Windnagle wrote:
>>> Just to reiterate, my original post doesn't suggest storing an IP
>>> address. The idea is to be anonymous / nontracable. If you check Radek's
>>> post you'll see an example of a hashed index that is anonymous.
>>> That said, I think that the hash needs to come from the "client" (the
>>> server / Joomla Instance) sending the information. This means we can update
>>> the record later. If we don't have some sort of unique (unique doesn't mean
>>> traceable) identifier, we can't look at things again later when the Joomla
>>> Instance is installing an upgrade.
>>> In fact, with this requirement using an IP address would be a bad idea
>>> because in the case where several Joomla instances are from the same server
>>> and IP address, there would be some data integrity issues. So most
>>> definitely, the IP address idea is out (and was never really "in").
>>> On Tue, Jun 5, 2012 at 10:33 AM, Daniele Rosario wrote:
>>>> Totally agreed. The Ip adress should not be stored imho. That's
>>>> backtrackable and could lead to information disclosure.
>>>> Daniele Rosario
>>>> On Tue, Jun 5, 2012 at 4:30 PM, Scoop wrote:
>>>>> To maintain better anonymity, perhaps identification could be through
>>>>> a hash of unique variables associated with the installation…just an idea.
>>>>> An IP Address is not exactly anonymous.
>>>>> Data collection can be a touchy subject and all of the points Brian
>>>>> made are good ones.
>>>>> Scott
>>>>> To post to this group, send an email to joomla-dev-cms@googlegroups.**
>>>>> com <joomla-dev-cms@googlegroups.com>.
>>>>> To unsubscribe from this group, send email to
>>>>> joomla-dev-cms+unsubscribe@**googlegroups.com<joomla-dev-cms%2Bunsubscribe@ googlegroups.com>
>>>>> .
>>>>> For more options, visit this group at http://groups.google.com/** >>>>> group/joomla-dev-cms?hl=en-GB<http://groups.google.com/group/joomla-dev-cms?hl=en-GB>
>>>>> .
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Joomla! CMS Development" group.
>>>> To post to this group, send an email to joomla-dev-cms@googlegroups.**
>>>> com <joomla-dev-cms@googlegroups.com>.
>>>> To unsubscribe from this group, send email to
>>>> joomla-dev-cms+unsubscribe@**googlegroups.com<joomla-dev-cms%2Bunsubscribe@ googlegroups.com>
>>>> .
>>>> For more options, visit this group at http://groups.google.com/** >>>> group/joomla-dev-cms?hl=en-GB<http://groups.google.com/group/joomla-dev-cms?hl=en-GB>
>>>> .
> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cms+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
On Tue, Jun 5, 2012 at 8:45 AM, Matt Thomas <m...@betweenbrain.com> wrote:
> If someone was to obtain, or intercept that data, couldn't they decrypt it?
> Best,
> Matt Thomas
> Founder betweenbrain™
> Lead Developer Construct Template Development Framework
> Phone: 203.632.9322
> Twitter: @betweenbrain
> Github: https://github.com/betweenbrain
> On Tue, Jun 5, 2012 at 11:42 AM, Radek Suski <suski.ra...@googlemail.com>
> wrote:
>> IP Address + Live Site URL -> md5 :)
>> I think it's unique enough and not possible to track back.
>> Regards,
>> Radek
>> On Tuesday, 5 June 2012 17:22:22 UTC+2, Scoop wrote:
>>> I think it's fine -- and a good idea to use the IP address as one of the
>>> "variables" I mentioned to be hashed (it was intentionally plural). But I
>>> think you're right that alone, it's not sufficiently unique.
>>> Scott
>>> On Tuesday, June 5, 2012 10:39:38 AM UTC-4, Chad Windnagle wrote:
>>>> Just to reiterate, my original post doesn't suggest storing an IP
>>>> address. The idea is to be anonymous / nontracable. If you check Radek's
>>>> post you'll see an example of a hashed index that is anonymous.
>>>> That said, I think that the hash needs to come from the "client" (the
>>>> server / Joomla Instance) sending the information. This means we can update
>>>> the record later. If we don't have some sort of unique (unique doesn't mean
>>>> traceable) identifier, we can't look at things again later when the Joomla
>>>> Instance is installing an upgrade.
>>>> In fact, with this requirement using an IP address would be a bad idea
>>>> because in the case where several Joomla instances are from the same server
>>>> and IP address, there would be some data integrity issues. So most
>>>> definitely, the IP address idea is out (and was never really "in").
>>>> -Chad
>>>> Regards,
>>>> Chad Windnagle
>>>> Fight SOPA
>>>> On Tue, Jun 5, 2012 at 10:33 AM, Daniele Rosario wrote:
>>>>> Totally agreed. The Ip adress should not be stored imho. That's
>>>>> backtrackable and could lead to information disclosure.
>>>>> Daniele Rosario
>>>>> On Tue, Jun 5, 2012 at 4:30 PM, Scoop wrote:
>>>>>> To maintain better anonymity, perhaps identification could be through
>>>>>> a hash of unique variables associated with the installation…just an idea. An
>>>>>> IP Address is not exactly anonymous.
>>>>>> Data collection can be a touchy subject and all of the points Brian
>>>>>> made are good ones.
>>>>>> Scott
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "Joomla! CMS Development" group.
>>>>>> To view this discussion on the web, visit
>>>>>> https://groups.google.com/d/msg/joomla-dev-cms/-/jotssdATGtEJ.
>>>>>> To post to this group, send an email to
>>>>>> joomla-dev-cms@googlegroups.com.
>>>>>> To unsubscribe from this group, send email to
>>>>>> joomla-dev-cms+unsubscribe@googlegroups.com.
>>>>>> For more options, visit this group at
>>>>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Joomla! CMS Development" group.
>>>>> To post to this group, send an email to
>>>>> joomla-dev-cms@googlegroups.com.
>>>>> To unsubscribe from this group, send email to
>>>>> joomla-dev-cms+unsubscribe@googlegroups.com.
>>>>> For more options, visit this group at
>>>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
>> To unsubscribe from this group, send email to
>> joomla-dev-cms+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cms+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> On Tue, Jun 5, 2012 at 8:45 AM, Matt Thomas <m...@betweenbrain.com> > wrote: > > If someone was to obtain, or intercept that data, couldn't they decrypt > it?
> > Best,
> > Matt Thomas > > Founder betweenbrain™ > > Lead Developer Construct Template Development Framework > > Phone: 203.632.9322 > > Twitter: @betweenbrain > > Github: https://github.com/betweenbrain
> > On Tue, Jun 5, 2012 at 11:42 AM, Radek Suski <suski.ra...@googlemail.com>
> > wrote:
> >> IP Address + Live Site URL -> md5 :) > >> I think it's unique enough and not possible to track back.
> >> Regards, > >> Radek
> >> On Tuesday, 5 June 2012 17:22:22 UTC+2, Scoop wrote:
> >>> I think it's fine -- and a good idea to use the IP address as one of > the > >>> "variables" I mentioned to be hashed (it was intentionally plural). > But I > >>> think you're right that alone, it's not sufficiently unique.
> >>> Scott
> >>> On Tuesday, June 5, 2012 10:39:38 AM UTC-4, Chad Windnagle wrote:
> >>>> Just to reiterate, my original post doesn't suggest storing an IP > >>>> address. The idea is to be anonymous / nontracable. If you check > Radek's > >>>> post you'll see an example of a hashed index that is anonymous.
> >>>> That said, I think that the hash needs to come from the "client" (the > >>>> server / Joomla Instance) sending the information. This means we can > update > >>>> the record later. If we don't have some sort of unique (unique > doesn't mean > >>>> traceable) identifier, we can't look at things again later when the > Joomla > >>>> Instance is installing an upgrade.
> >>>> In fact, with this requirement using an IP address would be a bad > idea > >>>> because in the case where several Joomla instances are from the same > server > >>>> and IP address, there would be some data integrity issues. So most > >>>> definitely, the IP address idea is out (and was never really "in").
> >>>> On Tue, Jun 5, 2012 at 10:33 AM, Daniele Rosario wrote:
> >>>>> Totally agreed. The Ip adress should not be stored imho. That's > >>>>> backtrackable and could lead to information disclosure.
> >>>>> Daniele Rosario
> >>>>> On Tue, Jun 5, 2012 at 4:30 PM, Scoop wrote:
> >>>>>> To maintain better anonymity, perhaps identification could be > through > >>>>>> a hash of unique variables associated with the installation…just an > idea. An > >>>>>> IP Address is not exactly anonymous.
> >>>>>> Data collection can be a touchy subject and all of the points Brian > >>>>>> made are good ones.
> >>>>>> Scott
> >>>>>> -- > >>>>>> You received this message because you are subscribed to the Google > >>>>>> Groups "Joomla! CMS Development" group. > >>>>>> To view this discussion on the web, visit > >>>>>> https://groups.google.com/d/msg/joomla-dev-cms/-/jotssdATGtEJ.
> >>>>>> To post to this group, send an email to > >>>>>> joomla-dev-cms@googlegroups.com. > >>>>>> To unsubscribe from this group, send email to > >>>>>> joomla-dev-cms+unsubscribe@googlegroups.com. > >>>>>> For more options, visit this group at > >>>>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> >>>>> -- > >>>>> You received this message because you are subscribed to the Google > >>>>> Groups "Joomla! CMS Development" group. > >>>>> To post to this group, send an email to > >>>>> joomla-dev-cms@googlegroups.com. > >>>>> To unsubscribe from this group, send email to > >>>>> joomla-dev-cms+unsubscribe@googlegroups.com. > >>>>> For more options, visit this group at > >>>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> > -- > > You received this message because you are subscribed to the Google > Groups > > "Joomla! CMS Development" group. > > To post to this group, send an email to joomla-dev-cms@googlegroups.com.
> On Tue, Jun 5, 2012 at 8:45 AM, Matt Thomas <m...@betweenbrain.com> wrote:
> > If someone was to obtain, or intercept that data, couldn't they decrypt
> it?
> > Best,
> > Matt Thomas
> > Founder betweenbrain™
> > Lead Developer Construct Template Development Framework
> > Phone: 203.632.9322
> > Twitter: @betweenbrain
> > Github: https://github.com/betweenbrain
> > On Tue, Jun 5, 2012 at 11:42 AM, Radek Suski <suski.ra...@googlemail.com
> > wrote:
> >> IP Address + Live Site URL -> md5 :)
> >> I think it's unique enough and not possible to track back.
> >> Regards,
> >> Radek
> >> On Tuesday, 5 June 2012 17:22:22 UTC+2, Scoop wrote:
> >>> I think it's fine -- and a good idea to use the IP address as one of
> the
> >>> "variables" I mentioned to be hashed (it was intentionally plural).
> But I
> >>> think you're right that alone, it's not sufficiently unique.
> >>> Scott
> >>> On Tuesday, June 5, 2012 10:39:38 AM UTC-4, Chad Windnagle wrote:
> >>>> Just to reiterate, my original post doesn't suggest storing an IP
> >>>> address. The idea is to be anonymous / nontracable. If you check
> Radek's
> >>>> post you'll see an example of a hashed index that is anonymous.
> >>>> That said, I think that the hash needs to come from the "client" (the
> >>>> server / Joomla Instance) sending the information. This means we can
> update
> >>>> the record later. If we don't have some sort of unique (unique
> doesn't mean
> >>>> traceable) identifier, we can't look at things again later when the
> Joomla
> >>>> Instance is installing an upgrade.
> >>>> In fact, with this requirement using an IP address would be a bad idea
> >>>> because in the case where several Joomla instances are from the same
> server
> >>>> and IP address, there would be some data integrity issues. So most
> >>>> definitely, the IP address idea is out (and was never really "in").
> >>>> On Tue, Jun 5, 2012 at 10:33 AM, Daniele Rosario wrote:
> >>>>> Totally agreed. The Ip adress should not be stored imho. That's
> >>>>> backtrackable and could lead to information disclosure.
> >>>>> Daniele Rosario
> >>>>> On Tue, Jun 5, 2012 at 4:30 PM, Scoop wrote:
> >>>>>> To maintain better anonymity, perhaps identification could be
> through
> >>>>>> a hash of unique variables associated with the installation…just an
> idea. An
> >>>>>> IP Address is not exactly anonymous.
> >>>>>> Data collection can be a touchy subject and all of the points Brian
> >>>>>> made are good ones.
> >>>>>> Scott
> >>>>>> --
> >>>>>> You received this message because you are subscribed to the Google
> >>>>>> Groups "Joomla! CMS Development" group.
> >>>>>> To view this discussion on the web, visit
> >>>>>> https://groups.google.com/d/msg/joomla-dev-cms/-/jotssdATGtEJ.
> >>>>>> To post to this group, send an email to
> >>>>>> joomla-dev-cms@googlegroups.com.
> >>>>>> To unsubscribe from this group, send email to
> >>>>>> joomla-dev-cms+unsubscribe@googlegroups.com.
> >>>>>> For more options, visit this group at
> >>>>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> >>>>> --
> >>>>> You received this message because you are subscribed to the Google
> >>>>> Groups "Joomla! CMS Development" group.
> >>>>> To post to this group, send an email to
> >>>>> joomla-dev-cms@googlegroups.com.
> >>>>> To unsubscribe from this group, send email to
> >>>>> joomla-dev-cms+unsubscribe@googlegroups.com.
> >>>>> For more options, visit this group at
> >>>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> >> To post to this group, send an email to joomla-dev-cms@googlegroups.com
> .
> >> To unsubscribe from this group, send email to
> >> joomla-dev-cms+unsubscribe@googlegroups.com.
> >> For more options, visit this group at
> >> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Joomla! CMS Development" group.
> > To post to this group, send an email to joomla-dev-cms@googlegroups.com.
> > To unsubscribe from this group, send email to
> > joomla-dev-cms+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cms+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> On Tue, Jun 5, 2012 at 8:45 AM, Matt Thomas <m...@betweenbrain.com>
>> wrote:
>> > If someone was to obtain, or intercept that data, couldn't they decrypt
>> it?
>> > Best,
>> > Matt Thomas
>> > Founder betweenbrain™
>> > Lead Developer Construct Template Development Framework
>> > Phone: 203.632.9322
>> > Twitter: @betweenbrain
>> > Github: https://github.com/betweenbrain
>> > On Tue, Jun 5, 2012 at 11:42 AM, Radek Suski <
>> suski.ra...@googlemail.com>
>> > wrote:
>> >> IP Address + Live Site URL -> md5 :)
>> >> I think it's unique enough and not possible to track back.
>> >> Regards,
>> >> Radek
>> >> On Tuesday, 5 June 2012 17:22:22 UTC+2, Scoop wrote:
>> >>> I think it's fine -- and a good idea to use the IP address as one of
>> the
>> >>> "variables" I mentioned to be hashed (it was intentionally plural).
>> But I
>> >>> think you're right that alone, it's not sufficiently unique.
>> >>> Scott
>> >>> On Tuesday, June 5, 2012 10:39:38 AM UTC-4, Chad Windnagle wrote:
>> >>>> Just to reiterate, my original post doesn't suggest storing an IP
>> >>>> address. The idea is to be anonymous / nontracable. If you check
>> Radek's
>> >>>> post you'll see an example of a hashed index that is anonymous.
>> >>>> That said, I think that the hash needs to come from the "client" (the
>> >>>> server / Joomla Instance) sending the information. This means we can
>> update
>> >>>> the record later. If we don't have some sort of unique (unique
>> doesn't mean
>> >>>> traceable) identifier, we can't look at things again later when the
>> Joomla
>> >>>> Instance is installing an upgrade.
>> >>>> In fact, with this requirement using an IP address would be a bad
>> idea
>> >>>> because in the case where several Joomla instances are from the same
>> server
>> >>>> and IP address, there would be some data integrity issues. So most
>> >>>> definitely, the IP address idea is out (and was never really "in").
>> >>>> On Tue, Jun 5, 2012 at 10:33 AM, Daniele Rosario wrote:
>> >>>>> Totally agreed. The Ip adress should not be stored imho. That's
>> >>>>> backtrackable and could lead to information disclosure.
>> >>>>> Daniele Rosario
>> >>>>> On Tue, Jun 5, 2012 at 4:30 PM, Scoop wrote:
>> >>>>>> To maintain better anonymity, perhaps identification could be
>> through
>> >>>>>> a hash of unique variables associated with the installation…just
>> an idea. An
>> >>>>>> IP Address is not exactly anonymous.
>> >>>>>> Data collection can be a touchy subject and all of the points Brian
>> >>>>>> made are good ones.
>> >>>>>> Scott
>> >>>>>> --
>> >>>>>> You received this message because you are subscribed to the Google
>> >>>>>> Groups "Joomla! CMS Development" group.
>> >>>>>> To view this discussion on the web, visit
>> >>>>>> https://groups.google.com/d/msg/joomla-dev-cms/-/jotssdATGtEJ.
>> >>>>>> To post to this group, send an email to
>> >>>>>> joomla-dev-cms@googlegroups.com.
>> >>>>>> To unsubscribe from this group, send email to
>> >>>>>> joomla-dev-cms+unsubscribe@googlegroups.com.
>> >>>>>> For more options, visit this group at
>> >>>>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> >>>>> --
>> >>>>> You received this message because you are subscribed to the Google
>> >>>>> Groups "Joomla! CMS Development" group.
>> >>>>> To post to this group, send an email to
>> >>>>> joomla-dev-cms@googlegroups.com.
>> >>>>> To unsubscribe from this group, send email to
>> >>>>> joomla-dev-cms+unsubscribe@googlegroups.com.
>> >>>>> For more options, visit this group at
>> >>>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> >> --
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >> "Joomla! CMS Development" group.
>> >> To view this discussion on the web, visit
>> >> https://groups.google.com/d/msg/joomla-dev-cms/-/VU9oOQw_S2EJ.
>> >> To post to this group, send an email to
>> joomla-dev-cms@googlegroups.com.
>> >> To unsubscribe from this group, send email to
>> >> joomla-dev-cms+unsubscribe@googlegroups.com.
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Joomla! CMS Development" group.
>> > To post to this group, send an email to joomla-dev-cms@googlegroups.com
>> .
>> > To unsubscribe from this group, send email to
>> > joomla-dev-cms+unsubscribe@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Joomla! CMS Development" group.
>> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
>> To unsubscribe from this group, send email to
>> joomla-dev-cms+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cms+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> On Tue, Jun 5, 2012 at 8:45 AM, Matt Thomas <m...@betweenbrain.com> >> wrote:
>> > If someone was to obtain, or intercept that data, couldn't they decrypt >> it?
>> > Best,
>> > Matt Thomas
>> > Founder betweenbrain™
>> > Lead Developer Construct Template Development Framework
>> > Phone: 203.632.9322
>> > Twitter: @betweenbrain
>> > Github: https://github.com/betweenbrain
>> > On Tue, Jun 5, 2012 at 11:42 AM, Radek Suski <
>> suski.ra...@googlemail.com>
>> > wrote:
>> >> IP Address + Live Site URL -> md5 :)
>> >> I think it's unique enough and not possible to track back.
>> >> Regards,
>> >> Radek
>> >> On Tuesday, 5 June 2012 17:22:22 UTC+2, Scoop wrote:
>> >>> I think it's fine -- and a good idea to use the IP address as one of >> the
>> >>> "variables" I mentioned to be hashed (it was intentionally plural). >> But I
>> >>> think you're right that alone, it's not sufficiently unique.
>> >>> Scott
>> >>> On Tuesday, June 5, 2012 10:39:38 AM UTC-4, Chad Windnagle wrote:
>> >>>> Just to reiterate, my original post doesn't suggest storing an IP
>> >>>> address. The idea is to be anonymous / nontracable. If you check >> Radek's
>> >>>> post you'll see an example of a hashed index that is anonymous.
>> >>>> That said, I think that the hash needs to come from the "client" (the
>> >>>> server / Joomla Instance) sending the information. This means we can >> update
>> >>>> the record later. If we don't have some sort of unique (unique >> doesn't mean
>> >>>> traceable) identifier, we can't look at things again later when the >> Joomla
>> >>>> Instance is installing an upgrade.
>> >>>> In fact, with this requirement using an IP address would be a bad >> idea
>> >>>> because in the case where several Joomla instances are from the same >> server
>> >>>> and IP address, there would be some data integrity issues. So most
>> >>>> definitely, the IP address idea is out (and was never really "in").
>> >>>> On Tue, Jun 5, 2012 at 10:33 AM, Daniele Rosario wrote:
>> >>>>> Totally agreed. The Ip adress should not be stored imho. That's
>> >>>>> backtrackable and could lead to information disclosure.
>> >>>>> Daniele Rosario
>> >>>>> On Tue, Jun 5, 2012 at 4:30 PM, Scoop wrote:
>> >>>>>> To maintain better anonymity, perhaps identification could be >> through
>> >>>>>> a hash of unique variables associated with the installation…just >> an idea. An
>> >>>>>> IP Address is not exactly anonymous.
>> >>>>>> Data collection can be a touchy subject and all of the points Brian
>> >>>>>> made are good ones.
>> >>>>>> Scott
>> >>>>>> --
>> >>>>>> You received this message because you are subscribed to the Google
>> >>>>>> Groups "Joomla! CMS Development" group.
>> >>>>>> To view this discussion on the web, visit
>> >>>>>> https://groups.google.com/d/msg/joomla-dev-cms/-/jotssdATGtEJ.
>> >>>>>> To post to this group, send an email to
>> >>>>>> joomla-dev-cms@googlegroups.com.
>> >>>>>> To unsubscribe from this group, send email to
>> >>>>>> joomla-dev-cms+unsubscribe@googlegroups.com.
>> >>>>>> For more options, visit this group at
>> >>>>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> >>>>> --
>> >>>>> You received this message because you are subscribed to the Google
>> >>>>> Groups "Joomla! CMS Development" group.
>> >>>>> To post to this group, send an email to
>> >>>>> joomla-dev-cms@googlegroups.com.
>> >>>>> To unsubscribe from this group, send email to
>> >>>>> joomla-dev-cms+unsubscribe@googlegroups.com.
>> >>>>> For more options, visit this group at
>> >>>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> >> --
>> >> You received this message because you are subscribed to the Google >> Groups
>> >> "Joomla! CMS Development" group.
>> >> To view this discussion on the web, visit
>> >> https://groups.google.com/d/msg/joomla-dev-cms/-/VU9oOQw_S2EJ.
>> >> To post to this group, send an email to >> joomla-dev-cms@googlegroups.com.
>> >> To unsubscribe from this group, send email to
>> >> joomla-dev-cms+unsubscribe@googlegroups.com.
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> > --
>> > You received this message because you are subscribed to the Google >> Groups
>> > "Joomla! CMS Development" group.
>> > To post to this group, send an email to joomla-dev-cms@googlegroups.com
>> .
>> > To unsubscribe from this group, send email to
>> > joomla-dev-cms+unsubscribe@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> --
>> You received this message because you are subscribed to the Google Groups >> "Joomla! CMS Development" group.
>> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
>> To unsubscribe from this group, send email to >> joomla-dev-cms+unsubscribe@googlegroups.com.
>> For more options, visit this group at >> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
