owencm

Co-author of the article here.

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.

Co-author of the article here.

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.

(Disclaimer: I work on these features on Chrome)

We're exploring that. It's not 100% clear either way, but I personally hope we can do it.

Feel free to star this issue if you want to keep track of progress: https://bugs.chromium.org/p/chromium/issues/detail?id=516147

Mods - title should read "Native Mac Notifications Behind A Flag in Chrome Stable"

http://www.flipkart.com/

Looks great! Out of interest, does this take advantage of any native features via node or could it also be a website?

I'm curious if the motivation of making a desktop app was just for the "installed app user experience" or because it was needed to access some API.

FWIW Alex Russell wrote a great article about why our current approaches don't work and why this is interesting to explore: https://infrequently.org/2015/08/doing-science-on-the-web/

[Full disclosure: I work on this project]

But it's opt out vs opt in which is a huge difference.

Sites can definitely work offline using the new Service Worker system: http://www.html5rocks.com/en/tutorials/service-worker/introd.... Try this example: https://voice-memos.appspot.com.

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.

Actually, sites in Chrome can work fully offline today using Service Worker (http://www.html5rocks.com/en/tutorials/service-worker/introd...). And they can get users to add the site to their homescreen, so they have the full icon+offline experience (https://developers.google.com/web/updates/2015/03/increasing...).

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.

Watch the video: it was in 34 generations, each consisting of likely hundreds of attempts.

Mod: please edit title appropriately.

+100

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.

FYI there is a public proposal on GitHub for an API which would allow developers to control the banner more, particularly it's timing or suppressing it. Hopefully this will happen soon. https://github.com/slightlyoff/AppInstallImprovements/blob/m...

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!

Please help me flesh it out so it can help people come to their own conclusion about Soylent's safety: http://www.slant.co/topics/695/~is-it-safe-to-replace-my-die...

All dislikes on YouTube have disappeared. The link is Gangnam Style showing 8,251,688 likes and 0 dislikes.

He also specifically mentions 'cloud'. Just saying.

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.

The whole point of steganography is to not leave any markers. But yes, in theory they could scan them on upload but I'm not exactly sure what their prerogative to do so would be (unless the extension turns out to be used for terrorism that is). And plus, with that many photos to process the low false positive rate is going yo cause them huge problems.

OP here. You're precisely correct, the goal of this project was to demonstrate a PoC of a steganography algorithm which can avoid JPEG recompression and is hence suitable for use in walled gardens such as Facebook.

Also, Chaffinch is a Cambridge project so <sarcasm>naturally not worth integrating with.</sarcasm> But really, this was a single term's undergraduate research project so scope for such integration was thoroughly out of the question.

Finding such clips is vital to YouTube's business. Detecting use of steganography isn't vital to Facebook so unless it becomes a very public issue (e.g. is widely used by terrorists) they are highly unlikely to integrate detectors for it.

Either way, this is a marked improvement over sending private messages on the Facebook or unencrypted emails (and sending encrypted emails is a very fast way to get noticed).

Fundamentally you're correct. Honestly, if I thought this extension was going to be useful to terrorists I wouldn't have released it! In my write-up (linked at the bottom of the article) and also in the instructions it is clear that this is a toy application for hobbyists and is not appropriate for serious security uses.

Also, those books do look interesting, might go pick one up..!

Hundreds of steganography tools already exist for making images which can be shared on any medium where recompression is not an issue (http://www.jjtc.com/Steganography/tools.html). In this case I wanted to provide a simple user experience and also handle Facebook's recompression specifically.

In the future this tool could be extended to other sites which recompress images when they're uploaded although it would certainly be a more confusing user experience.

You're right, if provided a folder of 10 images, one of which contained a secret message then detecting it would be trivial. For Facebook to do the same with 300+ million photo uploads daily would be certainly a non-trivial process. And govt agencies don't yet have full access to non-public albums so the risk of them downloading and scanning all images is also mitigated.

The retrospective scanning is a great point - I hadn't considered that.

The detection process is certainly not going to be built into the Facebook upload process unless really serious (and seriously public) usage of these techniques takes off such as wide-spread use by terrorists.

But theoretically, yes detecting could be integrated with uploading. That said, steganography algorithms and detectors generally play a cat and mouse game so as long as extension providers can move faster than Facebook in implementing new algorithms this risk is mitigated.

How far I take it depends largely on feedback I receive. I have now completed this research project so in that capacity it is complete.

I considered a number of flows but eventually decided this was most discrete. Check out the paper I link to at the bottom of my post to read all about the options I considered and why I selected this one.

Encryption provides the ability to communicate without any intercepter being able to read the content. In many cases this is fine, but in some cases using encryption software is enough to incriminate you (e.g. spies).

Hence steganography means that not only can your messages not be decoded, they can't be detected.

Specifically, this extension's innovation is allowing steganography on walled gardens such as Facebook which recompress images after uploading them.

Good point. I've rephrased this sentence to be less strong. The gist is that although they could theoretically be detected it would be computationally infeasible for Facebook to do the scanning since they receive 300+ million new photos a day and with a database of about 250 billion photos even if the NSA could get access, they could never feasibly scan them all.