gynvael

What you're saying makes sense and it's a good idea. It's not fully directly applicable to Paged Out! though due to certain assumptions we've made with our base operating model.

I.e. our intention is to charge readers neither for PDF nor for print, to the extent that is possible. In case of print-on-demand or print-subscription that of course won't be possible, but at various events we're successfully bringing printed Paged Out! issues to distribute for free. The idea is rather for the zine to finance itself through ad sales, sponsorship editions, and special collector bundled editions. We have a couple of other more-typical ideas as well, like Pateron later on.

Admittedly, so far we're in the red (not terribly though), but that's OK. There are still certain things we need to roll out before being able to evaluate whether we need to change the base operating model. If we do have to change it, it's not unlikely to start with ideas like the one you proposed - they do make sense.

Thanks! I pre-approved it today, so you probably already received a reply from our Editor-in-Chief :)

Yeah, we need to onboard more Print-on-Demand providers - perhaps some with easier purchase flow (this said, I have to give it to lulu that they have solid customer support, at least in my experience).

But - per your edit - the PoD option is for folks who either really want a printed Paged Out!, or want to throw some money into the project. This year we got back to finding sponsors to pay for prints to distribute them (for free) on various events - https://pagedout.institute/?page=event-prints.php - and we plan to keep increasing our presence at more events next year. So the "in the right circles" just means "one of these events".

Anyway, whichever way you choose to enjoy Paged Out! - bought, received for free, or just the PDF version - glad to have you with us :)

I mean... you actually can do that... https://pagedout.institute/?page=commercial-prints.php

"If you would like to sell printed copies of Paged Out!, please contact us about a commercial license [...]. We're happy to work both with very small sellers who print and bind Paged Out! at home, [...]"

ETA: Though admittedly I wouldn't count on buying a yacht for money earned this way ;). Our income from "official" (lulu.com) sales are about 30-300 CHF / month, and this is only because a lot of wonderful people want to support us and get the more expensive "sponsorship" editions.

Hi, project lead here :)

I fully agree with you. We are slooowly working towards having also the printed version available in a subscription model (note: PDFs will remain free and we will also continue to give out free - as in "sponsored by [some company or event]" - on conferences / demoscene parties / etc). We still have to do a couple of things first, like:

1. Make sure our prints are consistently of good quality. As we've learnt this year, printing is hard, especially if you have to support multiple different printing companies. We're well on our way with this.

2. Rebuild the older versions to have them print ready - this is required for e.g. ISSN registration which we are working on. As we don't do typical DTP, but rather use a waay more complex process of Python-scripts-processing-incoming-PDFs (perhaps this wasn't my brightest idea, but it has its upsides), this takes a while (mostly because older issues were built using previous build engine and PDFs are hard - our DTP programmer has a lot of horror stories).

3. Well, find a company (or multiple companies) that offers subscriptions and ships worldwide and test them.

So it will still take a bit of time, but we'll get there :)

If you're looking for recommendations for other zines, here are two (though both TXT format):

- https://phrack.org/ - well, this one you probably have heard about ;) (it has a printed form as well, but I think you have to actually find it on an event)

- https://tmpout.sh/ - this one focuses on Linux executables

But if you don't mind older content in amazing artistic forms, do check out old demoscene zines like Hugi: https://www.hugi.scene.org/ (note: these are in form of EXE files - that was pretty typical for scene zines)

Whoops, thanks! We'll fix it in a moment.

Thank you! :)

+1 to this! Paged Out! was inspired by some of the 1980s / early 1990s magazines (though Polish ones, like "Bajtek"). They could get stuff done on 1 page, which commonly was shared by multiple articles too :)

Hi, project lead here :)

Hah, that's a good point! I realize of course issues with PDFs (I have a dozen or so CVEs in PDF readers like Adobe Reader, Chrome, etc). This said, at the end of the day, there isn't much of a choice to be honest.

Admittedly this is because of where I wanted to go with this zine - i.e. make it printable, give authors the freedom to do whatever on the page (and not have to deal with manual DTP), and make it in a format that is widely supported and not limiting (and both PDF readers and writers are abundant).

Realistically if we wanted to go with a format that has 0 attack surface, it would have to be a headerless RGB pixel stream - but that's hardly usable. INB4: txt files have a greater attack surface than headerless RGB pixel streams, even if not by much (see various ANSI escape code problems over the last 4 decades).

P.S. Oh, and let's remember that demoscene/etc zines back in the days were EXEs ;)

Hi, project lead here :)

We do contact potential authors via email, but it's fully manual. I.e. we do not collect emails in an automated way, nor do we send them out in an automated way - everything is done manually by our Editor-in-Chief and, at times, other team members. Furthermore, we take care to only contact a given person once (I was on the receiving end of hakin9's mass author spamming a few years back, so we take care to not do what they did). Admittedly mistakes can happen here if we're unable to determine that it's actually the same person we've already contacted.

