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 
Cc: Hugh Wormington ; Rytis Slatkevičius 
; BOINC Developers Mailing List 

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 
> 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 >; 
Rytis Slatkevičius >
Cc: Matthew Blumberg >; 
BOINC Developers Mailing List 
>
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>.

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 >
Cc: Matthew Blumberg >; Rom 
Walton >; BOINC Developers Mailing 
List >; Tristan 
Olive >; Hugh 
Wormington >
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 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 
>>
 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 

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

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.

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 
Cc: Matthew Blumberg ; Rom Walton ; 
BOINC Developers Mailing List ; Tristan Olive 
; Hugh Wormington 
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 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 
> 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 

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 ; Rytis Slatkevičius 

Cc: Matthew Blumberg ; BOINC Developers Mailing List 

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.

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 
Cc: Matthew Blumberg ; Rom Walton ; 
BOINC Developers Mailing List ; Tristan Olive 
; Hugh Wormington 
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 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 
> 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