Improve ResourceRequestInfo::HasUserGesture API docs

Improve ResourceRequestInfo::HasUserGesture API docs

The name is misleading, as e.g. a request for a top-level resource in a
new window won't have the flag set, even if it was triggered by a user
gesture

The flag is exposed via the webvia API, so we can't just rip it out.

BUG=420649
R=mkosiba@chromium.org
NOTRY=true

Committed: https://crrev.com/d426dceb346561b7f78742111c5dfe6f7f59b0af
Cr-Commit-Position: refs/heads/master@{#300082}

[jochen (gone - plz use gerrit), 2014-10-17 07:09:55]

ptal

[mkosiba (inactive), 2014-10-17 08:54:33]

lgtm

https://codereview.chromium.org/650043002/diff/220001/content/public/browser/...
File content/public/browser/resource_request_info.h (right):

https://codereview.chromium.org/650043002/diff/220001/content/public/browser/...
content/public/browser/resource_request_info.h:107: // DO NOT BASE SECURITY
DECISIONS ON THIS FLAG!
Yes, you should be especially wary of using this to determine what to do with a
download :D

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/saf...

https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/do...

[jochen (gone - plz use gerrit), 2014-10-17 08:56:21]

+mattm for safe browsing

+rdsmith for downloads

[jochen (gone - plz use gerrit), 2014-10-17 08:56:27]

The CQ bit was checked by jochen@chromium.org

[commit-bot: I haz the power, 2014-10-17 08:56:57]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/650043002/220001

[commit-bot: I haz the power, 2014-10-17 08:57:22]

Committed patchset #3 (id:220001)

[commit-bot: I haz the power, 2014-10-17 08:58:11]

Patchset 3 (id:??) landed as
https://crrev.com/d426dceb346561b7f78742111c5dfe6f7f59b0af
Cr-Commit-Position: refs/heads/master@{#300082}

[Randy Smith (Not in Mondays), 2014-10-20 14:20:45]

rdsmith@chromium.org changed reviewers:
+ rdsmith@chromium.org

[Randy Smith (Not in Mondays), 2014-10-20 14:20:46]

+asanka, FHI.

https://codereview.chromium.org/650043002/diff/220001/content/public/browser/...
File content/public/browser/resource_request_info.h (right):

https://codereview.chromium.org/650043002/diff/220001/content/public/browser/...
content/public/browser/resource_request_info.h:107: // DO NOT BASE SECURITY
DECISIONS ON THIS FLAG!
On 2014/10/17 08:54:33, mkosiba wrote:
> Yes, you should be especially wary of using this to determine what to do with
a
> download :D
> 
>
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/saf...
> 
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/do...

We'd welcome other other suggestions as to how to make download decisions (but
you'll probably have to mind-meld extensively with the current conditional
cascade and you may feel dirty afterwards :-}).  Whether and how to download
resources has a pretty strong tension between security and convenience, and when
we've moved towards security (e.g. prompting people around downloading PDFs
because they can contain arbitrary executable code) we've gotten howls of
protest.  I don't expect we're going to change our current use of user gesture,
even though we do indeed know it's not reliable :-{.

[mkosiba (inactive), 2014-10-20 14:58:51]

On 2014/10/20 14:20:46, rdsmith wrote:
>
https://codereview.chromium.org/650043002/diff/220001/content/public/browser/...
> content/public/browser/resource_request_info.h:107: // DO NOT BASE SECURITY
> DECISIONS ON THIS FLAG!
> On 2014/10/17 08:54:33, mkosiba wrote:
> > Yes, you should be especially wary of using this to determine what to do
with
> a
> > download :D
> 
> We'd welcome other other suggestions as to how to make download decisions (but
> you'll probably have to mind-meld extensively with the current conditional
> cascade and you may feel dirty afterwards :-}).  Whether and how to download

