Yeah, we might not have said too clearly that the whole thing is a prototype made for other hackers. The code has been through a long journey, so we know pretty well how the foundations will look, but there is quite a lot of work to get the server into a good shape security-wise. Then, we need to work a lot on Developer Experience and then User Experience. But we're attracting people now, which is good.

We're not married to any particular coin, but we have people working on stuff like that. One project alumni is working on Filecoin, and we are talking a lot with the people of Safecoin. I'm pretty sure we can have stuff like in near future.

Whoooah! No, it is not. DRM is fundamentally broken, so, that's not what we're aiming for. Indeed, if you trust your data with someone who is not worthy of your trust, then there is very little technology can do to fix that broken trust. Then, it becomes a really difficult social, psychological and legal problem, where technology can only play a very minor part.

So, what we're doing here is to ensure that you can store stuff on a web server you control. Then, the intelligence sits on your client, so the apps you use will be restricted by the security model of your device, and therefore should not send your data off without your consent.

WebID currently builds on OIDC (because we couldn't get browser makers support WebID-TLS, which is much simpler), but I think you'll find that it doesn't have the same problems: https://github.com/solid/webid...

But the server is pretty simple, and can and will be implemented in many different languages. People are working on a Go implementation too. The nice thing about JS is that much of the same logic is both on the server and the client side, and so it is actually the same code. That's pretty nice for consistency and cost of implementing it.

I'm myself not really impressed with the security of the Node.js landscape, but that's what we decided to do first.

Basically all the stuff around it. First, you have the permission stuff that allows you to share those pics with the people you want, without uploading it somewhere totally beyond any reasonable control. Then, others are welcome to provide apps around it, so your pics could be part of somebody's feed, like instagram, only, those pics are never uploaded to somebody else's server.

But overall, the server side is intended to be pretty simple.

You make the stuff that we do sounds really simple, but yeah. That's pretty much it. :-)

But note that in spite of Tim having read-write capability in his first browser, it really never took off. And then we had this document web, when we also wanted a data web and an applications web. So, I guess we got the applications web, but just pretty primitive and constrained ones.

So, yeah, the server side is really very simple. It is like, the UNIX of the Web. But in terms of all the stuff that has been around for 25 years without taking off, there is really a lot to do...

Ah, but you are pinpointing it right there! It is more hassle than you want, why? If we could fix that problem, so that it wouldn't be more hassle to have it on your own webserver, then what would you do? And that's like iteration 1 of Solid, we're separating those apps from the data, so that you can have your data on your webserver, but you can use any calendar app you want. That way, companies will be competing to create the best apps, not to suck your data out of you. So, Solid is about making the infrastructure and the ecosystem to make sure that all those things aren't a hassle, they will be your preferred way to do it.

Right, good question, because that is the essence. But first of all, they are not running on a server you don't control, they are running on your client. So, Solid is doing a massive shift on where the intelligence will be. It will be mostly on the client. The server side will be pretty simple.

But the rest of the question is still interesting. It is a fairly long and intricate answer, but some of the short story here:

So, in the way it is working in browsers now, is the simple CORS restrictions. It is pretty broken, but it is what we have. So, we're making some hacks to identify web apps. And then, you can assign privileges to them. Since they are running on your device, the security of your browser applies to them.

Still, it doesn't mean that you can necessarily trust them, of course, but then, this is a social technology, so we could establish a Web of Trust around that. We're thinking a lot about that.

So, we don't know that yet. There are a few no-brainer business models of course, but we don't expect them to last long. But we have some really good people on the team, we'll figure it out.

It is certainly very convenient, when it works. It feels kinda strange to trust every financial detail of my life to the government, so whether it is good in a real sense is a question I'm very open to debate. It does allow some very useful applications to be developed, with a very nice potential for streamlining interaction between government, citizens and private sector. This is actually very high on the government's agenda, which I'm happy about, because the bureaucracy is sometimes both heavy and heavy handed. If it is done well, it could potentially enable citizens to simulate possible choices in their lives before they make a decision: "If I do $that, the taxes will be $this". It would also enable an improved public debate: now it is a lot of bickering of the style "if you raise $that_tax, it will adversly effect $that_group" "no, it won't, but not doing it is required by $that_group". They're just making things up, of course, the debate is usually completely devoid of facts. Soon, it might be possible to simulate those scenarios on a regular basis, so we get real facts on the table before making a decision. Unfortunately, there's a long way from good ideas to actual implementations. I've been in meetings with the people who actually order these systems, and what can I say... Heads gotta roll to go anywhere... They're easily blinded by suits, and they have no idea what makes a robust system. So, for now, I'm not too confident it will happen, even though there are some very interesting ideas around.

That's not correct. Only the final sums are/were published after the affected person has had a chance to verify and correct the information. Here all his details were published, which is a severe violation of his privacy.

If all you want to do is run an existing app in "the cloud", EC2 is a better choice for you. App Engine is designed around the philosophy that "We'll make scaling magically happen; but you need to obey our rules." These rules, for the large part, are designed to make scaling easier - all the seemingly-weird limitations in the datastore are there because they implicitly force you to shard your data early on. Since you'll be customizing your database layer for app engine, the logic goes, providing all kinds of programming languages isn't as important (since you might as well customize the rest of your app, right?) The other concern Google might have is sandboxing - they've done some fairly extensive modifications to Python, Java, and Go to get the kind of sandboxing that they need, and given PHP's not-so-stellar security history, they might not be as interested in supporting it. Heck, even if sandboxing worked well enough, I could see them saying "No, we don't want to support PHP because it's harder to write secure apps in PHP, and our entire philosophy in App Engine is to make the easy thing the right thing to do."

On a serial link, just use the right arrow key. Or possibly ESC (although you'll have to deal with clearing the ESC chord afterward if it happened to be in vi or something)

Alas, while the Fukushima facility has plenty of gamma, alpha, and beta radiation to go around, not to mention a glut of thermal energy, they're a bit scarce on the neutrons at the moment.

Writing the log first is an implementation detail if anything - and in fact, ext3's ordered mode is very careful to write the data first. No idea what Windows' NTFS implementation does of course. And as long as the WAL will fix up any outdated bitmaps, with traditional drives there's no problem. But if the drive decides to zero out blocks on its own initiative, then things get a bit... well, scary. I suppose you could legitimately do it if you collect the list of extents to trim at boot, after verifying the drive is clean, but filesystem corruption is still an issue (I doubt the disk runs a full fsck at startup...)

Isn't that a bit dangerous? I'd be worried about a scenario like:

• OS allocates block X and fills contents in memory.
• Application fsyncs(). OS writes an entry for updating the metadata to the write-ahead log, as well as writing actual block contents to block X. At this point, the block is committed to disk, so the OS returns from the fsync.
• OS crashes before updating actual metadata. User reboots.
• SSD decides that block X is free (looking at the metadata) and trims it
• OS reboots, applies write-back log. Block X contents have been lost

Or perhaps even:

• OS allocates block X and fills contents in memory. Write activity is low, so writeback is delayed for a while.
• Memory pressure causes block X contents to be flushed to disk. Metadata remains in memory.
• SSD decides block X is unallocated (WAL is empty, block is marked as unallocated) so it frees the block
• OS writes back metadata. Block is now zeroed.

Or even good old fashioned file system corruption being made worse by something like this...