I remember when people who ran web sites would ask me "How can I keep people on my site?" and I'd say "You can't. The very nature of the web is an ever expanding universe meant to be explored. People will leave your site, but if you want them to return you need to provide reasons for them to return, not just try to lock them in."
Many yearn for the "good old days" of the web. We could have those good old days back — or something even better — and if anything, it would be easier now than it ever was.
If you've ever found yourself missing the "good old days" of the #web, what is it that you miss? (Interpret "it" broadly: specific websites? types of activities? feelings? etc.) And approximately when were those good old days?
No wrong answers — I'm working on an article and wanted to get some outside thoughts.
@molly0xfff 1995-2005. There was a quirky Internet before that, but the #web everybody knows really blossomed in that era. Decentralized. Quirky. I was safe to say what you wanted (without worrying about people doxxing you). It was easy to create something with a minimum of HTML. Geocities was pretty bare bones and easy for people to figure out and make things. Early blogs. No walled digital gardens.
@molly0xfff
I started scrolling through the comments and was struck by how many conflate #web with #Internet. I suppose what I miss is that many who only know the Internet via the Web fail to understand they are NOT the same thing.
@molly0xfff Vast choice of millions of quirky small tiny websites, including, but not limited to, blogs, "check out my hobby", movie websites. All that personal expression that was not funneled into the same three websites' allowed formats.
@molly0xfff I miss telnet BBSes, mostly. But for #web things, I miss ephemeral sites like the Trojan Room Coffee Pot or FogCam. Nando.net was good, and Yahoo was fun when it felt like you were just clicking through a digitized Yellow Pages book.
> "If you've ever found yourself missing the "good old days" of the #web, what is it that you miss?"
@molly0xfff I like how simple and home-made everything was, but also how new and exciting it all was. Everyone felt like the web was something truly revolutionary and world changing, and we were participating in it all together.
So many people tried making their own homepages, and these were all like scrapbooks. People would post about what they liked, or what they knew about, or their hobbies, or they would make up memes, and they would share other peoples work just by linking to them, or sometimes just copying and pasting to their own website. People learned how to write basic markup in HTML from online tutorials and by looking at other websites. Some people would use web page editors by Netscape or Adobe.
And there were so many small companies out there trying to make money on new web based technology, but this was before JavaScript was the all-powerful language of the web. Sometimes they used Java, sometimes Adobe Flash, sometimes Macromedia Shockwave. No one knew what, if any, of these technologies would become the one that would become dominant, it was all up for grabs.
Before folks worried about cyberstalking (stalking but with bits). Hackers stealing your money. Identity thieves. Surveillance. Naughty bits. Being caught seeing naughty bits. Privacy to chat with friends without conversations being public. Disinformation. Advertising. Internet/social addiction. Cyberwarfare. Election interference. Ransomware. I experience today's #web through insecurity and anxiety and ad overload. I miss the awkward relatively quiet net of olde.
I've just started using limitless.ai. I find the experience pretty set-and-forget and I love it. For my meetings, I can focus on the person, not worrying about note taking. Better yet, in addition to the transcript are notes and a summary. Still testing it out but interesting.
Better yet, it's web based! So I can use it from nearly any device. This means so much to me. Ultimately, I'd prefer this tech to be local, but unlike others, I'm not knee jerk against cloud services. #UX#LLM#Web
"While more of the #web is becoming accessible to people with low-end connections, more of the web is becoming inaccessible to people with low-end devices even if they have high-end connections."
freeCodeCamp
freeCodeCamp's open-source mobile app
freeCodeCamp.org is an online learning platform offering a comprehensive curriculum in #web development and machine learning. The curriculum is self-paced and available free of charge. The App includes challenges, tutorials, Code Radio, and podcasts.
Contribute to freeCodeCamp: https://contribute.freecodecamp.org/
Adobe Magneto: una pericolosa minaccia RCE per i siti di e-commerce
Gli specialisti di Sicurezza Informatica hanno avvertito che gli #hacker stanno già sfruttando una nuova #vulnerabilità in #Magento (CVE-2024-20720) e l'utilizzatore per implementare una #backdoor persistente sui siti di e-commerce.
Can’t believe it’s been 16 years since I organised the world’s first virtual web conference (it was called <head>, it took place over 3 days, had 4 simultaneous tracks, over 70 speakers, and local in-world conference hubs in London, Manchester, Brigthon, Fribourg, and San Francisco, as well as as pre-conference party and a separate virtual hub in Second Life).
My current take on the #xz situation, not having read the actual source backdoor commits yet (thanks a lot #Github for hiding the evidence at this point...) besides reading what others have written about it (cf. https://boehs.org/node/everything-i-know-about-the-xz-backdoor for a good timeline):
This is going to be an excellent teaching example for advanced supply chain attacks that I will definitely be using in the future - after much more in-depth analysis.
It seems to have been a long game, executed with an impressive sequence of steps and preparation, including e.g. disabling OSSFuzz checks for the particular code path and pressuring the original maintainer into accepting the (malicious) contributions.
Given the luck involved in this case, we need to assume a number of other, currently unknown supply chain backdoors that were successfully deployed with comparable sophistication and are probably active in the field.
Safe(r) languages like #rustlang for such central library dependencies would maybe (really big maybe) have made it a bit harder to push a backdoor like this because - if and only if the safety features are used idiomatically in an open source project - reasonably looking code is (a bit?) more limited in the sneaky behavior it could include. We should still very much use those languages over C/C++ for infrastructure code because the much larger class of unintentional bugs is significantly mitigated, but I believe (without data to back it up) that even such "bugdoor" type changes will be harder to execute. However, given the sophistication in this case, it may not have helped at all. The attacker(s) have shown to be clever enough.
Sandboxing library code may have helped - as the attacker(s) explicitly disabled e.g. landlock, that might already have had some impact. We should create better tooling to make it much easier to link to infrastructure libraries in a sandboxed way (although that will have performance implications in many cases).
Automatic reproducible builds verification would have mitigated this particular vector of backdoor distribution, and the Debian team seems to be using the reproducibility advances of the last decade to verify/rebuild the build servers. We should build library and infrastructure code in a fully reproducible manner and automatically verify it, e.g. with added transparency logs for both source and binary artefacts. In general, it does however not prevent this kind of supply chain attack that directly targets source code at the "leaf" projects in Git commits.
Verifying the real-life identity of contributors to open source projects is hard and a difficult trade-off. Something similar to the #Debian#OpenPGP#web-of-trust would potentially have mitigated this style of attack somewhat, but with a different trade-off. We might have to think much harder about trust in individual accounts, and for some projects requiring a link to a real-world country-issued ID document may be the right balance (for others it wouldn't work). That is neither an easy nor a quick path, though. Also note that sophisticated nation state attackers will probably not have a problem procuring "good" fake IDs. It might still raise the bar, though.
What happened here seems clearly criminal - at least under my IANAL naive understanding of EU criminal law. There was clear intent to cause harm, and that makes the specific method less important. The legal system should also be able to help in mitigating supply chain attacks; not in preventing them, but in making them more costly if attackers can be tracked down (this is difficult in itself, see point 8) and face risk of punishment after the fact.