> Why does the intended audience of the feature matter? What matters is
> what it does and how it can be used, no?
I'll assume that the primary concern is with apps / sites that
unintentionally block deep links due to legitimate EPR usage. In this case
the intended audience matters because it's targeted. Contrast this with
CSP or HSTS where broad application across web apps / sites is understood
to be the long-term goal. The value prop for implementing an EPR manifest
for a large public web site is low. The manifest would be large, complex,
and dynamic, while the risk of XSS overall is bearable. But EPR is
extremely valuable for an admin interface, where the risk of XSS is
catastrophic and the number of entry points to list in a manifest is low.
> We just want to be cautious.
Fair enough.
> There are other ways we could limit some of these too I think. E.g. by
> introducing first-party and/or same-origin cookies.
I think that would address XSRF but not XSS. (?)
Dave
On Wed, Feb 11, 2015 at 11:42 PM, Anne van Kesteren <annevk@annevk.nl>
wrote:
> On Wed, Feb 11, 2015 at 11:09 PM, David Ross <drx@google.com> wrote:
> > That being said, I think the criticism is a bit unfair. EPR is an opt-in
> > feature with an intended audience largely separate from those who might
> wish
> > to prevent deep linking on their web sites.
>
> Why does the intended audience of the feature matter? What matters is
> what it does and how it can be used, no?
>
>
> > I don't see any reason to
> > believe that we will see excessive and inconsiderate application of EPR
> > leading to linkability issues on the web at large. If a publisher is
> > determined to prevent deep linking there are plenty of ways for them to
> do
> > that today, whether they choose to make use of the web platform or not.
> > IMO, quashing proposed platform functionality such as EPR constrains
> > consumers of the web platform and serves to limit the attractiveness of
> the
> > platform as a whole.
>
> We just want to be cautious.
>
>
> > EPR helps enable the web platform to support scenarios with very
> stringent
> > security requirements. For example, XSS or XSRF is an unacceptable
> failure
> > mode for sensitive applications. (Eg: Administrative consoles) Authors
> of
> > these sensitive applications sometimes favor implementation as a legacy
> > platform app, a mobile app, or even a command line app over the web app
> > platform simply because of this security consideration. I believe it's
> > important to provide the _option_ for developers to implement EPR to
> better
> > meet their security requirements.
>
> There are other ways we could limit some of these too I think. E.g. by
> introducing first-party and/or same-origin cookies.
>
>
> --
> https://annevankesteren.nl/
>