Sorry, I just wanted to point out to Jochen that there already is code using
that field for security purposes. Not that you guys should change your
implementation.
I have indeed mind-melded and embarrassingly enough even written such code,
so I can totally relate.

> resources has a pretty strong tension between security and convenience, and
when
> we've moved towards security (e.g. prompting people around downloading PDFs
> because they can contain arbitrary executable code) we've gotten howls of
> protest.  I don't expect we're going to change our current use of user
gesture,
> even though we do indeed know it's not reliable :-{.

I think this is fine as long as you guys are aware of the quirks.

[Randy Smith (Not in Mondays), 2014-10-20 15:01:45]

On 2014/10/20 14:58:51, mkosiba wrote:
> On 2014/10/20 14:20:46, rdsmith wrote:
> >
>
https://codereview.chromium.org/650043002/diff/220001/content/public/browser/...
> > content/public/browser/resource_request_info.h:107: // DO NOT BASE SECURITY
> > DECISIONS ON THIS FLAG!
> > On 2014/10/17 08:54:33, mkosiba wrote:
> > > Yes, you should be especially wary of using this to determine what to do
> with
> > a
> > > download :D
> > 
> > We'd welcome other other suggestions as to how to make download decisions
(but
> > you'll probably have to mind-meld extensively with the current conditional
> > cascade and you may feel dirty afterwards :-}).  Whether and how to download
> 
> Sorry, I just wanted to point out to Jochen that there already is code using
> that field for security purposes. Not that you guys should change your
> implementation.
> I have indeed mind-melded and embarrassingly enough even written such code,
> so I can totally relate.
> 
> > resources has a pretty strong tension between security and convenience, and
> when
> > we've moved towards security (e.g. prompting people around downloading PDFs
> > because they can contain arbitrary executable code) we've gotten howls of
> > protest.  I don't expect we're going to change our current use of user
> gesture,
> > even though we do indeed know it's not reliable :-{.
> 
> I think this is fine as long as you guys are aware of the quirks.

Somewhat painfully aware :-}.  Thanks!

[asanka, 2014-10-20 15:28:09]

On 2014/10/20 15:01:45, rdsmith wrote:
> On 2014/10/20 14:58:51, mkosiba wrote:
> > On 2014/10/20 14:20:46, rdsmith wrote:
> > >
> >
>
https://codereview.chromium.org/650043002/diff/220001/content/public/browser/...
> > > content/public/browser/resource_request_info.h:107: // DO NOT BASE
SECURITY
> > > DECISIONS ON THIS FLAG!
> > > On 2014/10/17 08:54:33, mkosiba wrote:
> > > > Yes, you should be especially wary of using this to determine what to do
> > with
> > > a
> > > > download :D
> > > 
> > > We'd welcome other other suggestions as to how to make download decisions
> (but
> > > you'll probably have to mind-meld extensively with the current conditional
> > > cascade and you may feel dirty afterwards :-}).  Whether and how to
download
> > 
> > Sorry, I just wanted to point out to Jochen that there already is code using
> > that field for security purposes. Not that you guys should change your
> > implementation.
> > I have indeed mind-melded and embarrassingly enough even written such code,
> > so I can totally relate.
> > 
> > > resources has a pretty strong tension between security and convenience,
and
> > when
> > > we've moved towards security (e.g. prompting people around downloading
PDFs
> > > because they can contain arbitrary executable code) we've gotten howls of
> > > protest.  I don't expect we're going to change our current use of user
> > gesture,
> > > even though we do indeed know it's not reliable :-{.
> > 
> > I think this is fine as long as you guys are aware of the quirks.
> 
> Somewhat painfully aware :-}.  Thanks!

Yup. Thanks for the heads up. There seems to be some extensions handling logic
that's not taking the unreliability of the "has user gesture" flag. I'll try to
get that resolved.

The downloads code is supposed to only use this flag when it's paired with some
other signal (like the user having a history of having visited the referrer
site).