Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[McLeod, John]

Even using IPV6 addresses as identification of an individual machine is not a 
good idea.  The default for some OSs is to use privacy addresses that change 
every 15 minutes or so.  However, it is much more likely that the first 64 bits 
will identify a household as the current crop of Consumer firewalls only work 
with one /64.  

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Rom 
Walton
Sent: Monday, September 28, 2015 11:56 AM
To: Filip Rydlo <filip.ry...@gmail.com>
Cc: BOINC-dev email list <boinc_dev@ssl.berkeley.edu>
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

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 ab

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Tristan Olive]

On Mon 28 Sep 2015 01:16:35 PM EDT, Rom Walton wrote:
>
> Originally I envisioned this as something interjected between steps 1
> and 2, when the browser window is closed, it passes the GUID to the
> lookup account phase and proceeds based on success or failure. What
> your proposing is to push more of the attach process into the client
> so the attach process can move between its states without the wizard
> being stuck displaying the bouncing ball between two computers.
>
> It would require a major overhaul of the client/manager-side attach
> process to support.
>


What about just pausing the wizard while the browser window is opened,
then when the user gets the "all clear" message in the browser, they can
click to continue the wizard. No reason for the wizard itself to have to
get any info from the browser window at all (as I'd think that would be
complicated and prone to maintenance issues).

-- 
Tristan Olive

___
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.

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

I would consider that a design failure.

Ideally, for a fully customized installer, there only needs to be two times the 
volunteer needs to provide input.  Once to kick off the installer and the other 
to confirm they really do want to contribute their CPU/GPU cycles to a given 
project/account manager.

Any additional interactions should be around failure cases, such as needing to 
know the proxy servers name and port number if there is a communication failure 
and the client cannot ping www.google.com.

- Rom

-Original Message-
From: Tristan Olive [mailto:tristan.ol...@studiodelta.us] On Behalf Of Tristan 
Olive
Sent: Monday, September 28, 2015 1:31 PM
To: Rom Walton <r...@romwnet.org>
Cc: Matthew Blumberg <m...@gridrepublic.org>; BOINC Developers Mailing List 
<boinc_dev@ssl.berkeley.edu>; Rytis Slatkevičius <ry...@gridrepublic.org>; Hugh 
Wormington <h...@gridrepublic.org>
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

On Mon 28 Sep 2015 01:16:35 PM EDT, Rom Walton wrote:
>
> Originally I envisioned this as something interjected between steps 1 
> and 2, when the browser window is closed, it passes the GUID to the 
> lookup account phase and proceeds based on success or failure. What 
> your proposing is to push more of the attach process into the client 
> so the attach process can move between its states without the wizard 
> being stuck displaying the bouncing ball between two computers.
>
> It would require a major overhaul of the client/manager-side attach 
> process to support.
>


What about just pausing the wizard while the browser window is opened, then 
when the user gets the "all clear" message in the browser, they can click to 
continue the wizard. No reason for the wizard itself to have to get any info 
from the browser window at all (as I'd think that would be complicated and 
prone to maintenance issues).

--
Tristan Olive

___
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.

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

2)  So the volunteer is supposed to leave the manager alone for a few hours 
while it is stuck in the attach wizard bouncing a ball between two computers?

I suspect that is not what you had in mind.

The whole reason for the wizards existence is to provide the client software 
with an authenticator to attach to a project/account manager with when 
completed.  If we leave the wizard and begin some background operation in the 
client, then the volunteer gets an empty UI not doing anything as far as they 
can tell.  They would have to go to the event log (Advanced UI thing) just to 
see what the client is up too.

Behind the wizard this is what is going on:

1.   Get Project Config RPC (Run in Manager): detect various things about a 
project/account manager.  Minimum password lengths, platforms supported, 
canonical project URL, etc.

2.   Lookup Account/Create Account (Run in Manager): get the volunteer to 
give us enough information to acquire an authenticator.

3.   Attach to project (Run in Client): when the wizard closes it instructs 
the client to attach to a project with the given authenticator.

Once the client begins the attach process, the UI sees a project.  It can 
display some information about it.

Originally I envisioned this as something interjected between steps 1 and 2, 
when the browser window is closed, it passes the GUID to the lookup account 
phase and proceeds based on success or failure.  What your proposing is to push 
more of the attach process into the client so the attach process can move 
between its states without the wizard being stuck displaying the bouncing ball 
between two computers.

