GSOC: Develop Mobile Version of Privly

[yasir adnan]

Hi,

Firstly, let me introduce myself. I'm Yasir Adnan and I'm 3rd year student of Computer Science. I'm interested to develop the Android version of Privly.

I have worked on android programming for the past few months and have worked on maps,adapters,databases,,intents,and android socket programming. I forked the privly-android project from github. I will be glad, If I get some guideline or help from mentors.

Thank you.

Yasir Adnan

 

[Sean McGregor]

Hi Yasir,

Welcome!

Sanchit and I talked about mobile versions a while back, and I believe
we settled on two use cases:

1. Make a Mobile Application for **Posting** Content: The application
would have local versions of Privly injectable applications and
interface with the user's chosen content server. The result of the
posting process in the application would be to copy the resulting link
to the clipboard, at which point the user could paste the link to an
unaffiliated application or browser. This workflow would become
extremely useful in the long run, because we can use the link as a
vector for PGP and other content/cryptography applications. Users
would need to click through to the link to view it in an extended
browser, but the benefit is not needing to trust mobile apps with
content.

2. Privly makes it easier to **view** content securely/privately on
any website and we presently don't have a way of making it easier on a
mobile devices. One option is to use an existing mobile browser
extension architecture (like Mozilla's), and another (much less
desirable) option is to bundle a browser into a Privly mobile
application.

I think tackling the first use case is feasible for a summer of work,
but the second may not be. We'll see what Sanchit has to say about it.

-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/groups/opt_out.
>
>



--
Sean McGregor

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

[Sanchit Karve]

Hi Yasir,

Welcome!

I'd just like to build on what Sean said about the use cases:

1) Posting content:

What we need is a Privly app that connects to social networking apps to post content.

This should be very easy as all you need to do is contact the Privly server for the secure URL and use the URI_INTENT_SCHEME Intent so that any social networking app can receive the url and allow it to be posted on their respective platforms.

2) Viewing content is slightly complicated as you can only inject code into other processes if you have root access (and even then it's not easy). An easier approach would be to develop a web app entirely in HTML5 and just display that in a browser object "inside" a Privly app....kinda along the lines of this: http://fb.html5isready.com/

This will give you more control over the content that facebook returns through its API but the flip side is, we'll need a separate version for every social network out there.

I'm open to ideas on alternate solutions as this isn't convenient for us to develop and maintain.

The current build of privly-android is just an empty project, but feel free to code up your idea and let us know what you're planning to do with it.

As always, don't hesitate to contact me if you have any questions or thoughts.

-Sanchit

[yasir adnan]

Hi,

Thanks both of you for the guidelines. Both of your ideas looks fine to me. Please Correct me, If anything is wrong here.

For Posting Content :

1) Need to develop a  local versions of Privly applications.

2) A link from clipboard can be copy and It should ability to post link directly to any social networking apps like facebook or twitter.

For viewing content, you want to develop a web application and access this web application via android webview control . Am i right?? 

Thanks

Yasir Adnan

[Sean McGregor]

On Wed, Apr 10, 2013 at 11:31 PM, yasir adnan <adnan...@gmail.com> wrote:
>
> Hi,
>

> Thanks both of you for the guidelines. Both of your ideas looks fine to me.
> Please Correct me, If anything is wrong here.
>
> For Posting Content :
>
> 1) Need to develop a local versions of Privly applications.

The Privly applications are presently being standardized to make them
more easily ported to new platforms. Since the current versions of
both the ZeroBin and PlainPost applications do not use templated HTML,
they could be ported to HTML5 mobile fairly easily.

>
> 2) A link from clipboard can be copy and It should ability to post link
> directly to any social networking apps like facebook or twitter.

Yep! This "dumb integration" works fairly well when you consider that
you could potentially pass PGP content through otherwise completely
closed mobile applications. Clicking the link from the app should open
a browser which could then read the content found on the link...

>
>
> For viewing content, you want to develop a web application and access this
> web application via android webview control . Am i right??

I'll have to defer to Sanchit on this one since I am not an expert on
Android's API. I *believe* this will not work because these web views
usually do not give you scripting access to the page's DOM. I think
the options are:

a) Build an extension for a mobile browser, this is closest to what
Privly currently does for reading content:
https://developer.mozilla.org/en-US/docs/Extensions/Mobile

b) Implement web web applications for every site with an API. This is
only feasible if/when people start incorporating Privly's design
pattern into their unaffiliated applications since we don't have the
resources to implement popular sites.

c) Package a complete browser with the Privly reading script baked in.
This is also too resource intensive.

Graduate Assistant in Machine Learning

Oregon State University, Department of Computer Science
Twitter: seanmcgregor

Facebook: facebook.com/SeanBMcGregor
irc.freenode.net: smcgregor

[Hery Ratsimihah]

Hi, My name is Hery Ratsimihah and I'm interested in working with you for GsOC 2013. Since I am an iOS developer, I was wondering if you were interested in a native iOS app. If so, what is the priority of this project? Would you possibly choose both an Android project and iOS project if the number of allotted slots permits, or only one of them?

