Atom

ASUS EPad: like the EeePad, but with less ecstasy — Well, isn't this typical ASUS. Yet another Eee Pad, or this time an 'EPad' as the placard says, has shown up on the Computex show floor. While the company introduced two Eee Pads at its press conference earlier this week -- the 10-inch EP101TC with NVIDIA Tegra 2 / Windows Embedded Compact 7 and the 12-inch EP121 with Intel / Windows 7 -- this new 10-inch version has popped up running Windows 7 at the Intel booth. We'd be lying if we said we knew what was going on here, but to us it looks like ASUS shot out a working Windows 7 model -- perhaps just to have a functioning device to display on the show floor. There's no telling if it's being powered by Intel's Atom Moorestown platform or a current Menlow Z Series CPU, but the design looks very similar to that of the EP101TC. We've sent off an inquriy to ASUS' PR team, but you'll still want to check out the video after the break of a very slim slate and real live "booth babe."

Continue reading ASUS EPad: like the EeePad, but with less ecstasy

ASUS EPad: like the EeePad, but with less ecstasy originally appeared on Engadget on Fri, 04 Jun 2010 07:14:00 EDT. Please see our terms for use of feeds.

Permalink   |  CarryPad  | Email this | Comments

Setting the record straight — I don't know Josh Fraser, so I'm going to assume he's well-intentioned. But this tweet from him represents something all-too-common. People spin stuff to make it look like corporate-owned technology is something other than what it is.

Here's what actually happened when I decided to implement PubSubHubBub. At first I was enthusiastic, and said so -- until I saw that it had no support for RSS. It was all about managing realtime updates for Atom feeds. It said so in the spec, and there was no indication that they planned to change it. In fact, it said quite the opposite. The authors didn't see any reason to implement support for RSS.

At that point I knew I wasn't going to implement it, because I don't have any code that generates Atom feeds, and I don't plan to write any. I do have code that parses them. There's enough Atom-formatted content out there that you have to. So I do. But I have a choice in what I transmit, so I use RSS 2.0. I know that every aggregator supports it, so I'm on solid ground in that choice.

Am I wrong to think that PubSubHubBub comes from Google? Well, I'm sure there are other people writing stuff that works with it, people who don't work for Google. But if there were going to be a major change in direction in PSHB, it would have to come from Google. Conversely, if you and I got together and decided that PSHB should fully embrace RSS, we'd find ourselves discussing this with Google people. Whether it happened or not, that decision would be made by people who work at Google. You decide whether that means it comes from Google or not. I don't care to argue hair-splits.

I was going try to work with them. Vic Gundotra, who I know for many years, before he worked at Google -- was setting up a meeting with the two leads when news of a Google patent on RSS reading lists came out. That reminded me, in very stark terms, how this works. The patent was in an area where I had done a lot of unpatented work. You don't find out about patents for years after they're filed. Has Google filed patents around PSHB? Is the Pope Catholic? It's in Google's nature to claim supposedly "open" technologies as their property. It's much better to use unpatented tech that pre-dates all this stuff. Which is where the <cloud> element in RSS 2.0 comes in.

Everything that PSHB does can be done with stuff that is prior art for PSHB and therefore in the future will not be subject to control by Google. To me it's a no-brainer to use it. I don't see why anyone else would go differently, unless Google is paying them to, or they don't understand how patents work. Google's fanboys will call this FUD -- which means fear, uncertainty and doubt. It certainly is fear -- sometimes fear is the right thing. There's no uncertainty or doubt because Google does file patents. If they haven't filed any around their work in PSHB they should say so, clearly and unambiguously, in a legally binding way (i.e. a statement from an officer of the company, in writing). Then we can all relax about it. Until then I'm going to assume they have.

Anyway, I'm not nervous about "jumping into bed" with BigCo's, because I don't do it. Life is too short to waste time waiting for a tiger to shed its stripes or for the church to name a non-Catholic Pope. I stay with RSS because it's solid, it works, and no one can tell me I can't use it.

Intel Considers Hardware Acceleration For Google's WebM Format — CWmike writes "Intel is considering hardware-based acceleration for Google's new WebM video file format in its Atom-based TV chips if the format gains popularity, an Intel executive said on Thursday. Announced last Wednesday at Google I/O, WebM files will include video streams compressed with the open-source VP8 video codec, which was acquired by Google when it bought On2 Technologies in February. 'Just like we did with other codecs like MPEG2, H.264 and VC1, if VP8 establishes itself in the Smart TV space, we will add it to our [hardware] decoders,' said Wilfred Martis, a general manager at Intel's Digital Home Group."