It would require a major overhaul of the client/manager-side attach process to 
support.

- Rom


From: hugh.w...@gmail.com [mailto:hugh.w...@gmail.com] On Behalf Of Hugh 
Wormington
Sent: Monday, September 28, 2015 12:35 PM
To: Rom Walton <r...@romwnet.org>
Cc: Hugh Wormington <h...@gridrepublic.org>; Matthew Blumberg 
<m...@gridrepublic.org>; Rytis Slatkevičius <ry...@gridrepublic.org>; BOINC 
Developers Mailing List <boinc_dev@ssl.berkeley.edu>
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

1) In the case of Progres Thru Processors the login is Facebook's, which they 
know. PTP links that through to the GR/BOINC user in the background. Apologies 
for not making that clear.
2) The client could poll for a few hours max, after which it could wait until 
the next time it's started up and then poll once and if necessary try the whole 
thing again.

  *   I notice that other software sometimes fires up a browser window e.g. for 
feedback after uninstalling. Granted that example is not critical, but with the 
right UI I think it should be robust. For example if the first attempt failed, 
the client could show a window containing a link with a text like "Add this 
computer to your Progress Thru Processors (or whatever) account to get going 
(opens a browser window)".
  *   No user interaction is required unless the browser is no longer logged in.
  *   I'm not aware of any plugins/AVs etc that would interfere with this 
process unless an AV identified the URL as suspect, in which case we're 
probably stuffed anyway.
  *   Rather than being browser-dependent it should be future-proof.
5) Interesting. There's a discussion about UUID uniquness in stackoverflow 
here<http://stackoverflow.com/questions/1155008/how-unique-is-uuid>.
Hugh

On 28 September 2015 at 16:48, Rom Walton 
<r...@romwnet.org<mailto:r...@romwnet.org>> wrote:


1.   In the case of Progress Thru Processors, it is a catastrophic failure 
case.  Volunteers do not know what username/password they have been assigned.

2-4.  How long should the client poll before assuming an error has occurred?  
All the various browser issues exist with plugins getting in the way plus now 
you might have window z-orders to worry about.  What happens if the manager is 
over the browser window when it is looking for a username/password?  What 
happens if the browser window is stuck behind a word processing application?

5.  They do happen though.  After deploying a test framework for a web property 
on a project I previously worked on, we would experience a 50% failure rate on 
test cases overnight every third day of testing.  While the math says one thing 
it is still something that has to be accounted for.  Granted the likelihood 
drops dramatically when they expire after a given amount of time.  But you 
still might run into denial of service attacks accepting what amounts to random 
input from random locations on the internet.  Although, I suppose you could 
just ignore the GUID if the session cookie is not available.

Frankly, the more and more I think about this, the less and less I like it.  
With browser cookie lookup we only had to deal with changes to three browsers 
who more or less kept things somewhat predictable day to day.  Now we ar

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Tristan Olive]

On Mon 28 Sep 2015 01:25:55 PM EDT, Rom Walton wrote:
> Violation of basic computational rights?
>
> I'm not sure the filename approach is really all that far out there.
>
> Microsoft uses it for Office 2016 deployments. Their new installer
> process does something similar to what we are trying to do when
> installing office.


I'm a Linux guy, that point just strengthened the argument against the
filename approach in my mind. :)

-- 
Tristan Olive

___
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.

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

Violation of basic computational rights?

I'm not sure the filename approach is really all that far out there.

Microsoft uses it for Office 2016 deployments.  Their new installer process 
does something similar to what we are trying to do when installing office.

An example of the filename they use is:
Setup.X64.en-US_O365HomePremRetail_0174f7b5-908c-4338-be4c-_TX_PR_.exe

Their web page that kicks off the download process simply states we are going 
to download a file to your computer.  When your browser gives you an option to 
save it or run it, choose run.

- Rom

-Original Message-
From: Tristan Olive [mailto:tristan.ol...@studiodelta.us] On Behalf Of Tristan 
Olive
Sent: Monday, September 28, 2015 1:00 PM
To: Rom Walton <r...@romwnet.org>
Cc: Hugh Wormington <h...@gridrepublic.org>; Rytis Slatkevičius 
<ry...@gridrepublic.org>; BOINC Developers Mailing List 
<boinc_dev@ssl.berkeley.edu>; Matthew Blumberg <m...@gridrepublic.org>
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

