Haketilo

I think it's a great idea! If we try and get as many browsers as possible too, and perhaps write some more (quick and dirty) fixes of various kinds, that might help get the point across even better.

That works really well!

Unforeseen circumstances meant I haven't done much on this so far, unfortunately; however, I will take some screenshots tomorrow and send them through. I also have a few ideas for interface fixes and a fix for nasa.gov in the works, which I'll include if they can be completed fast enough.

That works really well!

Surprising, isn't it?

One would expect that Google's CSP rule from http-equiv tag would be blocking our injected script - but it doesn't. And from your response it seems this is true not only for UC but also for TorBrowser

I started composing this attachment as a PDF. I will need to work on the styling, though (or you can do this if you want)

https://koszko.org/hachette-show-off.tar.xz

Those are looking good- nevertheless, I'll probably leave styling to you, seeing as I am terrible at it! File attachment here seems to be timing out for me, so I will e-mail through all what I've got; while it might not be necessary, these are two purely interface fixes and some on LibreWolf.

File attachment here seems to be timing out for me

Probably not really the matter of time. Apache log:

[Fri Jul 30 10:07:07.288392 2021] [fcgid:warn] [pid 29218:tid 139757363361536] [client <hidden by koszko>] mod_fcgid: HTTP request length 137856 (so far) exceeds MaxRequestLen (131072), referer: https://hachettebugs.koszko.org/issues/68/edit
[Fri Jul 30 10:07:28.479643 2021] [fcgid:warn] [pid 29217:tid 139757329790720] [client <hidden by koszko>] mod_fcgid: HTTP request length 137857 (so far) exceeds MaxRequestLen (131072), referer: https://hachettebugs.koszko.org/issues/68/edit
[Fri Jul 30 10:09:10.771009 2021] [fcgid:warn] [pid 29218:tid 139757422110464] [client <hidden by koszko>] mod_fcgid: HTTP request length 137857 (so far) exceeds MaxRequestLen (131072), referer: https://hachettebugs.koszko.org/issues/68/edit

I had the same issue when uploading tarball with screenshots. It's clearly a matter of web server configuration, but that's not a priority for me, so we can stick to alternative methods for now.

Thank you for these :)

What do you think of the pdf in its current form?

https://koszko.org/preview.pdf

EDIT: Also, I put all the fixes in a git repo: https://git.koszko.org/hachette_fixes_tmp

What do you think of the pdf in its current form?

It genuinely looks amazing, and the summaries are really effective!

There are only really two small changes I can suggest, which I can make if you want assuming you have the source code somewhere (LaTeX?):

• Perhaps note somewhere that the fixes are in https://git.koszko.org/hachette_fixes_tmp, just in case they want to test.
• Artificial page breaks might help in some places to stop paragraphs/sections being broken across lines.

(Typos aren't really an issue; while I'm happy to proofread if you want, nothing is really noticeable or impedes meaning.)

There are only really two small changes I can suggest, which I can make if you want

Go on with all you suggested. It's once again https://koszko.org/hachette-show-off.tar.xz

One would expect that Google's CSP rule from http-equiv tag would be blocking our injected script - but it doesn't.

Are you sure it's not ours?

Probably not really the matter of time. Apache log: [snip]

Ah, that makes sense. At least now we know for future :).

I had the same issue when uploading tarball with screenshots. It's clearly a matter of web server configuration, but that's not a priority for me, so we can stick to alternative methods for now.

Agreed; there's unlikely to be many occasions that require uploading 4MB tarballs anyway.

One would expect that Google's CSP rule from http-equiv tag would be blocking our injected script - but it doesn't.

Are you sure it's not ours?

Now that I check - it must have been. Although I remember considering it and deciding it's not, based on it looking different from what I expected... Anyway, must have been a mistake of mine 🤦

Making losedows phone exchange the main stackexchange example, and then using ask ubuntu to show how Hachette can easily be used to apply the same fix on different domains (would that need a settings screenshot too?).

I don't think this is needed.

How do you think - should I try to include the Odysee fix in the preview in case I finish it today?

I don't think this is needed.

OK- I've stripped that out entirely and just left the ask ubuntu (is that what you meant?).