Read more of this story at Slashdot.

With Google I/O 2010 finally upon us, what better time to introduce developers to the latest updates to the Google Buzz API?

As announced at the launch of Google Buzz, the Google Buzz API aligns itself with the ever-growing family of freely available and community-developed protocols, formats, and standards for sharing and consuming social content on the web, including ActivityStreams, Atom, AtomPub, JSON, OAuth, PubSubHubbub, MediaRSS, PortableContacts, and more.

The Google Buzz API, a member of the Google Code Labs, is very much a work in progress — we intend to continue to iterate out in the open as we go along — and we hope the features we are making available today will help inspire developers and provide a solid foundation for new applications to be built.

We are already excited to see developers who were helping us test the API deliver terrific applications. Today you'll start seeing the following sites and services integrate with Google Buzz:


End-users opt into using applications built with the Google Buzz API via an interstitial confirmation screen outlining the application's requested access scope (read-only, read/write, etc.). They can see which apps have access to their data and can disable access at any time from the Google Accounts page, the Google Dashboard, the “Buzz" tab in Gmail Settings, or from the app itself.

This initial iteration of the API includes support for fetching public per-user activity feeds, fetching authorized and authenticated per-user activity feeds (both what the user creates, and what they see), searching over public updates (by keyword, by author, and by location), posting new updates (including text, html, images, and more), posting comments, liking updates, retrieving and updating profiles and social graphs, and more. The best way to get started is to dive right in and begin reading the Google Buzz API developer documentation.

There’s a lot more to come, and we expect to keep moving quickly from here. But none of this would be possible without the hard work of everyone participating in creating the protocols upon which Google Buzz is built, so we ask and encourage developers to get involved with the communities behind ActivityStreams, OAuth, and the countless others that we depend on.

And as with any young API, there will undoubtedly be bugs and issues and places where we’ve deviated from what the specifications say, or with what developers may expect. When you see something amiss, get confused by an approach we’ve taken, or just want to comment on our progress, we invite you to update the Buzz API issue tracker and please join the conversation on the developer forum.

With that, we’d like to welcome everyone to the first version of the Google Buzz API. We can’t wait to see what else we can build together.

By DeWitt Clinton, Google Developer Team

From the spec.. Section 7.1 “When new content is added to a feed, a notification is sent to the hub by the publisher. The hub MUST accept a POST request to the hub URL containing the notification. This request MUST have a Content-Type of application/x-www-form-urlencoded (described in Section 17.13.4 of [W3C.REC‑html401‑19991224]) and the following parameters in its body:”

Ok… so question… the content publisher knows what content has been updated when it sends this notification… why not support an option that would allow the publisher to push that content to the hub rather than requiring the hub to go off an fetch it all the time? This obviously opens up some risk to the hub, but there are ways of mitigating that…


POST /hub?hub.mode=publish HTTP/1.1
Content-Type: application/atom+xml

<entry ... >
...
</entry >

If multiple entries have been updated, an atom:feed document can be posted containing all of the updated entries. Would be very nice if the hub supported this as an alternative option to the form post.

Another question… how do I notify the server that content has been deleted? Obviously if the hub can support the posting of an atom:entry like above, it could also support posting of an Atom Tombstone… and there could be a variant of the form-post option that allows the content-publisher to indicate deleted content.

In Section 7.4: “If the subscriber supplied a value for hub.secret in their subscription request, the hub MUST generate an HMAC signature of the payload and include that signature in the request headers of the content distribution request. The X-Hub-Signature header’s value MUST be in the form sha1=signature where signature is a 40-byte, hexadecimal representation of a SHA1 signature [RFC3174]. The signature MUST be computed using the HMAC algorithm [RFC2104] with the request body as the data and the hub.secret as the key.”

First of all… can we PLEASE stop inventing application-specific X-Whatever HTTP headers. The need to be able to sign HTTP requests and responses is well established. From what I can see, the ability to request an HMAC for a request/response/session/whatever seems to be a generally useful thing that doesn’t need to be tied to Pubsubhubbub. Naming this X-Hub-Signature is just plain silly. With just a little bit of effort, we can design a proper, general purpose signature mechanism for HTTP requests and responses that can serve the same fundamental purpose and would be useful for more than just PSHB (ok, got tired of typing the whole name out).