I agree that an IP cannot be expected to be a reliable, unique identifier, even 
short term. However, I also think the long filename is unreliable, as it 
requires that a user not do basic file management on his own system. It feels 
like a "violation of basic computational rights" to expect this. Also, is the 
maximum path length on Windows still an issue? We can't be sure where the 
download directory is located, as that is also browser dependent and user 
configurable, so the total path length is unpredictable.

To go along with what Hugh is suggesting, see the attached (rudimentary) chart 
showing the flow of how this could work. Note that the nonce really is only 
used to establish a handshake of sorts between the client and server; once that 
has been done, the server gives the client a separate, verifiably-unique auth 
key to be used in  for client authentication going forward.

If the browser launch fails, can we add a link or button or menu item somewhere 
in the client as a manual retry? Then we could send the user a notice after 
some time saying, "we see you have not completed installation, please follow 
these directions to continue."

--
Tristan Olive

___
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.

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

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.

Wh

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

1.   In the case of Progress Thru Processors, it is a catastrophic failure 
case.  Volunteers do not know what username/password they have been assigned.

2-4.  How long should the client poll before assuming an error has occurred?  
All the various browser issues exist with plugins getting in the way plus now 
you might have window z-orders to worry about.  What happens if the manager is 
over the browser window when it is looking for a username/password?  What 
happens if the browser window is stuck behind a word processing application?

5.  They do happen though.  After deploying a test framework for a web property 
on a project I previously worked on, we would experience a 50% failure rate on 
test cases overnight every third day of testing.  While the math says one thing 
it is still something that has to be accounted for.  Granted the likelihood 
drops dramatically when they expire after a given amount of time.  But you 
still might run into denial of service attacks accepting what amounts to random 
input from random locations on the internet.  Although, I suppose you could 
just ignore the GUID if the session cookie is not available.

Frankly, the more and more I think about this, the less and less I like it.  
With browser cookie lookup we only had to deal with changes to three browsers 
who more or less kept things somewhat predictable day to day.  Now we are 
trying to work into the equation any number of browsers and the random factor 
of what the volunteer has configured (browser preferences, virus scanners, 
anti-malware detectors, browser plugins) and how they are using their system at 
the time of install.

- Rom

From: hugh.w...@gmail.com [mailto:hugh.w...@gmail.com] On Behalf Of Hugh 
Wormington
Sent: Monday, September 28, 2015 5:22 AM
To: Rom Walton <r...@romwnet.org>
Cc: Hugh Wormington <h...@gridrepublic.org>; Matthew Blumberg 
<m...@gridrepublic.org>; Rytis Slatkevičius <ry...@gridrepublic.org>; BOINC 
Developers Mailing List <boinc_dev@ssl.berkeley.edu>
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)


1. This shouldn't matter. If the session cookie is missing (ie user not already 
logged into the website in that browser) then they will just be asked to login. 
NB the current installer cookies should no longer be used since the user 
identification comes from the website login. The user is then greeted with some 
message like "this computer has been added to your account".

2. to 4. I agree that approach seems unfeasible. I imagined the client simply 
poll the AMS until its GUID is "claimed" by a user. Is that feasible?
It might also be good to have the ability to "retry attach" to a user account 
in case the original process didn't complete, maybe at boot time if it finds 
itself unclaimed. A "retry" would simply involve  reloading the original 
browser URL.

5. GUIDs are widely used; the generator eg UUID ensures duplicates are so rare 
that statistically they never happen.
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]Hugh

On 28 September 2015 at 01:44, Rom Walton 
<r...@romwnet.org<mailto:r...@romwnet.org>> wrote:
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: [boi

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Filip Rydlo]

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>:

> 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] On Behalf Of Hugh
> Wormington
> Sent: Sunday, September 27, 2015 5:22 PM
> To: Rom Walton <r...@romwnet.org>
> Cc: Matthew Blumberg <m...@gridrepublic.org>; Hugh Wormington <
> h...@gridrepublic.org>; Rytis Slatkevičius <ry...@gridrepublic.org>;
> BOINC Developers Mailing List <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 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>] On Behalf Of Matthew
> Blumberg
> Sent: Friday, September 25, 2015 6:27 PM
> To: Rom Walton <

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Hugh Wormington]

1. This shouldn't matter. If the session cookie is missing (ie user not
already logged into the website in that browser) then they will just be
asked to login. NB the current installer cookies should no longer be used
since the user identification comes from the website login. The user is
then greeted with some message like "this computer has been added to your
account".

