Re: A modest content security proposal.

On Tue, Jul 23, 2019 at 12:45 PM Craig Francis <craig.francis@gmail.com>
wrote:

> On Tue, 23 Jul 2019 at 08:51, Mike West <mkwst@google.com> wrote:
> A more typical (smaller) website probably doesn't need that many paths,
> and if they only contain static files, then you're unlikely to find a
> redirect in there.
>
> I don't have fundamental objections to including some sort of path
>> restrictions in whatever we do next. I don't think they're terribly useful
>> as-defined in CSP3: they sincerely complicate writing a parser, and they're
>> more or less neutered so as to not leak data about redirects.
>>
>
These two paragraphs reminded me... back before CSP, I worked on a system
to do resource confinement, and our research at the time found that many
sysadmins were totally ok with everything being based on domains, but many
web design folk preferred paths, because they didn't always have sufficient
control over their hosting (or their customers didn't, or it had the
potential for a whole lot of open tickets and communication hassles even
when it was doable).

... Of course, since the projects where we asked these questions was a
research project, we made a note of it and then only wrote the demo code to
support domains because paths would have been more work and weren't really
more likely to get us a publication. ;)  (Ah, academia!)

The tools have changed since that research paper, but I *suspect* there's
still a "friction" against subdomains.  Hosted services like github pages
or wordpress may not have that type of flexibility, and contract designers
may have the same problems now as they did a decade ago.  These seem like
issues that may affect folk who would be especially interested in a sleek
new CSP.  Not sure how we'd test the hypothesis, but I'm thinking that
Craig is onto something here so I guess I'm +1 for supporting paths too.

 Terri