This is just a strawman… but…

POST /whatever HTTP/1.1
Session: sid=abc, secret=foo, hash=sha1-hmac

... some data ...

HTTP/1.1 200 OK
Session: sid=abc, hash=sha1-hmac
Digest: sha1-hmac:{hmac}

With this, the request includes a new hypothetical “Session” header that is used to establish a security session between the client and the server. This can be used to communicate a variety of parameters… in the example it’s just a simple secret and algorithm. One could imagine a more complex scenario (e.g. DH) but I won’t go there yet. The server does it’s thing with that header and establish it’s own view of the session. In the response, or in subsequent communications, the server can include a Session header identifying the session id and any of it’s own parameters. In the example response above, a new hypothetical Digest header is used to communicate the calculated HMAC over the response payload. Whoever processes that message can determine from the Session header whether it has the information it needs to validate the HMAC and go from there. This pattern can be used for a variety of purposes to establish digital signing of content, negotiation of keys, encryption of content payload that operates independently of SSL (e.g. XML encryption of an Atom document), etc.

The main point right now is not exactly how all of this would work, but more that the digest mechanism does not and should not be defined strictly in terms of PSHB… if this kind of mechanism is important for PSHB, it’s likely going to be important for other types of applications too. Take the time to develop the solution properly rather than developing one-off-protocol-specific hacks.

So the other day I kind of glossed over why the Salmon Protocols idea of “Magic Signatures” is flawed… I wanted to expand on that just a little… Fundamentally it goes back to one very simple and basic principle of Digital Signatures: Only What Is Signed Is Secure.

With Magic Signatures, you basically have a bag-of-bits and a signature calculated over those bits. The spec tries to say that if you take that signature and bits and insert it into an Atom or JSON document, it somehow proves the provenance of the containing Atom or JSON. This claim is based on the assumption that the bag-of-bits being signed somehow represents the document that contains the signature.

The Magic Signature spec says: “The scope of the verification covers only the contents of the Magic Envelope itself. In some cases, e.g., when using envelope data as provenance for enclosing data, the decoded “data” value must be checked against or override the enclosing data. A secure if lossy mechanism is to throw away the enclosing information and replace it with the output of the decoded “data”. Another altnernative is to compare trees, override with signed information where there are conflicts, and annotate signed parts. The correct mechanism depends on the security model required by the processor and is outside the scope of this specification.”

In other words, the spec does not define any reliable means of taking one of these “magic signatures” and verifying the provenance of the envelope containing it. It’s possible, for instance, to generate a signature over a block of JSON-encoded data and drop that into an Atom entry that roughly correlates to the same underlying data. According to the Magic Signatures spec, so long as the digital signature of the JSON data is correct, the Magic Signature in the Atom entry is valid and somehow proves the provenance of the Atom entry.

Problem is, Only What Is Signed Is Secure. Only the block of JSON-encoded data is signed, making it the ONLY block of data whose provenance is proven. The Atom entry itself could have been generated by anyone, at any time, and could contain additional pieces of information that the originator of the JSON-encoded data never intended. If a would-be attacker figures out that a service provider is using the compare-and-merge strategy suggested by the spec, then that service and it’s users will be exposed to a potentially very serious attack vector.

Magic Signatures tries to circumvent the exact mechanisms that the XML Digital Signatures specification puts in place to defend against this exact kind of issue.

This problem, however, only applies to the enveloped magic signature.. what about standalone magic signature documents? I’ll deal with the standalone documents in another post.

So I’ve been reading up a bit on the Salmon Protocol… and in particular this one part called “Magic Signatures“… which is essentially supposed to be a simpler way of encoding digital signatures within an XML structure (as opposed to XML-DSIG). In all actuality, it’s just a way of representing a digital signature of any arbitrary bag-o-bits in either an XML or JSON data structure. Nothing too fancy but it certainly serves a very different purpose than an XML Digital Signature.

There is one particular statement made in the draft that bothers me… “Magic Envelope parameters may be embedded within an Atom Entry to provide verifiable provenance”

The spec then goes on to provide this example,


