Skip to content
This repository has been archived by the owner on Dec 27, 2023. It is now read-only.

Develop Host-Page API #162

Open
smcgregor opened this issue Feb 23, 2015 · 9 comments
Open

Develop Host-Page API #162

smcgregor opened this issue Feb 23, 2015 · 9 comments

Comments

@smcgregor
Copy link
Member

An injectable application may expose a message-based API to the host page it is embedded into. This project focuses on enabling the host page to appropriately influence the operation of the application. Examples of potential API calls for a host page include selections of fonts and font sizes, maximum length of content, etc.

@rachidasen
Copy link

I am 3rd year computer engineering student from Jamia Millia Islamia,India I have been programming in HTML, CSS, JS, Java, C, C++ for the past 3 years.

Can you please guide me further, as to what are the prerequisites for the project, and any other "tasks" that I might complete to improve my chances of selection.

@smcgregor
Copy link
Member Author

Howdy @rachidasen

The first steps are to work your way through the "Levels" found here: https://priv.ly/pages/develop#StartingWithBasics

Following that we can start talking about more specific tasks that will prepare you to submit an awesome proposal. In the meantime, it would be good to track the changes of this pull request since it is implementing a message interface that would be used by this project.

-Sean

@smcgregor
Copy link
Member Author

People are asking for more details on this "idea" so I will add them in the form of a list of problems we hope this project would address.

  • Privly-applications break the styling of web applications since their contents are not necessarily using the same fonts and formatting.
  • Privly-applications don't abide by the limits of host-pages in terms of acceptable length, content, etc. So it is possible to post a very long status update to Facebook or Twitter in a way that bypasses these community controls.
  • Websites may display user-submitted content in multiple places, but some of these places might not be suitable for injection.

@manrajgrover
Copy link
Contributor

Hi @smcgregor sir,

So basically the idea of the API would be to get the URL where injection will take place and then send the CSS and JS files/changes accordingly, right sir? One more thing that can be done is get the CSS of the input field using its ID and then accordingly inject data. This can be handled in the front end.

This would also require us to create a good database with details of major sites where injection of the extension will take place.

All major things and database interaction can be done using AJAX calls with JSON data being sent according to the URL.

Am I correct sir? Anything I am missing or need more information about? Please correct me. Thank you.

@smcgregor
Copy link
Member Author

The problem with a server-side database is that a server will be able to log the websites visited by users. Perhaps an approach would be to analyze the styling of the host page using a content script, then send a stylesheet into the injected application with postMessage.

@yeleywale
Copy link

Intent on being part of Google Summer of Code Team

Hello smcgregor,

I am Akinwale Alexander, A final year student at Bluecrest college, Accra, Ghana. After scanning through some participating organisation in GSOC 2015, I found Privly, and some of the projects within the program, of particular interest.

So I have taken the time to check out Privly on Github to understand its inner workings with a view to contributing some codes before a day or two. I am preparing a proposal on this project as well as completing the puzzles on the organisation's website. Based on what you have said above, let me quickly make the following comments( I stand corrected):

  • That the application is injectable means it will indirectly work in the host page it is embedded
  • This will be decoupled from a particular implementation,
  • An example that is not far-fetched, even though that may not be thought of yet, is for the application to process pages written in markdown.
  • The application can be displayed in a seamless way with same look and feel of the host-page.

Making the application work across the open web with different service endpoints and making it work in an agnostic way poses an initial challenge.

@manrajgrover
Copy link
Contributor

Hi @smcgregor sir,

The problem with a server-side database is that a server will be able to log the websites visited by users.

Yes sir. What I meant by database is collecting all the information that vary or have certain restriction and then send specific data to the injected application. I am not proposing to use MySQL or any other DB but something(a list of things) we can refer to for adding checks.

Perhaps an approach would be to analyze the styling of the host page using a content script, then send a stylesheet into the injected application with postMessage.

Yes sir. This approach sounds good. We can analyze the page for certain checks using source code, URL etc using content script and then send specific changes and not all to be applied. Specific changes and not all to make transfer faster and fast rendering since major CSS and JS portion will remain the same. One more thing that should be done is to keep things responsive.

A question arises in my mind if API will be posted on priv.ly's server or there is a plan to include it in the extension itself. I would suggest former as it will give the ability to make changes without touching the extension. Also new changes can be deployed soon.

Please correct me if I am wrong.

Websites may display user-submitted content in multiple places, but some of these places might not be suitable for injection.

This point remains untouched. Sir could you please elaborate the same.

@smcgregor
Copy link
Member Author

@waleander I believe your characterization is correct. If you submit a proposal for GSoC, we expect you to open a few pull requests to showcase your ability to work with out code base. Since there are only 4 days left to submit a proposal, you are running out of time.

@manrajgrover I think you may be wanting to put too much trust in a remote service. We don't want to enable content servers or other services to track the web pages visited by our users. Similarly, we can put API docs on the priv.ly site, but we don't want to build a system that places trust in the priv.ly site or any other site. We place some trust in the content server, but that is only to support users who don't have the extension installed yet.

For the last point, see this issue.

@manrajgrover
Copy link
Contributor

@smcgregor sir,

Then I think we would have to handle all this in the extension itself. We first would have to check the domain and call the API in content-script and make checks accordingly before posting changes. All this will take place in background within extension itself. Therefore we would need to release updates later on for every other fix related to this, if missed.

I went through this issue and tried reproducing it but was not successful. I guess its fixed. But yes I did see the lock appear in broken positions and the ways extension is effecting user experience on Facebook.

So to summarize:

We have three problems to address:

1.Privly-applications break the styling of web applications since their contents are not necessarily using the same fonts and formatting.

We will have to check the page or manually create a reference for major websites with things like font-size, input box size etc. This can be done dynamically as well as statically. For dynamic solution we would need to check CSS properties related to the box message is going to enter before setting properties of the injection. I would prefer this as this would allow minimum changes if website is revamped and sounds future proof.

2.Privly-applications don't abide by the limits of host-pages in terms of acceptable length, content, etc. So it is possible to post a very long status update to Facebook or Twitter in a way that bypasses these community controls.

Here we would have to create checks manually(static checks). I don't think there is any other way possible. Therefore a reference data set will be required here.

3.Websites may display user-submitted content in multiple places, but some of these places might not be suitable for injection.

Some issues on Facebook like broken post preview or display of lock even after closing of box were observed. This is mostly related to problem of extension not able to listen events. We need a reference to listen all events and execute functions accordingly.

So the tasks in this project would be:
1.To create a reference set for major websites where CSS is not working properly as well as problems related to them. Refer to the issues already reported and map them to set created. Also check character limits and anything else that is required.
2.To handle CSS properties in Content-Script according to the properties of the input field. Also add a parameter for number of characters to the lock to limit characters on new.html.
3.To handle character limits on new.html before getting link.
4.To fix styling related to point 3 for text and injected text. Listen for DOM events on page and execute functions accordingly. Another reference data set as well as issues would have to be created.
5.Testing of extension on various websites and fixing bugs.

Sir please correct me if I am wrong. I have started working on the proposal. Also please add if anything I am missing or would be required.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants