girst

I strongly suspect that this book is little more than LLM output, based both on the writing itself and the existence of https://github.com/AdrianMastronardi/bookwright. I find it despicable that the "author" did not disclose this.

> Using LegacyFox means I have to build/make it after every update of Firefox, right?

Nope! Installing once is enough.

As long as you're upgrading in-place (which you probably do), it will stay persistent, since Legacyfox doesn't overwrite files provided by Firefox.

Hi, I'm the maintainer/"janitor keeping the lights on" for VimFx. It still works on up-to-date Firefox versions, as long as you copy a litte bit of javascript in Firefox' install directory[1].

> Vimium these days does not work when a page hasn't finished loading and it doesn't work on blank pages (about:blank) or any other "system page"

This is the single thing that makes the (current) Webextension framework unusable for such extensions, and the reason I keep working on VimFx.

[1]: https://git.gir.st/LegacyFox.git

>It does contain a bit more information than required, such as the specifics of the vaccine.

between eu member states, the acceptance of e.g. sputnik-v (the russian corona vaccine) varies. having the name (or id) of the vaccine in the code allows countries who don't recognize a given vaccine to validate codes issued by other eu nations, who are more open to such a vaccine. (what a horriblly worded sentence, i hope you get what i'm trying to say)

well, i've written that code quite hastily, and mostly for my own need. i'd guess, the most likely cause would be a missing libzbar.

the juicy bits seem to be here: https://github.com/ehn-dcc-development

First, the music itself wasn't written by me, but by Rob Miles[1]. So I had a version in C available. I then iteratively transformed the code into simpler and simpler expressions, and finally into a simulated assembly language, written as C macros[2]. Only the final step, initializing peripherals, stetting up interrupt handlers, etc was done with the actual chips. Of course, I made some erros with the before mentioned C macros, so some final debugging was trial-and-error. Later on I also used simulators, but they don't support all the necessary features of the MCUs, or were outright broken[3] (patches now upstream).

[1]: http://txti.es/bitshiftvariationsincminor

[2]: https://git.gir.st/Chiptunes-pms150c.git/blob/f1b013452400b0...

[3]: https://sourceforge.net/p/sdcc/patches/379/

Hi, author here. What a nice surprise to see my project turn up here :)

If you have any questions, shoot!

Happy Holidays, HN!

Serles-ACME is a small (1300 LoC) Python ACME server that you can hook up to your existing PKI. We have written an adaptor for the Free-as-in-Freedom and Free-as-in-Beer EJBCA Community Edition, or you can write one for your PKI in about 10-20 lines (patches/pulls very welcome).

We are DVTirol[1], the IT provider for the federal government of the state of Tyrol, Austria, and have developed this tool for our internal use, and have been running it for some time now for our servers. And given that the existing solutions are prohibitively expensive[2] or not available[3] at all, we decided to make the source available for you to profit from it, too!

The documentation, including setup instructions for Serles-ACME and EJBCA, live at https://serles-acme.readthedocs.io/ . We intend to provide a CI/CD pipline for unit testing and pypi-publishing[4] after the holidays (unit test coverage is already at 100%), so stay tuned for that.

Who this is for:

- You want to build up you own PKI, either for company or home use

- You want to automate the issuing process for all your devices/servers

- You already using another PKI Software and want to use certbot with it

Please let us know if you're using it, or contribute backend adaptors for your PKI!

[1]: https://dvt.at

[2]: e.g. EJBCA Enterprise: "if you have to ask, you can't afford it"

[3]: smallstep's ACME is still in early access, and no pricing either

[4]: https://pypi.org/project/serles-acme/

given that the outage affects redirector.googlevideo.com and youtube.com/get_video_info, but as you say, not the f3---<something>.googlevideo.com domains serving the actual streams, i suspect they have problems with the database storing where streams are actually hosted.

and now youtube.com/get_video_info, the undocumented endpoint for querying (among other things) streaming urls, is broken as well. returns "Video ID is invalid." or "An error occurred. Please try again later."

yep. thinking it over, that makes more sense. amended my comment

doing a `curl -v https://redirector.googlevideo.com` (the host you'll connect to before getting redirected to the actual mp4/m4a streams) opens a tls connection (and gives a cert), but it then hangs for two minutes, before returning a 502.

i'd wager some database storing info about the streams crashed :^D (given that it also crashes on /, it's more likely something else)

