I read this about two years ago, but I think it has some relevant
sections for you:
F. Beato, I. Ion, S. Capkun, M. Langheinrich, and B. P. (2013). For
Some Eyes Only: Protecting Online Information Sharing. In ACM
Conference on Data and Application Security and Privacy.
http://e-collection.library.ethz.ch/eserv/eth:5961/eth-5961-01.pdf
More responses inline below.
On Wed, Mar 25, 2015 at 8:02 PM, Timo Richter <
timo...@gmail.com> wrote:
> Hi Sean,
>
> I had some practical ideas about the project. First I would develop a
> content script to check the actual website for privly urls in the current
> website's images. In this case the privly url is the visual (QR-)code in the
> corner of a blurred photo. It may be detected using the CamanJS library. If
> analysing images causes privly.js to take too long at reading a website, I
> would either limit this function to Facebook / to image galleries. Or I
> would require to offer the privly-url below it, as the alternative-tag or in
> the image description. (Possible on FB)
Don't think about performance before you have a prototype. Figure out
how to plug it all together then optimize. Premature optimization is
the root of all evil [0].
I bet you would need to abandon CamanJS before you would have anything workable.
[0]
https://shreevatsa.wordpress.com/2008/05/16/premature-optimization-is-the-root-of-all-evil/
> At first I have to calculate an optimal visual code. Maybe it can be smaller
> than QR because it will not need such a high error correction? A QR code on
> a website will not experience a finger print or accidental contact with
> coffee. I will check how small the visual code may be. A visually too small
> code would lead the program to be unable to read it. Some websites compress
> uploaded pictures to JPEG. Too big is not helpful either because the
> non-privly user does not need to see the code. He will rather have to see
> the human-readable url in letters, either in the photo itself or next to it.
> Finally I would develop the application that manages the upload of photos to
> a site. The photos will be sent to the content server of course. To the
> actual website it will publish the blurred version of the photo together
> with the privly URL as a code in the edge of the photo.
If you are talking to a technical audience, stop calling it a blurred
image. Assuming you are encrypting the image, call it an encrypted
image.
QR codes are for cameras. I recommend displaying a link in the photo
that is easy to type into the address bar. Then use color/saturation
changes in the background to give the URL in a machine readable form.
The placeholder image could also include instructions that tell the
uninitiated users what they are looking at and what they need to do to
view it -- download the extension or type in the address.
>
> Concerning GSoC, on their calendar[1] it says that from the 28 March until
> the 13 April “Mentoring organizations review and rank student proposals;
> where necessary, mentoring organizations may request further proposal detail
> from the student applicant.” So in case it will still be possible to decline
> the application until the 13 of April and I could create a concept shortly.
> Outside GSoC I could also work on this, but I would need to do it as an
> internship and need some kind of contract because I want to have the work
> acknowledged by my university. A GSoC would definitely be my favourite.
We've helped students get course credit before, so that shouldn't be a problem.
Regarding GSoC: You are probably a month out from getting this to a
point where we could accept it as a GSoC project. That is assuming you
work _very_ hard for the next month.