privly / privly-chrome Goto Github PK

The ZeroBin application is currently served from the remote content server. It needs to have a local version served directly from the extension to prevent attacks from malicious content servers.

The PlainPost injectable application has a local version implemented so it is mostly a matter of re-packaging ZeroBin and copying the way that PlainPosts are integrated into the extension.

We have two refactoring tasks:

1. Break the background script into several separate scripts. The background page is handling messaging between the content scripts and the extension, but it will soon handle more use cases. We need to break background.js into several well-documented scripts.
2. Better document the API calls. Google's API is heavy in function passing, and I defined many of the functions inside the API calls. This is fairly compact, but it makes it more difficult to document the application. We should define the functions outside the API call, and put in more documentation.

The extension updates but does not notify users of changes. Immediately after updating, the extension should open an HTML doc with a version history.

Firebug provides an example, but it is oriented towards developers. Ours needs to be more plain spoken since it targets non-sophisticated users.

I think you already know this is an issue, but figured I'd submit it anyhow.

Chrome: 21.0.1180.60 m
Privly: 0.0.6

Step 1: Create Privly link and paste it into the "status update" part of Privly.
Step 2. Click "post" WITHOUT "x"ing out the preview.

Outcome: http://imgur.com/sjfNJ

Privly Link: https://priv.ly/zero_bin/#privlyLinkKey=pr5%2FxzYowj0FnQPr5GqapNUlFEsjCzZyJIZQ%2BImrJWY%3D&privlyCiphertextURL=https%3A%2F%2Fpriv.ly%2Fzero_bin%2F213%3FburntAfter%3D1344391997%26random_token%3D4398156f8d&privlyInject1=true&p=p

The following circumstances make the privly button act very strange:

• In Facebook chat small window, when the button appears in the form, if the main page is scrolled, the button will change its position according to the scrolling [1]
  
• In Gmail, when composing a new mail, adding bold text and selecting it will modify the button's position [2]
  

In order to prepare for Pygmy development, we need to implement the scaffolding of the "Manager Applications," which will provide local Access Control Lists and Public Key management.

(from an anonymous user in the bug report form)

With v.0.3.5 of the extension

1. Type a message in the text box.
2. Highlight only some text (not all)
3. Right click in text box to bring up contextual menu.
4. Choose Privly Content Extension->Post with PlainPost (or you can choose anything in that menu really).
5. Note that your new post entry box in the popup window is pre-populated with your 1. highlighted text and only the highlighted text.
6. Complete your post in the popup window that results.

Observe that after completing the post, the popup window closes, but the entire content of the text box is replaced with the link to the post and not just the originally selected text.

I would reasonably expect one of the following behaviors. Either:
a.) The new post link only replaces the highlighted text and not the entire text box contents.
-or-
b.) If the entire text box is to be replaced, then right clicking and creating a new post should open a popup window with the entire text box contents pre-populated and not just the text that was highlighted.

Option a.) would be ideal, while option b.) is a more sane alternative to what is currently being observed in v.0.3.5.

There is an event provided by the chrome.runtime api to determine when an extension is updated or installed. Currently we use stored values in LocalStorage to determine this. We should update firstrun.js to use this API instead of maintaining this functionality ourselves.

Browser: Chrome 21.0.1180.60 m
Privly version: 0.0.5
Website: facebook.com

When posting a privly link on my facebook status, the content is replaced with the wrong content. It shows 2 copies of the facebook title bar as my status.

Please let me know if you need a screenshot.

We are currently distributing the extension through the Chrome store, which has restrictions on what you can publish. We need to determine how to properly package the application for the Chrome Store since we don't have another option: http://techie-buzz.com/browsers/chrome-blocking-extension-apps-scripts-chrome-web-store.html

The PlainPost and ZeroBin injectable applications do not have the ability to edit content within the context of the host page. The desired interaction is:

• Double Click: Edit the content if the user has permission to, otherwise open the content in a new window.
• Single Click: Open the content in a new window.

The extension's global namespace is getting crowded. It is time to go through and encapsulate most of the files.

When visiting a page that has iframes, changing the active tab by clicking to a different tab results in an "Uncaught ReferenceError: privly is not defined" in the context of the original tab's JavaScript console. Note that this is not the extension's console. The error results from the following API call defined in reading_process.js:

chrome.tabs.executeScript(THE_ID_OF_THE_CHANGED_TAB, {
      code: "if(privly !== undefined){privly.start();}",
      allFrames: true
 });

If you remove allFrames:true from the API call, the problem does not present.

This is strange behavior since the script explicitly checks whether privly is defined. This bug does not harm UX, but it is rather annoying having it in the code base.