Thank you,

Hery Ratsimihah

[Sean McGregor]

Hery,

Sanchit has Android development experience, but our mentors are not
experienced with iOS development. You can still propose an iOS app,
but we will take a more critical look at your skills/experience on the
platform since we will be less helpful on platform specific issues.

That said, our most important metric for evaluating proposals is
engagement with the project before the deadline. If you show an
understanding of Privly's mobile requirements, I doubt your platform
choice will be a hindrance. One way to approach the problem is to
emphasize building a cross-platform application.

We don't know how many student slots we have until the next step of
the process, but there is potential for more than one student to work
on mobile.

If you want to start on iOS, I think a good start would be to get
basic authentication running:

1. Fork the repository [1] and add a mobile application stub (a basic
starting app)
2. Authenticate the app into the content server using token
authentication [2]. To subsequently authenticate the app, set the
"auth_token" parameter to the token on future requests.

You should have received an invite to the Alpha server so you can work on this.


Best,
Sean

[1] https://github.com/privly/privly-ios
[2] https://privlyalpha.org/token_authentications/new

[Hery Ratsimihah]

Hi Sean,

Thank you for getting back to me. I just received the invitation, thanks!

I'll get back to you when I'm done with basic authentication.

Best,

Hery

[Hery Ratsimihah]

Hi Sean,

I got more familiar with priv.ly API and finished implementing basic authentication. As explained in my push request comment, the authentication token is saved in the user preferences for future requests authentication.

Based on what I did so far, I believe that a entire summer would be more than enough to build a solid native iOS app for posting content.

The API should make it very convenient to implement the case you described above in which users copy links created from within this app and paste them to 'unaffiliated application or browser'.

Please let me know if you'd be interested in that. 

Also, I'd be willing to keep maintain priv.ly iOS application even after the end of the program.

Thank you,

Hery

On Sunday, April 21, 2013 2:54:59 PM UTC-4, Sean McGregor wrote:

[Sean McGregor]

Hery,

I'll setup an xcode environment so I can review the pull request.

I agree that it should not take a whole summer of work to finish the
posting application.

The balance of the time could be taken up by developing a mobile
browser extension for injecting content into websites. However, mobile
browser extensions are only a convincing use case on tablets. Another
option could be an application that hooks into the big social network
APIs.

Another student previously shared an Android design on the list that
should be workable for iOS. I recommend you comment on it as
appropriate and adopt it for iOS. We should not have different designs
for different platforms.

For your GSoC application, let's focus on developing the "reading use
case," and I will work with vshivam (his IRC Nick) on the posting use
case. For this you should either write up an implementation plan for
extending a mobile browser (Mozilla has a mobile extension framework),
or say why we should not extend a mobile browser and should instead
support social network APIs. Look at the usability and the power of
both approaches and come to your own conclusion.

How does this sound to you?

-Sean

[Hery Ratsimihah]

Hi Sean,

Just to clarify things, when you say focusing on the "reading use case", you are referring to the second part of the project (mobile browser extension/social network APIs) and not on the content posting app, right? And I completely agree that our app design should be consistent across platforms.

Regarding the choice between extending a mobile browser or supporting social networks APIs, I think that supporting social networks APIs would be a better choice for a couple of reasons. 

First, as you said, "mobile browser extensions are only a convincing use case on tablets," and smartphones take a big part of mobile devices usage. So we may keep a a lot of mobile devices users out of the loop by targeting only tablet users.

Second, an application that supports social networks APIs could be integrated to the content posting app I would be implementing first. It would thus result in one consistent app that does both content posting and hooks into social networks APIs, instead of a separate app and mobile browser extension. 

The third point is related to the first one. Safari represents 62% of all mobile browsers [1] and does not support extensions. Se we'd be excluding lots of mobile users by opting for a mobile browser extension.

Please let me know if this makes sense.

Best

Hery

[1] http://www.macrumors.com/2013/04/03/safari-dominates-as-top-mobile-browser-with-62-of-internet-traffic/

[Hery Ratsimihah]

Also, when writing proposals, I was wondering if you preferred students to leave questions and answer below them, or if we can remove the questions and format our proposal as paragraph answers and outlines for each part (Personal Details, Personal Availability, and so on...)

Thank you.

 I will be hosting my proposal at this address:

https://docs.google.com/document/d/1aV3c8Ebv0_pHyb37y8XW08Sh39Af_vPHYJGaWSmGFoo/edit?usp=sharing

[Sean McGregor]

Hery,

You are right on all counts, but I wouldn't discount mobile extensions
entirely since it is a tradeoff between generality and usability.
Regardless, let's get you started on designing the reading
functionality for integration into the mobile application.

Some design considerations:

* It should not be tightly integrated with any particular API, and it
should make it easy to track with API changes into the future. We
don't want to monitor/maintain brittle integration across 5+ networks
and content types.
* I think we probably don't want to pipe in all the social network,
email, etc content into the app's UI. We should probably limit the
displayed content to information with embedded Privly-type links. So
they would use the Privly app for private content, and the native apps
for everything else.