Regarding Fedora's Firefox: The Fedora Firefox mainainers, Martin Stransky and Jan Horak, are also the main maintainers of the Linux/GTK parts of Firefox. The VAAPI patches you've mentioned are (afair) mostly-if-not-all Martin's work. So he's not applying some rando's "untested" patches.

Just pouring some salt into your wounds: this video <https://youtu.be/RBL1cVzIQik> is over nine years old :^)

(I don't think it's exactly the same, but at least similar)

wow, that's as simple as it is genius.

the core of the hack is the realisation that one can generate arbitrary tcp or udp packets from a browser by exploiting ip packet fragmentation (embed the evil packet in a large http post request that gets fragmented at just the right place).

and worst of all: i don't see a quick way to mitigate this. afaict, router firmware will need to be updated to check the fragment offset, right?

The plan you've described is exactly what https://jshint.com/relicensing-2020/ did.

ETA: discussed here, with a more in-depth link: https://news.ycombinator.com/item?id=24051655

It has really annoyed me that CircleCI thinks it's a good idea to force you to connect your Github account to see CI output. I wrote this addon so I can contribute PRs to projects that use this CI provider without divulging personal data to them.

So yeah; this addon is extremely tiny. But that just further shows how their login wall is pure "growth hacking" BS.

If someone wants to upload this addon to google chrome, please do (I'll put a link on the AMO page)!

Or they can lull you into a false sense of security. (which is the reason chrom{e,ium} has removed their XSS auditor)

Cloudflare's and all other "Webapp Firewalls" are just snake oil. They can't know what transformations are done server-side on untrusted input, so you'll always (with enough time and determination) be able to craft a string that passes the WAF but exploits the backend.

Just a few examples: https://github.com/frizb/Bypassing-Web-Application-Firewalls

In a 1000 years people will surely benefit from the millions of copy-pasted dotfiles :^)

wow--impressive!

the core is here (https://github.com/lhoursquentin/sed-bin/blob/master/par.sed), and it's 600 lines of beautifully commented sed

well, compared to undisclosed affiliate marketing for trading sites[1], soliciting of donations without consent[2] or the recent redirection through affiliate links[3], this seems pretty tame.

[1]: https://github.com/brave/brave-browser/issues/8793

[2]: https://davidgerard.co.uk/blockchain/2019/01/13/brave-web-br...

[3]: https://news.ycombinator.com/item?id=23442027

>because the existing implementation was too mature.

That's not what I gathered from their official response to the deprecation[1]. But the major problem with WebSQL for Mozilla seems to be this:

>We don’t think it is the right basis for an API exposed to general web content, not least of all because there isn’t a credible, widely accepted standard that subsets SQL in a useful way. Additionally, we don’t want changes to SQLite to affect the web later

edit: and once again: security might have been a deciding factor, too[2].

[1]: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...

[2]: https://news.ycombinator.com/item?id=18685296

nearly all of those APIs are also considered 'harmful' by Mozilla[1]. Some have even been disabled after implementation because of this[2]. These were developed by Google for Chrome OS, and besides the privacy issues, they substantially increase attack surface for security vulnerabilities.

[1]: https://mozilla.github.io/standards-positions/

[2]: https://developer.mozilla.org/en-US/docs/Web/API/Battery_Sta...

Do not keep it transparent! The Gimp for example keeps the underlying colour data, and just sets the opacity to 0.

this bug (closed as Expected Behavior) has a demonstration: https://gitlab.gnome.org/GNOME/gimp/-/issues/4487

Note that a browser firewall like uBlock Origin with EasyPrivacy (easylist.to) already blocks this: https://imgur.com/s7efEez.png

deldo.el has come a long way since 2009!

https://github.com/qdot/deldo http://www.youtube.com/watch?v=D1sXuHnf_lo

Are these results surprising? Probably not. But does that mean we shouldn't talk about them? Because that's what (a portion of) this comment section seems to think.

> Since my adblocker is blocking the guce.advertising.com domain, I guess I don't get to visit TechCrunch.

Same here. I usually 'proxy' through the Internet Archive in these situations: https://web.archive.org/web/20200213123006/https://techcrunc...