I agree with dpark - an unstated goal of this proposal was for developers to be able to easily move legacy sites with legacy endpoints to long sessions without needing to update those endpoints or pages.
The service worker approach can effectively intercept requests to any endpoint and perform the re-generation of a short cookie if needed, without needing to change every page on the site or the legacy endpoints.
An unstated goal (we probably should have stated it, looking back) was for sites to be able to easily move legacy sites with legacy endpoints to long sessions.
The service worker approach can effectively intercept requests to any endpoint and perform the re-generation of a short cookie if needed, without needing to change every page on the site or the legacy endpoints.
One additional benefit is that it minimizes the transmission of the long term token, which is generally good if you're worried about it somehow getting intercepted. You may or may not be too concerned about that risk though.
That feature was designed but never built, so his point still stands. In my ideal world sites can do that stuff, they just have to ask, and users can always say no.
We try and make sure that the Chromium blog (http://blog.chromium.org/) always covers new features as they make it into the new Beta. Imho you should be able to read the beta blog posts on that blog and not miss any new developer shiny things. Also fwiw we're going to try and do a better job of making the release notes link to the appropriate beta blog post on the Chromium blog, I agree we've done a poor job on that in the past.
This was already possible on desktop using the following flash polyfill: https://github.com/zeroclipboard/zeroclipboard. So on desktop at least this doesn't introduce any new threats, so this seems a little strongly worded to me.
I've started a wiki page on Slant.co for people to outline the main arguments why Soylent may or may not be healthy since these threads can be very hard to follow all the great discussion going back and forth!
Just for clarity's sake, I use F5 to flip bits. Your suggestion in 1) makes sense to me, although I've not read of somebody trying this - if you have any more data on it I'd love to see it.
2) This general idea is a good one and the way it is used in steganography is Wet Paper Codes. These effectively provide options for how to encode short messages so you can select that which best matches the coefficients which already exist. A simple example:
Encode 00 as either 0000, 0001, 0010 or 0011
Encode 01 as either 0100, 0101, 0110 or 0111
And so on
Hence when we wish to send a 2-bit message we often only need to change a single bit in the coefficients to get to a correct code word.
Hence Wet Paper Codes are able to achieve a high ratio of bits transferred to bits flipped.
I'm sure a keyed shuffle is the right way to go, certainly also encrypting is helpful but I see no downside of more evenly spreading changes across an image using a shuffle.
I agree with dpark - an unstated goal of this proposal was for developers to be able to easily move legacy sites with legacy endpoints to long sessions without needing to update those endpoints or pages.
The service worker approach can effectively intercept requests to any endpoint and perform the re-generation of a short cookie if needed, without needing to change every page on the site or the legacy endpoints.