We find folks to contact in several ways. One is that someone from the team read/saw something they think is cool on the Internet - then we try to reach out to the author to ask if they are interested to write something / re-make some blog posts in form of 1-page articles (I personally believe there is value in re-surfacing cool stuff). We also look around in typical spaced where folks publish articles or where such articles surface (social media, aggregating sites, etc) and reach out to some of them.

I don't have exact stats, but a lot of articles come just from our Call for Paper, which we post about on our social media.

Hi, project lead here.

If your question is about "was the cover / zine made by AI", the answer is no, but there might be articles about AI or articles polished by AI. The cover is never made by AI - always by human artists.

You can actually read our AI clause here btw - https://pagedout.institute/?page=writing.php#ai-clause - I'll copy paste it:

"""

Here at Paged Out!, we are aware of the growing popularity and use of AI. Thus, here is our stance regarding articles prepared using various kinds of AI.

What's allowed and accepted:

- use of AI when polishing the language or deciding how to rewrite or formulate individual sentences;

- use of AI output in articles about AIs which generated said output or which generate similar output.

What's not allowed and won't be accepted:

- articles that have been partially or fully written or more aptly generated using prompts in AI (like ChatGPT/Bard);

- images generated by AI other than what's mentioned in the "allowed" section.

Cases not covered and borderline cases will be decided on on a case-by-case basis. When in doubt – e-mail us.

"""

Paged Out!'s project lead here. This is really weird... could you tell me which group did you get the email from? If you email me (gynvael@pagedout.institute) your email I can both remove it and try to figure out how your email got there.

Spot on. So here's the problem: initially we wanted to just put the print-ready files on the website. But then — once we got more experience with physical printing — we've learned that it's not so simple, because there are several moving parameters (like bleed sizes, spine sizes, etc).

As such, for now unfortunately you still have to email us with the parameters you need, so we can generate a PDF set for you. But in the future we want to just generate all possible sets and put them out there (all in due time).

Mailed printed subscriptions for a decent price are somewhere on our TODO list. First we want to make it available for free on more events (like conferences, demoparties, etc).

> This is a pretty clear statement on normativity.

I disagree – it's a technical remark on redundancy of fields (this is related to my hypothesis in the article that redundancy in formats is the primary cause of parser discrepancy). It doesn't acknowledge InfoZIP being canonical in any way.

> You also left out an important part of my comment when you quoted it. (The operative word at the front of the sentence is "seems".)

Fair, though my point still stands.

Author here :)

Are you saying that parser discrepancy is a well known problem OR that this exact technical issue described (CD offset vs CD size used to derive CD location) is a well known problem?

If the prior, you are of course right — parser discrepancy and the existence of these kinds of "multiple personality" files isn't a new thing. I'm pretty sure this can be traced back to at least the '80 :)

However, if you mean the latter, I would appreciate a link if you can recall where you've seen it before / read about it — I can then add it to the article.

Author here :)

> a belief by the author of this post that Info-ZIP is the canonical implementation

↑ Where did you get this from?

I don't think nowadays there's such a thing as a canonical implementation — ZIP implementation world is too fragmented and implementations are too widespread.

One more note is that the article isn't about who's right or wrong in terms of interpreting APPNOTE.TXT — this is besides the point. The point there is that a parser discrepancy can cause security issues, and the article documents just another discrepancy found in the real world implementations (and there are A LOT of these with regards to the ZIP format).

I've looked through the method this paper uses to anonymize user IDs and message IDs, I don't think it works. It's a long topic so I've written down my thoughts here: https://hackarcana.com/article/anonymization-in-discord-unve...

Received, thanks!

Hi Philip. Would you be able to share with me just a few anonymized user IDs (random ones are fine)? I wanted to double-check their format, since I'm pretty sure their method is broken. My email address is there → https://gynvael.coldwind.pl/?id=50 (contact section)

The format of Paged Out! – the 1 page limit, the custom layout, are done on purpose. They have their downsides of course – exactly as you have pointed out. It has to be recognized, that so do the no-page limit / strict layout publications (and I am writing this as someone who has been cooperating with several technical magazines as both a reviewer/editor and an author over the last 15 years).

In a typical magazine authors feel the pressure to write long articles about everything, and they don't feel comfortable posting short notes on cute tricks. So Paged Out! is basically meant to fall into this 1-page niche where short notes on cute tricks can find a happy home.

Is this 1-page format limiting? Yes, it is. Can you write everything in this format? No, you can't. And that's OK.

We're not trying to be PoC || GTFO or Phrack (both of which are wonderful btw and I'm a huge fan of both; there's a lot of love flowing in the zine community btw - see e.g. DNS TXT records for pagedout.phrack.org and phrack.pagedout.institute). We just found our own niche of short articles to occupy.

As for the layout chaos – I understand what you mean. At the same time, this is another niche which I put PO! in on purpose. I sometimes joke that PO! is a therapy for me after having to squeeze my idea into the exact layout a publisher wants, or after reviewing too many waaay too long articles for another magazine.

This is to say: I recognize your points and I believe you are right. At the same time I'm pretty happy with this little flawed niche I found and put PO! in.

Two more links about these two points: https://pagedout.institute/?page=faq.php#why-one-page & https://pagedout.institute/?page=faq.php#layout

> It would be good to figure out how many people actually care about printability.

The final goal is to do mass prints of Paged Out! to give out at events. We've already done that once, and we're chatting with sponsors and events about doing more of this. And actually "how can I get a printed issue" is THE most common question we get from readers. So there's interest in a printed version from both sides (readers + our team).

With regards to the HTML idea – it was something I considered as well (and an idea I come back to from time to time). The issues that made me decide against it are:

- Not everyone knows HTML/CSS on a level that would allow them to express what they want. This would downgrade the "creativeness" of layouts. While some typical text processors or WYSIWYG editors can output decent HTML, that's not true across the board.

- Asking authors to do more work (especially to fight with making sure HTML behaves correctly when printing to PDF), would have a negative effect – I a significant chunk of authors would pull out.

- It does solve readability issues for typical text layouts. It doesn't solve them for more creative layouts, especially on mobile phones.

- For better or worse almost every newsletter, blog, news website, etc on the internet uses HTML format. I think I prefer PO! to stay in the magazine category.

Anyway, I'm going to be revisiting this idea from time to time, especially if PO! happens to get more funding for whatever reason.

Yeah. I don't think it's a solvable problem, but ideas are always welcome :)

Sadly that's not doable for us. LaTeX, for all its benefits, has terrible user experience and would drive away a lot of authors. One of the benefits of using PDFs is that anyone can use almost any tool they feel comfortable with to make the article (except for Photoshop - we banned Photoshop PDFs because they are ridiculously constructed). For example, I use Google Slides for my articles (which seems like a weird choice, but it's so easy to do complex one-of formatting in it).

You hit the nail on the had with your question – this is the most problematic part of it.

Most illustrations are a bit simpler to handle than code and the way is pretty much paved by HTML img alt texts (the well written ones, that actually can substitute for the illustration by conveying the same information). Ideally we should receive the ALT texts from article authors, but effectively (for now) it would be up to the person reading to come up with a solid substitution text.

Code is a different can of worms. My favorite idea so far is to basically explain what the code does as close as possible, without actually reading it, and then having a separate audio track with the code being read (likely just by a text-to-speech algorithm, though possibly augmented a bit to include things like "next line" or "this line has a 2-level indent" for Python code).

I don't have an example yet, but let me get back to you on that next week, since I was thinking of doing recordings for my two articles in this issue.

(PO! lead here) You are right, that's one of the unfortunate limitations of the format – having to constantly scroll the PDF. And this is on me, since ultimately I've made some decisions when establishing it which basically boxed us into this format.

I.e. thanks to using a PDF we can give authors full flexibility on how to lay out their article, which allows folks to be really really creative (as you can see in this issue). The obvious problem with that (apart from countless hours foxtrot_charlie - our DTP/PDF programmer - has to spent on fighting with PDF weirdness) is that reading an A4 PDF isn't great for phones, computers screens, or tables. It's even worse if you're using a screen reader, since getting PDFs in the way we get them and making them screen reader compatible is... complicated, to say the least (that's why it's not yet there). On the flip side, everyone has a PDF reader nowadays, articles look everywhere the same (this wouldn't be true for other formats), and it's also printable almost out of the box.

So, pros and cons. At the end of the day I don't think there's an easy out for us without breaking any of the things which make Paged Out! what folks like about it. The things I want to improve is getting printed versions more accessible, and some day finally getting solid screen reader support. But other than that I do believe the scrolling problem with remain with the zine.

ETA: Actually I also want "readings" of articles to become a thing. From the get go we put the in the author's license (note: not all articles use it, but most do) the ability for folks to agree to have their articles be recorded in an audio form. I think that would be cool for folks who like consuming things like audiobooks or podcasts. And it would save us from scrolling (for the cost of having illustrations described instead of seeing them).

Agreed! I've used them for printing a few larger PDFs as well, and the only part which I cringe at usually is the shipping cost (which it's bad, it's just that the print is so cheap there shipping looks pretty significant next to it).

Random story/context: I've actually learnt about lulu from Intel - a decade ago or something, when they stopped shipping Intel Manuals for free to anyone who asked, they redirected people to lulu to get a printed-on-demand copy.

Thanks! I'll pass this to the author.

Out of curiosity I've started looking in Django docs (I'm more of a flask person myself), and they seems to confirm what you're saying. More to the point, the `strings` are the main issue. The default autoescape actually encodes ' and " as HTML entities, but doesn't encode a backslash, so leaving a \ at end of a ' or " string would escape the string ending - this would be exploitable if the attacker controls two strings of the same "type' in a row.

I guess this is the proper way to do it: https://docs.djangoproject.com/en/5.1/ref/templates/builtins...

Thanks! Kudos to the rest of the team and the authors :)