Validate origins when generating subdomain tokens

Validate origins when generating subdomain tokens

Subdomain tokens will match against any subdomains of the given origin.
This relaxed matching should not be applied when subdomains represent
separate logical sites (e.g. <user>.github.io). Thus, subdomain tokens
are not to be issued for such domains. For more detail, see the last
question in the Origin Trials developer guide:
https://github.com/jpchase/OriginTrials/blob/gh-pages/developer-guide.md

This CL adds a utility to validate that a origin is not found in the
Public Suffix List. The token generation script will now call the
utility to check the origin, only for subdomain tokens. The utility
is used when the generation script is manually run by the origin
trials team to issue tokens. The intent is to automate the origin
checks, to reduce the number of manual steps in issuing tokens.

BUG=658856
Committed: https://crrev.com/6205808cb4e9c61264e4aa48676e2f5833a61326
Cr-Commit-Position: refs/heads/master@{#440554}

[chasej, 2016-10-27 21:47:56]

The CQ bit was checked by chasej@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-27 21:49:07]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-27 21:54:12]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-27 21:54:13]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[chasej, 2016-10-28 17:30:58]

The CQ bit was checked by chasej@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-28 17:31:25]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[chasej, 2016-10-28 18:22:53]

chasej@chromium.org changed reviewers:
+ iclelland@chromium.org

[chasej, 2016-10-28 18:22:54]

iclelland, please take a look.

[commit-bot: I haz the power, 2016-10-28 18:53:08]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-28 18:53:08]

Dry run: Try jobs failed on following builders:
  win_clang on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/...)

[chasej, 2016-11-02 14:24:53]

iclelland, please take a look.

[iclelland, 2016-11-02 15:25:47]

Sorry for the delay; this looks pretty good. I've left a few questions in
comments.

Also, is the test wired up to run anywhere? I don't see it mentioned in either
of the BUILD files.

Also also, I'm curious -- why is the cc file name 'check_subdomain_origin.cc'
rather than 'validate_subdomain_origin.cc'?

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/gen...
File tools/origin_trials/generate_token.py (right):

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/gen...
tools/origin_trials/generate_token.py:95: utility_path =
"bin/validate_subdomain_origin"
How does this utility end up in a bin/ directory? I've tried running

ninja -c out/Default validate_subdomain_origin

and it builds, but it places the executable in my output directory, where the
script doesn't find it.

I don't think that the script should be in src/tools, since it's generated, but
maybe we could do something like what run-blink-tests does, and take a --target
parameter which points to the correct output directory (default to /out/Default,
but allow any other directory to be used)

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/gen...
tools/origin_trials/generate_token.py:105: return rc == 0
It is also possible for other non-zero status to be returned: I tried moving the
utility into a bin/ directory, and running it from there returns a 127 status,
as the shared libraries are not available (I built as a component build)

stderr there says "bin/validate_subdomain_origin: error while loading shared
libraries: libbase.so: cannot open shared object file: No such file or
directory"

Clearly my error, but the script silently interpreted this as "The specified
origin is not valid for use in a subdomain token." for every domain.

