Forgot your password?
typodupeerror

Comment: Re:Why? (Score 1) 92

by Cley Faye (#47533745) Attached to: New SSL Server Rules Go Into Effect Nov. 1

it doesn't have to be turned on after you finish signing certs until its time to sign another batch...

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.

Comment: Re: Why? (Score 1) 92

by Cley Faye (#47533719) Attached to: New SSL Server Rules Go Into Effect Nov. 1

Are you connecting to that self signed cert that is university owned or that self-signed cert that is setup by my evil laptop on the wifi network?

[...]

With BYOD you simply cannot use a self-signed certificates. Your potential attack surface than increases.

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.

Comment: Re: How is this news. (Score 1) 91

by Cley Faye (#47519025) Attached to: Intel Launches Self-Encrypting SSD
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.

Comment: Re:How is this news. (Score 2) 91

by Cley Faye (#47518253) Attached to: Intel Launches Self-Encrypting SSD
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.

Comment: Summary of advantages: (Score 1) 91

by Cley Faye (#47518237) Attached to: Intel Launches Self-Encrypting SSD
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.

Comment: Re:Rounding differences (Score 1) 194

by Cley Faye (#47507173) Attached to: A New Form of Online Tracking: Canvas Fingerprinting

I'm more curious about why "different computer draws the image slightly differently".

Slight rounding differences, shape edge antialiasing behavior, font antialiasing behavior, installed fonts, and the like are the big ones I can think of. HTML5 Canvas behavior isn't specified down to the bit level.

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.

Comment: Re:Why does this work (Score 1) 194

by Cley Faye (#47507157) Attached to: A New Form of Online Tracking: Canvas Fingerprinting

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)

Comment: Why does this work (Score 2) 194

by Cley Faye (#47506967) Attached to: A New Form of Online Tracking: Canvas Fingerprinting
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.

"Life is a garment we continuously alter, but which never seems to fit." -- David McCord

Working...