privly / privly-web Goto Github PK

We need a format for:

• How the link identifies itself as supporting the Privly Protocol

The proof-of-concept implementation uses a regular expression that matches https://priv.ly/posts_/IDENTIFIER, but we need to freeze a URL tag that can interface with any server's URL structure. The reference implementation is in Rails, but it should support the maximum number of server technologies without needing URL rewriting.

(Good for new people to Privly development)

We need all identifiers on the system to be randomly generated to prevent publicly available content and keys being crawled.

More information for new people: When you generate new content on a rails server, it usually stores it at a URL like /posts/47, where 47 is the unique identifier for the resource. This is a problem for Privly development because we want the server to (1) not store any information it does not require for performing its service, and (2) not give users metadata about the content they are reading unless the user who created it wants to share that metadata. Herein lies the problem: rails traditionally generates URLs where each newly created piece of content, in our case "posts," has an identifier that is one greater than the last created piece of content. This allows users to infer:

1. The relative creation order of content.
2. Whether there is likely content on the server at a particular resource identifier. This is very problematic because bots/crawlers/indexers could crawl each of the URLs in sequence to grab all the public content on the server.

We mitigated problem (2) by adding a random token that permissions every piece of content. Since this random token is only found on Privly-type URLs and on the server, without discovering a Privly URL, it is unlikely that a bot will be able to index content on the server.

However, we have not yet addressed issue (1), which is where you come in. You could change it so that every resource identifier is randomly generated on the server. This requires changing the identifier of the posts model so that its primary key is not auto-incrementing. It also requires some logic that prevents identifier collisions, since simply randomly selecting a resource identifier will eventually result in duplications.

A good place to start appears to be this stack overflow post, but you should also add test coverage and see what happens when you run rake test.

Good hunting/feel free to comment!

Style should depend on the site hosting the content.

No information aside from content should be relayed.

We need a complete record of the development, organization, privacy, and security issues associated with Privly development.

People should be able to easily interface any extension with the content/key server.

We need to design the TShirts for our backers.

We need a web application for the public face of Privly development at priv.ly. The bare essentials are a blog and a few landing pages, but additional functionality is welcome.

We need people to help with:

• Organization development (see organizing milestone)
• Rails Application Development
• UI Design
• Formal cryptographic specification
• Formal API specification
• System security
• Writing URL specification
• Collecting bugs from across the web
• Writing Firefox Extension
• Writing Chrome Extension
• Writing Safari Extension
• Writing Opera Extension
• Writing Internet Explorer Extension
• Writing mobile applications
• Writing Thunderbird extension
• Localization

(and more!)

Markdown permits images from arbitrary sources which allows tracking pixels.

The extension needs a user interface that supports:

• Disabling all extension functionality
• Passive mode (when users click the Privly link the content expands in place)
• Click through mode (when the user clicks the Privly link it takes them to the content server)
• Active mode (all links are automatically inserted in place)

A UI will hook into these modes, for more information: https://github.com/smcgregor/privly-web/issues/36

We need for hosts to be able to collect funds for hosting and bandwidth costs. Hosts will not be able to fund operation through advertising and data auctions. We should support major payment processors, and BitCoin.

We need to define what will happen with user data if we get a lawful order under various circumstances. This is particularly important for countries with host servers and domain registrars.

I know how to get Tshirts to Americans, but many of our supporters our in Europe and it doesn't make sense to spend project funds on shipping internationally.

the "public" attribute of posts could likely be changed when the user has update permissions. We need to make share permissions a requirement for this one attribute.

Provide an interface for importing an existing private key, or generating a new one. The alpha version will support PGP from one individual to another, but building out the key management UI for lists of "friends", Twitter users, and others is going to take more time and design.

The token auth method does not respect Devise's configuration for account locking.

We need a formal specification of the final sharing model found in this video: http://vimeo.com/39095681

Definitions:

• linkToken = encryption token attached to the link
• symmetricKey = key used to encrypt content
• publicKey = encryption key specific to each user the content will be shared with
• privateKey = decryption key specific to each user the content was shared with

Content Creation:

• Encrypt content with symmetricKey, send ciphertext to server
• Generate link with linkToken on it
• We need to share the symmetricKey with others, so they can decrypt the content
• symmetricKey%linkToken (read symmetricKey encrypted with linkToken) is generated, meaning only users who have linkToken (the key attached to the link) can decrypt it to find symmetricKey
• (symmetricKey%linkToken)%publicKey (read, symmetricKey%linkToken encrypted with public key) is generated for every user we wish to share the content with.
• send twice encrypted keys (symmetricKey%linkToken)%publicKey to the server for distribution

After content is generated...

ALICE HAS (encrypting user):

• linkToken
• link to ciphertext
• symmetricKey
• publicKey for each user shared with
• cleartext
• ciphertext

BOB HAS (receiving user):

• publicKey
• privateKey
• linkToken
• link to ciphertext
• Encrypted Key (symmetricKey%linkToken)%publicKey
• ciphertext

CONTENT SERVER HAS:

• content ciphertext
• Twice encrypted content key (symmetricKey%linkToken)%publicKey for each receiving user

HOST SITE HAS (bookface.com):

