Skip to content
This repository has been archived by the owner on Mar 7, 2019. It is now read-only.

Automatic Newer Version Checks #424

Closed
kgiszewski opened this issue Sep 5, 2017 · 9 comments
Closed

Automatic Newer Version Checks #424

kgiszewski opened this issue Sep 5, 2017 · 9 comments

Comments

@kgiszewski
Copy link
Owner

kgiszewski commented Sep 5, 2017

I'm pondering adding a version check to Archetype. The reason is two-fold.

  1. Notify the user of a newer version
  2. Allow Archetype core members to get a sense of how many active installs exist in the wild (the main reason I want to propose this)

As a general concept, we'd have to allow for a user to opt-out. I would automatically opt them in on install.

The 'check' would happen each time an Archetype configuration was displayed.

The opt-out would need to be global which might be a challenge since the Archetype configuration screens are instance based. Maybe an AppSetting will suffice, but a GUI would be more friendly.

I propose storing the 'current version' on a server and the 'check' sends the following information to that server:

  • Current Archetype version
  • Current Umbraco Core version
  • Domain (i.e. foo.local) Public IP of the request A random GUID generated on install

The Archetype JS code would proxy the request to server side code which would then attempt to make a server side HTTPS call to the Archetype server.

We would probably need to disclose what information is being sent and make it apart of the Terms of Service (which currently do not exist) https://github.com/kgiszewski/Archetype/blob/master/Terms%20of%20Service.md.

Looking to gather any support or resistance :) Spitballing of ideas on how to implement is also solicited :)

Bottom line is that knowing how many active installs would be a decision input in regards to future development and\or support.

A non-scientific poll on the topic: https://twitter.com/KevinGiszewski/status/905075499277234180

@kgiszewski
Copy link
Owner Author

One thing I think we can do to address privacy concerns is to NOT collect the domain rather simply record the public IP of the request. That way it's not divulging anything that we might use to figure out a client name (which we don't want to do).

@kgiszewski
Copy link
Owner Author

Proof of concept...

image

@kgiszewski
Copy link
Owner Author

image

@Nicholas-Westby
Copy link
Contributor

I will definitely be turning off this feature (I do the same with the Umbraco core update notifications), but the fact that you've made it so easy to do so by making it editable in the UI is much appreciated!

If you really want to go above and beyond, you could allow for a unique identifier to be configured so that it could be used in place of the public IP address. On install or first run, you could set that identifier to a randomly generated string (perhaps a GUID). That way, not even an IP address is logged, which would possibly ease some privacy concerns.

Also, you might want to clarify in your notification that it's Archetype that has a new release (otherwise people might assume it's for something else, such as the Umbraco core).

@kgiszewski
Copy link
Owner Author

@Nicholas-Westby Funny you mention the GUID. I thought of that exact solution. If I go that route I'm not sure people would be 'convinced' we're not logging by IP since the request has to go somewhere and it'll leave the footprint.

I do like the GUID idea b/c it's useless in a hacked DB situation and I will probably take that approach.

I'm a bit terrified about the response I might get on this :) However I think we HAVE to have some sort of 'active installs' metric to base any sort of future viability of this project. Just using the number of Nuget installs is probably not even close to reliable.

Seems just about every app has some sort of 'ping back' mechanism these days. Seems this might be new territory for a plugin in the Umbraco eco-system.

I have been pondering a 'News' tab as well that would give us a conduit to users.

I'm also pondering 'sponsors' that could get a logo well placed in the config area.

@Nicholas-Westby
Copy link
Contributor

If I go that route I'm not sure people would be 'convinced' we're not logging by IP since the request has to go somewhere and it'll leave the footprint.

The way I see that, you can either add a clarification (e.g., to the terms of use) that explicitly indicate you are definitely not logging the IP address, or you can be clear about that not being true and just include this image:

no-good

I think as long as you're transparent about what you're doing and you provide an easy way to opt out, most peeps should accept the idea :-)

@kgiszewski
Copy link
Owner Author

Yea, I'm putting everything in the open except the destination API.

Terms of service will probably be an external link to a living document.

I might have to provide a popup about the TOS.

@kgiszewski
Copy link
Owner Author

PR out for review. Would like this to go in the next release.

@kgiszewski
Copy link
Owner Author

Merged in

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants