I'm a bit worried about a potential "security" concern if people overuse the hash attribute. This is something that really should only be used when you really need to refer to a specific version of a resource -- and it should be a resource that you expect to be stable for a useful period of time. My concern is that people will tend to think that it is "cool" to add in more metadata on links and thus will just hash all kinds of stuff -- because they can. The result will be a large number of "broken" hashes and a sense that since most hashes are broken, the fact that a hash is broken is simply not interesting... At that point, various social engineering operations become possible.
We really should consider discouraging people from using the hash attribute unless it is really necessary and unless they actually expect that the resource they are hashing *should* be stable for a usefully long period of time. bob wyman On Tue, May 25, 2010 at 5:06 PM, James Snell <[email protected]> wrote: > I've been considering either an "accessed" attribute or specifying > terms that indicate that atom:updated element be used as the > point-in-time for the links for atom:entry and atom:feed. The when > attribute would serve the same purpose for at:deleted-entry and I > assume that other containers for atom:link could specify their own > relevant time. And you make an excellent point on focusing on the > specific utility of the attributes. Are there are security concerns > you can think of relating to the specific use cases for these > attributes? > > On Tue, May 25, 2010 at 12:52 PM, Bob Wyman <[email protected]> wrote: > > The way you describe the utility of the hash, you make it sound like it > is > > somehow "inadequate" for the traditional use of hashes. But, that's not > > really relevant here. This is a use of a hash for a different purpose > than > > the hashes we normally use in link integrity checking. I would suggest > that > > you focus on the utility of this style of hash rather than emphasizing > the > > things that it doesn't even attempt to do. > > BTW: I realize that this may be totally unnecessary, however, I can't > help > > thinking that a "last-accessed-on" attribute to show when the link was > last > > accessed and thus when the hash was generated might be useful... In > nothing > > else, there is a good bit of precedence in things like formal standards > for > > citing web resources that typically require that a "last-accessed" date > be > > provided. I'm not willing to invest a great deal in fighting for this. I > > just thought I would mention it. > > bob wyman > > > > On Tue, May 25, 2010 at 3:07 PM, James Snell <[email protected]> wrote: > >> > >> Ok, so I'm working on finishing up the basic link extensions draft. > >> The Security Considerations are currently TBD. I wanted to take a > >> moment to solicit input on appropriate security considerations for > >> these optional, advisory extension attributes. > >> > >> One in particular... hash digest are often used as a simple means of > >> verifying that data has not been modified while in transit.. hash > >> digests contained within an atom:link cannot be used for that purpose. > >> Rather, the hash attribute is used to express the state of the linked > >> resource at a given point in time so that a feed consumer can detect > >> whether or not the resource has been modified since the link was > >> created. > >> > >> Other than that, there really shouldn't be any further security > >> concerns with regards to the link extensions.. but I welcome being > >> corrected on that :-) Thoughts? > >> > >> -- > >> - James Snell > >> http://www.snellspace.com > >> [email protected] > >> > > > > > > > > -- > - James Snell > http://www.snellspace.com > [email protected] >
