Slashdot Mirror
Google Tags Content Creators
bizwriter writes "Google announced that it will support authorship HTML tags, a way to associate Web content with the individuals who create it. Suddenly, search engines know when one person was responsible for a body of work, no matter where content appears on the Web. If Google incorporates this into page relevance and ranking, as it is considering, the result could change the balance of power between those who create and those who publish."
It is made to sound more uncontrolled that it is. This is what really happens:
The markup uses existing standards such as HTML5 (rel=”author”) and XFN (rel=”me”) to enable search engines and other web services to identify works by the same author across the web.
This is handy, allowing search engines to find content by a specific author. It's not like Google will automatically decide what content links to which author.
We can't expect Google to give purely weighted search results based on this either. More like they will keep their existing page rankings, and include this extra author meta-data in specialized searches.
We know that great content comes from great authors, and we’re looking closely at ways this markup could help us highlight authors and rank search results.
The bnet article seems to over dramatize it, possibly due to a lack of understanding what this means for content creators.
Or do I also have the wrong idea?
Oh dear me, am I missing something?
So you can totally spoof random people's names into any webpage? So searches for author=Obama come up with doctored pics of Osama-Obama slash or something?
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
probably nothing.. as well as another site copying your site can just remove your tag and replace it with theirs, claiming they're the original author..
Learn about pinball machines on www.flippers.be
what's to stop me from "borrowing" someone's author tag
Federal law, as I pointed out in another comment.
They can't. The fact that it is just basic HTML means that detect-and-strip will be downright trivial; but there is nothing(outside of the darkest fantasies of the "trusted computing" set) that could actually stop such activity.
It seems like this falls into the category of 'potentially useful incremental change'. It isn't resistant to rip-offs(but neither was the status quo) and it makes it somewhat easier for good-faith actors to make a pertinent piece of metadata easily accessible. The metadata dreams of the 'semantic web' types seem doomed to founder in a morass of epistemological horrors; but tagging a few bits of metadata that people are obviously interested in seems quite sensible.
More robust(not entirely bulletproof) solutions would certainly be possible; but they would involve much greater changes to the way web browsers work, and the workflow of common authoring mechanisms. For instance, assymetric-key crypto and document signing would, if widely used by authors and sensibly interpreted by web browsers and other document/media viewing applications allow authorship claims to be harder to falsify.(You could still falsely claim to have authored somebody else's work, just strip their signature and substitute your own; but you could no longer falsely claim that somebody else was the author of a given work, since you wouldn't be able to sign it as them). If you added cryptographically verified timestamps from one or more "trusted" sources, you could go one step further and allow people to demonstrate that they were the first to sign something(which would still be vulnerable to rip-offs by scrapermedia LLC programmatically scooping up every unsigned document that some poor noob puts on the web and automatically 'first-signing' it; but would make stripping and re-signing much easier to detect in general).
Such changes, though, would, unlike the HTML tag, involve serious overhaul of how the browser works, how much 'normal people' use crypto(and protect their private keys), and the features supported by authoring software. This doesn't mean that it would be a bad thing(in fact, it would have other interesting side-benefits); but it would Not be an easy move to make.
(The side benefits, of such a change, for browsers; would be that it would allow you to make the browser cache immensely more powerful and useful: In order to support cryptographic verification of authored elements and then integration of those elements with stylesheets and other webpage/CMS goo, browsers would have to have a generic capability to retrieve, cryptographically validate, and then integrate "packages" of material. This capability could also be applied to things like CSS stylesheets, javascript libraries, etc. Hypothetically, for instance, instead of a page simply specifying a javascript library, and a location on the server from which to retrieve it, a page could specify the library, its SHA-whatever hash, and its signer, along with at least one URL at which to obtain it. If the browser already has an object with an identical SHA hash(even if downloaded when visiting some entirely different domain, not uncommon for semi-standard stuff like jquery) it could skip retrieval. This would also allow page authors to link to 3rd party locations without fear of tampering that could compromise their pages. Given the increasing prevalence of large, resource-heavy, web applications, use of 3rd party CDNs, and similar, giving browsers the ability to securely cache 'packages' and then use them to construct pages, free from concerns about cross-domain attacks, and giving page authors the ability to securely invoke 3rd party resources, without risk of after-the-fact tampering, would be quite handy.)
Didn't know the federal law had jurisdiction in the UK.
That didn't stop your Parliament from enacting its own counterpart to this legislation in 2003, as section 296ZG of British copyright law.