privly / privly-applications Goto Github PK

Moved from privly/privly-chrome#82.

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 log out option should be log in.

This happened on a computer that never logged in privly before.

The privly apps can scroll a bit horizontally. This happens both in Chrome for Android as well as inside Privly Android app.

When a new link is created outside the extension or without using the context menu, the user is responsible for copying and pasting the link to the host page. As it currently stands, the user must copy a hyperlink which will open the corresponding application if accidentally clicked. The Privly applications should better support copy and pasting by making it easier to highlight the generated link.

There is no way to automatically access the clipboard without using flash -- which we won't do.

This is an introductory issue. If you have any level of question or want clarification on resolving this issue please respond with a comment.

The encrypt and decrypt functions in personapgp.js make use of the OpenPGP.js library. Basic tests that demonstrate all of the functionality you will need to understand are in pgp/test/openpgp.js.

The encrypt function found in pgp/js/personapgp.js currently encrypts messages without signing them. An additional parameter will need to be added to the encrypt function. If that parameter is a private key, it should call signAndEncryptMessage instead of encryptMessage. If the private key is not provided, it should not sign the message and its behavior should not change from what it does currently.

Once this functionality is implemented, the decrypt function will need to be able to detect if ciphertext is signed or not. Then, if the message is signed then verify the signature, and if it is not then the behavior of decrypt should not change.

The existing code base calls the PersonaPGP.encrypt function from new.js after hitting the 'save' button on new.html. The PersonaPGP.decrypt function is called from show.js while loading the message that is displayed on show.html. Alternatively, both of the commands could be called directly from the console while on the new.html or show.html pages.

Note that the call made to the encrypt function will need to be updated in new.js with the additional parameter of the private key. See the pgp/README.md for details of the structure of data stored in localforage.

The Login application should provide a link to register for the content server.

Current Login App:

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 login dialog for the privly-applications currently has only one error message if the user fails to login. This is a problem because it fails to separate bad passwords from server errors. checkCredentials in new.js should be modified to check for an error status code. I think adding a check for response.json.error === true and then calling the appropriate callback should work, callbacks.loginFailure().

This is an introductory issue, but I expect it still to be challenging for people because the design considerations are different from most JS applications. The easiest way to get started is to clone the privly-chrome repository with git clone --recursive https://github.com/privly/privly-chrome.git. This will clone the privly-applications repository inside the Chrome extension and allow you to make changes to the privly-applications/Login/js/new.js. You will need to load an unpacked extension to get the code into Chrome.

To launch the login dialog with the extension's version of the form you should initiate a posting process by right clicking on a form element on a page and selecting "post with ZeroBin". This will prompt you to login and you can view the form.

This task should give you a better idea of what local code and remote code are in the Privly ecosystem.

On Firefox 29.0.1, the index application found at apps/Index/new.html on the content server exhibits a strange resizing behavior where the iframe continuously resizes from the proper size to a size that is far too large.

How to replicate:

1. This doesn't work on Chrome so you'll need to use Firefox
2. Log into a content server and visit: apps/Index/new.html
3. This only happens when you visit the hosted context of the application WHILE you have the Firefox extension installed, so make sure you have the Firefox extension running.
4. Click on a PlainPost application link so it previews inside the index application.
5. Behold the resizing weirdness.

Some of the apps still have the message:

"This post is temporary. All new content is destroyed within 30 days ."

This is no longer true, so it should be removed.

When we store variables using localforage they should be namespaced to the PGP app. These variables include:

• directoryURL
• email
• my_contacts
• my_keypairs
• persona-bridge

When you view content in the History application's hosted context (privly-web) the "download extension" message appears. This download extension message should not appear in the hosted context if it is injected. This can be fixed in the privly-web adapter.

Currently, the PR that I am attempting to merge does not inject into a page. It appears to every time localforage loads. The exact error is

uncaught SecurityError: An attempt was made to break through the security policy of the user agent.

Which is output every time that localforage is loaded in the context of a host page. I have tried this on both reddit and gmail. Clicking the link and loading the app from the local source allows the content to be loaded without issue.

I have tried removing show.js and personapgp.js from the list of scripts that load in show.html, but the error occurs just the same.

I thought that in a previous commit this had been working without that same issue, so I rolled back to 2084a69. I had to regenerate keys because the data structure in localforage changed between the current commit and 2084a69, but still the same error persisted.

If a user types a message and then closes the window or accidentally clicks on a link on the message creation screen, the message is lost. Users have come to expect applications to have the ability to recover from such simple mistakes.

There are jquery plugins, sisyphus.js and garlic.js, that are designed to provide this functionality. I've not evaluated either very closely but they seem worth considering.

