Re: CfC: FPWD of Entry Point Regulation

Important correction -- the latest version of the spec is located here:
https://w3c.github.io/webappsec/specs/epr/

> It's not entirely clear to me how the comments that were raised against
the charter were addressed.
The key part is contained within the latter half of the introduction:

---
If an author can limit incoming traffic to a strict set of well-audited
entry points, web applications can reduce the risk these attacks present,
and indeed some authors have taken steps to do so via server-side logic,
single page application (SPA) frameworks, (and, soon, via Service Workers).
Server-side techniques can be an effective solution, but have a number of
drawbacks. Complexity to the side, they are prone to false-positive
restrictions in cases where a user’s intent should override the author’s
intent (bookmarked links, for instance).
This document defines a browser-enforced mechanism which can be layered on
top of an existing application without server-side modifications, providing
the attack mitigation authors desire, while allowing user intent to trumph
brittle filters when possible.
---

Web developers already can choose models that avoid exposing all their
resources via direct links, for better or worse.  At least with EPR we get
some hard security guarantees as well as explicit flagging that
countermeasures against abuse can key off of.

By "countermeasures against abuse," I am referring to suggestions like the
idea that the existence of EPR can factor into search engine ranking.  I
left this out of the spec for the time being, but I'm open to adding it in,
as well as any other ideas along similar lines that help remove any
incentive for EPR to be abused.

> E.g. forcing users to enter through /.
Ack, the old version of the spec hadn't yet added detail around the default
EPR policy (section 4.2).  Please refer to the version on w3c.github.io
linked above.
Manifests allow for arbitrary entry points to be specified.  Prior to a
policy being available, the default EPR policy applies.  The default policy
does allow for navigation to arbitrary paths, not just /.

> ...the fact that user agents aren't required to enforce anything (as the
document reads now) makes me wonder if it can really achieve its stated
goal.
Thinking through this in the context of the example in the spec (section
1.2), the administration console would only benefit from EPR if the user
agent decided to enforce EPR.  But the same could be said about CSP or any
other browser security technology.



On Thu, Apr 30, 2015 at 3:46 AM, <chaals@yandex-team.ru> wrote:

> 30.04.2015, 10:54, "Anne van Kesteren" <annevk@annevk.nl>:
> > On Tue, Apr 28, 2015 at 10:20 PM, Brad Hill <hillbrad@gmail.com> wrote:
> >>  https://mikewest.github.io/webappsec/specs/epr/
> >
> > It's not entirely clear to me how the comments that were raised
> > against the charter were addressed. This seems hurtful still to
> > linking across the web. E.g. forcing users to enter through /.
>
> Yeah, but the fact that user agents can ignore it is important... until we
> get websites that block if it isn't enforced.
>
> Which makes the sites anti-web rather than the spec.
>
> On the other hand, the fact that user agents aren't required to enforce
> anything (as the document reads now) makes me wonder if it can really
> achieve its stated goal. And what might be added to it between now and a
> request to advance it to CR.
>
> cheers
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> chaals@yandex-team.ru - - - Find more at http://yandex.com
>
>