Not sure how a prenup is relevant given that she married Bezos in 1993 and Amazon didn't exist until 1994.

I did watch the entire season, I think Jodie Whitaker is a fantastic Doctor but wish the show had better/more consistent writers supporting her. I didn't care for the historical events episodes at all, too much Quantum Leap and not enough science fiction. BUT there were a few really great, what I consider true Doctor Who episodes like The Ghost Monmument, The Tsuranga Conundrum, Kerblam! and It Takes You Away.

They also make money from businesses that use G Suite.
And consumers that pay for extra online storage on Google drive (I do).
And Google Fi, their wireless cell service (I use this, too, sooo much better and cheaper than verizon).
And Google Fiber, their internet service (I don't use this but would if it was offered in my area).
I also use Google domains and pay for registration through them and Virus Total which Alphabet owns and is an invaluable free service.

So yeah, they sell ads, but they are not wholly dependent on clickbait revenue the way Facebook is.

...a reputable auditor verifies the source of data and process, reviewing evidence directly from the systems involved. This is standard for anything, it's why we have CPAs to ensure companies aren't cheating investors. If it's really true, then a third-party should be able to verify the results.

But it doesn't matter because Facebook obviously isn't interested in stopping any clickbait like fake news since they depend on the revenue it provides. If they were, they would simply create a whitelist of all reputable news sources which all share the same traits regardless of bias accusations: they have qualified editors and journalists (no, random bloggers who copy/paste/scrape news from the AP wire are not editors or journalists), do fact-checking and verify sources per journalism best practices, publish retractions/corrections as needed, and mark opinion pieces clearly as such. They can come up with whatever criteria they want to make the bar high enough to filter out the clickbait crap. It's really not that hard.

On a side note, I don't know why anyone believes anything that has more likes or followers (aka whenever something "goes viral") has more value since it's highly likely it's all being manipulated by paid spambots.

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.

But how many of those users are just spam or fake bot accounts? Seems like once Facebook buys a company they essentially become yet another spam machine of whatever nonsense generates CTR (that's at best, at worst they help distribute malicious payloads).

https://www.nytimes.com/2018/0...

"Dovetale said that, on average, 16.4 percent of the followers on Instagram’s top 20 accounts were fraudulent.

Sylo, which requires influencers to share access to their public and private post statistics, said it had rejected 77 percent of influencers who have tried to register on its platform after their accounts showed issues like abnormal spikes in engagement on posts or a large number of generic, emoji-laden comments that bots are known for."

...someone to say in order to protect its existence. ;)

For more information, see this movie: https://www.rottentomatoes.com...

Once I saw that the latest version is iLO 5, I figured it had to be vulnerable to the same exploit as iLO 4 and sure enough:

https://support.hpe.com/hpsc/d...

"A security vulnerability in HPE Integrated Lights-Out 4, 5 (iLO 4 prior to v2.60, and iLO 5 prior to v1.30) could be remotely or locally exploited by an Administrative user to allow remote or local code execution."