There probably were warnings. But the question is, how important where they, and how long before did they happen. If a magma stream crawled through an earthcrack, if could have triggered minimal seismic activity for 10-15 minutes before the event, which is both too short and too small to be noticed.
Remember that Japan is located in a very active place regarding underground activities.

Yes, I think see what you mean. Apps like "Hangout", "Google Video", "Google Books", that kind of apps?

The difference here is that these are always present, but don't interfere with the content of your account. When my Android phone installed Google Video, it didn't replace another Video app, didn't become the "default" video viewer, and wasn't added anywhere except the applications menu. Unless I actively looked for it, I would not find it.

Now, when google decided to add some free music to my music library, it did show up while I was browsing *my* music, and I had to do something to remove it. But I think there's a difference between new app/services being pushed, and content being added to a user account. The former is part of the system's evolution, while the later is more akind of pop-up ads.

About today's topic: from the summary, it looks like there's two issues: first is automatic download on user's devices (even those not using this feature at all), and no obvious way to remove this. I believe the issue is more about this than pushing new services.

Google Music offer a single-click option to disable "free" content from showing up in your library, and most google services ask you before changing their behavior. What are you referring to exactly?

On one side, VPN users are pirate. Ok. So no VPN.
On the other side, not using a VPN to work/transfer personal stuff is a security risk, that can lead to data leak, identity theft, etc. So, VPN. And screw the BBC. I suppose they do all their data transfer in the clear, too?

For once, no, I'm not thinking porn when discussing virtual reality. One thing I'd like to see is a fully virtual keyboard, that could pop out in front of you, and be actually usable. That would be more interesting than force-feedback porn, which can already be simulated by other means (including maybe actual sex).

Can't tell if you way off, because what you described is roughly what is already happening. Each app have it's own virtual memory space. Part of the "issue" described here is accessing memory *usage statistics*, not access to memory itself, which would be pretty bad if it could happen without any kind of escalation/debugging tools.

To be fair, with OCSP you need something that's online all the time your certificates are used. But unless you have hundreds of peoples checking your certificates simultaneously, any low-end contraption can handle it.

That's why the previous poster said "Or the college provides an easy way for the BYOD people to acquire the college's cert."

You don't have to trust any self-signed certificate that the web server throws at you. You go to the official, public website of your uni/work/whatever (or to the IT dept. if they want to do this by hand), and grab the CA cert there. You trust this website, it can have a regular certificate issued by any public authority, and using this newly downloaded cert. as a CA, you can safely connect to anything your workplace have in it's private network.

The only hindrance is that the users have to install this certificate once. Through easy GUI.

You could have formulated it better, but it's true that KDE don't try to change "for change sake". And even if it did, it's one of these desktop that still have relatively easy visual customization.

Yes, TRIM is there to improve performance when writing in a block, but it don't need to erase it, not when receiving the trim command or afterward. The performance problem comes from a write operation that is smaller thn the block. Imagine a block size of 1kB. If you want to write 200 bytes in it, you have to read the whole block, update the relevant part in memory, and write the updated 1kB. Now, if you have the knowledge that the block is completely unused by the FS, then you can skip the reading part, and just write an 1kB chunk of whatever with the correct 200 bytes. No read/update penalty, AND the ssd firmware can decide to reuse that block for transparent wear-leveling, improving both performances and lifetime. But, all this doesn't require actual deletion of the block content at all.

TRIM don't actually zap the data, it just mark a block as unused. This is to increase performances, because on the next write in this block, there is no need to read it, update it in memory, then write it. But until something is written there, no guarantee that the content itself is erased. Custom firmware could read it, or advanced forensics could get the chips out and get data from it or something.

This idea is amazing.
Instead of having:
- full control over the encryption software
- full control over the encryption key
- data that goes in clear in the ram, then is never seen in clear by the hard-drive
- performance nearly identical through either hardware-enabled encryption (AES...), or even software based implementations (even a smartphone can do it transparently)
We're trading all this for:
- who knows what really happen down there
- hey, is your secure key even used for anything more than ciphering a header?
- data goes in clear in the ram, then in clear to the drive, that do whatever with it. It's so easy to make sure an SSD doesn't make invisible copy too.
- performance nearly identical through (supposedly) hardware encryption.

Yeah, no, please stop fixing problem that doesn't exist.

Maybe it should. Providing an API and saying "it kinda work like this, most of the time, your mileage may vary" doesn't sound very good.

yes, but, there is so much layers that are supposed to smooth the hardware difference:

• canvas operations are raster-based and lossless
• browser scripts (either ecmascript or another) should provide consistent execution: whatever the underlying hardware, if I ask JavaScript to draw a circle with (x,y) center and r radius, the result should be predictable, and not hardware dependant
• even considering that browsers use "hardware acceleration" as a way to speed things up, there is still at least one layer between the software and the hardware (either an opengl driver, or some other monstrosities drivers) that *should* provide reproducible, consistent result with various hardware

Now, I perfectly understand why neither the browser, the OS API, and the driver would bother to provide perfect results: we're trading performances for accuracy. After all, if I draw my circle with 0.1 pixel of error, it will look good because of antialiasing. But I still think that software results that are independant of external input should not vary from one hardware to another. There is only one good output for a deterministic software function when always providing the same input.

Imagine the horror if different processors would return different values when computing 1/0.999 just because they have different hardware (oh wait, this one kinda happened :D)

Instead of focusing on the privacy issue, I'm more curious about why "different computer draws the image slightly differently". Browsers are supposed to provide abstraction from the machine, and the same scripts run on different computers is supposed to behave in the same way. At most, it could tap into things like the user id, but shouldn't have access to more than that.