W3C home > Mailing lists > Public > public-html@w3.org > March 2007

Re: Multipart response support

From: Luka Kladaric <allixsenos@gmail.com>
Date: Wed, 28 Mar 2007 13:55:48 +0200
Message-ID: <3022aca10703280455m1fdaa363yb04ac446d422d6e2@mail.gmail.com>
To: public-html@w3.org

On 3/28/07, Henrik Dvergsdal <henrik.dvergsdal@hibo.no> wrote:
> > security through obscurity, anyone?
> This is no more obscure than attachements in emails and images in
> Word documents. Actually it corresponds more closely to what most
> people think is happening.

if all you're after is streamlining the HTTP fetch process, then fine.
(I still don't agree with it, but ok)... but if you're trying to solve
DRM issues and use it to 'hide' bits and pieces that in the end do
something for the user, you're wasting a *LOT* of time, money and
other resources on something you simply will not be able to achieve

as for the HTTP fetch process, as someone (that failed to reply the
group, and you cut their name out) already said, browsers do a pretty
decent job at handling the fetch process as it is...

> It will represent a significant barrier though. Obtaining hidden code
> etc. simply won't be worth while in many situations. The same goes
> for images and other types of media.

not only is this completely the opposite of what HTML is about, it's
impractical and useless... 'significant barrier' means it's not worth
the trouble of achieving something half the world would be against

hiding images from the transport streams just means you're raising the
value of commercial screenshot software

and you'll always have getright and wget to get the job done

web developers need to deal with the fact that what you put on the
web, is on the web... and if someone *wants* to (ab)use it and doesn't
care for the copyright laws, they *will* do it.

the video industry has a *lot* more money to waste on this and even
they've been unsucsessful... and they reinvent the wheel every 5 years
while ours have to work on old roads as well...

> > DRM should not be encouraged, let alone by an html spec.
> This is a quite modest form of DRM.

modest DRM isn't.

> Well, by putting images in a multipart response, authors will at
> least prohibit links directly into those images at their site. There
> are circumstances where this is quite useful.

check referer on your incoming image requests.

> I also think raising the barriers towards stealing and making it more
> explicit can be a good thing.

"raising the barriers", "hidden data", "DRM"... what is this? the
RIAA/MPAA WG? *none* of that belongs anywhere *near* HTML.

> Just because there are ways of working around such measures doesn't
> mean they are completely useless.

yes, yes it does.

> This is definetly not a transport layer issue. HTTP already supports
> multipart responses. And I think that any proposed change in HTML and
> corresponding browser support is withing the scope of this group.

you're not proposing a change to HTML. you're proposing a wrapper *for* HTML.

The geek shall inherit the earth.
Received on Wednesday, 28 March 2007 11:55:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:21:35 UTC