Karma's unit testing supports generating code-coverage statistics. We can then hook the code coverage into CodeClimate to generate another nifty badge for the repo's README.

Hide Menu Options from the PrivlyApplications for PrivlyAndroid. Can you give instructions on how to hide the menu for mobile platform.

If a user views content in the hosted context, they should be solicited to download the extension.

We may want to change the existing message to not immediately state 'Never View This Site Again'. It makes perfect sense if you understand why that message is being displayed, but if you don't it is far from an appropriate welcome mat.

Perhaps the message should be custom tailored to the user by using the referrer. Something like 'Why did you leave $site to view this content? Download the extension and you won't have to.' That's far from perfect but is the general sentiment.

The PGP app generates key pairs with OpenPGP.js. Currently OpenPGP.js does not support setting a key expiration time. It does however set a creation date.

If we assume that all keys should expire 30 days from the time of creation, we can use this to determine when a new key should be generated. However, this will not work if/when we decide to let people import their own PGP keys.

Since we are not implementing key revocation, short lived keys are essential. We need to make sure detecting key expiration is robust before relying on it to not break the established threat model.

Until we allow people to import their own keys, I don't see an issue with just relying on creation time. I have not fully explored the implications of this though. I'm looking for feedback before implementation.

If a user is trying to create new content and they are not signed in they are presented with the login screen. After successfully signing in they are redirected. Currently, the redirect is to the new.html of the Help application. It should be the new.html of the application that was originally requested.

This issue is intended for people who have already had a couple of pull requests merged. The skills required include knowledge of the build system, how Privly works in general, and skills in HTML/CSS/JS.

The general purpose of this issue is to improve the box that displays the metadata for posts. I have a suggestion, but many improvements are possible.

Suggestion

All the current URLs for Privly contain both an application URL and (encoded on the application URL) a URL for the data associated with the post. Currently, only one of these URLs are displayed to the user in the metadata section. Instead, several fields should be displayed:

• Original URL: The complete URL as it was encountered on the web.
• Application domain: The domain where the link hosts the application if users don't have the extension installed
• Where the data is stored: The domain of the data endpoint for the content. This will not necessarily match the application domain

Getting this right will be tricky, because displaying these data in a beautiful way is not trivial. Feel free to open pull requests to discuss design directions.

Javascript changes should likely go here.

Flask would really like the CSRF token to be with every POST and DELETE request, which includes the POST to /users/sign_out.

This may not be necessary and Flask can be forced to ignore this as an exception.

Giving users a choice between PlainPost and ZeroBin serves as a point of confusion. PlainPost and ZeroBin do not differ significantly from the perspective of users. We should remove PlainPost, and rename ZeroBin to message.

This eliminates confusion about ZeroBin being a separate peice of software from Privly, and makes the right choice for users by default. Of course, documentation and threat models will make reference to ZeroBin, but general users should not be exposed this level of detail.

This will simplify rollout initially, and additional applications can be added over time with meaningful-to-user application names.

When the user clicks the "preview" link the content appears at the top of the page. Instead, the content should be previewed immediately underneath the row containing the record being previewed.

@fullvlad has further suggestions from when he performed a think aloud study on the app.

As documented in #63, there is some fine tuning that needs to take place in order to reliably get the persona private key into persona-bridge.

Currently we only check if persona-bridge is an element in localforage. To make the app more robust we should check if persona-bridge actually contains the private key and not just assume it is there if persona-bridge is set.

Current Behavior:
Facebook and other sites preview linked content by crawling the address. Since we don't give the bot the actual content, the preview defaults to the text of the user controls.

Expected:
We should give bots a statement indicating that this is private content and the user should click the link to read it.

See, among others, Facebook's API

In the case of Facebook, the user should remove the preview since it hurts the UI to have two of the same links expanded on the same page. Since we don't have control over Facebook's preview window, we have to rely on the end user to exit the preview.

Moved from privly/privly-web#78

Firefox detection needs to be changed because Components is now deprecated.

Right now when a user installs the extensions they are greeted with a changelog. This means nothing to most users, and only serves to confuse them. We should use this opportunity to give meaningful information to new users.

We should decide as a group precisely what content should live there. A quick guide integrated with a 'playground' for learning how to use privly comes to mind. This is not an ideal solution since we shouldn't have to train people to use the software, but it is leaps and bounds ahead of not providing that training.

I would like to hear thoughts on this idea, and other ideas for the content that should live on the first run page.

See also privly/privly-chrome#33

I circled below where we should put he pencil icon that is found on the "new" dropdown menu. This is intended to be an introductory issue for people new to Privly development. It will teach the developer the build system and the composition of the applications. For the uninitiated, this task will also teach how to use icons from twitter bootstrap