<?xml version="1.0" encoding="utf-8"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<id>tag:example.com,2009:3897938434</id>
<author><name>E. Xample</name><uri>acct:test@example.com</uri></author>
<content>Verify this content via me:provenance.</content>
<title>A verifiable entry.</title>
<updated>2009-12-18T20:04:03Z</updated>
<me:provenance xmlns:me="http://salmon-protocol.org/ns/magic-env">
<me:data type='application/atom+xml'>
PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz4KPGVudHJ5IHhtbG5zPS
dodHRwOi8vd3d3LnczLm9yZy8yMDA1L0F0b20nPgogIDxpZD50YWc6ZXhhbXBsZS5jb20s
MjAwOTpjbXQtMC40NDc3NTcxODwvaWQ-ICAKICA8YXV0aG9yPjxuYW1lPnRlc3RAZXhhbX
BsZS5jb208L25hbWUPHVyaT5hY2N0OmpwYW56ZXJAZ29vZ2xlLmNvbTwvdXJpPjwvYXV0a
G9yPgogIDx0aHI6aW4tcmVwbHktdG8geG1sbnM6dGhyPSdodHRwOi8vcHVybC5vcmcvc3l
uZGljYXRpb24vdGhyZWFkLzEuMCcKICAgICAgcmVmPSd0YWc6YmxvZ2dlci5jb20sMTk5O
TpibG9nLTg5MzU5MTM3NDMxMzMxMjczNy5wb3N0LTM4NjE2NjMyNTg1Mzg4NTc5NTQnPnR
hZzpibG9nZ2VyLmNvbSwxOTk5OmJsb2ctODkzNTkxMzc0MzEzMzEyNzM3LnBvc3QtMzg2M
TY2MzI1ODUzODg1Nzk1NAogIDwvdGhyOmluLXJlcGx5LXRvPgogIDxjb250ZW50PlNhbG1
vbiBzd2ltIHVwc3RyZWFtITwvY29udGVudD4KICA8dGl0bGUU2FsbW9uIHN3aW0gdXBzdH
JlYW0hPC90aXRsZT4KICA8dXBkYXRlZD4yMDA5LTEyLTE4VDIwOjA0OjAzWjwvdXBkYXRl
ZD4KPC9lbnRyeT4KICAgIA
</me:data>
<me:encoding>base64url</me:encoding>
<me:alg>RSA-SHA256</me:alg>
<me:sig>
EvGSD2vi8qYcveHnb-rrlok07qnCXjn8YSeCDDXlbhILSabgvNsPpbe76up8w63i2f
WHvLKJzeGLKfyHg8ZomQ
</me:sig>
</me:provenance>
</entry>


The challenge here is that the signature ONLY covers the bag-o-bits in the me:data element… it doesn’t actually provide any information or coverage about the containing atom:entry and cannot be used to verify provenance of the containing entry… even if the Base64 encoded data in the bag-o-bits happens to match the data contained by the containing entry.

There are other issues I have with the draft but overall, I’m just not seeing the benefit of using this vs. XML Digital Signatures… at least within an Atom Entry. I know that XML-DSIG does not provide a solution for JSON, which is very important, but an underspecified and flawed “Magic Signature” is not the right “fix”.

Google has purchased a stealthy startup called Agnilux, according to PEHub. Agnilux was founded by engineers who formerly worked at startup PA Semi, which Apple purchased in 2008. The startup is supposedly making some type of server. Google buying such a company could go a long way toward proving that for webscale data centers there’s nothing like tweaking your infrastructure — from the silicon up.

We’ve written about SeaMicro, which is making its own specialty server using Atom chips, and Smooth-Stone, which is using its chip design expertise to build an ARM-based server, and discussed today how the tide might be turning when it comes to commodity infrastructure. If Google has purchased this startup with the goal of making its own servers run more efficiently, or to adapt them to Google-specific compute needs, that’s a huge bet on specialty hardware for webscale computing.

Activity Streams —

There is no doubt that feeds and social networks go along together very well. I even argued that building a social application without feeds and PubSubHubbub was a mistake. Today, we’re announcing that Superfeedr is now able to parse ActivityStreams data! We decided to add this to our schema (like we did a few weeks ago for GeoRSS).

Even if atom entries are the smallest common denominator to describe online content, it’s now obvious that they’re not allowing us to represent fully the richness of social data.

If you’re not familiar with it. Here is a small intro to Activity Streams.

They’re support by a lot of the big social players, including Facebook, MySpace, Windows Live, Google Buzz, Opera, "TypePad"https://wiki.activitystrea.ms/TypePad-Activity-Streams, Gowalla…