I think the simplest thing to do is to check for any out-of-bounds status here,
and sys.exit() with an error if we see one.

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
File tools/origin_trials/validate_subdomain_origin/check_subdomain_origin.cc
(right):

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/check_subdomain_origin.cc:55: //
Check if it looks like an url, that is not valid
nit: drop the comma

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/check_subdomain_origin.cc:56: if
(base::StartsWith(origin, "http",
Less of a nit: Why does this utility care whether it's an http prefix
specifically? I could imagine requiring 'https', and failing on 'http','ftp',
'gopher', 'mailto', or anything else, but it seems strange to only fail on http.

More broadly, though, does this utility even need to worry about that? It it's
not a secure origin, then the generate_token.py script will refuse to generate
it for its own reasons. This utility could easily be reused in other contexts
where secure origin isn't a requirement; it probably shouldn't be trying to be
enforce it.

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/check_subdomain_origin.cc:74:
host.set(canon_host->c_str());
What happens to this string after this block ends? canon_host is free()d, but
I'm not sure if that invalidates the pointer returned by c_str(), which is just
copied into host.ptr_ by the set() method.

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/check_subdomain_origin.cc:107:
std::cerr << "validate_subdomain_origin: Origin in Public Suffix List - "
Nit -- I'd prefer a '-v' or '-q' option to control whether there is any output
at all, and be consistent with outputting a message whether or not the domain
passes.

If I could have a pony, I'd have the utility print a message when called with no
parameters (by someone just using it from the command line) and have an option
for the script to make it silent, so the script can decide on the format for the
error output, if any.

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
File tools/origin_trials/validate_subdomain_origin/test_validate.py (right):

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/test_validate.py:18: TestOrigins =
{
Can we document what these expected return values are? Or declare them as
symbols so they're clear?

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/test_validate.py:38:
DEFAULT_UTILITY_PATH = '../bin/validate_subdomain_origin'
Same question as in generate_token.py (but moreso -- why ../bin here, and just
bin/ there? I'm not sure what directory this script is intended to be run from)

[iclelland, 2016-11-02 15:28:55]

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
File tools/origin_trials/validate_subdomain_origin/check_subdomain_origin.cc
(right):

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/check_subdomain_origin.cc:56: if
(base::StartsWith(origin, "http",
On 2016/11/02 15:25:47, iclelland wrote:
> Less of a nit: Why does this utility care whether it's an http prefix
> specifically? I could imagine requiring 'https', and failing on 'http','ftp',
> 'gopher', 'mailto', or anything else, but it seems strange to only fail on
http.
> 
> More broadly, though, does this utility even need to worry about that? It it's
> not a secure origin, then the generate_token.py script will refuse to generate
> it for its own reasons. This utility could easily be reused in other contexts
> where secure origin isn't a requirement; it probably shouldn't be trying to be
> enforce it.

Actually, I misunderstood -- I tried to get this to trigger by using various
protocols, and it doesn't. I see that it only comes into play when the origin
given can't be parsed as a full URL, such as when a hostname is passed.

Unfortunately, this means that it also fails to pass legitimate domains, such as
"httpd.apache.org", because of the "http" prefix.

Is this test actually required, or is it just trying to provide helpful errors
for the operator? If we don't need it, I'd suggest getting rid of it and letting
bad URLs fail on their own.

[chasej, 2016-11-03 19:23:40]

iclelland, please take another look.

I've addressed most of the comments. There is one
outstanding, that I'm looking to discuss further.

Note that I renamed the source file to
validate_subdomain_origin.cc (that was missed when
I first renamed the utility, prior to uploading).
That messes up the diff from the last patch set.
The changes there were:
- Adding a --quiet option
- Extracting the output of messages into functions

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/gen...
File tools/origin_trials/generate_token.py (right):

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/gen...
tools/origin_trials/generate_token.py:95: utility_path =
"bin/validate_subdomain_origin"
On 2016/11/02 15:25:47, iclelland wrote:
> How does this utility end up in a bin/ directory? I've tried running
> 
> ninja -c out/Default validate_subdomain_origin
> 
> and it builds, but it places the executable in my output directory, where the
> script doesn't find it.
> 
> I don't think that the script should be in src/tools, since it's generated,
but
> maybe we could do something like what run-blink-tests does, and take a
--target
> parameter which points to the correct output directory (default to
/out/Default,
> but allow any other directory to be used)

I forgot to add instructions, but I just used a symbolic link (e.g. ln -s
path/to/out/Default/validate_subdomain_origin bin/validate_subdomain_origin).

Since the generate script is run manually, I thought a manual install step was
reasonable.

I do like your suggestion of --target parameter with a default. Changed to use
that approach.

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/gen...
tools/origin_trials/generate_token.py:105: return rc == 0
On 2016/11/02 15:25:47, iclelland wrote:
> It is also possible for other non-zero status to be returned: I tried moving
the
> utility into a bin/ directory, and running it from there returns a 127 status,
> as the shared libraries are not available (I built as a component build)
> 
> stderr there says "bin/validate_subdomain_origin: error while loading shared
> libraries: libbase.so: cannot open shared object file: No such file or
> directory"
> 
> Clearly my error, but the script silently interpreted this as "The specified
> origin is not valid for use in a subdomain token." for every domain.
> 
> I think the simplest thing to do is to check for any out-of-bounds status
here,
> and sys.exit() with an error if we see one.

Done.

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
File tools/origin_trials/validate_subdomain_origin/check_subdomain_origin.cc
(right):

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/check_subdomain_origin.cc:55: //
Check if it looks like an url, that is not valid
On 2016/11/02 15:25:47, iclelland wrote:
> nit: drop the comma

Done.

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/check_subdomain_origin.cc:56: if
(base::StartsWith(origin, "http",
On 2016/11/02 15:28:55, iclelland wrote:
> On 2016/11/02 15:25:47, iclelland wrote:
> > Less of a nit: Why does this utility care whether it's an http prefix
> > specifically? I could imagine requiring 'https', and failing on
'http','ftp',
> > 'gopher', 'mailto', or anything else, but it seems strange to only fail on
> http.
> > 
> > More broadly, though, does this utility even need to worry about that? It
it's
> > not a secure origin, then the generate_token.py script will refuse to
generate
> > it for its own reasons. This utility could easily be reused in other
contexts
> > where secure origin isn't a requirement; it probably shouldn't be trying to
be
> > enforce it.
> 
> Actually, I misunderstood -- I tried to get this to trigger by using various
> protocols, and it doesn't. I see that it only comes into play when the origin
> given can't be parsed as a full URL, such as when a hostname is passed.
> 
> Unfortunately, this means that it also fails to pass legitimate domains, such
as
> "httpd.apache.org", because of the "http" prefix.
> 
> Is this test actually required, or is it just trying to provide helpful errors
> for the operator? If we don't need it, I'd suggest getting rid of it and
letting
> bad URLs fail on their own.

I was trying to address the scenario where GURL.is_valid() returns false, and
the origin should be considered invalid. CanonicalizeHost() doesn't catch many
of those scenarios (e.g. it simply escapes invalid domain chars).

Upon further testing, there's other inputs that I would consider invalid for
token generation purposes, which GURL will happily report as valid.

I'm now thinking that the utility should give on trying to check for malformed
(or otherwise "invalid" origins). Instead, it is up to the caller to ensure that
the origin meets any other validity rules. This utility will simply check if the
origin can be used for subdomain matching. With that approach, I could get rid
of the check for the http|https prefix entirely.

Thoughts?

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/check_subdomain_origin.cc:74:
host.set(canon_host->c_str());
On 2016/11/02 15:25:47, iclelland wrote:
> What happens to this string after this block ends? canon_host is free()d, but
> I'm not sure if that invalidates the pointer returned by c_str(), which is
just
> copied into host.ptr_ by the set() method.

canon_host not is declared in this block - it's scoped to the entire function.
That's why it's assigned via MakeUnique. My expectation is that the string lives
until the end of the function, and thus it's safe to assign to host inside the
block.

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/check_subdomain_origin.cc:107:
std::cerr << "validate_subdomain_origin: Origin in Public Suffix List - "
On 2016/11/02 15:25:47, iclelland wrote:
> Nit -- I'd prefer a '-v' or '-q' option to control whether there is any output
> at all, and be consistent with outputting a message whether or not the domain
> passes.
> 
> If I could have a pony, I'd have the utility print a message when called with
no
> parameters (by someone just using it from the command line) and have an option
> for the script to make it silent, so the script can decide on the format for
the
> error output, if any.

Done. You can have a pony, but just this one time ;-)

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
File tools/origin_trials/validate_subdomain_origin/test_validate.py (right):

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/test_validate.py:18: TestOrigins =
{
On 2016/11/02 15:25:47, iclelland wrote:
> Can we document what these expected return values are? Or declare them as
> symbols so they're clear?

Done. Declared constants to document the expected return values.

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/test_validate.py:38:
DEFAULT_UTILITY_PATH = '../bin/validate_subdomain_origin'
On 2016/11/02 15:25:47, iclelland wrote:
> Same question as in generate_token.py (but moreso -- why ../bin here, and just
> bin/ there? I'm not sure what directory this script is intended to be run
from)

The assumption is that each script is run from it's containing directory. Thus,
the different paths in the two scripts. I put this test script in the same
directory as the source, as I would expect it would only be run when making
changes to the utility.

[iclelland, 2016-11-03 19:47:55]

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
File tools/origin_trials/validate_subdomain_origin/check_subdomain_origin.cc
(right):

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/check_subdomain_origin.cc:56: if
(base::StartsWith(origin, "http",
On 2016/11/03 19:23:40, chasej wrote:
> On 2016/11/02 15:28:55, iclelland wrote:
> > On 2016/11/02 15:25:47, iclelland wrote:
> > > Less of a nit: Why does this utility care whether it's an http prefix
> > > specifically? I could imagine requiring 'https', and failing on
> 'http','ftp',
> > > 'gopher', 'mailto', or anything else, but it seems strange to only fail on
> > http.
> > > 
> > > More broadly, though, does this utility even need to worry about that? It
> it's
> > > not a secure origin, then the generate_token.py script will refuse to
> generate
> > > it for its own reasons. This utility could easily be reused in other
> contexts
> > > where secure origin isn't a requirement; it probably shouldn't be trying
to
> be
> > > enforce it.
> > 
> > Actually, I misunderstood -- I tried to get this to trigger by using various
> > protocols, and it doesn't. I see that it only comes into play when the
origin
> > given can't be parsed as a full URL, such as when a hostname is passed.
> > 
> > Unfortunately, this means that it also fails to pass legitimate domains,
such
> as
> > "httpd.apache.org", because of the "http" prefix.
> > 
> > Is this test actually required, or is it just trying to provide helpful
errors
> > for the operator? If we don't need it, I'd suggest getting rid of it and
> letting
> > bad URLs fail on their own.
> 
> I was trying to address the scenario where GURL.is_valid() returns false, and
> the origin should be considered invalid. CanonicalizeHost() doesn't catch many
> of those scenarios (e.g. it simply escapes invalid domain chars).
> 
> Upon further testing, there's other inputs that I would consider invalid for
> token generation purposes, which GURL will happily report as valid.
> 
> I'm now thinking that the utility should give on trying to check for malformed
> (or otherwise "invalid" origins). Instead, it is up to the caller to ensure
that
> the origin meets any other validity rules. This utility will simply check if
the
> origin can be used for subdomain matching. With that approach, I could get rid
> of the check for the http|https prefix entirely.
> 
> Thoughts?

I agree that if we can drop this check, then we should. The calling script
already has logic to make sure that the string is shaped like some sort of
origin or hostname.

https://codereview.chromium.org/2456053004/diff/20001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/check_subdomain_origin.cc:74:
host.set(canon_host->c_str());
On 2016/11/03 19:23:40, chasej wrote:
> On 2016/11/02 15:25:47, iclelland wrote:
> > What happens to this string after this block ends? canon_host is free()d,
but
> > I'm not sure if that invalidates the pointer returned by c_str(), which is
> just
> > copied into host.ptr_ by the set() method.
> 
> canon_host not is declared in this block - it's scoped to the entire function.
> That's why it's assigned via MakeUnique. My expectation is that the string
lives
> until the end of the function, and thus it's safe to assign to host inside the
> block.

Ahh, you're right; that makes sense. Thanks.

https://codereview.chromium.org/2456053004/diff/40001/tools/origin_trials/gen...
File tools/origin_trials/generate_token.py (right):

https://codereview.chromium.org/2456053004/diff/40001/tools/origin_trials/gen...
tools/origin_trials/generate_token.py:110: print("Unexpected return code from
validate subdomain utility: %d" % rc)
May as well use |utility_path| here instead

https://codereview.chromium.org/2456053004/diff/40001/tools/origin_trials/gen...
tools/origin_trials/generate_token.py:177: ", relative to the script directory",
Is this correct? I think that since you're just using os.path.expanduser on it,
then it should be relative to whatever directory the user runs the script from.
(And allow for things like ~ expansion)

https://codereview.chromium.org/2456053004/diff/40001/tools/origin_trials/val...
File tools/origin_trials/validate_subdomain_origin/test_validate.py (right):

https://codereview.chromium.org/2456053004/diff/40001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/test_validate.py:58: if not
os.path.exists(args.utility_path):
Can you call os.path.expanduser on this before using it, for consistency? That
will let people do things like
 --utility-path=~/something_else/validate_utility
and it will work as expected.

[chasej, 2016-11-03 20:58:55]

The CQ bit was checked by chasej@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-03 20:59:26]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[chasej, 2016-11-03 21:13:10]

iclelland, please take a look.

I've removed the check for valid urls. Instead, the help just
notes that the caller is responsible for providing well-formed or correct
origins.

https://codereview.chromium.org/2456053004/diff/40001/tools/origin_trials/gen...
File tools/origin_trials/generate_token.py (right):

https://codereview.chromium.org/2456053004/diff/40001/tools/origin_trials/gen...
tools/origin_trials/generate_token.py:110: print("Unexpected return code from
validate subdomain utility: %d" % rc)
On 2016/11/03 19:47:55, iclelland wrote:
> May as well use |utility_path| here instead

Done.

https://codereview.chromium.org/2456053004/diff/40001/tools/origin_trials/gen...
tools/origin_trials/generate_token.py:177: ", relative to the script directory",
On 2016/11/03 19:47:55, iclelland wrote:
> Is this correct? I think that since you're just using os.path.expanduser on
it,
> then it should be relative to whatever directory the user runs the script
from.
> (And allow for things like ~ expansion)

Done. Just removed the part about "relative to ..."

https://codereview.chromium.org/2456053004/diff/40001/tools/origin_trials/val...
File tools/origin_trials/validate_subdomain_origin/test_validate.py (right):

https://codereview.chromium.org/2456053004/diff/40001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/test_validate.py:58: if not
os.path.exists(args.utility_path):
On 2016/11/03 19:47:55, iclelland wrote:
> Can you call os.path.expanduser on this before using it, for consistency? That
> will let people do things like
>  --utility-path=~/something_else/validate_utility
> and it will work as expected.

Done.

[commit-bot: I haz the power, 2016-11-03 22:24:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-03 22:24:06]

Dry run: Try jobs failed on following builders:
  win_clang on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/...)

[chasej, 2016-11-04 16:48:04]

The CQ bit was checked by chasej@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-04 16:48:24]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[iclelland, 2016-11-04 17:20:56]

lgtm

[commit-bot: I haz the power, 2016-11-04 17:53:05]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-04 17:53:06]

Dry run: This issue passed the CQ dry run.

[chasej, 2016-11-04 17:58:53]

chasej@chromium.org changed reviewers:
+ agrieve@chromium.org, rdsmith@chromium.org

[chasej, 2016-11-04 17:58:53]

agrieve, please take a look at BUILD.gn. I wasn't sure exactly where I should
add a new utility. Let me know if there's a better place.

rdsmith, I need an owners review of the DEPS for the dependency on net/base.

[agrieve, 2016-11-04 18:06:33]

lgtm /w nits

https://codereview.chromium.org/2456053004/diff/80001/BUILD.gn
File BUILD.gn (right):

https://codereview.chromium.org/2456053004/diff/80001/BUILD.gn#newcode273
BUILD.gn:273: "//tools/origin_trials/validate_subdomain_origin",
I'm guessing there's not GYP version of this, so you should add it to the
"gn_only" target instead.

https://codereview.chromium.org/2456053004/diff/80001/tools/origin_trials/val...
File tools/origin_trials/validate_subdomain_origin/BUILD.gn (right):

https://codereview.chromium.org/2456053004/diff/80001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/BUILD.gn:5:
import("//build/symlink.gni")
Doesn't look like you're using symlink(), so you can remove this.

https://codereview.chromium.org/2456053004/diff/80001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/BUILD.gn:7:
executable("validate_subdomain_origin") {
Bonus points if you made this work for target_os="android".

To do so, wrap the target in:

if (current_toolchain == host_toolchain) {}

And in the root BUILD.gn, do:
deps += ["//tools/origin_trials/validate_subdomain_origin($host_toolchain)"]

[chasej, 2016-11-04 19:26:36]

agrieve, thanks for the review. I did have one followup question below.

https://codereview.chromium.org/2456053004/diff/80001/BUILD.gn
File BUILD.gn (right):

https://codereview.chromium.org/2456053004/diff/80001/BUILD.gn#newcode273
BUILD.gn:273: "//tools/origin_trials/validate_subdomain_origin",
On 2016/11/04 18:06:32, agrieve wrote:
> I'm guessing there's not GYP version of this, so you should add it to the
> "gn_only" target instead.

Moved to "gn_only", in an existing block for "!is_ios".

https://codereview.chromium.org/2456053004/diff/80001/tools/origin_trials/val...
File tools/origin_trials/validate_subdomain_origin/BUILD.gn (right):

https://codereview.chromium.org/2456053004/diff/80001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/BUILD.gn:5:
import("//build/symlink.gni")
On 2016/11/04 18:06:32, agrieve wrote:
> Doesn't look like you're using symlink(), so you can remove this.

Done.

https://codereview.chromium.org/2456053004/diff/80001/tools/origin_trials/val...
tools/origin_trials/validate_subdomain_origin/BUILD.gn:7:
executable("validate_subdomain_origin") {
On 2016/11/04 18:06:32, agrieve wrote:
> Bonus points if you made this work for target_os="android".
> 
> To do so, wrap the target in:
> 
> if (current_toolchain == host_toolchain) {}
> 
> And in the root BUILD.gn, do:
> deps += ["//tools/origin_trials/validate_subdomain_origin($host_toolchain)"]

I made the change, but I'm wondering if it applies here? This utility is meant
to be used from the command line or called from the generate_token.py script. I
don't see that happening on Android.

[chasej, 2016-11-10 16:49:38]

On 2016/11/04 17:58:53, chasej wrote:
> agrieve, please take a look at BUILD.gn. I wasn't sure exactly where I should
> add a new utility. Let me know if there's a better place.
> 
> rdsmith, I need an owners review of the DEPS for the dependency on net/base.

rdsmith, please take a look.

[Randy Smith (Not in Mondays), 2016-11-10 17:02:21]

On 2016/11/10 16:49:38, chasej wrote:
> On 2016/11/04 17:58:53, chasej wrote:
> > agrieve, please take a look at BUILD.gn. I wasn't sure exactly where I
should
> > add a new utility. Let me know if there's a better place.
> > 
> > rdsmith, I need an owners review of the DEPS for the dependency on net/base.
> 
> rdsmith, please take a look.

Ack, but checking in with team about appropriate guidelines for evaluating such.
 I expect that I'll response by end of the day.  (Sorry I didn't notice you
pulling me in earlier.)

[Randy Smith (Not in Mondays), 2016-11-10 18:45:07]

On 2016/11/10 17:02:21, Randy Smith - Not in Mondays wrote:
> On 2016/11/10 16:49:38, chasej wrote:
> > On 2016/11/04 17:58:53, chasej wrote:
> > > agrieve, please take a look at BUILD.gn. I wasn't sure exactly where I
> should
> > > add a new utility. Let me know if there's a better place.
> > > 
> > > rdsmith, I need an owners review of the DEPS for the dependency on
net/base.
> > 
> > rdsmith, please take a look.
> 
> Ack, but checking in with team about appropriate guidelines for evaluating
such.
>  I expect that I'll response by end of the day.  (Sorry I didn't notice you
> pulling me in earlier.)

tools/origin_trials/validate_subdomain_origin/DEPS LGTM.

[chasej, 2016-11-10 18:45:13]

The CQ bit was checked by chasej@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-10 18:45:50]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[chasej, 2016-11-10 18:47:51]

iclelland, please take one more look.

I've changed the logic so that IP addresses are now invalid.

[commit-bot: I haz the power, 2016-11-10 18:50:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-10 18:50:41]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)

[Ryan Sleevi, 2016-11-10 19:21:37]

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

[Ryan Sleevi, 2016-11-10 19:21:38]

I'm a little nervous about introducing any new dependencies on the Public Suffix
List, both for the PSL (as a PSL maintainer) and for Chrome.

I had some trouble understanding the context of this CL - that is, approaching
the bug and the description still left me uncertain the 'why' aspect of what you
were concerned about/trying to do.

Without wanting to block this, could you help me understand a little more what
the goals are?

[Ryan Sleevi, 2016-11-10 19:25:19]

https://codereview.chromium.org/2456053004/diff/140001/tools/origin_trials/va...
File tools/origin_trials/validate_subdomain_origin/validate_subdomain_origin.cc
(right):

https://codereview.chromium.org/2456053004/diff/140001/tools/origin_trials/va...
tools/origin_trials/validate_subdomain_origin/validate_subdomain_origin.cc:32:
static const char kOptionQuiet[] = "quiet";
Why not simply use LOG/VLOG to control this degree of verbosity?

[chasej, 2016-11-10 19:38:12]

Description was changed from

==========
Validate origins when generating subdomain tokens

Subdomain tokens will match against any subdomains of the given origin.
This relaxed matching should not be applied when subdomains represent
separate logical sites (e.g. <user>.github.io). Thus, subdomain tokens
are not to be issued for such domains.

This CL adds a utility to validate that a origin is not found in the
Public Suffix List. The token generation script will now call the
utility to check the origin, only for subdomain tokens.

BUG=658856
==========

to

==========
Validate origins when generating subdomain tokens

Subdomain tokens will match against any subdomains of the given origin.
This relaxed matching should not be applied when subdomains represent
separate logical sites (e.g. <user>.github.io). Thus, subdomain tokens
are not to be issued for such domains. For more detail, see the last
question in the Origin Trials developer guide:
https://github.com/jpchase/OriginTrials/blob/gh-pages/developer-guide.md

This CL adds a utility to validate that a origin is not found in the
Public Suffix List. The token generation script will now call the
utility to check the origin, only for subdomain tokens.

BUG=658856
==========

[iclelland, 2016-11-10 19:46:29]

New changes lgtm, thanks

https://codereview.chromium.org/2456053004/diff/140001/tools/origin_trials/va...
File tools/origin_trials/validate_subdomain_origin/test_validate.py (right):

https://codereview.chromium.org/2456053004/diff/140001/tools/origin_trials/va...
tools/origin_trials/validate_subdomain_origin/test_validate.py:30: '10.0.0.1':
STATUS_IP_ADDRESS,
May as well add an IPv6 address here as well; I don't think they could be
mistaken for hostnames, but just for completeness, to be sure they're returning
the right status code.

https://codereview.chromium.org/2456053004/diff/140001/tools/origin_trials/va...
File tools/origin_trials/validate_subdomain_origin/validate_subdomain_origin.cc
(right):

https://codereview.chromium.org/2456053004/diff/140001/tools/origin_trials/va...
tools/origin_trials/validate_subdomain_origin/validate_subdomain_origin.cc:32:
static const char kOptionQuiet[] = "quiet";
On 2016/11/10 19:25:19, Ryan Sleevi wrote:
> Why not simply use LOG/VLOG to control this degree of verbosity?

I didn't realize VLOG was appropriate for use in command-line utilities (I
assumed it was for chromium logging, not necessarily suitable for stderr-style
tooling output)
It looks like net/tools/quic/quic_client_bin.cc does something like that,
though.

[chasej, 2016-11-10 20:07:46]

Description was changed from

==========
Validate origins when generating subdomain tokens

Subdomain tokens will match against any subdomains of the given origin.
This relaxed matching should not be applied when subdomains represent
separate logical sites (e.g. <user>.github.io). Thus, subdomain tokens
are not to be issued for such domains. For more detail, see the last
question in the Origin Trials developer guide:
https://github.com/jpchase/OriginTrials/blob/gh-pages/developer-guide.md

This CL adds a utility to validate that a origin is not found in the
Public Suffix List. The token generation script will now call the
utility to check the origin, only for subdomain tokens.

BUG=658856
==========

to

==========
Validate origins when generating subdomain tokens

Subdomain tokens will match against any subdomains of the given origin.
This relaxed matching should not be applied when subdomains represent
separate logical sites (e.g. <user>.github.io). Thus, subdomain tokens
are not to be issued for such domains. For more detail, see the last
question in the Origin Trials developer guide:
https://github.com/jpchase/OriginTrials/blob/gh-pages/developer-guide.md

This CL adds a utility to validate that a origin is not found in the
Public Suffix List. The token generation script will now call the
utility to check the origin, only for subdomain tokens. The utility
is used when the generation script is manually run by the origin
trials team to issue tokens. The intent is to automate the origin
checks, to reduce the number of manual steps in issuing tokens.

BUG=658856
==========

[chasej, 2016-11-10 20:21:05]

On 2016/11/10 19:21:38, Ryan Sleevi wrote:
> I'm a little nervous about introducing any new dependencies on the Public
Suffix
> List, both for the PSL (as a PSL maintainer) and for Chrome.
> 
> I had some trouble understanding the context of this CL - that is, approaching
> the bug and the description still left me uncertain the 'why' aspect of what
you
> were concerned about/trying to do.
> 
> Without wanting to block this, could you help me understand a little more what
> the goals are?

I'll try to explain better, and I've update the CL description. I'll go back to
the beginning, so apologies if you've already covered this ground. The
background
starts in this thread:
https://groups.google.com/a/chromium.org/forum/#!topic/experimentation-dev/44...

To summarize, for some potential users of origin trials, the approach of one
token
per exact origin was a barrier to adoption. The suggestion was to allow for one
token to match multiple subdomains of the specified origin. Originally, we were
calling these "wildcard tokens", but have since settled on "subdomain tokens".
While the suggestion reduces the friction in using origin trials, there was some
concern that such tokens could enable experimental features more broadly than
intended (e.g. in third-party hosting/white-labelling scenarios).

We decided the risk was minimal, and is mitigated by the ability of origin
trials
to remotely disable features. We also decided to add restrictions to which
origins
would be allowed to request subdomain tokens. Specifically, we would ban public
suffixes (eTLDs) from being issued subdomain tokens.

So, in an earlier CL, we implemented support in Chrome to accept/validate
such subdomain tokens. As the token issuance process is controlled by Chrome,
there is no client-side validation of the origins. In this CL, the goal is to
add
automated validation of origins, to the generation of subdomain tokens. The
intent
is *not* to have 100% accurate validation. Rather, the intent is to block the
most
common (com, co.uk, github.io, etc), and save some manual checks in the process.

Using the public suffix list was seen as convenient way to automate these
checks,
without maintaining our own list of blacklisted origins. As well, it a public
resource that we could reference, if web developers asked about the
restrictions.

Hopefully, that helps you understand. I'm happy to provide more detail. Would
also welcome suggestions for a better approach.

[Ryan Sleevi, 2016-11-10 20:39:16]

On 2016/11/10 20:21:05, chasej wrote:
> Using the public suffix list was seen as convenient way to automate these
> checks,
> without maintaining our own list of blacklisted origins. As well, it a public
> resource that we could reference, if web developers asked about the
> restrictions.

Thanks. I'm definitely missing context on how Origin Trials are implemented, but
doesn't the risk exist that origins will be encouraged to remove their domains
from the PSL in white-labeling scenarios? The use of the PSL is voluntary and
self-reported - and we explicitly don't take third-party submissions.

I just want to make sure that's part of your threat model. Certainly, adding
yourself to the PSL to get around things like Disk Quotas is a real threat that
we don't have a solution for; here, it seems like removing (or not including
yourself) in order to get on the origin trial is the other risk.

Since I'm not that familiar with the threat model, but you're using it to reject
rather than accept, that seems fine. I did want to make sure we're not going to
see another rush of entries to get on the PSL just because a popular product
used it (e.g. Let's Encrypt caused a near doubling in the PSL size, due to
people putting their vanity domains on as a way of bypassing Let's Encrypt's
rate limits)

LGTM with caveats, and feel free to reach out if there's any questions or things
I can help with re: PSL

[chasej, 2016-11-11 15:34:40]

On 2016/11/10 20:39:16, Ryan Sleevi wrote:
> On 2016/11/10 20:21:05, chasej wrote:
> > Using the public suffix list was seen as convenient way to automate these
> > checks,
> > without maintaining our own list of blacklisted origins. As well, it a
public
> > resource that we could reference, if web developers asked about the
> > restrictions.
> 
> Thanks. I'm definitely missing context on how Origin Trials are implemented,
but
> doesn't the risk exist that origins will be encouraged to remove their domains
> from the PSL in white-labeling scenarios? The use of the PSL is voluntary and
> self-reported - and we explicitly don't take third-party submissions.
> 
> I just want to make sure that's part of your threat model. Certainly, adding
> yourself to the PSL to get around things like Disk Quotas is a real threat
that
> we don't have a solution for; here, it seems like removing (or not including
> yourself) in order to get on the origin trial is the other risk.
> 
> Since I'm not that familiar with the threat model, but you're using it to
reject
> rather than accept, that seems fine. I did want to make sure we're not going
to
> see another rush of entries to get on the PSL just because a popular product
> used it (e.g. Let's Encrypt caused a near doubling in the PSL size, due to
> people putting their vanity domains on as a way of bypassing Let's Encrypt's
> rate limits)
> 
> LGTM with caveats, and feel free to reach out if there's any questions or
things
> I can help with re: PSL

That's a good question about origins avoiding the PSL for origin trials. I
would think that's a minor risk.

Using subdomain tokens is mostly about convenience. The alternative is
requesting
a regular token for each individual subdomain, which would require more
administration, server configuration, etc. So, a subdomain token doesn't allow
origins access that would otherwise be impossible.

The other point is that origin trials limits usage per origin for regular
tokens.
For subdomain tokens, the same per-origin limit applies to all subdomains that
use the token. That essentially reduces the usage per subdomain. Staying within
the usage limit is the responsibility of the origin presenting the token.

Thanks for helping think through the threat model. We'll be watching the
requests for subdomain tokens. If we identify issues, we can revisit this
approach.

[chasej, 2016-11-11 19:54:03]

The CQ bit was checked by chasej@chromium.org

[chasej, 2016-11-11 19:54:03]

The patchset sent to the CQ was uploaded after l-g-t-m from
agrieve@chromium.org, iclelland@chromium.org, rsleevi@chromium.org,
rdsmith@chromium.org
Link to the patchset: https://codereview.chromium.org/2456053004/#ps160001
(title: "Use stdout for utility output")

[commit-bot: I haz the power, 2016-11-11 19:54:40]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-11 20:00:08]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-11 20:00:09]

Try jobs failed on following builders:
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[chasej, 2016-11-16 16:35:08]

The CQ bit was checked by chasej@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-16 16:35:41]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-16 16:42:54]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-16 16:42:55]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)

