GSOC: For images posting qr-code instead of link

[Timo Richter]

Dear privly community,

I just found your awesome project and I have had the same idea that privly realises, but I never took the time to really do it. I would like to help extending privly because I would also like use it soon.
Let me introduce myself briefly. My name is Timo Richter, I have written code for an open source project before. [1] I am studying computer science in Germany and Portugal since 2010 and am experienced in JavaScript, Python, Ruby, HTML5, CSS3 and more. I am specialised in coding theory and web applications.
My proposal is this: Let's think of uploading photos on Facebook as an example. On an upload the real photo will be blurred and uploaded showing the url to the clear photo on privly. People who are not interested in using privly at least see some blurred photos, become interested and might start to use it to see the clear photos more easily. The blurred photos would be shown in Facebook's normal picture viewer and can be commented on. With the help of my new feature, blurred photos shall be detected and exchanged with the clear photo. I will develop an efficient visual code – probably similar to QR – to have the blurred photos easily identified by the program. Also the code can be easily read by the computer and would contain the url to the real photo.
My timezone is UTC and I am doing the level 2 at the moment. Do you think this idea would fit in a SoC?


Best wishes,

Timo


[1] https://github.com/LibreOffice/help/tree/master/wiki-to-help . 23.11.2014

[Sean McGregor]

Hi Timo,

It is an interesting use case that our architecture would support
through minor modifications, but you don't have enough time to bring
it to proof-of-concept before the GSoC application period closes. It
is only because I rarely say things are impossible that I say this is
_possible_ for GSoC 2015.

Regardless, I would be happy to provide input about the idea if you
are still interested either from an intellectual standpoint or if you
want to implement it regardless of GSoC.

Best,
Sean

> --
> You received this message because you are subscribed to the Privly
> development mailing list. To post to this list, send email to
> pri...@googlegroups.com. To unsubscribe from this group, send email to
> privly+un...@googlegroups.com. For more options, visit this group at
> https://groups.google.com/d/forum/privly?hl=en
>
> Privly testers should also sign up for this list:
> https://groups.google.com/forum/#!forum/privly-test
> ---
> You received this message because you are subscribed to the Google Groups
> "privly" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to privly+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Sean McGregor

Oregon State University, Department of Computer Science
Twitter: seanmcgregor
irc.freenode.net: smcgregor

[Timo Richter]

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)
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.

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.

Best wishes,

Timo

[1] https://www.google-melange.com/gsoc/events/google/gsoc2015 . 26/03/15

You received this message because you are subscribed to a topic in the Google Groups "privly" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/privly/FFXAcZQqATY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to privly+un...@googlegroups.com.

[Sean McGregor]

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.

[Timo Richter]

see below.

2015-03-26 7:25 GMT+02:00 Sean McGregor <smcg...@seanbmcgregor.com>:

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

The text is interesting. I don't see that much advantage in having an index of encrypted links instead of putting the links themselves, but I like the idea of including steganography. The privly link or even the encrypted photo itself could be included in the blurred photo on the foreign website. Primitive methods were concatinating* a jpeg file with a zip file. Normal programs show the jpeg, archiver show the contents of the zip. In coding theory there are also codes that not only encode but also hide content. A codeword might take an encryption key A to show some fairytale and encryption key B to reveal the real content. So one can claim that the key would be A and still hide the content. It is also possible to calculate a QR-Code that will look like an arbitrary drawing but still conserve the source code word. This idea might analogically be helpful on pictures.

If the encrypted picture is in the public picture, we would not need a content server.

* $ cat blurred-picture.jpg > upload.jpg && cat clear-picture-zipped.zip >> upload.jpg

The normal user without the privly-plugin should see a blurred image with the url on top and a small QR code, or may the text not have any picture behind it at all. The blurred image is just there to catch the user's attraction to type the url in. The (probably different than QR) code is resistant to JPEG compression and will be read by the plugin to replace the picture. By a machine a well designed code is being read a lot easier with less errors than the human-readable url read by OCR.

>
> 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.

2 month of work to become accepted for a 3 month lasting summer of code? I cannot afford that ;-)