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.

Why? It's a matter of updating the firmware. There already is a physical button on chromecast devices. It's also stated that holding the button down 25 seconds will factory reset a chromecast.

Meh. They just removed the texture file before rendering.

You know, seeing how things are going lately, not being able to connect to current cellular networks looks more and more appealing.

An even better link: http://news.sciencemag.org/environment/2014/06/ninety-nine-percent-oceans-plastic-missing

If you think so, then don't come complaining when your phone take ages to pinpoint your location through pure GPS. Wifi positioning is incredibly helpful.