[chasej, 2016-11-21 19:24:06]

The CQ bit was checked by chasej@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-21 19:25:21]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-21 19:36:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-21 19:36:24]

Dry run: Try jobs failed on following builders:
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)

[chasej, 2016-12-16 17:19:53]

Patchset #12 (id:220001) has been deleted

[chasej, 2016-12-16 19:35:32]

The CQ bit was checked by chasej@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-16 19:36:14]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-17 00:04:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-17 00:04:05]

Dry run: This issue passed the CQ dry run.

[chasej, 2016-12-19 21:09:37]

chasej@chromium.org changed reviewers:
+ brettw@chromium.org

[chasej, 2016-12-19 21:09:37]

brettw@chromium.org: Please review changes in url/features.gni.

This CL adds a utility for use in the manual process for generating origin trial
tokens. However, the android_cronet bot was failing due android-related
configuration mismatch.

[Ryan Sleevi, 2016-12-22 22:42:22]

The CQ bit was checked by rsleevi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-22 22:42:46]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[brettw, 2016-12-22 22:48:28]

url/ lgtm

[commit-bot: I haz the power, 2016-12-23 00:03:06]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-23 00:03:07]

Dry run: This issue passed the CQ dry run.

[Ryan Sleevi, 2016-12-23 00:15:38]