For the sake of file organization, the C++ test cases found on the nacl branch should not be in the same file as the compiled lib's message interface. The HelloWorld examples should be in a file called tests.cc.

The extension is not identifying itself to the web server.

It isn't clear whether Google's Native Client (NaCl) can support NSS, but I am working on it. Many projects could benefit from NSS compilation for NaCl by adding it to the NaCl Ports list. Failing NaCl support, we can default to standard plugin development. Neither options are preferable as NaCL takes a lot of effort and NPAPI is more prone to security issues.

The content script currently injects an application regardless of whether the content returns status 200. Future versions should not change the User Experience for links that don't return content for injection. The injectable apps should decide whether they want to be displayed.

We need to add the right click menu that the Firefox Extension has. After we implement it targeting the anonymous endpoint (see: http://www.privly.org/content/web-application-api), then we can work on integrating authentication.

I believe the LocalStorage remains in the Chrome browser even after the extension is uninstalled. Since the extension is storing keys now, this is potentially a way to compromise a key store after the user believes their keys were destroyed.

Maybe there are hooks to clear storage on extension removal?

Your fork does not run on TravisCI by default so you don't run all the integration tests on every "push".

This can be very confusing. This issue is for helping people setup TravisCI with SauceLabs. Comment if the documentation for continuous integration is not sufficient and you need help. We will then translate any issues or misconceptions into changes in the documentation.

The development guide has details.

This should fix some issues, particularly with Facebook, where there is a delay in injection.

See: https://developer.chrome.com/extensions/content_scripts

The injectable applications as deployed in this extension have essentially become a fork of their version in the Privly-Web server. This is not maintainable in the long run. We need to move all the injectable applications into a separate repository, and build it as a package that could be integrated with an extension or a web server.

The code base cannot be effectively managed and kept secure moving forward without test coverage. The high use of callbacks in the Chrome API may require the addition of callbacks to every function defined in the extension.

The tooltip does not currently indicate the source domain of the content. The desired behavior will put:

(App):(Content Permissions)
(Security Glyph)
(Source Domain)

Where (App) is the name of the Injectable App used for the content, (Content Permissions) indicates whether the user has update/destroy/share permissions, (Security Glyph) is the extension-unique spoofing Glyph, and (Source Domain) is the domain of the source content.

On clicking the "options" link, the menu will open in a different page on top of the option page. Clicking other links won't trigger this issue.

The Problem: privly.js is capable of injecting an iframe for any linked content, but the injected document needs to send the height of the iframe's content via postmessage to the parent document (this is how the parent document knows how big the iframe needs to be). Currently, privly.js will send the resize message from within the injected iframe, but sandbox restrictions prevent the injected script from accessing the parent document with the parent.postMessage statement (see below).

Options:
a) (short term solution) Drop support for non-privly server links, since Privly links will send the resize message without needing
b) (long term solution) Write a Chrome-specific workaround

