NLNet application for UOI Call August 2021¶

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.

• Table of contents
• NLNet application for UOI Call August 2021
  • Note for answers:
  • Abstract: Can you explain the whole project and its expected outcome(s).
  • 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?
  • Requested Amount (in Euro)
  • Explain what the requested budget will be used for? Does the project have other funding sources, both past and present?
  • Compare your own project with existing or historical efforts.
  • What are significant technical challenges you expect to solve during the project, if any?
  • Describe the ecosystem of the project. How will you engage with relevant actors and promote the outcomes?
  • Thematic call
  • Attachments

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.

A browser extension, "Hachette", (later possibly also an HTTP proxy and custom web browser) will be developed that facilitates browsing websites with custom changes (e.g. substituted page scripts, different site styling, alternative or aggregate interfaces for sites, accessibility&usability fixes, user translations, etc.) and makes it easy to edit such resources or develop them from scratch. Websites that force proprietary javascript, spyware and anti-features upon visitors will become fixable.

A project-maintained default repository, "Hydrilla", 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 opinions about sites and to offer or solicit help with fixing problematic ones. 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.

All parts of the project shall be freely licensed (GPL, CC BY-SA).

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

Our team currently consists of the following members:

• Wojtek (project maintainer) (https://koszko.org/en/koszko.html) TODO: maybe attach CV when sending the application
• Jahoti (https://jahoti.tilde.team)
• Nick (https://nicksphere.com) TODO: maybe attach resume when sending the application

Our experience:

• This project itself, consisting of Hachette (https://hachettebugs.koszko.org/projects/hachette) and Hydrilla (https://hachettebugs.koszko.org/projects/hydrilla), already exists as a simple yet functional setup. It is mostly written by Wojtek, with some contributions from Jahoti and Nick, and Hydrilla is entirely Wojtek's work.
• Nick has studied Distributed Networks & Cybersecurity at Southern Illinois University Edwardsville, graduating with a major in the field.

Additionally, we are consulting possible security issues of Hachette and the repository with Richard Stallman himself.

[Colby doesn't show activity. We'll probably have to omit him in the application :/]

Requested Amount (in Euro)¶

Between 5000 and 50000

8376

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 (https://nlnet.nl/useroperated/eligibility/):

The requested budget will fund the necessary infrastructure (for 3 years) and 4 months of 2 developers' full-time work, as further detailed in the attached breakdown.
Additionally, we prepared a table showing how many months of developers' work we could fund in case of different budgets*. Longer work means the ability to deliver a more featureful product.

Months allocated	Budget
2	€5764
4	€8376
6	€10988
8	€13600
10	€16212
12	€18824
16	€24048
20	€29272

* might be cut if some infrastructure is dropped

Current intended uses:

• Infrastructure
  • Domain Name, another 2 years (€ ~26)
  • SSL Cert, 3 years (€ ~534)
  • Hosting for VCS, Project management software, website and script repo, 3 years (€ ~2592)
• Human labor
  • Project management
  • Social
    • Understanding what features users most want from Hachette
    • Writing documentation for users for Hachette and Hydrilla
    • 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 Hachette and Hydrilla for potentially underrepresented demographics
    • Distribution of Hachette in extension stores (as long as freedom and access concerns allow)
    • Distribution of Hachette and Hydrilla in GNU/Linux package managers
    • Setting up and moderating the Hydrilla repository
      • Developing and writing policies for packages, packagers and (if adopted) auditors
  • Technical
    • Design and development of Hachette and Hydrilla (available under the GPLv3)
    • Writing developer documentation for Hachette and Hydrilla
    • Implementing accessibility of Hachette and Hydrilla for potentially underrepresented demographics
    • Writing and performing rigorous testing of Hachette and Hydrilla
    • Configuring a comprehensive automatic build and publishing process for Hachette and Hydrilla
    • Support for MV3 in Hachette
    • Creating and porting independent fixes and enhancements for some websites
    • Security vetting on Hydrilla

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 shares the ideals with LibreJS. 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 and content 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, these tools only focus on trying to filter out trackers, ads or untrusted resources, giving the user passive but not active control over browsing.

• 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. While they do offer some facility to source custom user scripts from online repositories and keep them up-to-date, they are designed with supplementing websites with minor tweaks in mind. As a result they chose to execute user scripts in privileged environments instead of the non-privileged page's context, thus avoiding interference with page's own scripts but also creating a security risk. A viable solution should inject scripts right into a page, making them execute in a proper sandbox. An even broader capacity to inject and maintain collections of various resources- and even to edit and develop them- is also critical.

• Hypothesis project offers facility for sharing annotations on web content. This idea is similar to one of our planned use-cases and it's even possible that Hachette will, at some point, support Hypothesis annotations. However, the general goals of this project are significantly broader.

• Weboob tool implements graphical interfaces and programming APIs for various websites in Python programming language. It succeeds in achieving some of the goals we set in front of Hachette. The main difference is that our project sticks to the usual technological stack of the Web, decreasing the amount of work required and that it also covers creations of a repository that will allow for greater scalability. As Weboob's code is freely licensed, it is likely some pieces of it will at some point be rewritten into javascript and uploaded to Hydrilla.

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

Optional but recommended

• Porting to Manifest v3, especially while the standard and availability remain immature, will be a significant and important challenge.
• Developing Hydrilla as secure and robust server software that can continue working even under high load.
• Ensuring all functions of Hachette work properly under all supported platforms.
• Testing javascript code that runs inside browser and uses a lot of browser APIs.

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?

End-users, particularly those with a technical inclination, will be recruited through outreach efforts in fora and locations generally sympathetic to the ideals of a free and open web. They are critical as a community to both support and expand this project and create leverage for the repository to drive change in web design practices.

Support from web developers and website owners is critical for long-term success in changing the web, as they collectively engineer its contents. Any who want our help in ethically (re)designing their creations will be offered as much support as physically possible; however, to break new ground among this group, it is expected that the leverage a strong community and influence over the repository afford will be needed.

Contributors to fill the repository and/or work on the browser extension and infrastructure obviously play an important role in attracting new users and building leverage for the movement. At least while scripts are the primary offering, sufficient capacity for this should be available among the technically knowledgeable user base just as it currently is. Further effort and experience will be sought through GNU, and appropriate organizations for other types of customization as they are added.

Thematic call¶

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

Attachments¶

• Wojtek's CV
• Nick's resume (pending permission)
• A short PDF with screenshots of sites broken by disabling JS and their versions fixed using Hachette.
• Tasks list (copied from the relevant section of the application draft above)

TODO: drop 1 of these or put both resumes in a single file - there seems to be a limit of 3 attachments

[Suggested solution- drop Nick's resume if he doesn't reply with permission before submission, and the tasks list otherwise- they'll probably ask about it]