The CQ bit was checked by rsleevi@chromium.org

[Ryan Sleevi, 2016-12-23 00:15:38]

The patchset sent to the CQ was uploaded after l-g-t-m from
iclelland@chromium.org, agrieve@chromium.org, rsleevi@chromium.org,
rdsmith@chromium.org
Link to the patchset: https://codereview.chromium.org/2456053004/#ps240001
(title: "Fix android_cronet build error")

[commit-bot: I haz the power, 2016-12-23 00:16:12]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-23 00:20:51]

CQ is committing da patch.

Bot data: {"patchset_id": 240001, "attempt_start_ts": 1482452138295080,
"parent_rev": "4892e3635a0f9d5454ee64c74713c737f1cf85d6", "commit_rev":
"6afa3dbc7c6520ef4e8fda26aa15262ce82a4d5c"}

[commit-bot: I haz the power, 2016-12-23 00:21:29]

Description was changed from

==========
Validate origins when generating subdomain tokens

Subdomain tokens will match against any subdomains of the given origin.
This relaxed matching should not be applied when subdomains represent
separate logical sites (e.g. <user>.github.io). Thus, subdomain tokens
are not to be issued for such domains. For more detail, see the last
question in the Origin Trials developer guide:
https://github.com/jpchase/OriginTrials/blob/gh-pages/developer-guide.md