• linkToken
• link to ciphertext
• Updating the content is easy, as you just send a new cipher text to Privly
• Adding new users is easy
• Revoking users:
  • need to update symmetricKey
  • generate symmetricKey'
  • encrypt content with symmetricKey', send to server
  • tell server to stop handing out old twice encrypted key (symmetricKey%linkToken)%publicKey, send new keys for all still-allowed users

The auth_token sits on the extension. If the user logs out of either the remote site, or the extension, it should invalidate the token on both.

the scroll height is returning 150px as a minimum. This looks awkward for short sentences.

The extension needs to manage security within the iframe and running code returned by the remote server within the injected iframe is problematic.

We need a simple bug submission page for non-developers. Initially we will use it for finding odd behavior across the web.

Later we will begin using it to collect data so we can generate config files for interfacing with specific sites (users choose whether they want to participate).

The server should optionally collect:

• URL where the problem occurred
• Whether it broke functionality on the host site
• Whether it replaced a link it should not have, or missed replacing the link
• The URL that needed to be replaced
• Operating System
• Browser
• Extension version

We can re-add integration with Facebook and other services when this functionality has been fully specified.

Since we can't use Privly to advertise, we need a way to fund the mission. The non-profit organization will be supported by licensing the extension network's default white list to for-profit companies that adhere to the principles of the Privly community. We either need to form the for-profit company to host the reference implementation, or contract a respected company.

The server and the extensions 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.

The attributes are accessible to mass assignment, need to: http://railscasts.com/episodes/237-dynamic-attr-accessible?view=asciicast

We need a terms of service that effectively protects anyone hosting content for the Privly extension network.

A good example implementation is how GreeseMonkey works on Firefox. There is an icon in the "chrome" of the browser that you can turn on and off by clicking on the icon, and there is a drop down menu immediately to the right of the icon. The icon indicates the currently running mode where the following graphics are displayed according to their mode:

• Extension disabled: A red slash through a faded out icon
• Click through mode: A blue slash through a faded out icon
• Passive mode: A faded out icon
• Active mode: An icon

For more information on modes: https://github.com/smcgregor/privly-web/issues/35

We need to register for the DMCA, and add a DMCA process to the site.

http://www.copyright.gov/onlinesp/

We are going to retire priv.ly as a host of content. It will become the marketing/communications page for the system.

The development server should always be running the HEAD of the master branch. It can sit on any domain since the extensions will (soon) interface with any domain.

The injected iframes use the web application's javascripts. This is unnecessary overhead and should be refactored to use only core JS functionality.

https://priv.ly/users/sign_in

Sign in/sign up looks similar - consider some disambiguation

We need to draft the organizational governance.

This document will double as a statement of principles and a guarantor of rights for anyone posting content to a white-listed server.

Browsing public posts without signing into the system currently requires solving a captcha served by Google servers. We should eliminate this dependency.

We don't have to limit the injected content to text, but we have to solve some privacy and liability issues first.

Only posts owned by the signed in user should show on the index action

We can implement chat functionality in the expanded iframes.

It is increasingly important for organizations to have a patent portfolio to defend themselves from other patents. We need help patenting elements of Privly for the non-profit to license freely.

We need a discussion around this. I have debated about it for a while.

From an email:

"...the name they chose to host the server: priv.ly, is registered in the Libyan top-level-domain. That means the Libyan government gets to choose what address this name points to, can tamper with its secure DNS records, or just turn it off....

Even if Ghaddafi is dead now, that's not a smart choice of jurisdictions to host a service of this nature just because service names like bit.ly are cute and trendy right now."

A potential DDOS attack on the system is tricking out users into visiting a page with many Privly links. If the links are all injected with content automatically, this could have every user sending thousands of requests to the content server.

It is difficult to ascertain the address of iframes without looking at the source code. We need a method for validating the Privly origin of content. Perhaps randomly generating a security message or image at install time, then displaying it on the iframe tooltip when the mouse is over the content.

We need a format that:

• Identifies the link as supporting the Privly protocol
• Tells the extension that the link has an encryption token
• Supports removing the token from the URL before requesting the content

The web application should be more spartan, and only include:

• Content and key server functionality
• Default landing page with information about the site
• An about page that explains the server and links to privly.org
• Generic terms of service, privacy policy, and DMCA policy
• License

The same origin policy will not apply to the host sending content and keys from the server to the iframe. The remote server should return data-only formats to the extension, which will populate the iframe with content. This prevents the remote host from sending unencrypted data back to the content server.

A random password is assigned to users if they authenticate through a provider (like Facebook). The user still confirms the account over the associated email address. The mailer should notify them that this account does not have a real password, and give instructions on how to assign one.

The DB seeds broke when we added put in attribute accessibility. Need to update the seeds.

On public posts, Facebook previews the content behind links. They probably respect robots.txt, but the file is apparently not structured right for them.

We need to replace the existing captchas with one hosted by the content server. This is important for public links since the host site might not respect our terms of service.

We need to incorporate Privly as a non-profit dedicated to providing software for the private sharing of information on the web. This will protect the privacy mission, shield the developers from legal liability, and decrease tax expenses.