During new PGP message creation we need to address the following:

• If the user does not have an email set the 'pending server check' still shows up even if the server check has already completed.
• The message input form should not display if email is not yet set.
• Check the entered directory provider url. prepend http if it is not there.
• Avoid having a user enter a directory url altogether by establishing a default.

When you click the upper left of the Privly application shown below, it takes the user to their content server. This confuses the distinction between the user's local application environment and the application environment of the remote content server. The top level text of a site is usually associated with "I am here" but in this case the user is in the browser extension. We should change the behavior of clicking on the content server address to give the user a message like "your content server is dev.privly.org. To change your content server, visit the options page."

There are potentially better fixes to this issue, but I'll need to experiment.

As soon as the ZeroBin application loads in the WebView, the application keeps throwing this exception indefinitely

Uncaught BUG: random: addEntropy only supports number, array of numbers or string --  From line 1 of file:///android_asset/PrivlyApplications/vendorsjcl.js 

Workaround: Replace sjcl.random.startCollectors(); in zerobin.js with sjcl.random.addEntropy(random string);

Since privly-applications is going to replace all templating from the content server, the applications module will need to display the donate link.

The metadata section of the applications should have a re-share URL that is the original URL of the application. Currently only the data URL for the app is displayed, which causes confusion when people try to re-share it.

This section of code reassigns the URL in instances where the true URL has been added to a second URL as a parameter. This should be more restrictive so it will only grab the URL parameter if it was placed there by the extension. Without being more selective, this could potentially be used to circumvent the whitelist that determines which domains are automatically injected. This poses a tracking risk but it is not a security risk to content.

  getApplicationUrl: function(url) {

    //handles the Chrome platform
    if (url.indexOf("privlyOriginalURL=") >= 0) {
      url = decodeURIComponent(url);
     return url.substr(url.indexOf("privlyOriginalURL=") + 18);
    }
    return url;
  },

code context

We need to address the source of entropy that openpgp.js and jwcrypto use. Since openpgp.js uses the jsbn library, I assume it uses the rng contained in the jsbn library.

After further research into how openpgp.js sources entropy I think it would be wise to send an email to the openpgp.js mailing list to see how other projects that use it handle entropy.

Since jwcrypto is primarily a server side library, I doubt there is a lot of info on seeding it from the browser environment, but it might be worth looking in to.

The privly-applications bundle has Javascript tests, but they are not currently integrated into Travis, or any other continuous integration framework. While it is complicated to run the tests in the scripting environment of the browser extensions, it is standard to run these tests in a normal hosted context like the privly-web server. This issue is for running the Javascript tests inside Travis, a headless browser, or as a Grunt task.

Here is an explanation of how Javascript tests are currently written.

Instead of listing all of the required python packages in the header of the build.py file, we should create a requirements.txt file.

The requirements.txt file should be generated with pip freeze while in a python virtual env that only has the packages required to run the build.py installed. Once this is in place, we can remove the required package information from the header of build.py.

This is an introductory issue. If you have any level of question or want clarification on resolving this issue please respond with a comment.

findPubKey is a function in personapgp.js that queries local storage, and if not found there queries a remote directory provider. This test is meant only to exercise the search of local storage. The test should be added to pgp/test/personapgp.js

These tests should be limited to the case when keys are already in localforage. The tests should make sure that findPubKey succeeds when expected, and fails when exptected. The return value of findPubKey is an array of public keys.

Basic pseudo code for the tests is as follows:

1. Generate a keypair using openpgp.js ( example in pgp/test/openpgp.js )
2. Extract just the public key from the keypair ( example in Login/js/new.js )
3. Associate this public key with an arbitrary email address in the expected format ( format documented in the readme )
4. Add the email: [pub key] to localforage using setItem ( note that you will need to use getItem, then append your new key and then call setItem with your new data added. Unfortunately there is no way to simply append to an existing item in localforage. )
5. Use the PersonaPGP.findPubKey function to retrieve the public key as an array.
6. Use jasmine expect statements to evaluate if everything went according to plan.
7. Now call the PersonaPGP.findPubKey function on an email address that you know does not exist. Again using jasmine make sure it returns as expected.
8. Clean up after the test. Meaning, remove the email address and keypair that was added to 'my_contacts'.

Note that all of the calls to localforage are asynchronous. Using callbacks or promises will be required.

Line 59 of show.js, which is $('textarea').autosize();, currently throws Uncaught TypeError: undefined is not a function when there is not content displayed on the page. This shouldn't happen.

