Whether links fail because of DDoS attacks, censorship, or just plain old link rot, reliably accessing linked content is a problem for Internet users everywhere. The more routes we provide to information, the more all people can freely share that information, even in the face of filtering or blockages. Amber adds to these routes.
Amber automatically preserves a snapshot of every page linked to on a website, giving visitors a fallback option if links become inaccessible. If one of the pages linked to on this website were to ever go down, Amber can provide visitors with access to an alternate version. This safeguards the promise of the URL: that information placed online can remain there, even amidst network or endpoint disruptions.
Amber is an open source project led by the Berkman Center for Internet & Society. It builds on a proposal from Tim Berners-Lee and Jonathan Zittrain for a "mutual aid treaty for the Internet" that would enable operators of websites to enter easily into mutually beneficial agreements and bolster the robustness of the entire web. The project also aims to mitigate risks associated with increasing centralization of online content.
Amber is a multi-platform project - there are implementations for Wordpress, Apache, and Nginx as well as this project for Drupal. The code in the "libraries" subdirectory is common across all these platforms, so may contain some deviations from standard Drupal coding practices. Any code in that subdirectory will not use any Drupal-specific libraries or functionality. Similarly, the "amber.js" file is being used across multiple platforms, so doesn't contain any Drupal dependencies, nor does it use jQuery.
Project Page: https://www.drupal.org/sandbox/jlicht/2633514
Documentation: http://amberlink.org/
Git Clone Link: git clone --branch 7.x-1.x http://git.drupal.org/sandbox/jlicht/2633514.git amber
Project Reviews
https://www.drupal.org/node/2653354#comment-10769986
https://www.drupal.org/node/2637590#comment-10770038
https://www.drupal.org/node/2564055#comment-10770092
https://www.drupal.org/node/2633408#comment-10840068
https://www.drupal.org/node/2652682#comment-10840144
https://www.drupal.org/node/2654168#comment-10840158
| Comment | File | Size | Author |
|---|---|---|---|
| #22 | coder-results.txt | 368.83 KB | klausi |
Comments
Comment #2
jlicht commentedComment #3
PA robot commentedThere are some errors reported by automated review tools, did you already check them? See http://pareview.sh/pareview/httpgitdrupalorgsandboxjlicht2633514git
We are currently quite busy with all the project applications and we prefer projects with a review bonus. Please help reviewing and put yourself on the high priority list, then we will take a look at your project right away :-)
Also, you should get your friends, colleagues or other community members involved to review this application. Let them go through the review checklist and post a comment that sets this issue to "needs work" (they found some problems with the project) or "reviewed & tested by the community" (they found no major flaws).
I'm a robot and this is an automated message from Project Applications Scraper.
Comment #4
PA robot commentedClosing due to lack of activity. If you are still working on this application, you should fix all known problems and then set the status to "Needs review". (See also the project application workflow).
I'm a robot and this is an automated message from Project Applications Scraper.
Comment #5
jlicht commentedAll known problems from the automated review tools have been fixed
Comment #6
fusionx1 commentedhi jlicht,
i confirmed it has no problem with pareview. sh
I tried installing the amber module it work smoothly.
I have two recommendations:
1. Would be great if you can separate the html iframe markup on seperate tpl using hook theme.
2. I found some serious floss on .install file
sites/all/modules/contrib/amber/amber.install:
+14: [critical] Potential problem: drupal_set_message() only accepts filtered text, be sure all !placeholders for $variables in t() are fully sanitized using check_plain(), filter_xss() or similar.
Thanks,
fusionx1
Comment #7
jlicht commentedThanks for the feedback fusionx1.
I've addressed both issues:
c7fa83e - Use hook_theme() to display iframe
7cced33 - Properly escape variables in drupal_set_message()
Comment #8
jlicht commentedAdding "PARReview: review bonus" tag.
My reviews:
https://www.drupal.org/node/2653354#comment-10769986
https://www.drupal.org/node/2637590#comment-10770038
https://www.drupal.org/node/2564055#comment-10770092
Comment #9
klausiPlease add all your reviews of other projects to the issue summary so that we can better track them.
manual review:
Removing review bonus tag, you can add it again if you have done another 3 reviews of other projects.
Comment #10
klausiForgot pareview.sh output.
Comment #11
jlicht commentedComment #12
jlicht commentedI've addressed the comments from the review by @klausi (thanks!)
1) All the feedback from ESLint has been incorporated. Some of the feedback from the coding standards has been incorporated (trailing whitespace, unneeded includes in the .info file, missing doc comment). There are also comments related to line length, function parameter comment formatting, whitespace before and after parenthesis that have NOT yet been incorporated. I have concerns about making these changes, but (IMO) these are not significant enough to prevent project approval.
2) Added a "How it Works" section to the Readme.txt file to explain exactly what the module actually does, and how it interacts with Drupal
3) The 'libraries' folder contains the core functionality for Amber, and I don't think it's necessary to distribute it as a separate library. There aren't any other users of the library besides the Amber plugins for Drupal and Wordpress, both maintained by the same organization, so it's highly unlikely that a user would ever be in a position to upgrade the library independent of the core module. Additionally, distributing the library separately would introduce an additional barrier to installing the module for a new user, and we're trying to make the installation process absolutely as simple as possible. I hope this addressed the issue that was raised.
4) Added CSRF protection using Drupal tokens
Comment #13
jlicht commentedComment #14
jlicht commentedComment #15
jlicht commentedAdding 'PARreview: review bonus' tag back, as I have completed three more project reviews.
Comment #16
klausiReview of the 7.x-1.x branch (commit 18f7105):
This automated report was generated with PAReview.sh, your friendly project application review script. You can also use the online version to check your project. You have to get a review bonus to get a review from me.
manual review:
Comment #17
jlicht commentedThanks for the detailed review! Comments are below. I believe all the of the major issues have been addressed, and hope that we can go ahead and approve this module.
---
still tons of automated review errors - please take a look at them. At least doc blocks on function should be there to indicate a hook implementation or the purpose of the function.
I've run the Coder module with "strict" settings and cleaned up all the PHP errors within the Drupal-specific files. (That is, not the library files that are being shared across other platforms). I've also addressed the majority of the ESLint issues.
project page: still no information how the module works within Drupal. Can you copy the info from the README?
Done
instead of "return drupal_access_denied();" you should use "return MENU_ACCESS_DENIED;" when to CSRF token is invalid.
Done
amber_entity_update(): if you are only targeting nodes you should use hook_node_update() instead. Same for the insert hook.
Done
node/%/cache looks vulnerable to CSRF exploits - it triggers a database update without verifying intent. Since only amber admins are allowed to do this I'm assuming this is the same CSRF vulnerability as with the delete operation we had above.
This is a possibility, and I'll change this to add an explicit check of intent or CSRF token check. However, this is a non-destructive action, so the consequence should be minimal.
Wait a second ... the module archives arbitrary web sites including javascript on disk, correct? Then it delivers the foreign javascript assets under the domain of the Drupal site, thereby completely killing the same origin policy for javascript. If an attacker puts up a dangerous Javascript file on their site and you archive that site it means the dangerous JS can be delivered from your domain. Perfect for XSS! Am I missing something? How do you protect users from dangerous external javascript that suddenly runs in the context of your site under amber/cacheframe/%/assets? Looks like this is a severe security breach for any Drupal site using that module?
We protect users from arbitrary javascript by ensuring that requests to "amber/cacheframe/%/assets" are only made within the context of an iframe (served by "amber/cache/%" and amber_iframe.tpl.php) that is fully sandboxed.
Considering your feedback, we've also added logic to prevent users from loading the cached javascript outside the context of the iframe by checking the HTTP Referer header. If the Referer is empty or does not match the expected URL of our page that serves the sandboxed iframe, we reject the request.
Comment #18
klausiNice security challenge - indeed I don't see a way out of the sandboxed iframe with the referrer checks, so that looks good.
Unfortunately you are storing your cache in the public file system. Which means I can directly link to a malicious site HTML with something like http://drupal-7.localhost/sites/default/files/amber/31ae08526f2d01078f94... . Any JS in there will be fully executed in the context of your site ==> XSS.
You either need to move your cache to the private file system (which must be outside of the docroot) or you store your cache in the database instead.
Comment #19
jlicht commentedGood catch!
I've updated the cache logic to ensure that the cache is stored in the private file system.
Commit: http://cgit.drupalcode.org/sandbox-jlicht-2633514/commit/?id=9def5e42b0b...
Comment #20
klausiSaving snapshots now fails because the module tries to create a directory in /31ae08526f2d01078f948ea54008ed24 for example in the root file system. Can you check that the private files conversion works so that I can test again?
Comment #21
jlicht commentedPossibly silly question, but have you set the private directory path in the environment in which you're testing?
There should be an error on the configuration page if you try to select the "local" save option without the private file directory set, but if you don't update that page you might not encounter it.
Thanks!
Comment #22
klausiDid a clean install again and made sure I had a private files directory set up before installing Amber, which worked. I think you should check that the private file system works on install to avoid errors.
manual review:
But otherwise looks good to me. Assigning to Naveen as he might have time to take a final look at this.
Comment #23
jlicht commentedThanks for the last review - I'm glad to see that this is now RTBC.
However, I'm not clear on what happens next - it still doesn't look like I have permissions to promote this to a full project. Is there anything I can do to move this process along?
Comment #24
klausino objections for more than a week, so ...
Thanks for your contribution, Jeffrey!
I updated your account so you can promote this to a full project and also create new projects as either a sandbox or a "full" project.
Here are some recommended readings to help with excellent maintainership:
You can find lots more contributors chatting on IRC in #drupal-contribute. So, come hang out and stay involved!
Thanks, also, for your patience with the review process. Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.
Thanks to the dedicated reviewer(s) as well.