2. to 4. I agree that approach seems unfeasible. I imagined the client
simply poll the AMS until its GUID is "claimed" by a user. Is that
feasible?
It might also be good to have the ability to "retry attach" to a user
account in case the original process didn't complete, maybe at boot time if
it finds itself unclaimed. A "retry" would simply involve  reloading the
original browser URL.

5. GUIDs are widely used; the generator eg UUID ensures duplicates are so
rare that statistically they never happen.
Hugh

On 28 September 2015 at 01:44, Rom Walton <r...@romwnet.org> wrote:

> 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] *On Behalf Of *Hugh
> Wormington
> *Sent:* Sunday, September 27, 2015 5:22 PM
> *To:* Rom Walton <r...@romwnet.org>
> *Cc:* Matthew Blumberg <m...@gridrepublic.org>; Hugh Wormington <
> h...@gridrepublic.org>; Rytis Slatkevičius <ry...@gridrepublic.org>;
> BOINC Developers Mailing List <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> 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 ins

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Hugh Wormington]

> 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> 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] *On Behalf
> Of *Matthew Blumberg
> *Sent:* Friday, September 25, 2015 6:27 PM
> *To:* Rom Walton <r...@romwnet.org>
> *Cc:* Hugh Wormington <h...@gridrepublic.org>; Rytis Slatkevičius <
> ry...@gridrepublic.org>; BOINC Developers Mailing List <
> 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]
>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> 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] On Behalf Of
> Rom Walton
> Sent: Friday, September 25, 2015 10:02 AM
> To: Hugh Wormington <h...@gridrepublic.org>; Rytis Slatkevičius <
> ry...@gridrepublic.org>
> Cc: Matthew Blumberg <m...@gridrepublic.org>; BOINC Developers Mailing
> List <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:///lookup_account.php<https://%3cproject_url%3e/lookup_account.php
> <https://%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 m

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

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] On Behalf Of Hugh 
Wormington
Sent: Sunday, September 27, 2015 5:22 PM
To: Rom Walton <r...@romwnet.org>
Cc: Matthew Blumberg <m...@gridrepublic.org>; Hugh Wormington 
<h...@gridrepublic.org>; Rytis Slatkevičius <ry...@gridrepublic.org>; BOINC 
Developers Mailing List <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>> 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>] On Behalf Of 
Matthew Blumberg
Sent: Friday, September 25, 2015 6:27 PM
To: Rom Walton <r...@romwnet.org<mailto:r...@romwnet.org>>
Cc: 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)

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>
  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

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

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] On Behalf Of Matthew 
Blumberg
Sent: Friday, September 25, 2015 6:27 PM
To: Rom Walton <r...@romwnet.org>
Cc: Hugh Wormington <h...@gridrepublic.org>; Rytis Slatkevičius 
<ry...@gridrepublic.org>; BOINC Developers Mailing List 
<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>
  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>> 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>]
 On Behalf Of Rom Walton
Sent: Friday, September 25, 2015 10:02 AM
To: Hugh Wormington <h...@gridrepublic.org<mailto:h...@gridrepublic.org>>; 
Rytis Slatkevičius <ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>>
Cc: Matthew Blumberg <m...@gridrepublic.org<mailto:m...@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)

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:///lookup_account.php<https://%3cproject_url%3e/lookup_account.php<https://%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>] On Behalf Of Hugh 
Wormington
Sent: Friday, September 25, 2015 6:56 AM
To: Rytis Slatkevičius <ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>>
Cc: Matthew Blumberg <m...@gridrepublic.org<mailto:m...@gridrepublic.org>>; Rom 
Walton <r...@romwnet.org<mailto:r...@romwnet.org>>; BOINC Developers Mailing 
List <boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>>; Tristan 
Olive <tol...@gridrepublic.org<mailto:tol...@gridrepublic.org>>; Hugh 
Wormington <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> 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>>>
 wrote:
Is there really a need for such schemes?

A script will be running to generate the download filenames (I assume at 
boinc.berkeley.ed

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rytis Slatkevičius]

Is there really a need for such schemes?

