Sharing Engine/Tracking, Moderation and Security
This page is to document discussions regarding tracking, moderation and security for the sharing engine. The time spent on this discussion is being tracked on ticket #391.
This page was started following a Skype discussion on 1st Feburary 2012 in which issues of security, spam and moderation were discussed.
The security options available are limited by the nature of the project -- no code will be running on remote servers, webmasters deploying the widget onto their sites will just be copying and pasting code onto their sites and then users of their sites will be completing and submitting the form to the Transition Network server.
There will be nothing stopping 3rd parties copying the code and putting it onto other sites -- there are no checks which can't be spoofed (eg HTTP Referer headers) to ensure that the form submission resulted from someone completing the form on the site where the form is supposed to reside -- this is due to the nature of the web, specifically HTTP, HTML and Javascript.
When a webmaster decides to deploy the sharing engine widget on one or more of their website they will complete an application process on the Transition Network site and then get a block of code they can deploy on their sites. This code will need some unique identifier to ensure that all submissions from this code block are put in the moderation queue for this specific webmaster.
iframes
Using an iframe will allow the most feature rich widget to be developed as it's essentially a window displaying a page from the Transition website on the remote sites, however there are some very old desktop browsers and some old mobile devices which don't support iframes, all new smart phones have iframe support. You can test iframe support here.
XHTML 1.0 allows iframes but they were omitted from XHTML 1.1, they are in HTML 5, see the Wikipedia frames page, especially it's [https://en.wikipedia.org/wiki/Framing_%28World_Wide_Web%29#Critique critique section.
Iframes in HTML specifications:
- HTML 4.01 Inline frames: the IFRAME element
- XHTML™ 1.1 - Module-based XHTML - "XHTML Frames... are not available in this document type"
- XHTML™ Basic 1.1 - Second Edition - Frames - "Frames are not supported. Frames depend on a screen interface and may not be applicable to some small appliances like phones, pagers, and watches."
- HTML5 W3C Working Draft 25 May 2011 - The iframe element
Specific mobile support for iframes:
- Blackberry, supported since version 4.6
- Android, supported, however problems with scrolling.
Questions
- For accessibility and devices that don't support javascript are we going to have a
<noscript>fallback? - Which of these approaches (or a mixture of them) are we going to adopt for the widget?
- HTML forms -- these have the advantage that they will work on any device, they have the disadvantage that without AJAX enhancement they are not interactive, also updating the forms would be down to the webmasters -- they couldn't be updated centrally.
- Javascript write -- this has the advantage that the code can be updated centrally but the disadvantage that it won't work with clients who don't support javascript.
- Iframes -- this option gives the most flexibility for updates and options but it's also got a bad security history and poor support on older devices.
- Spam is probably going to be a massive problem, would it help if webmasters could create their own specific questions to defeat spammers?
