Re: [whatwg] checksum attribute in a href tag
Anne van Kesteren, 2012-10-19 14:57 (Europe/Helsinki): > On Fri, Oct 19, 2012 at 1:50 PM, A. Rauschenbach > wrote: >> I'm sick of coping the checksum of important files by hand or QR-code to the >> download manager or console. >> >> To solve the problem I suggest a checksum attribute in the tag. >> >> example: http://example.com/important.file"; >> checksum="MD5:32c3675211199b671fbca1304d819289;SHA1:6e1ddeede3979c953788a3499616af35ee5fd772">download >> >> Another advantage is that your visitors (browser) can verify that the >> document (e.g. a pdf) you linked to is still the same. > > If you serve important files over HTTP without TLS I don't think a > checksum is going to help anyone much. Checksum can help even with encrypted connections. Example scenario: User connects to https://download.manufacturer.com/ and clicks link Firmware version 15 The download then starts and file gets saved to the filesystem. However, the system has memory corruption and despite the fact that the file got to the user agent intact, the file will end up as corrupted to the filesystem. However, if user agent had computed and verified the checksum after re-reading the file back from the local filesystem, it would have noticed the error. You might think that memory corruption is rare but trust me, it happens often enough to be worried about. After it has bitten you once, you learn to be paranoid about that. I'm speaking from experience here - I once had a memory corruption that caused three bits (out of 8GB) to randomly fail and that caused filesystem data corruption. And I had already been running a memory tester (memtest86) for a day without errors after I had installed the memory so I assumed it would be fine. Search for "git corrupt" for more evidence from real world software developers and remember that software developers are usually using high quality hardware. You don't want to fail with an important opaque file such as a firmware image. Hopefully the firmware image will contain internal checksum but it wouldn't hurt if the problem were found before trying to flash the image. -- Mikko
Re: [whatwg] Spec for location object needs to make some properties unforgeable; need supporting WebIDL changes
On 10/23/12 5:45 PM, Ian Hickson wrote: heycam, bz, what's the conclusion on this? I don't think we ever reached one... Should I define a valueOf and make just that, the toString serializer, and href unforgeable? In the end, all properties and methods that let you read stuff out of Location need to be unforgeable as far as I can tell. Incidentally there's also a request to mark the 'location' attribute itself (on Document, presumably also the one on Window) unforgeable: It's already unforgeable on Window, fwiw. -Boris
Re: [whatwg] Which html5 features should replace plugins like flash
On Tue, 23 Oct 2012, Jonas Grus Dinesen wrote: > > I understand that some of the motivation of html5 was to reduce the need > for plugins like the flash player. But are there some features that are > specifically developed with this intention? > > The question is relevant for me because I am working on a school project > (it university, copenhagen) in which I will try find out if, and to what > extend, certain features will be able to reduce or maybe eliminate the > need for fx flash. I want to focus on video, audio, svgand canvas tags > and apis. > > Then it would be nice with a clear argument for why I did not focus on > fx websockets, geolocation or other nice html5 things. We didn't really pay much attention to Flash at all, to be honest. However, I understand that a lot of features now in the Web platform as standards do cover very similar ground to what Flash can do. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Spec for location object needs to make some properties unforgeable; need supporting WebIDL changes
On Fri, 28 Sep 2012, Boris Zbarsky wrote: > On 9/28/12 12:44 AM, Cameron McCormack wrote: > > What about other functions from Object.prototype, by the way? > > toLocaleString, watch, hasOwnProperty, etc.? If there are a bunch of > > properties (that don't correspond to IDL members) that need protecting, > > maybe handling it in [DefineOwnProperty] is the simplest thing to do. > > I don't think the rest of those need protecting for Location. And > simply making valueOf an own non-configurable property is a lot simpler > than creating yet another custom [DefineOwnProperty] implementation, at > least in Gecko, and has the benefit of not being weird magic from the > point of view of the web page. I can't speak for other > implementations... heycam, bz, what's the conclusion on this? Should I stick [Unforgeable] on the interface to make everything in that interface unforgeable? Should I define a valueOf and make just that, the toString serializer, and href unforgeable? Something else? Incidentally there's also a request to mark the 'location' attribute itself (on Document, presumably also the one on Window) unforgeable: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19560 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Which html5 features should replace plugins like flash
Hi mailing list I understand that some of the motivation of html5 was to reduce the need for plugins like the flash player. But are there some features that are specifically developed with this intention? The question is relevant for me because I am working on a school project (it university, copenhagen) in which I will try find out if, and to what extend, certain features will be able to reduce or maybe eliminate the need for fx flash. I want to focus on video, audio, svgand canvas tags and apis. Then it would be nice with a clear argument for why I did not focus on fx websockets, geolocation or other nice html5 things. I posted the same question at the help mailing list earlier but this list seems to be a better forum. Grus
Re: [whatwg] maincontent element spec updated and supporting data provided (Henri Sivonen)
Hi Henri,
A single-word element name would me more consistent with
> other HTML element names. would be rather generic, so I
> think would be the better option.
>
Have changed name [1]:
After consideration of feedback I have changed the name of the element
from to . The reasoning for the change:
Feedback indicates preference for a shorter one word element name.
Most commenter's proffered as a name.
The element name is already proposed for use in the shadow DOM
specification [2]
As the element maps onto the ARIA role=main it seems an appropriate name to
use.
It would probably make sense to add
> main { display: block; }
> to the UA stylesheet.
>
have added.
If Hixie had added this element in the same batch as ,
> and , he would have made the parsing algorithm
> similarly sensitive to this element. However, I'm inclined to advise
> against changes to the parsing algorithm at this stage (you have none;
> I am mainly writing this for Hixie), since it would move us further
> from a stable state for the parsing algorithm and, if the
> element is used in a conforming way, it won't have a element
> preceding it anyway.
>
have captured your feedback on parsing in bug:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19591
[1]
https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html
[2]
http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#content-element
>
> --
>
> Message: 4
> Date: Thu, 18 Oct 2012 09:12:41 +0300
> From: Henri Sivonen
> To: whatwg
> Subject: Re: [whatwg] maincontent element spec updated and supporting
> dataprovided
> Message-ID:
> <
> cajqvaudr2qvcpd82s4zriz3itsgq_y1q+fi2s5vnmr++txv...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Oct 17, 2012 at 3:03 AM, Steve Faulkner
> wrote:
> > I have updated the spec [1] and would appreciate any
> feedback
> > (including, but not limited to implementers).
>
> A single-word element name would me more consistent with
> other HTML element names. would be rather generic, so I
> think would be the better option.
>
> It would probably make sense to add
> main { display: block; }
> to the UA stylesheet.
>
> If Hixie had added this element in the same batch as ,
> and , he would have made the parsing algorithm
> similarly sensitive to this element. However, I'm inclined to advise
> against changes to the parsing algorithm at this stage (you have none;
> I am mainly writing this for Hixie), since it would move us further
> from a stable state for the parsing algorithm and, if the
> element is used in a conforming way, it won't have a element
> preceding it anyway.
>
> --
> Henri Sivonen
> hsivo...@iki.fi
> http://hsivonen.iki.fi/
>
>
> -
>