A script will be running to generate the download filenames (I assume at
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 (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 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 7

On Fri, Sep 25, 2015 at 12:28 AM, Matthew Blumberg 
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]
>
> Best Wishes,
>
> ..Matt
>
>
>
>
> On Mon, Sep 21, 2015 at 10:59 AM, Rom Walton  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
>> \\.\ 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
>> 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.

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[David Anderson]

That scheme sounds plausible,
but it seems more complex than what Rom proposed.
-- D

On 9/24/2015 11:48 PM, Rytis Slatkevičius 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); 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 (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 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 7

On Fri, Sep 25, 2015 at 12:28 AM, Matthew Blumberg 
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]

Best Wishes,

..Matt




On Mon, Sep 21, 2015 at 10:59 AM, Rom Walton  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
\\.\ 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
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.


___
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.

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

Using IP addresses is kind of iffy, think a bunch of computers within a 
corporate environment.  With a small company we probably wouldn't run into a 
problem.  IBM or Microsoft, we probably would.

Cookies themselves are a weak point as the browsers are constantly changing and 
require us to update the cookie detection code.  Over time things fall apart 
for the same BOINC version.  

Once the installer is code-signed, the contents of the installation package 
cannot be changed.  If we had a static URL on the Internet that we point the 
installer to and it disappears, then that scheme falls apart.

Encoding things within the file name avoids a single point of failure relative 
to the code-signed installer.  The server-side code that handles the file 
rename process can run from whichever server the volunteer is downloading the 
installer from.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Christian Beer
Sent: Friday, September 25, 2015 8:40 AM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

What Rytis suggests sounds good but relies on the availability of 
boinc.berkeley.edu which I consider a week point at the moment. Sending 
Web-RPCs is better than the cookie thing because we already support Web-RPC's 
and just need to define where to send the RPC to. We would need a permanent URL 
where the Client can get the metadata from that doesn't change because it is 
hardcoded in the Client/Installer. The IP lookup should work if the metadata 
expires within a few hours because the IP maybe reassigned to another user in 
the meantime. Sure the scenario to exploit this is unlikely but possible.

MfG / Regards
Christian Beer

Am 25.09.2015 um 10:08 schrieb David Anderson:
> That scheme sounds plausible,
> but it seems more complex than what Rom proposed.
> -- D
>
> On 9/24/2015 11:48 PM, Rytis Slatkevičius 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); 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 (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 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 7
>>
>> On Fri, Sep 25, 2015 at 12:28 AM, Matthew Blumberg
>> <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]
>>>
>>> Best Wishes,
>>>
>>> ..Matt
>>>
>>>
>>>
>>>
>>> On Mon, Sep 21, 2015 at 10:59 AM, Rom Walton <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 s

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

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:///lookup_account.php<https://%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] On Behalf Of Hugh 
Wormington
Sent: Friday, September 25, 2015 6:56 AM
To: Rytis Slatkevičius <ry...@gridrepublic.org>
Cc: Matthew Blumberg <m...@gridrepublic.org>; Rom Walton <r...@romwnet.org>; 
BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu>; Tristan Olive 
<tol...@gridrepublic.org>; Hugh Wormington <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> 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>> 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>); 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> 
(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> 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 7<tel:%2B370%20670%207>

On Fri, Sep 25, 2015 at 12:28 AM, Matthew Blumberg 
<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>

Best Wishes,

..Matt




On Mon, Sep 21, 2015 at 10:59 AM, Rom Walton 
<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 
\\.\ 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

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

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] On Behalf Of Rom 
Walton
Sent: Friday, September 25, 2015 10:02 AM
To: Hugh Wormington <h...@gridrepublic.org>; Rytis Slatkevičius 
<ry...@gridrepublic.org>
Cc: Matthew Blumberg <m...@gridrepublic.org>; BOINC Developers Mailing List 
<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:///lookup_account.php<https://%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] On Behalf Of Hugh 
Wormington
Sent: Friday, September 25, 2015 6:56 AM
To: Rytis Slatkevičius <ry...@gridrepublic.org>
Cc: Matthew Blumberg <m...@gridrepublic.org>; Rom Walton <r...@romwnet.org>; 
BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu>; Tristan Olive 
<tol...@gridrepublic.org>; Hugh Wormington <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> 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>> 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>); 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> 
(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> 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 7<tel:%2B370%20670%207>

On Fri, Sep 25, 2015 at 12:28 AM, Matthew Blumberg 
<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>

Best Wishes,

..Matt




On Mon, Sep 21, 2015 at 10:59 AM, Rom Walton 
<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 ar