They extends the regular atom entries, by adding 2 nodes: verbs and object. The author information can also be extended.
With this, it is possible to represent almost any action done by a specific user: Julien commented on a blog post. Astro was tagged in a picture. John friended Andy.

Soon, we will start to extrapolate ActivityStreams data out of non-as data, and then, all the data that you’ll get from Superfeedr will be ActivityStream!

HP Slate Leaks, Gets Subdued Response —

No one has seem much of the HP Slate until now. The ten seconds Steve Ballmer fumbled with it at CES 2010 don't really count as a debut, but someone at Conecti.ca has finally spent some real time with the device. Conecti.ca managed a quick hands-on and review. The verdict is a decidedly ambivalent one. Certainly not the response HP would have liked for their supposed iPad killer.

The HP Slate is a keyboardless touchscreen tablet with an 8.9-inch screen that rocks an Atom CPU. In every way that matters, it's a netbook without a keyboard. This is often cited as a strength, but the reviewers point out that it's also the Slate's biggest weakness. While it runs Flash and any Windows app you care to run, the touch interface on Windows 7 makes the device hard to use. HP has made a special finger-friendly graphical front-end, but much of the device's functionality is lost in it. The device also has a dock with HDMI, USB ports, and a kickstand.

It's unlikely this first salvo will sink the unicorn pad, and we're not sure it needs to be sunk. There's still a lot to learn about the new tablet market. Would you consider purchasing the HP Slate? If not, what would you need to see in a tablet to convince you?

Image via Conecti.ca

Intel Trashes Tablets, Then Announces Android Ported to Atom Chips —

Apple sold over 500,000 iPads in its first week, but that trend doesn't have execs at Intel convinced that the iPad is at all ushering in a new era of tablet computing. Speaking to the Intel Developer Forum in Beijing, David Perlmutter, co-general manager of Intel's Architecture Group, seemed a bit down about the whole touch-based computing thing. "These new categories are hard to predict," he said and then went on to talk about how well netbooks were doing.

What has us confused about these negative sentiments isn't the fact that Intel downplayed the tablet market - after all, their chips aren't present in a good many of the tablets now emerging on the market. It's that they came at the same time as a rather important announcement from the chip giant: Intel has ported Google's Android operating system to its Atom microprocessor.

Sponsor

Intel: Jury's Still Out on Tablets

Perlmutter wasn't the only Intel exec to downplay the tablet upsurge. According to an IDG News report, Justin Rattner, head of Intel Labs, also had this to say:

"The jury is still out" on tablets.  Although he conceded that the new round of slate computers "probably has some legs," he also reminded everyone that "this is by no means the first attempt at tablets." It's more of a "third epoch," he said.

While that may be true, comparing ye ol' tablets of days yore to the iPad and its offspring -  the Android-based tablets, the JooJoo, the rumored Chrome OS tablets, the WePad, etc. - seems ridiculous. Technology has evolved so much since the first tablets emerged. No longer are these clunky, heavy behemoths that require pen-based input, have batteries that barely last for a few hours or run so hot, that they get uncomfortable in your lap.

Plus, doesn't the upcoming HP Slate have Intel inside? According to a leaked spec sheet, it does. HP's first entry into this new tablet era includes Intel's integrated UMA graphics and sports a 1.6 GHz Intel Atom Menlow Z530 processor - a chip which actually beats the iPad's custom ARM A4 1 GHz in clockspeed. Maybe the Intel execs could have mentioned something like that instead?

Intel Ports Android to Atom

What's even more odd about these negative remarks is that they were made at the same conference where Intel announced they had ported Google's Android OS to their Atom chips. According to Renee James, SVP and general manager of Intel's software and services group, the company has Android running on Atom-based smartphones and already has some customers interested in it. "Intel is enabling all OSes for Atom phones," James is quoted as saying in PC World. The move is important for the company since currently most Android phones use ARM processors.

Of course, Android is also a popular choice for many tablet computers - which is why the execs' remarks seem so odd. Shouldn't Intel be promoting how Atom chips can run on tablets, too? 

It's worth nothing that Intel isn't the first to get Android on the Atom chip. Acer, for example, ported Android to netbooks last year. And MIPS ported Android to run on set-top boxes, digital TVs, mobile internet devices (MIDs), mobile handsets, home media players and VoIP systems.

Discuss

Chip maker Intel has revealed that it has got Google's Android phone software running on its low-powered Atom processors.