[whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Smylers]

Elliotte Harold writes:

> Smylers wrote:
> 
> > > That's a sometimes convenient feature for site developers,  but
> > > there's nothing you can do with content loaded from two sites you
> > > can't do with content loaded from one.
> > 
> > Here's some I can think of:
> > 
> > * Many sites are funded by displaying adverts from a third-party
> >   service which picks appropriate ads for the current user-page
> >   combination.
> 
> Serve ads from the host site.

That's fine if the host site can do it.  But often the point of
subcontracting something to a third party is through lack of ability to
do it oneself.

A website on a particular topic may be financially viable by running
third-party-provided ads; that requires merely a standard template in
each page, a one-off cost which can be forgotten about.  Whereas running
ads themselves would take ongoing effort by the site (uploading them,
making the pages link to them).

That may reduce the time those running the site have available to work
on the site's content.  Or they may have to pay somebody else to set up
the ads.  Either of which could make the site no longer financially
viable.

> >  Further, I don't see how users can be tracked across multiple sites.
> >  This is useful to serve users a variety of different ads, rather than
> >  the same one lots of times, even as they read multiple sites which all
> >  use the same third party ad service.
> 
> That's a feature, not a bug. Or another way: users shouldn't be able
> to be tracked across sites. That they are is a bug, not a feature.

If I'm going to see ads, I'd rather get different ads than repeatedly
encounter the same ones.

> > * Third party traffic analysis services, ranging from simple image
> >   hit-counters to something like Google Analytics, require being
> >   part of a page's loading.
> 
> Not all such services do require this though.

That's true.

> I don't have time to respond in detail to each of the valid points
> your raise.  I may later.

No, I understand your general point, and I'm sure for each of them I
could come up with an alternative technical implementation.

It's just that I think such alternatives require sites to make other
changes -- changes to their business models, such as switching to a more
advanced hosting package, or having to perform in-house tasks which were
previously outsourced.  And of course they break the business models of
some of the outsources, whose products could no longer be used.

> If we break these things such that third party content is no longer
> the simplest solution that could possibly work, then developers and
> sites will move on to the next simplest solution.

Or they won't bother, and sites that currently exist will give up.

> Addressing the root cause will cause pain because a lot of systems you
> mention will have to be rewritten to work in the new world.

Indeed; that's my major concern here.

HTML in general is a sub-optimal.  XHTML 2 tried the approach of
accepting transition pain in order to move to a saner place, but that
doesn't seem to have gained traction.

I'm simply not persuaded that those who would have to pay the cost of
that pain will accept it.

The first time a browser is released that implements this idea, many
existing sites will fail.  Users will blame the browser (we know that
because Mozilla-based browsers got blamed for things it did correctly
but differently from IE, such as alt text not being in a tooltip).

At that point, all other browsers (and older releases of that browser)
will still work.  Why would users bother switching?

And if users don't switch, why would sites bother updating themselves?

Nor do I see that it is within the remit of HTML 5 to outlaw certain
business models that were permitted under HTML 4.  We're saying that
such sites aren't welcome on the web?  What if such sites are served
with valid HTML 4; should they still have HTML 5's new rules applied to
them?

> So be it.

For any suggestion on this mailing list it's proponents could dismiss
its costs with "so be it".  That doesn't in any way justify why those
costs are worthwhile.  You appear to be arguing here that the costs are
worth it no matter how high they are.

Simon