Skip to content
This repository has been archived by the owner on Oct 6, 2021. It is now read-only.

Document UX Wins #20

Closed
paragonie-scott opened this issue May 13, 2016 · 10 comments
Closed

Document UX Wins #20

paragonie-scott opened this issue May 13, 2016 · 10 comments

Comments

@paragonie-scott
Copy link
Member

paragonie-scott commented May 13, 2016

Between now and version 1.0.0, we should make a list of things Airship does better than the existing CMSes, and how these benefits relate to (quoting a Reddit post with feedback from bopp):

  • Developers: These are the backend-developers. The people who install the CMS, configure it, and build any custom functionality.
  • Implementors: These are the "frontend developers". The people who structure the content, set up the contenttypes, and implement the theming of the website in HTML/CSS in the templating language provided by the CMS.
  • Editors: These are the people who work in the CMS on a daily basis. They write new content, edit existing pages, etc.

I'd also like to add to this list for a few more use-cases:

  • Pseudonymous publishers: Activists or entertainers who wish to publish their content on a Tor Hidden Service for their safety and/or to protect the enigma of their persona. We should go out of our way to protect the server's IP and use authors rather than users for any public interaction.
@paragonie-scott
Copy link
Member Author

paragonie-scott commented May 13, 2016

User Experience Wins

This comment will (NO LONGER BE) be edited frequently.

All Users

  • Static page caching (cuts response time to less than 1ms on modest hardware)
  • When you delete a blog post or custom page, you can specify a URL to redirect visitors so they don't get the dreaded 404 page
  • Separation of username (for access controls) and author profile (for publishing)

Editors

  • Multiple text formats
    • Rich text (HTML with a WYSIWYG interface)
    • Raw HTML
    • Markdown
    • ReStructuredText
  • Recursive blog category structure
  • Blog Series
    • Can be organized however the editor wants
    • Each blog post can be assigned to any number of series
  • RSS feeds
  • XML Sitemaps (mostly for SEO purposes)

Pseudonymous Publishers

  • All outbound HTTP/HTTPS requests can be forcefully proxied over Tor
    • Yes, including ReCAPTCHA

Developers

  • Ed25519-signed JSON communication
    • I'm not kidding. The API for taking advantage of this is quite simple, too.
  • Best-in-class cryptographic features powered by Halite.
  • Barge: a simple command line interface for creating, building, signing, and releasing Airship Cabins and Gadgets.

Implementors

  • Barge (WIP): a simple command line interface for creating, building, signing, and releasing Airship Motifs.
  • Uses Twig, which is a more sane templating language than Smarty.

Security Benefits

  • Secure password storage
  • Automatic updates
  • Virtual filesystem for user-uploaded files
    • Allows access controls based on URL patterns
    • Prevents server software (e.g. Apache) from accidentally executing an uploaded file as code
  • Manage your Content-Security-Policy headers via web interface
  • Opt out of password reset emails, or require them to be encrypted with your PGP public key
  • Mandatory CSRF protection on all POST form handlers
  • Comprehensive yet simple access controls management
    • Hierarchical group-based and user-based access controls
    • Multi-site architecture where each site has its own permissions matrix
    • Groups can inherit permissions in a hierarchy
    • Permission can be granted to groups or users
    • The UX for all of the above is simple and intuitive
  • Adjustable login throttling (based in IP subnet OR username)

Vulnerabilities You Don't Have to Worry About

  • SQL Injections - We never concatenate user-provided string data with query strings
  • Session Vulnerabilities - If you use TLS (which you should!) Airship enforces HSTS and secure-only cookies
  • Broken Authentication - Well-implemented authentication protocols (You can even opt out of password resets!)
  • XSS - We filter on output, not in input, to prevent column truncation to enable stored-XSS attacks
  • Insecure Direct Object Reference - Our router is a whitelist
  • Sensitive Data Exposure - We use HiddenString to hide sensitive data from stack traces
  • Missing Function Level Access Control - Not in the Cabins we ship with anyway! (See access controls above)
  • CSRF - Mandatory token enforcement
  • Using Components with Known Vulnerabilities - We self-update! And we do so more securely than everyone else.
  • Open Redirection (unless you go out of your way to make it possible)
  • PHP Object Injection - We never use unserialize() (bonus: no memory corruption issues from that function either)
  • Insecure RNG - We use the kernel's CSPRNG
  • Password Hashing DoS - We use a throttling system called AirBrake and allow fast-failing

A particularly savvy reader will notice we covered 9 out of 10 entries of the 2013 edition of the OWASP Top 10 in this list. The one we couldn't include, Security Misconfiguration, is still something you'll have to worry about when you change settings. It's secure by default, however.

@Petah
Copy link

Petah commented May 14, 2016

How about multiple blocks? Drag and drop layout management? Navigation editors, image galleries, site maps and full site search?

This is coming from a content editor perspective.

@paragonie-scott
Copy link
Member Author

How about multiple blocks?

Motifs consist of two parts: Static resources (CSS, JS), and Twig templates. You can override the "base template" by changing one line in the motif.json file to completely restructure everything.

Gadgets can override specific templates (e.g. via the Cargo API).

Drag and drop layout management?

That's an idea worth considering.

Navigation editors, image galleries, site maps and full site search?

  • Navigation editors: You can change what goes in the navbar, but that's something better-suited for a gadget than core functionality.
  • Image galleries: That's a good idea.
  • Site maps: Intended to be baked in.
  • Full site search: Not implementing in version 1, because I need to do more research on search engine development and then design it to not be a denial of service vector.

Thanks for the suggestions! 👍

@carnage
Copy link

carnage commented Jun 9, 2016

How about 2 factor auth?

@paragonie-scott
Copy link
Member Author

How to implement it?

  • Google Authenticator - hostile towards Tor users
  • SMS - requires a phone number and Twilio account
  • Yubikey - requires additional hardware

@carnage
Copy link

carnage commented Jun 9, 2016

GPG encrypted email?

@paragonie-scott
Copy link
Member Author

Already implemented. :)

@carnage
Copy link

carnage commented Jun 9, 2016

as a 2fa mechanism?

@paragonie-scott
Copy link
Member Author

I'll make a ticket for implementing 2FA, but I'm not sure if it will land before v1.0.0 due to the anticipated research burden and short time table.

@paragonie-scott
Copy link
Member Author

Okay, this list is good. I'll get around to writing this before v1

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

3 participants