Re: [whatwg] Link Fingerprints (HTML version)
On Fri, 21 Mar 2008, Gervase Markham wrote: Some WHAT-WG participants may be aware of Link Fingerprints, which was a way to embed the hash of a file in a link to that file, thereby ensuring that the link user got only the exact file the link creator was referring to. http://www.foo.com/file.zip#!sha256:09F9... Implementing this idea was a Summer of Code project for Mozilla in 2007, but the draft RFC received a chilly reception on various IETF mailing lists. I have therefore reformulated Link Fingerprints as a simple extension to HTML. This makes it useful in a smaller set of contexts, but still hits the major use cases. a href=http://www.foo.com/file.zip; checksum=sha256:09F9...File/a The updated spec is here: http://www.gerv.net/security/link-fingerprints/ Please read it for more detailed aims, rationale and behaviour. Would the WHAT-WG be interested in looking at standardising this? (Before anyone asks, the key difference between Link Fingerprints and Content-MD5 is that the hash is served from a different server to the file.) This was discussed back in 2006: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-November/thread.html#7825 As far as I can tell, the issues raised in that thread are not yet addressed by the proposal above. (Thanks to Philip` for finding that link.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Link Fingerprints (HTML version)
Ian Hickson wrote: This was discussed back in 2006: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-November/thread.html#7825 As far as I can tell, the issues raised in that thread are not yet addressed by the proposal above. Thanks for the pointer. I don't think I was around for that discussion; or, if I was, I don't remember it. I'll read it carefully and see what needs changing. Gerv
Re: [whatwg] access to local path in input type=file
timeless replied to my concern: me In the code which follows, both IE7, FF(2.0), and Safari(3.1) allow the user to change the src attribute of an image based on her perusal of local file space. Opera 9.5 doesn't seem to allow access to the path data necessary for accomplishing this rollover effect, and I suspect that may be how it is supposed to be according to emerging standards. That is the situation when the HTML file is stored on localhost. timeless The web changed, today firefox only provides the leafname, not the full path (this is a good thing for security/privacy reasons), and we don't allow remote access to local content (this is a good thing). Security Error: Content at http://granite.sru.edu/~ddailey/imageUpload.htm may not load or link to file://localhost/78255.png. Actually, when I use Firefox 2.0012, the script contained in that file ( http://granite.sru.edu/~ddailey/imageUpload.htm) actually results in displaying the local path name in the input on that page, as well as in the alert. The data seems to be available, but merely useless for the application at hand. me While I understand the possible risk of exposing a path name of the local file system to script, the various use cases of allowing users to access local images within HTML, the canvas tag and within svg all seem self-evident to me. Is there some standard workaround to allow the user to change the source of an image on a web page to one that is locally stored? timeless in the modern world, you shouldn't be able to embed local images from remote content. if a user wants to see a preview an image they can use their os, file picker, favorite image viewer, etc. Perhaps I should have spelled out the use cases a bit more: I am not interested in previewing the thing, rather I'm interested in working with it application style-- as in photo editing it (in a web-based application) warping it (as with SVG clipPaths in another of the examples I illustrated) in morphing two images together using triangulations, clipPaths, warping, and opacity. I'm interested in doing image analysis, using the canvas tag and producing chromatic histograms, in calcuating differences between two images, in finding median images from a collection. Yes, I know one can buy software (or even freeware) and install it, but I'm interested in among other things in supporting scientists who wish to collaboratively edit one another's images on the web, in allowing a person to create and preview morph and animation sequences locally using remote script. The end user maintains copyright on the images, the script writer retains copyright (and closed source if desired) of the script itself. The app runs in the client rather than on the server, hence allowing the server to play server games rather than doing image processing. The first application I developed (circa 1999) using this ability to access pictures on localhost was an animation generator that allowed the user to import a series of jpg files (as from a movie clip) and to create a small video using setTimeout from which the source code (HTML and script) was generated by the app so that the end user could create the video without herself having to script. The thing worked in the two dominant browsers at the time. Last I looked there was no consensus between browser companies on formats for video in HTML so this still seems like the only way to proceed for the task at hand short of paying bigbucks. you can silently auto submit the image and send them back a version. The privacy (and copyright) exposure to the end user of having to submit the image to a server, have that stored temporarily on the server and then make a round trip back to the local machine seems far worse that the privacy risk of having script read the path of a file the user has already consented to make visible. Perhaps we need a new img type=local-file to cover the use cases??? What I'm ultimately interested in is not really the sort of thing one would expect to use forms for -- neither is doing content analysis inside a textarea however. Those just happen to be the tools that html provides. I know that under discussion in HTML5 is some amount of ability to read and write files locally. Would script access to local images be included in that capability? modern browsers will not expose path, only leaf. Well then I guess FF2.0012 and IE 7 are not considered modern. My FF3 installation seems flaky so I can't get it to launch. Opera 9. shows only the leaf but FF2 shows the whole path. regards, David
Re: [whatwg] [HTML5] Accessibility question
Apologies for not replying sooner, I've been struck with a bit of the flu. The problem I'm trying to solve is the case where you need descriptive text for screen readers but that text is not necessary for sighted users. For example, our accessibility guidelines at Yahoo! say that every unordered list (ul) should be preceeded by a header that describes its use. The header may say something like Page options or Available styles and we use CSS tricks (text-indent: -1px;) to hide these headings from display while allowing screen readers to read them. To sighted users, the meaning of the list is apparent because they can see the visual treatments we've applied whereas blind users would just hear a list read out of context. Another example is for buttons that make use of sprites. Something is implemented as a link but with a background image that's part of a sprite. The link needs to have descriptive text for screen readers but the text is unnecessary for sighted users as they can see the image. For example: a href=# class=closespanClose/span/a For things like this, I usually end up using the same CSS trick mentioned above to move the Close text out of the way. Just looking at the HTML, it's not apparent that Close is not intended to seen. Whereas the following clears it up: a href=# class=closespan noviewClose/span/a Now I know from looking at the source code that Close is clearly not intended to be seen. -Nicholas - Original Message From: Ian Hickson [EMAIL PROTECTED] To: Nicholas C. Zakas [EMAIL PROTECTED] Cc: whatwg List [EMAIL PROTECTED] Sent: Sunday, March 16, 2008 6:36:17 PM Subject: Re: [whatwg] [HTML5] Accessibility question On Sun, 16 Mar 2008, Nicholas C. Zakas wrote: I know the topic has come up a few times, but I'm still wondering if HTML 5 should provide some sort of logic around content that should not be displayed by browsers but should be read by screen readers. Perhaps a noview boolean attribute on each element could be used to tell UAs not to render the content but to report it to screen readers? Or maybe a noview/ element could be used to surround content that shouldn't be displayed but should be accessible to screen readers? Wouldn't hiding content from sighted viewers hurt accessibility for sighted viewers? Could you elaborate more on what problem you are trying to solve? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [whatwg] [HTML5] Accessibility question
I don't think this is a CSS issue, it follows along the lines of noscript for hiding content in some cases or @irrelevant (hopefully renamed to @ignore :) ) hiding content in others. CSS generated content will be displayed on the screen just as regular content is, which is the very problem I'm proposing needs to be solved. -Nicholas - Original Message From: Sam Kuper [EMAIL PROTECTED] To: Ian Hickson [EMAIL PROTECTED] Cc: Nicholas C. Zakas [EMAIL PROTECTED]; whatwg List [EMAIL PROTECTED] Sent: Monday, March 17, 2008 7:19:48 PM Subject: Re: [whatwg] [HTML5] Accessibility question On 17/03/2008, Ian Hickson [EMAIL PROTECTED] wrote: That seems more like a CSS issue. I now think so too. Simon Pieters made the point that CSS3 can solve this problem. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: [whatwg] access to local path in input type=file
The spec should just say to not expose the full path by default. That way, browser makers can (not must or should or anything like that) provide a I'll be the judge of that! user option to override that globally or per-site if they want. -- Michael
