Project

General

Profile

Actions

NLNet application for UOI Call August 2021 » History » Revision 9

« Previous | Revision 9/38 (diff) | Next »
jahoti, 07/09/2021 03:27 AM
Restructured task list to better reflect requirements and roles


NLNet application for UOI Call August 2021

This document is live and being actively edited; however, due to its critical nature, it is currently locked. Please make suggestions and note errors in the associated forum thread.

Please note:

NLNet privacy statement.
When a project gets selected, it will legally need to retain your information for compliance purposes for at least seven years.

TODO:

  • confirm Wojtek is OK with submitting the application/being the contact
  • rename the extension
  • get a website up
  • reference the documentation for in-depth material, rather than stuffing it in the answer

Note for answers:

Please be short and to the point in your answers; focus primarily on the what and how, not so much on the why. Add longer descriptions as attachments. If English isn't your first language, don't worry - reviewers don't care about spelling errors, only about great ideas. Apologies for the inconvenience of having to submit in English. On the up side, you can be as technical as you need to be (but you don't have to). Do stay concrete. Use plain text in your reply only, if you need any HTML to make your point please include this as attachment.

Attachments should only contain background information: Please make sure that the proposal without attachments is self-contained and concise.
Accepted formats: HTML, PDF, OpenDocument Format and plain text files.

Abstract: Can you explain the whole project and its expected outcome(s).

No more than 1200 characters.

Technologically, a cross-platform browser extension will be developed that can add user-provided resources- or collections thereof- such as scripts to pages, either alongside or in place of resources embedded in the page. Additionally, functionality will be provided to load such (collections of) resources from a variety of locations securely and with updates as appropriate (local storage, the webpage, resporitories of shared scripts), as well as to make it easy to edit such resources or develop them from scratch for a variety of use cases, such as translation or changing page layout.

Socially, a project-maintained default repository will serve as a rallying point, providing not only a comprehensive and trustworthy source of libre, privacy-respecting, secure and generally ethical site resources (including community-developed ones), but also a forum to share information about sites' user-friendliness in this respect and to offer or solicit help with fixing problematic sites. Such a central hub further provides a unified body to negotiate with and pressure or advocate for particular website owners, strengthening the movement for a user-operated Internet.

Have you been involved with projects or organisations relevant to this project before? And if so, can you tell us a bit about your contributions?

Optional; this can help determine if you are the right person to undertake this effort

Requested Amount (in Euro)

Between 5000 and 50000

Explain what the requested budget will be used for? Does the project have other funding sources, both past and present?

If you want, you can in addition attach a budget at the bottom of the form. Fundable activities are listed at https://nlnet.nl/useroperated/eligibility/.

Current intended uses (costs to be determined)- H* represents Hachette and Hydrilla in what follows:

  • Infrastructure
    • Domain Name
    • SSL Cert
    • Hosting for VCS, Project management software, website, and script repo
  • Human labor
    • Project management
    • Social
      • Understanding what features users most want from Hachette
      • Writing documentation for end users for H*
      • Determining effective methods to automatically aggregate already-available free JavaScript used on websites
      • Studying what sites should be prioritized for fixing to deliver maximum impact
      • Ensuring accessibility of H* for potentially underrepresented demographics
      • Distribution of Hachette in extension stores (potentially excluding G. Chrome due to freedom and access concerns)
      • Distribution of H* in GNU/Linux package managers
    • Technical
      • Design and development of H* (available under the GPLv3)
      • Writing developer documentation for H*
      • Implementing accessibility of H* for potentially underrepresented demographics
      • Writing and performing rigorous testing of H*
      • Configuring a comprehensive automatic build and publishing process for H*
      • Support for MV3 in Hachette

Compare your own project with existing or historical efforts.

What is new, more thorough, otherwise different, etc.

  • GNU LibreJS is the closest available comparison, as a project which also combines a browser extension with a social approach to push for greater user
    control of the software webpages require. Hachette draws both inspiration and code from LibreJS, and will likely continue to do so. However, the very narrow scope of LibreJS makes it unsuitable for the wider goals of Hachette. It only supports GNU IceCat, while this project has been built from the start for both Firefox- and Chromium-based browsers with plans for more. Likewise, LibreJS only concerns itself with giving users the legal right to modify the JavaScript their browser runs, whereas Hachette aims to provide a concrete way for anyone to modify the logic, visual layout, and other facets of what a browser presents when it loads up a webpage.

  • Ad blockers overlap with the blocking functionality of the extension, and will likely continue to provide a source of code for this purpose as they have on previous occasions. Unfortunately, due to the focus of these tools on trying to filter out trackers, ads or untrusted resources rather than simply ones that can be removed or replaced using an injecting tool (as Hachette seeks to do), no known such tool provides a suitable blocker and level of control without an extremely over-complicated interface and significant initial configuration.

  • Userscript managers (e.g. GreaseMonkey and ViolentMonkey) have a long history of providing independent script injection on websites, yet differ wildly and irreconcilably from Hachette. They are designed to enhance, with facilities to execute scripts in privileged environments as well as to source such scripts from online repositories and keep them up-to-date. For restoring control to the user, by contrast, executing script outside the page context where webmasters would run it is an unnecessary complication and security risk, while a broader capacity to inject and maintain collections of various resources- and even to edit and develop them- is critical.

What are significant technical challenges you expect to solve during the project, if any?

Optional but recommended

Describe the ecosystem of the project. How will you engage with relevant actors and promote the outcomes?

E.g. Which actors will you involve? Who should run or deploy your solution to make it a success?

Thematic call

Included as a reminder- make sure to set this to User-Operated Internet Fund.

Updated by jahoti about 2 years ago · 9 revisions

Also available in: PDF HTML TXT