This CL adds a utility to validate that a origin is not found in the
Public Suffix List. The token generation script will now call the
utility to check the origin, only for subdomain tokens. The utility
is used when the generation script is manually run by the origin
trials team to issue tokens. The intent is to automate the origin
checks, to reduce the number of manual steps in issuing tokens.

BUG=658856
==========

to

==========
Validate origins when generating subdomain tokens

Subdomain tokens will match against any subdomains of the given origin.
This relaxed matching should not be applied when subdomains represent
separate logical sites (e.g. <user>.github.io). Thus, subdomain tokens
are not to be issued for such domains. For more detail, see the last
question in the Origin Trials developer guide:
https://github.com/jpchase/OriginTrials/blob/gh-pages/developer-guide.md

This CL adds a utility to validate that a origin is not found in the
Public Suffix List. The token generation script will now call the
utility to check the origin, only for subdomain tokens. The utility
is used when the generation script is manually run by the origin
trials team to issue tokens. The intent is to automate the origin
checks, to reduce the number of manual steps in issuing tokens.

BUG=658856

Review-Url: https://codereview.chromium.org/2456053004
==========

[commit-bot: I haz the power, 2016-12-23 00:21:31]

Committed patchset #12 (id:240001)

[commit-bot: I haz the power, 2016-12-23 00:23:31]