Regarding your GSoC application, please maintain the headings as they
are found in the application guide. It makes them easier to review and
check off the boxes.

-Sean

[Hery Ratsimihah]

Hi Sean,

I want to make sure I understand you correctly.

To paraphrase you, we will not be using any social network API directly, but will look for embedded Privly-type links within these web apps instead? 

If so, do we have any way to find such links? Or will it require techniques like web scraping? Hopefully not, because from experience, web scraping tends to be slow.

Also, we will also be displaying every post from the user's privly account, right?

Thank you,

Hery

[Sean McGregor]

No web scraping. Use the APIs but only display content which contains Privly-type links. Basically, the social network's app supports the unprotected content and our app supports the Privly content.

Sent from a mobile device

[Hery Ratsimihah]

That sounds better. How about limiting the scope of the app to Facebook and Twitter's APIS for now?

[Hery Ratsimihah]

Also, when downloading content from social networks, would it be a good idea to use regular expressions to find Privly-type links and filter out anything that doesn't include them?

[Shivam Verma]

Hi Hery,

If you check out privly.js it does use Regex to find the privly type links. Though we need to change this according to the documentation there, to move to a whitelist approach.

Shivam | +91 7507632590
4th Year, Information Systems
BITS-Pilani, Goa Campus.

[Hery Ratsimihah]

Hi Shivam,

Just what we need, thank you for that.

Also, I'm currently making the timeline of my project. One of the SMART goal I have is "finalize UI mockups with Android developer." Do you think June 1 is a reasonable deadline for that? We would likely be done before that date.

Best,

Hery

[Sean McGregor]

* Privly.js in the Chrome extension currently modifies the regular
expression with the user's current whitelist. This approach could be
used in a mobile app.

* If you are looking to propose API integration on particular networks
or sites, Facebook and Twitter are a good place to start. You could
also look at integrating email.

-Sean

[Hery Ratsimihah]

That sounds good. For email integration, would starting with Gmail accounts like Mailbox be a good idea? Google uses OAuth 2.0 for its IMAP and SMTP services and it should be convenient to implement on iOS. 

Also, I am currently working on my timeline, which is currently such that my project would be done by August 7. If you have time, could you have a look at it and let me know if my deadlines are reasonable? If they are, we should come up with more features to add to the app. There could even be enough time left to develop a browser extension.

https://docs.google.com/document/d/1aV3c8Ebv0_pHyb37y8XW08Sh39Af_vPHYJGaWSmGFoo/edit?usp=sharing

Thank you,

Hery

[Sean McGregor]

On Wed, Apr 24, 2013 at 3:18 PM, Hery Ratsimihah <aeonz...@gmail.com> wrote:
> That sounds good. For email integration, would starting with Gmail accounts
> like Mailbox be a good idea? Google uses OAuth 2.0 for its IMAP and SMTP
> services and it should be convenient to implement on iOS.

For email, I am thinking we would pre-configure a few providers [1],
and then provide a UI for manually integrating imap or POP. Most
people are terrible at hooking phones into email protocols so this
seems like a good balance.

[1] http://gigaom.com/2012/10/31/gmail-finally-beats-hotmail-according-to-third-party-data-chart/

>
> Also, I am currently working on my timeline, which is currently such that my
> project would be done by August 7. If you have time, could you have a look
> at it and let me know if my deadlines are reasonable? If they are, we should
> come up with more features to add to the app. There could even be enough
> time left to develop a browser extension.

I will review the GSoC applications and give comments in the next two
days. You can pad the application with "if I am ahead of schedule, I
will work on ___," but I would not promise anything you aren't certain
you can implement during the term. Since you want to maintain the
project moving forward, It is also good to see what you will develop
the application into after the summer completes.

I should be able to review your iOS pull request in full this Saturday
(I am waiting for a Mountain Lion disk).

Can you submit the application to the GSoC website and we will work
through there? It has commenting and collaboration functionality for
mentors. If you don't want to reformat it there yet, you can submit
the Google Doc link (for now).

[Hery Ratsimihah]

Great, I can add Hotmail and Yahoo integration to my proposal. That's definitely something I can implement. 
Manual integration of additional IMAP and POP services is one of the extra features that can be added if time allows. If not, I can add it after the end of the program as repository maintainer.

I submitted my proposal to the GSoC website. Please let me know if there is anything I can do to make it easier to read.

Best,

Hery

[Shivam Verma]

Hi ! Sorry for the late reply.

I think June 1 should be a suitable date to finalize the mockups. 

[Hery Ratsimihah]

That's ok. I added a "reading mode" button to the iOS app UI, so that users can switch to reading mode once they're authenticated. See the second screenshot.

https://f.cloud.github.com/assets/910954/453825/27c09dde-b327-11e2-8e82-c7d47ba799c9.png

https://f.cloud.github.com/assets/910954/453826/27c1e752-b327-11e2-836d-2a2023d2e16e.png