One IP address can represent many machines if they are behind a NAT device. Now that North America has run out of IP addresses to be assigned, I expect carrier grade NATs will be used by more ISPs than in the past.
IP addresses as a means of identification is a bad idea. ----- Rom From: Filip Rydlo [mailto:filip.ry...@gmail.com] Sent: Monday, September 28, 2015 3:49 AM To: Rom Walton <r...@romwnet.org> Cc: BOINC-dev email list <boinc_dev@ssl.berkeley.edu> Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs) Yes, Rom. It really seems like a monster on the client side. This is neither easy nor error-proof. So, ... : Why not to save the unique "GUID" (generated by the server) + all this info (with perfectly encrypted password) in a dedicated (MySQL) DATABASE on the main BOINC web-server? (it could be easily "cron"-ned to be cleaned from old entries and Vacuum-analyzed every 4 hours or so) It would be browser-independent. IT would be easily implemented as temporary and as valid only for the given I.P. address - which is the same (during a short interval like 1 hour) across all browsers on the PC / VM , as far as I know. Namaste Filip 2015-09-28 2:44 GMT+02:00 Rom Walton <r...@romwnet.org<mailto:r...@romwnet.org>>: GUID would be more appropriate. I foresee a few problems with this approach though: 1. The ‘default’ browser wxWidgets detects may not be the browser the volunteer downloaded BOINC with. 2. The manager would have to wait on the association to complete which means it has to know how to deal with whatever browser to launched. (Basically the manager would have to know how each browser works. (window names, window class names, window titles, what events each window responds too)) (This is actually a more complicated problem than dealing with cookies.) 3. We may never be able to find out if the association was successful from the manager perspective. 4. Some browser plugins redirect errors and monkey with the error pages. (Norton 360, Google Toolbar, Yahoo Toolbar, etc.) 5. There is a remote possibility that two machines can generate the same GUID, without being able to check against the master list ahead of time it could happen. This solution might look okay from a server perspective, but it is a monster from a client implementation perspective. ----- Rom From: hugh.w...@gmail.com<mailto:hugh.w...@gmail.com> [mailto:hugh.w...@gmail.com<mailto:hugh.w...@gmail.com>] On Behalf Of Hugh Wormington Sent: Sunday, September 27, 2015 5:22 PM To: Rom Walton <r...@romwnet.org<mailto:r...@romwnet.org>> Cc: Matthew Blumberg <m...@gridrepublic.org<mailto:m...@gridrepublic.org>>; Hugh Wormington <h...@gridrepublic.org<mailto:h...@gridrepublic.org>>; Rytis Slatkevičius <ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>>; BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>> Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs) > Where is the nonce generated? By the installer. > If it is generated by the installer and passed to the account manager, how to > we know who it came from? The installer loads a browser on the url passing the "nonce" as a url parameter. The receiving page is then able to associate it with a logged-in user, after which the association is known. A little side issue for avoidance of lexical confusion.... I'm a little unsure if this is really a "nonce" : * Nonce: is an arbitrary number that may only be used once in secure communication exchange (See diagram on this wikipedia page<https://en.wikipedia.org/wiki/Cryptographic_nonce>) It doesn't carry any information itself. * GUID: A globally unique identifier (GUID, /ˈɡuːɪd/) is a unique reference number used as an identifier in computer software. The term "GUID" typically refers to various implementations of the universally unique identifier<https://en.wikipedia.org/wiki/Universally_unique_identifier> (UUID) standard (Wikipedia<https://en.wikipedia.org/wiki/Globally_unique_identifier>) I think we're talking about a GUID which the installer generates at install time and uses to identify itself to two different processes 1) the front end web application 2) the account manager server. (A CPID is a kind of GUID, but this one isn't a CPID, since CPIDs are (AFAIK) generated by the BOINC project servers.) So is it a nonce or a GUID? Hugh PS Many apologies if I'm teaching grandmothers to suck eggs (does that work internationally??). On 26 September 2015 at 02:56, Rom Walton <r...@romwnet.org<mailto:r...@romwnet.org><mailto:r...@romwnet.org<mailto:r...@romwnet.org>>> wrote: In theory we could open up a browser with a URL like that. Where is the nonce generated? If it is generated from the account manager, how does the installer find it? If it is generated by the installer and passed to the account manager, how to we know who it came from? ----- Rom From: mblumb...@picador.net<mailto:mblumb...@picador.net><mailto:mblumb...@picador.net<mailto:mblumb...@picador.net>> [mailto:mblumb...@picador.net<mailto:mblumb...@picador.net><mailto:mblumb...@picador.net<mailto:mblumb...@picador.net>>] On Behalf Of Matthew Blumberg Sent: Friday, September 25, 2015 6:27 PM To: Rom Walton <r...@romwnet.org<mailto:r...@romwnet.org><mailto:r...@romwnet.org<mailto:r...@romwnet.org>>> Cc: Hugh Wormington <h...@gridrepublic.org<mailto:h...@gridrepublic.org><mailto:h...@gridrepublic.org<mailto:h...@gridrepublic.org>>>; Rytis Slatkevičius <ry...@gridrepublic.org<mailto:ry...@gridrepublic.org><mailto:ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>>>; BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu><mailto:boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>>> Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs) So for GR/CE/PTP you end up with filenames like: gr_setup_asc_ODU0NjVfZWEwYWJkNjc4NDc2MjllMWFlOWVkM2I4YWRmZmZmZmY=.exe i'm really not comfortable with filenames like that for AMS, is it possible to : 1. open a browser window upon completion of install (*as is done already); but instead of using return_url from the cookie, use instead the URL from acct_mgr_url.xml, and append a random number as a parameter, e.g. http://acctmgr.com/?return_id=[nonce]<http://acctmgr.com/?return_id=%5bnonce%5d><http://acctmgr.com/?return_id=%5bnonce%5d> 2. and then also use that same return_id as the user email address (e.g. as of the user had entered this into the email field when registering manually) (*tristan/rytis/hught, pls add any clarification if i'm missing something or got something wrong) On Fri, Sep 25, 2015 at 10:21 AM, Rom Walton <r...@romwnet.org<mailto:r...@romwnet.org><mailto:r...@romwnet.org<mailto:r...@romwnet.org>>> wrote: A point of clarification. Everything the client needs to communicate with a project/account manager will be in project_init.xml or acct_mgr_url.xml. All that will be missing to do an attach is an authenticator. ----- Rom -----Original Message----- From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu<mailto:boinc_dev-boun...@ssl.berkeley.edu><mailto:boinc_dev-boun...@ssl.berkeley.edu<mailto:boinc_dev-boun...@ssl.berkeley.edu>>] On Behalf Of Rom Walton Sent: Friday, September 25, 2015 10:02 AM To: Hugh Wormington <h...@gridrepublic.org<mailto:h...@gridrepublic.org><mailto:h...@gridrepublic.org<mailto:h...@gridrepublic.org>>>; Rytis Slatkevičius <ry...@gridrepublic.org<mailto:ry...@gridrepublic.org><mailto:ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>>> Cc: Matthew Blumberg <m...@gridrepublic.org<mailto:m...@gridrepublic.org><mailto:m...@gridrepublic.org<mailto:m...@gridrepublic.org>>>; BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu><mailto:boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>>> Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs) In essence this is what the setup cookie is for. In cases where there is a customized installer, everything the client needs will be in the project_init.xml or acct_mgr_url.xml (in the case of account managers) files. BOINC will treat the setup cookie as opaque data and just send it back to https://<project_url>/lookup_account.php<https://%3cproject_url%3e/lookup_account.php<https://%3cproject_url%3e/lookup_account.php%3chttps:/%3cproject_url%3e/lookup_account.php<https://%3cproject_url%3e/lookup_account.php%3chttps:/%3cproject_url%3e/lookup_account.php%3chttps:/%3cproject_url%3e/lookup_account.php%3chttps:/%3cproject_url%3e/lookup_account.php>>>. So for GR/CE/PTP you end up with filenames like: gr_setup_asc_ODU0NjVfZWEwYWJkNjc4NDc2MjllMWFlOWVkM2I4YWRmZmZmZmY=.exe The filename can be made shorter as it depends on how large you want your random piece of data to be. ----- Rom From: hugh.w...@gmail.com<mailto:hugh.w...@gmail.com><mailto:hugh.w...@gmail.com<mailto:hugh.w...@gmail.com>> [mailto:hugh.w...@gmail.com<mailto:hugh.w...@gmail.com><mailto:hugh.w...@gmail.com<mailto:hugh.w...@gmail.com>>] On Behalf Of Hugh Wormington Sent: Friday, September 25, 2015 6:56 AM To: Rytis Slatkevičius <ry...@gridrepublic.org<mailto:ry...@gridrepublic.org><mailto:ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>>> Cc: Matthew Blumberg <m...@gridrepublic.org<mailto:m...@gridrepublic.org><mailto:m...@gridrepublic.org<mailto:m...@gridrepublic.org>>>; Rom Walton <r...@romwnet.org<mailto:r...@romwnet.org><mailto:r...@romwnet.org<mailto:r...@romwnet.org>>>; BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu><mailto:boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>>>; Tristan Olive <tol...@gridrepublic.org<mailto:tol...@gridrepublic.org><mailto:tol...@gridrepublic.org<mailto:tol...@gridrepublic.org>>>; Hugh Wormington <h...@gridrepublic.org<mailto:h...@gridrepublic.org><mailto:h...@gridrepublic.org<mailto:h...@gridrepublic.org>>> Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs) Further to Rytis's email (is this the place to continue this discussion or in Jira?): I agree, but I think the stored meta data need not include user info, only the project url. The installer would load a page on boinc.berkeley.edu<http://boinc.berkeley.edu><http://boinc.berkeley.edu><http://boinc.berkeley.edu> in a browser, passing the nonce or cipid or guid as a URL parameter (whichever variant is adopted). That in turn would forward it to the project site. At this point the project site could receive the cookies it set earlier (private and secure), and the nonce/cipid/guid and continue the process. If it finds no cookies it can ask the user to log in to the project site and then continue. Hugh On 25 September 2015 at 07:48, Rytis Slatkevičius <ry...@gridrepublic.org<mailto:ry...@gridrepublic.org><mailto:ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>><mailto:ry...@gridrepublic.org<mailto:ry...@gridrepublic.org><mailto:ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>>>> wrote: Is there really a need for such schemes? A script will be running to generate the download filenames (I assume at boinc.berkeley.edu<http://boinc.berkeley.edu><http://boinc.berkeley.edu><http://boinc.berkeley.edu>); why not store user's temporary metadata on the server instead of passing it through the installer filename, and look it up based on the IP address? There are not going to be any clashes if metadata is stored for only a short while. The process would be as follows: 1. The user registers at a website; 2. The website sends an RPC to boinc.berkeley.edu<http://boinc.berkeley.edu><http://boinc.berkeley.edu><http://boinc.berkeley.edu> (or other URLs, e.g. in case of a custom build), storing metadata as well as user's IP address; 3. The user downloads a regular installation file and installs; 4. Once installed, the first thing the client does is contact boinc.berkeley.edu<http://boinc.berkeley.edu><http://boinc.berkeley.edu><http://boinc.berkeley.edu> to retrieve metadata and attach wherever needed (maybe even possible through the installer?). The server would load data based on the requester's IP address. -- Pagarbiai / Sincerely Rytis Slatkevičius +370 670 77777<tel:%2B370%20670%2077777><tel:%2B370%20670%2077777><tel:%2B370%20670%2077777> On Fri, Sep 25, 2015 at 12:28 AM, Matthew Blumberg <m...@gridrepublic.org<mailto:m...@gridrepublic.org><mailto:m...@gridrepublic.org<mailto:m...@gridrepublic.org>><mailto:m...@gridrepublic.org<mailto:m...@gridrepublic.org><mailto:m...@gridrepublic.org<mailto:m...@gridrepublic.org>>>> wrote: I'm a little worried about the proposed approach; I fear it will notably reduce conversion-completion rates -- if i got an installer with a 120 character filename, i'd [a] edit to clean it up, and/or [b] assume it was corrupted or infected and be afraid to run it. In any event, by way of making this work in the AMS context, can we request one minor revision to the current scheme -- In the current scheme, at completion of install, the wizard opens a browser window using the return_url specified in the browser cookie. Could you instead open a browser window upon completion, using the URL from acct_mgr_url.xml, and appending a random number as a parameter, e.g. http://acctmgr.com/?return_id=[nonce]<http://acctmgr.com/?return_id=%5bnonce%5d><http://acctmgr.com/?return_id=%5bnonce%5d><http://acctmgr.com/?return_id=%5bnonce%5d> Best Wishes, ..Matt On Mon, Sep 21, 2015 at 10:59 AM, Rom Walton <r...@romwnet.org<mailto:r...@romwnet.org><mailto:r...@romwnet.org<mailto:r...@romwnet.org>><mailto:r...@romwnet.org<mailto:r...@romwnet.org><mailto:r...@romwnet.org<mailto:r...@romwnet.org>>>> wrote: Howdy Folks, Current Strategy: https://boinc.berkeley.edu/trac/wiki/SimpleAttach As part of the simplification process we (WCG and I) would like to propose the idea of cookieless installs. See: https://boinc.berkeley.edu/trac/wiki/SimpleAttach#CookielessInstalls Pros: We would be able to get around the various issues with cookies such as: * Browser implementations changing over time. * Sqlite changing over time * Unknown browsers Cons: Realistically we are limited to filenames that are 256 characters in size. Note: By default various shells on Windows limit the file namespace to 256 characters, the limits can by bypassed by prefixing the filename with \\.\<file://./<file://./%3cfile:/<file://./%3cfile:/%3cfile:/%253cfile:/>>> but most users do not know that. I also suspect that most browsers will complain about malware or something of that nature is we attempt to go past 256 characters. ----- Rom _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu><mailto:boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>><mailto:boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu><mailto:boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>>> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu><mailto:boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu><mailto:boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