To reproduce this error, just directly access privly-applications/PlainPost/show.html. Note that there is a race condition and the page may need to be refereshed a few times in order to reproduce.

Right now when someone signs in with Persona they are not always given the choice of how long they want to sign in for. This choice (this session vs a month) turns out to be the difference between storing the private key in memory or persistently on disk.

As it is currently implemented (84a82eac7ee28c7c1c1476c0d113808235e7d704) we are only able to capture the private key when the user selects a month. This problem is compounded by the fact that a user is not always given the choice of how long they would like to sign in for. This is very confusing for a new user because this means they will have to sign in and sign out with persona multiple times in order to get it to work.

If a user has turned off injection and they click on a link, they are shown the message in the hosted context. If they have gone to the trouble of installing the extension, the least we could do is provide them with the additional security properties of viewing the message in the extension context.

On small (mobile) screens the History app's contents overflow.

To fit within the confines of the mobile screen we need to shrink the buttons on the left and allow the text to wrap within the cells.

You can replicate this issue on the web browser by shrinking the width of the window to be very small.

See a screen capture and the cross-references issue: privly/privly-android#33

When you add privly-applications, you currently need to modify the build script to be aware of the new applications. We are going to move towards a system where the build.py file finds manifest files inside directories and builds them into the privly-application package. This will allow for new packages to be incorporated into privly-applications more easily.

1. Modify the build script so that you can run python build.py from any directory. It currently only runs properly if your current working directory is the directory with the build file.
2. Modify the build script to have more user messaging. In particular, tell the user what packages were built.
3. Look at the current template for the manifests here. It is a dictionary of paths to the files that need to be built. Break these into individual files (eg, PlainPost/privly-app.manifest) inside the application directories and have the build script find each file in the build process.
4. Update the new manifest file format to be more fully featured (like labels for release status). Then add build flags that let the build script include or ignore applications based on their build status.

The Stanford Javascript Cryptography Library released a new update. I believe it is addressing an issue we already patched with how entropy is collected, but we should continue tracking the project.

https://github.com/bitwiseshiftleft/sjcl/releases/tag/1.0.2

Adding "mobile_hide" css class to the navbar hides it but empty space remains on top of webpage.

Currently the new PGP message page has an autocomplete form that pulls from local storage. The user is permitted to enter an email not found in local storage, but they are not given feedback if the email they entered was found on the directory provider. As it is currently implemented, the search of the remote directory does not take place until the user hits the submit button.

The form should be updated so that upon tokenization a search is conducted on the directory provider. Feedback should be provided to the user if the key is found or not. If the key is not found, we should provide an option to the user to invite their friend to use Privly.

We also need to keep key expiration (#62) in mind when initially pulling from local storage.

There are a lot of edge cases that this functionality will run in to, but it is essential to address the primary use case and give the user feedback.

During development of the PGP prototype, we ran into an issue related to CORS and querying the key server with a POST request. To simplify things we used a GET request to add keys to the key server.

This breaks convention and would be confusing for anyone new to the code base. We need to change these requests to use POST instead, which will involve using CORS. This will need to be a coordinated update in both the privly-applications repo and the privly-keyserver repo.

We need native language support for anywhere it is being used. Communicating in the native language of the users is important for reducing the risk that people misunderstand the security guarantees of the system.

Right now the header of Content on the new content creation pages does not provide a lot of information. Perhaps we should change it to something like Content You want to Share.

I'm sure there are other enhancements to that page that could be made to make it easier to understand as a standalone page, but that is the first that comes to mind.

I'd like to link to documentation on how to create Jasmine tests for Privly. Perhaps this documentation should be here: https://github.com/privly/privly-organization/wiki/Developer-Guides ...?

The primary location to inform users about the privacy properties of applications is the new.html page. These pages currently include warnings about the properties of the applications, but I don't think it is enough. We need to strike a balance between disclosing the properties inside the application itself and length.

We need to express which parties have access to what under what circumstances. If this cannot be succinctly stated and understood, we should only advertise the properties of the app in the worst circumstance possible.

ZeroBin should tell users in the warning section:

• "This app protects privacy from law abiding online service providers. If the Online Service Provider is willing to proactively attack your privacy, then this app provides no protection."
• "People with the link you create and access to the server where the content is stored will be able to read the content"
• "The server currently gives the encrypted content to anyone with the link. Read why"

PlainPost should tell users in the warning section:

• "This app protects privacy from law abiding online service providers. If the Online Service Provider is willing to proactively attack your privacy, then this app provides no protection."
• "The content server you upload this content to is able to read the content. If you don't want the content to be readable by the content server, use ZeroBin."
• "The server currently gives the encrypted content to anyone with the link. Read why"