This has been their policy but now it's more explicitly defined. Go look through the submissions on https://github.com/flathub/flathub/pulls?q=is%3Apr to understand how bad the problem they are dealing with is.
It's weird because I am sure that a large number of established apps in flathub, such as.. Chromium https://flathub.org/en/apps/org.chromium.Chromium has AI-assisted code, and this bans all AI-assisted code
The policy as it stands is contradictory with flathub practice, unless it specifies that already accepted apps are grandfathered or something like that.
After some time it's looking like AI is becoming just another tool in the developer toolbox. So we can confidently say that, over time, only projects with specific anti-AI policies will be free of AI code (and actually, even such projects I'm not sure)
So it's basically a ban on most new projects, made by inexperienced developers. Which is okay I guess, if this means they can better review projects.
Nice. But unfortunately these addresses are hard to remember and "nobody" recognizes them when reading examples. One of those "standards" that have been a great idea, but lack practical relevance.
> But unfortunately these addresses are hard to remember and "nobody" recognizes them when reading examples.
How does that matter? The point isn't that the reader should know that "oh, this is a reserved address". The point is that there should be no room for the address that's actually being used by someone to end up being used incorrectly just because it showed up in some random documentation.
Much like how you probably wouldn't be thrilled if your phone number was used as an example in some random documentation somewhere.
> But unfortunately these addresses are hard to remember and "nobody" recognizes them when reading examples.
Mmm.
It's pretty easy to put three IPv4 /24s on a sticky note on your monitor. I think it's not unfair to say that if one can remember every fact related to one's job, then one has a job with a very, very small scope.
Also, this is another great reason to use IPv6. The v6 documentation prefix is '2001:db8::/32'... plenty of space for example subnets and easy to remember.
For me it's the opposite: I usually misremember 192.0.0.0/8 as being entirely private, so for 192.0.2.0/32, I usually assume that the example given is supposed to be a private v4 address/network.
Anyone who writes technical documentation about networking knows the key ranges, and at least TEST-NET-1 (192.0.2/24) is pretty easy to remember. You only gotta look it up a few times, instead of being sloppy and justifying so with “no one cares anyway”.
It partly because attitudes like that is why software is a mess. Too few people care about correct semantics, everyone is satisfied with whatever sticks. From lists for sets, to tag soup instead of markup, and so on - all the way to modern code slop.
Without justifying it, the reason is simple. They are using a front end framework (bootstrap) that many developers use/understand that also supports 99.9% of browsers.
Running a browser without javascript that you still want graphics to display (so not a screenreader or text-based-browser), is part of the .1% they are willing to disappoint.
Do I think it is overkill? Sure. Do I still use jQuery at work even though the vast majority of its once handy features are now baked into JS in the browser by default? Of course.
How do you jump straight from JS to screen reader or text based browser? What happened to HTML+CSS viewer? Isn't reading an RFC the perfect poster child for an activity that ought to consist of viewing a noninteractive document?
It’ll be a run-on effect of whatever framework they are using, and they very justifiably don’t want to bother catering to you. Having JS disabled in 2026 and complaining about sites not behaving is simply a performative act.
2015: It's a SPA blog because my employer forced me to do it that way, I didn't want it.
2026: It's a SPA blog because I very justifiably don't want to bother catering to you. Having JS disabled in 2026 and complaining about sites not behaving is simply a performative act.
Even then, they're using disallow lists. If you go on a random web page with novel JS, then that'll still be run.
The only people working of allow lists are the people running NoScript and the like, and those truly aren't running random JS. But those people are a rounding error compared to the greater internet.
>and they very justifiably don’t want to bother catering to you
Considering they are one of the very few sites and VPNs that allow sign up without JS your claim is verifiably false. They also collaborate with and develop there own tor browser fork which has the highest rate of non JS user.
What "buttons icons"? When I set the "javascript.enabled" preference in Firefox 151 to "false" and reload the page for RFC 5737, I get a "Javascript disabled? Blah blah blah blah." complaint near the top of the page. I do not get
* the useless-to-me "document history" bar graph at the top
* the automatic switch to Dark Mode(TM) that I don't care about
* functional pull down menus at the very tippy top of the page that are entirely unrelated to RFCs that I give zero shits about
The "without javascript" version of the page seems to me to be otherwise identical. Amusingly, the "Email authors", "IPR", & etc buttons switch to the pages they reference notably faster with Javascript disabled.
What broken things were you seeing that I haven't mentioned? Were you using Chrom(e|ium)? Safari?
> I set the "javascript.enabled" preference in Firefox 151 to "false" and reload the page
Do it the other way around - disable javascript first, clear cache/open incognito (maybe close/open browser after that just for good measure), then go to the page.
If you load it with javascript first - buttons icons stay loaded after you disable it.
The only thing that I don't do in Firefox's "Private Browsing" mode is play a handful of stupid little in-browser games that save progress in a cookie or whatever. I even have Firefox set up to open in "Private Browsing" by default. Here's what I did just now:
1) Quit Firefox
2) Opened Firefox
3) Visited 'about:config'
4) Set 'javascript.enabled' to 'false'
5) Quit Firefox
6) Opened Firefox
7) Re-visited 'about:config' and verified that 'javascript.enabled' is still set to 'false'
It's still exactly like I reported it was. The "Manage browsing data" thing accessed through Firefox's regular settings dialog doesn't indicate that there is any data saved by any ietf.org subdomain, and when I watch the Network pane, a ctrl+shift+f5 reload of the RFC5737 page indicates that the page loads everything from an ietf.org subdomain... so the saved resources from one of the like eight domains in that list aren't relevant.
I checked more closely and here is what appears to be missing:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://static.ietf.org/dt/12.65.2/ietf/bootstrap-icons.5b9cac4e.woff. (Reason: CORS request did not succeed). Status code: (null).
Bootstrap icons.
Block javascript - icons won't load.
Allow javascript - icons load.
Block javascript again - icons load, unless tab is closed and then opened again.
This behavior has been observed previously.
I tried to selectively block css to see how it's tied to javascript.
Block javascript, block css from static.ietf.org - icons won't load, page layout is broken.
Allow javascript, block css from static.ietf.org - the icons won't load, layout is fine.
Evidently, with javascript blocked, layout css loads fine, but bootstrap icons only able to load when javascript is not blocked.
'javascript.enabled' setting seem to has no effect on icons. However, unlike NoScript, it does not provide any domain separation/granularity.
Yesterday I was renewing my vehicle registration through my US states website. They offered a range of payment options using embedded options on the site. The direct bank account option had the lowest fee but when I tried it I was immediately scared of the security. They used a 3rd party bank account transfer provider that asked me what bank I used and looked like it was going to prompt me for my login info before it errored out and I moved on.
Why can't the US have sane banking standards instead of this mess where you have to agree to a new 3rd party TOS and EULA for every purchase you want to make.
US should have sane transfers soon. The Federal Reserve developed FedNow which is instant bank transfers. It is more secure than ACH since it only does pushes and requests.
It takes time for banks to implement it. There is also conflict with Zelle that some banks developed. I don't think it is meant for buying things, but secure and fast replacement for ACH would be good enough.
What you see is a glued or patchwork to make the things work somehow with the existing state of things. Strictly speaking, a lot of banks do not offer API support and yet these third party tools are able to orchestrate a flow with is nothing less than man-in-the-middle-attack.
The change if it happens at all, across the board to streamline can only from from government mandate. The industry is always going to go for finding some low cost option to achieve the target. The private players are always going to optimize for short term gains.
When using a government website, you were intimidated by the security posture of... Plaid? (Genuine question, maybe this was some other provider but Plaid's aggregator tool is the most common place I see this pop up in real life for ACH)
I personally have _no idea_ what the security posture of plaid is. I know they're a startup and made a bit of noise a few years ago, but if I was trying to buy something and a third party app popped up saying, "hey give me total access to withdraw directly from your bank account for a sec", why on earth would I say yes to that?
It also seems to go against common security advice. "Never log into your back account if redirected by a website you sort of, but don't really trust, except sometimes its alright and it's up to you to tell the difference" is a terrible way to secure banking.
In fairness they redirect you to your bank to login, you authorize the application (which can be revoked at any time), and then they redirect you back with tokenized information. (In fact it's kind of a pain point that when I use Plaid to link my bank for eg reimbursement deposits from my FSA/HSA, it has tokenized the account numbers so I can't actually tell which account is which.) I guess I get for less savvy users why that might look scary but the alternative is... keying your account number directly into a merchant's system for ACH, which is actually scary (and the default on many government websites which I actually trust less!)
Nowadays Plaid uses OAuth for many banks, but the real problem is and always has been that they get full access to your transaction data and pass it on to their users.
If any site asks me for my bank login credentials, I run far away and start checking if I've made any security mistakes. So far Paypal is the only credentials I'll enter after a redirect.
I went back and checked. It was not Plaid but Trustly. I've never heard of either before but Trustly's name makes me want to trust it even less than Plaid. And I'm more concerned about all of my personal information such as my transaction history for the past 90 days being siphoned up by yet another commercial entity that can probably profit more from it than the transaction fee they would have collected.
What products? Cisco hasn't built a product in decades, they only acquire companies and throw their name in front of the existing product. Do they mean they will only be purchasing AI built products by the end of 2027?
20 some years ago when cable broadband was new, you connected a computer and got public IP. For this example let's just assume it was a public/24. Back then there was no firewall built into Windows, it didn't ask you if you were connecting to a public or private network.
For some ISPs you could connect a switch or hub (they still existed with cable came out, 1gbps switches were expensive) and connect multiple computers and they would all get different public IPs.
Back then a lot of network applications like windows filesharing heavily used the local subnet broadcast IP to announce themselves to other local computers on the network. Yes this meant when you opened up windows file sharing you might see the share from Dave's computer across town. I don't recall if the hidden always on shares like $c where widely know about at this time.
ISPs fixed this by blocking most of the traffic to and from the subnet broadcast address at the modem/headend level but for some time after I could still run a packet capture and see all the ARP packets and some other broadcasts from other models on my node, but it wasn't enough to be able to interfere with them anymore.
I understand this aspect, and this conversation is tricky because most consumer routers have this barebones firewall built in to reject the routing mentioned by the OP. So what we think of as a "router doing nat" often is subtly doing more. I'd hate to call what a barebones consumer router is doing a firewall because there are important firewall features that it does not have that are necessary for security.
Yes. Every clone of this idea does the same thing and a new one pops up every week. When I try to point out that the secrets should be exposed through file namespaces instead of ENV vars, the amount of hostility is shocking.
Honestly I was expecting more. There are many languages that support Unicode in variable or function names and I expected it to be used there.
It sounds like Python only allows approved Unicode characters to start a variable name but if it allowed any you could do something like `nonprintable = lambda x: insert exploit code here`. If that was hidden in what looked like a blank line between other additions would you catch it?
I'm sure there's some other language out there that has similar syntax and lax Unicode rules this could be used in.
The solution is that this and many other Unicode formatting characters should be ignored and converted to a visible indicator in all code views when you expect plain text.
Yes, I am very familiar with zbarimg and qrencode. But, other people might not be, and that's why just scanning a QR code works. Not everyone has Bitwarden, 1Password, Pass, keepass, etc.... also these tools may not be approved by your security teams.
And we are talking about the root account for your production AWS account. No need to get fancy. Just print the QR code, and put it in a safe hoping you never need it.
reply