(From http://blog.afterthedeadline.com/2010/05/14/how-to-jump-through-hoops-and-make-a-chrome-extension/)

Content scripts (Chrome JS extensions) run in a sandbox separate of the environment scripts attached to a page see. This is good as it reduces the possibility of extensions conflicting with web applications. Content scripts see the same DOM that user scripts see. It is possible to make changes to the DOM and inspect it. I recommend that you read the Chrome extension tutorial and watch Google’s video to understand content scripts.

Unfortunately, Google left a few toys out of the sandbox. It’s nearly impossible to work with an IFRAME. The contentWindow property of any IFRAME DOM element is null. Also window.frames is empty. This is a known bug.

Thankfully, the contentDocument.documentElement property does exist. Through this I can set and get the contents of an IFRAME. That’s close to what I want, but not exact. To proofread an editor, After the Deadline creates an editable DIV and copies style information from the editor to this new DIV. To make this convincing for IFRAMES, I have a need to access style information from the contentWindow property.

I tried to make a content script that figures out if it’s attached to an IFRAME. If it is, the script could communicate the needed information to the extension background script via Chrome’s message passing mechanism.

Unfortunately this didn’t work because Chrome only allows scripts to attach to URLs that have an http:// or https:// scheme. Dynamically generated IFRAMEs used by WYSIWYG editors usually have an empty source attribute which does not match an http:// or https:// scheme.

This thread suggests adding a SCRIPT tag to the DOM to execute a script outside the Chrome extension sandbox. However this isn’t necessarily a straight forward process either.

Most people do not know the full background information of the Privly extension. When the extension updates (or is first installed) it should display a summary of what the extension does in addition to the updates from the last version.

This is an entry level issue for users to become familiar with the Privly Project's code base. You should pick a file from CodeClimate and improve files per the recommendation of the programmatic code quality system.

Do not close this issue in your commits since this is intended to be a more permanent issue.

In Think-aloud studies users are not noticing the extension's icon after installing the extension. On first-run we should somehow flash the icon so the user will look at it and know they can now click there.

This is a more advanced issue for people working on Privly User Experience (UX).

This extension's options and first run pages provide a link into the Privly applications bundle. If you navigate between the bundle and the options interface a few times, you will find the separation between the two pages to be awkward. Users will ask: "what is the difference between these two places?" and "where did the options go?"

The reason privly-applications do not currently have the options interface built-in is that the options interface is only necessary in the extensions, and should not be shown when the Privly Applications are served by a content server.

This screen capture shows the options page for the extension:

And this screen capture shows where the link takes you.

One potential fix is to move the options and first run pages into the privly-applications repository, but you should think about other solutions as well. If you move the options interface into the Privly Applications bundle, you will need to hide the links to the options interface and first run pages when the privly-applications are hosted by a remote content server. If you open a pull request, I will help you do the UI hiding.

Browser: Chrome 21.0.1180.60 m
Privly version: 0.0.5
Website: turntable.fm/the_indie_jones chat, facebook.com chat

When you post a privly link and the content is replaced, the text is cut off on the bottom. It looks like it's not resizing the iFrame properly.

In the chrome extension when you right click within the body of a new message and select plain post the new plain post window appears. However upon submitting the content the link that represents the content is not inserted into the body of the message.

Attempting to insert a link into the subject of a new message succeeds. However, the extension does not recognize the link and does not inject the content behind it into the page when viewing the sent message. If the link is copied and pasted from the subject into the body, the content is correctly injected when viewing the sent message.

The behavior was present with privly version 0.3.1 and Mac OS X Mountain Lion with the latest version of chrome.

The first run page currently opens in an seperate window. This should be changed to open inside a new tab in the user's browser.

The user wants to post content via a form and they don't want to think about using Privly. It should "just work". This requires hijacking the appropriate posting forms. There are several cases we should examine:

1. The host page's form submits when the user hits the "enter" key.
2. The host page's form has a "submit" or a "send" button.

Both of these cases need to be supported in seamless posting and pose very different design constraints. More problematically, you can't tell which case the form falls into in the code.

To compensate for both cases, the following activity could be used, under the assumption that the user wants to post with Privly:

1. When the user clicks on a text area, the extension automatically creates a new link and drops it into the host page. This link is now associated with the content the user is eventually going to write into the form.
2. The browser extension then puts an iframe into the context of the host page that is associated with the new link. When the user types into the iframe, it updates the content stored at the content server.
3. When the user hits the "enter" key, or the "submit" button on the web page, the link is submitted and the iframe disappears.

When not logged into to Privly, if the Options page is selected from the drop down menu, the user will be taken to the options page as though they have already logged in. The nav bar at the top will give the user the options: history, new link, options, and log out.

Other pages from the drop down menu only show the option to log in on the nav bar and display a message asking users to sign in.

Browser: Chrome 21.0.1180.60 m
Privly version: 0.0.5
Website: turntable.fm/the_indie_jones

When posting a privly link on a chat window, it does not inject the content. Instead, it shows a link that says, "Injectable Content: Read in Place". Then you have to click on the content to show it.

However, when Sean tested with Firefox, this was not the case. Also, when Sean posted a privly link using Firefox, and I viewed it on Chrome it worked (showed the content, not a link).

If you need a screenshot, please let me know.

When you manually add privlyInject1 to a non-whitelisted hyperlink, it will put the link into passive mode for injection. This passive mode link does not currently get its indirection removed. For instance, send https://news.ycombinator.com/#privlyInject1 to Hushmail.com, and you still get their spoofing warning service. However, if the news.ycombinator.com is on the user-defined whitelist, the user does not get this error.

To fix this issue, privly.js needs an update to handle passive links more uniformly.

This commit 566d378 appears to be incorrect. When I git clone --recursive https://github.com/privly/privly-chrome I get the following error:

fatal: reference is not a tree: ab2f020b4164cd14f3b8f7ddeecfd00a6eeb20b9 Unable to checkout 'ab2f020b4164cd14f3b8f7ddeecfd00a6eeb20b9' in submodule path 'privly-applications'

Trying to checkout that commit when in the privly-applications repo gives me a similar error message. I think the commit you want is 2cedca7e25374bd49f256d10de1e383b9ff5603b

If a user navigates their posting application tab to another application firing a PrivlyMessageSecretEvent, the extension will message the app the starting values of the form. We need to either take away the user's ability to navigate that tab, or only send messages to the list of approved URLs.

This is an introductory issue. It assumes sophistication in programming but not in Privly software.

The options page (shown below) has awkward UX:

• The user whitelist section has a save button but the content server section automatically saves. This will likely confuse users since it isn't clear that the content server section updates immediately.
• The user must interact with the CSV form -- non-technical users are not very good at interacting with a CSV form.
• The layout is ugly.

This issue is an invitation to improve the UX of the options page. Since the options page doesn't directly involve interacting with Privly Applications, this is an easier issue to do your first pull request on.

The Chrome extension almost has all the necessary components to release the Eagle Alpha. The final checklist includes:

• Remove the font file from the extension and replace it with graphics.
• Run tests and use the extension heavily for a few days.
• Write a blog post detailing future development of the Public Key Infrastructure on Google's Native Client.
• Write an announcement for Privly.org, including details of the spoofing glyph.
• Write a blog post detailing the current functionality of the Chrome extension.
• Finish the first-run page with the some of the above information.

I could use some help with the testing and the graphics/layout work, but the writing is on me.

The pages directory contains the configuration UI for the extension as well as the "first run" page that shows the changes for each new version of the extension. Since Privly Applications use Bootstrap 3, these pages should be migrated from Bootstrap 2 to Bootstrap 3 to maintain consistency. This involves changing the syntax of the HTML files to use the new CSS classes and dropping in the new CSS and JS files.

Currently all new posts to the server are destroyed within 30 days. Since we now make this the default in the UI on privly-applications, we can remove the server-side requirement. Anyone who circumvents the default knows that they are not guaranteed hosting on the content beyond that time frame.

The PrivlyBtn (Host page posting button) has too low of a timeout, and is only displayed 'onClick'. The timeout should be increased to 5s (5000ms), and the button displayed on mouse movement over the textarea of the posting context.

This can currently produce a very confusing experience for the user as they may not know to click before the button appears.

Note: This should be further evaluated as it is possible for hover to change the location of the lock icon. Not all sites post content into the text area being edited.

When gmail has been running in a tab for a long time, the content script added by the Chrome extension sometimes stops detecting Privly-type links. I suspect the content script is either not running in the tab or is not being triggered to run through the mutation observer.

When I examine the browser extension's console and the web page's console, I don't see any errors that could cause this behavior.

If anyone else experiences this issue, please comment. I am going to keep an eye out for it.

We need an easy way to activate and deactivate the extension without accessing the Chrome extension settings. The simplest way to implement this functionality is to control when the content script is injected (privly.js), but we could also send messages to the content script after it is loaded.

In Hangouts when you generate a Privly URL and send it, it should be rendered immediately, just how it works on facebook, instead, it shows the URL and renders it only after the Chrome tabs are changed. This happens every time a page is refreshed, the Privly URL's are displayed and don't render automatically and update only after tabs are changed.

When content is modified or injected by a browser extension, the resulting content may break the visual separation between user-submitted content and site notices or navigation. This creates a potential vector for users to craft spoofing attacks, which may lead a user to install malware or divulge sensitive information, including credentials for the Host Page.

To combat spoofing, the separate scripting environment of the Injectable-App must display a custom tooltip indicating the source and type of content. The tooltip appears when the user hovers their cursor over the content.

A second type of spoofing may occur if the Host Page attempts to present its content as originating from a trusted Content Server. Privly content does not benefit from the guarantees provided by the browser address bar, so it must provide a method for verifying the origin of Injectable Apps within the context of an untrusted Host Page. To authenticate the tooltip, a unique random glyph must be associated with every Extension. The glyph is displayed next to the tooltip of injected applications.

This version should solidify the development process for new injectable apps. To further this goal, we will develop several novel apps. A few candidates are:

• Add IRC Client
• Implement Off the Record (OTR). Injecting an IRC client into the context of the host page could be tied to a URL-Unique channel.
• Design an app that has a paired message passing API that may optionally be used by the host page to influence the operation of the app.

Problem: The background script is attempting to update the whitelist for content that is not a webpage.
Replication: Open the background.html page from the extension settings menu and view the javascript console as you close and open tabs. You will quickly see the message below:

Unchecked runtime.lastError while running tabs.executeScript: Cannot access contents of url "data:text/html,chromewebdata". Extension manifest must request permission to access this host.
at Object.readingProcess.activateContentInjectionScript

I believe this was introduced by bd90575