Description was changed from

==========
Validate origins when generating subdomain tokens

Subdomain tokens will match against any subdomains of the given origin.
This relaxed matching should not be applied when subdomains represent
separate logical sites (e.g. <user>.github.io). Thus, subdomain tokens
are not to be issued for such domains. For more detail, see the last
question in the Origin Trials developer guide:
https://github.com/jpchase/OriginTrials/blob/gh-pages/developer-guide.md

This CL adds a utility to validate that a origin is not found in the
Public Suffix List. The token generation script will now call the
utility to check the origin, only for subdomain tokens. The utility
is used when the generation script is manually run by the origin
trials team to issue tokens. The intent is to automate the origin
checks, to reduce the number of manual steps in issuing tokens.

BUG=658856

Review-Url: https://codereview.chromium.org/2456053004
==========

to

==========
Validate origins when generating subdomain tokens

Subdomain tokens will match against any subdomains of the given origin.
This relaxed matching should not be applied when subdomains represent
separate logical sites (e.g. <user>.github.io). Thus, subdomain tokens
are not to be issued for such domains. For more detail, see the last
question in the Origin Trials developer guide:
https://github.com/jpchase/OriginTrials/blob/gh-pages/developer-guide.md

This CL adds a utility to validate that a origin is not found in the
Public Suffix List. The token generation script will now call the
utility to check the origin, only for subdomain tokens. The utility
is used when the generation script is manually run by the origin
trials team to issue tokens. The intent is to automate the origin
checks, to reduce the number of manual steps in issuing tokens.

BUG=658856

Committed: https://crrev.com/6205808cb4e9c61264e4aa48676e2f5833a61326
Cr-Commit-Position: refs/heads/master@{#440554}
==========

[commit-bot: I haz the power, 2016-12-23 00:23:33]

Patchset 12 (id:??) landed as
https://crrev.com/6205808cb4e9c61264e4aa48676e2f5833a61326
Cr-Commit-Position: refs/heads/master@{#440554}

[amineer, 2016-12-24 17:35:50]

A revert of this CL (patchset #12 id:240001) has been created in
https://codereview.chromium.org/2605563003/ by amineer@chromium.org.

The reason for reverting is: Breaks official Android builds, see
https://bugs.chromium.org/p/chromium/issues/detail?id=676894.