No, it's not what I meant :D
I was referring to "would that need a settings screenshot too". I meant an additional settings screenshot is not needed.
But perhaps leaving it with just `Ask Ubuntu' is not a bad idea? We could just leave a short notice that this also works for other *.stackexchange sites. Seems NLnet appreciates brevity (and this is also why I asked about Odysee fix).

Btw, I noticed my Mozilla browsers crash on every attempt to play a video. This happens regardless of whether Hachette is on. They are both outdated, though. Could you please test the partial Odysee fix with with TBB and LeW? See if you can view the video at https://odysee.com/@osiixy:4/Big-Buck-Bunny-60fps-4K---Official-Blender-Foundation-Short-Film:5

No, it's not what I meant :D
I was referring to "would that need a settings screenshot too". I meant an additional settings screenshot is not needed.
But perhaps leaving it with just `Ask Ubuntu' is not a bad idea? We could just leave a short notice that this also works for other *.stackexchange sites. Seems NLnet appreciates brevity (and this is also why I asked about Odysee fix).

Ohhh- I'll revert this now, lest we resubmit (if we still have time it's not a bad idea!)- it's just a picture, which they can skip if they want.

I still think Odyssey is a good idea, as it's a "complex" API-based fix by the looks of it. That's something we don't really have otherwise, and proves this isn't just another userscript manager.

Btw, I noticed my Mozilla browsers crash on every attempt to play a video. This happens regardless of whether Hachette is on. They are both outdated, though. Could you please test the partial Odysee fix with with TBB and LeW? See if you can view the video at https://odysee.com/@osiixy:4/Big-Buck-Bunny-60fps-4K---Official-Blender-Foundation-Short-Film:5

I'll do this right now.

I'll do this right now.

No need to hurry - I already have a screenshot sufficient for the preview.

I would be entertained if it turned out the crashes are related to ARM. Or to running in a chroot :)

You did it- it works! Technically the video never actually played on TBB, given how painfully slow the network is, yet the fact that it was loading and one frame did actually show up seems sufficient evidence.

I would be entertained if it turned out the crashes are related to ARM. Or to running in a chroot :)

If it is, please share ;).

You did it- it works!

In case you want to devote some time to improve this fix, here[1] is one video page that doesn't work. I assume it is because of unicode emojis in video name. The link is correct - I generated it using both the original app and my own search interface.

Oh, and- while it's definitely not relevant for the preview- I'm working on pcspecialist.co.uk.

Great! I think it is now more relevant than improving Odysee (which we will do later anyway).

And thanks for re-uploading the tex file. I already pdftk'd the resumes into one. Re-submitting

[1] https://odysee.com/@EvelynJoy:4/funny-bunny-%F0%9F%90%B0-%F0%9F%92%97:f

In case you want to devote some time to improve this fix, here[1] is one video page that doesn't work. I assume it is because of unicode emojis in video name.

If only- it seems for some reason Odyssey isn't embedding the schema in that page, which means there's nothing to parse the link from. They must be using a distinct API to load the videos.

They must be using a distinct API to load the videos.

Anyway, we only need video name and the first hex digit of its claim id to construct the stream url. We can extract those from page url. For the bunny example, the video url would be:
https://cdn.lbryplayer.xyz/content/claims/funny-bunny-%F0%9F%90%B0-%F0%9F%92%97/f/stream

Also, in my fix, when jsonrpc request is made, a list of lbry urls containing video names and claim id's gets sent to the API server. It turns out the claim id can in such case be replaced with just its first hex digit and it still works. With name and claim id's first digit extracted from the url, we can actually use the very same jsonrpc api to fetch the missing video details like title, description and upload date

Correct assumption [that I'm working on Odyssey]. I should've stated that explicitly

That's OK- it would have been a good learning experience anyway!

have instead been trying to make sure the layout "fix" for stallman.org does actually help with accessibility, as well as extending it to NASA.
What do you mean by "extending it to NASA"?

That was objectively horrible wording- sorry! I meant creating a fix for nasa.gov (which doesn't render without JS), using the layout constructor that builds the stallman.org and abc.net.au alternative interfaces.