Personally, I think the web/browsers has churned far too much, and if that stopped happening, perhaps we would get more accessible sites and browser diversity as people "stop looking for new dogs and start teaching new tricks to the old ones." Of course, Google would try its hardest to never let that happen, since change is its weapon of monopoly.
May be risking a lot of downvotes, but I really want to work for somewhere that cares about a11y for very selfish reasons - I want to use semantic html and not have to do stupid shit like using a package that re-implements the select element with divs
It's a shame the UI elements built into HTML are so lacking, which I think is what ultimately drives people do things like this.
Look at <select multiple> for example—the browser built-in is borderline unusable. Anything that requires combining a click with the shift and ctrl/cmd keys is not going to go down well with the average user. Same goes for <select>s that need more advanced behaviour like filtering. There's <datalist>, but it's incredibly basic and pretty useless for most cases you'd want that sort of input.
The web is an app platform whether we like it or not, and I'd like to see a robust set of browser-native controls with mechanisms to customise styling and behaviour. It would improve accessibility, improve performance, reduce page sizes (because we wouldn't be re-implementing the whole world in JS), and it would at least go a little way to offsetting the slow erosion of quality desktop software that web technologies are bringing.
The browser select-multiple widget works like that because that's how it's worked in most desktop OSs since Macintosh System 1.0 in 1984 (at least). It's been simple and predictable and easily learned for decades, calling it "borderline unusable" is just hyperbole.
Now, if you wanted to say that HTML's standard widgets should be allowed to reflect the platform-native look-and-feel (for example, adding a "selected" checkbox on touch-screens, or supporting long-press to select items, or whatever) instead of being tied to Windows 95 appearance and behaviour by backwards-compatibility concerns, then yeah, I'd agree with that.
It's "borderline unusable" because the vast majority of people who use computers probably wouldn't know how to select more than one item. There are no affordances and virtually nothing uses it any more.
Even in the early desktop era when it was popular, many non-enthusiasts probably just didn't know how to use a UI control like that. It just didn't cause a problem because most people didn't use computers much.
I would bet that most internet users today have never even used a UI where that control is popular.
Because they’ll only read what they believe is essential to their goal. Small text below a form element does not scream “critical” it doesn’t get read. I’ve watched many users use websites: they only read what they think is important and skip everything else.
Not just naive users either. I am very computer literate and yet I find myself in situations where I've skipped that text and only find it when I go back.
It makes me think when I'm designing things. If I have problems with stuff like that, how can I make it better.
Really, if people read everything they'd never get anything done. They see dozens to hundreds of things marked visually as important that they'll do fine ignoring, every single day. Of course they often miss the one or two per day that they actually needed to read.
Then there's the way styles are so different, especially on the web. Horribly user-hostile. How does this site mark something as important, assuming it bothers in the first place? Who knows. And if I'm only planning to be on it for 30s, I'm not going to learn that.
I guarantee you fewer than 50% of people who use a desktop computer at least once a week know how to multi-select and range-select using shift and ctrl on them, though. That's why you need the text—which many will, for reasons that are actually pretty good, ignore.
It is standard but it is not used often. In fact, I can’t remember the last time I saw one used that want some ancient, intranet application built on Cold Fusion.
Many users don’t even know you can use a key shortcut to copy/paste.
No, we should stop dumbing down UIs to the lowest common denominator because that's how you get user-hostile software that treats users like sheep to be herded and monetised.
The less you encourage learning and self-improvement, the less it will happen.
You get user hostile software that treats people as sheep to be herded and monetised because of the capitalisation of software, not because designers are making their interfaces too easy to use.
Don't blame designers for that, blame VCs and Silicon Valley.
I agree that calling it borderline unusable, when it works great for power users on the desktop, is hyperbolic. Unfortunately for those power users, Digikey, one of the best electronics distributors and also one of the best examples on the web of parametric catalog search, recently disagreed, changing from the classic and highly functional control/shift + click to select multiple to a weird click and drag/click and repeat paradigm.
Those "Mac System paradigms from [the] 80s" are also the Windows paradigms from the 1980s to the 2020s. Still "an order of magnitude" more users more familiar with iOS and Android than that? I doubt it.
Android alone had 2.8 billion users in 2020, so I do not understand what kind of rationale can possible lead to think this is less than PC and Mac users.
Ah. So when I thought I was saying 2.8 billion isn't "an order of magnitude MORE" than the surely at least a billion people who've used Windows at some point in the last three and a half decades, I was actually saying "2.8 billion is less than at-least-a-billion"? Funny, that's not what I thought I was saying.
If you absolutely have to put words in my mouth, please make them at least a little less stupid ones. Maistuivat vähän paskalta.
> It's a shame the UI elements built into HTML are so lacking, which I think is what ultimately drives people do things like this.
I like to imagine that if browser makers had collaborated better on standardising CSS hooks into the default widgets, we would not have seen such strong adoption of tools like bootstrap. We possibly would have had a different pathway through template+controller libraries too.
As a FED, I didn’t help. I rode the gravy train along with Backbone, Angular and React. I wish I had fought harder and spoken more eloquently on the practicality of a11y-first semantic mark-up and progressive enhancement. I caved in to the demands of the agencies who took me on to get stuff done in the trendy stacks.
> Anything that requires combining a click with the shift and ctrl/cmd keys is not going to go down well with the average user.
Is there a reason the element has to be implemented that way? Correct me if I'm wrong, but aren't the details of how it works up to the browser? It only works that way because every OSs native select widget worked that way and once upon a time browsers actually tried to integrate well with the OS and used native widgets.
I suspect that one of the big reasons why native HTML widgets are not improved, is because everybody who needs something "fancy" (by web standards), just rolls their own.
> Anything that requires combining a click with the shift and ctrl/cmd keys is not going to go down well with the average user.
This is part of the problem. Your average user at temporal point X has difficulty combining mouse clicks with keyboard modifiers. You build interface around that notion and in a later temporal point Y your average user cannot combine those at all and you have lost input mode. Your average user has problem distinguishing single click from double click. You install debounce logic, train them there is no difference between the two and lose input mode.
The web is a shitty platform for apps, because currently it is supposed to be used from at least proper PC, touchable handheld device, embedded in controlling container and in relatively near future virtual environments. Game developers have tried for literally decades to bridge the gap between PCs and consoles and mostly failed at that with both platforms being relatively static. The web being a moving target is much more difficult to fit on different device classes. Yet we try to do that and as a result are moving to the lowest common denominator.
> Game developers have tried for literally decades to bridge the gap between PCs and consoles and mostly failed at that with both platforms being relatively static.
For grand strategy / RTS, yeah, that's kind of a function of the complexity. Most other game genres are fairly well defined in the expected control schemes on both platforms now though.
There are lots of people without your educational background. It's a few years old now, but I remember finding Alice Bartlett's talk on <select> box inaccessability [1] quite instructive.
This, rather than JavaScript would have been the way to extend the web into a more cross platform application domain. Now we have essentially a bitmapped graphics terminal where each and every entity re-invents the user interface in new, incompatible and broken ways.
> Anything that requires combining a click with the shift and ctrl/cmd keys is not going to go down well with the average user
This is how computers have worked since pretty much day 1, not just the web. I remember getting computing classes in school, but it seems the current generation is completely ignoring all of that and instead just plays on their phone.
And it's not just keyboard modifiers -- in middle school I remember having to explain double clicking. People eventually got used to it, then the web got popular, and I had to explain to users not to double click on web links but do click on desktop links. Even in this century I still occasionally see people using double click to navigate the web.
Could be argued that that was a mistake in the original specs for the Web. At the time, as I recall it, "double-click for action" was already a pretty well-entrenched standard on multiple platforms.
I work with the GOV.UK Design System and everything's geared towards making services accessible. Your government (or health service) might have their own.
I do freakishly experimental webdesign at times (like for designer portfolios, where freakishly experimental webdesign is kinda part of the thing), but for everything where it is much more about the info and the content I will bend over backwards to use semantic html (and even with those freakish sites I will try).
If you never looked at your website via lynx or used a screenreader I highly encourage it. It will give you a different perspective on things.
My point was that it's inaccessible: "accessibility", "internationalization" and "localization" are clear to everyone, but "a11y", "i18n" and "l10n" are not at all obvious even to native English speakers, and especially those using screen readers.
I've never understood why these shortenings are so common. Is it just to avoid the mental load of having to remember how to spell long words? Isn't the mental load of having to remember which number goes with which word worse?
Same reason people use contractions. It's faster and conveys equivalent meaning.
A11y is probably the easiest one to remember because it looks like ally. Which is what you're being by worrying about accessibility when you yourself don't rely on the standards.
You only have to remember two digits instead of the correct order of 10–18 letters. It’s probably also a lazy typist thing: four characters instead of 20.
My bad, I had read the parent quickly & thought they'd said "I still don't know what it means" rather than "I still know what it means" so just wanted to expand the jargon for the thread here.
Work for a government agency (in the US). We're required by law to meet accessibility standards, and at my workplace, we often do so through the path of least resistance – not using JavaScript to reimplement features that are already accessible and thereby take on the responsibility for implementing accessibility ourselves.
> not using JavaScript to reimplement features that are already accessible
Seriously, I've seen pages that create links by using a styled <span> tag with an onclick even that merely called a function that set document.location using a hard-coded value.
Did developers forget that `<a href=....>` exists?
I can't think of many new browser features I've used in the past few years. There's the permissions API and the fileReader API that are part of apps I've built (and they're very useful), and I've played with a few things like sharedArrayBuffers and WebGL2 but not in anything that's been deployed. Browsers do move fast, but not that fast, and most of the new features are super niche things that the majority of developers don't really need.
If you're prioritizing looking at new things over accessibility and cross-browser support then you are making that choice; browser vendors are not forcing it upon you.
The one feature I want more than anything in the world (and seems to be stalled in Chrome land, which means it’s stalled overall since chrome tends to drive the standards) is the streams API (aka websockets with backpressure). There’s no easy way for clients to signal to servers that they’re overwhelmed, and the result is either saturating the network or the CPU since the message handlers are synchronous.
Yes, and this is what really bothers me. Feature detection is a thing in browsers. There's things like @supports in CSS, "if (<property> in <API>)" in JS, and there are even whole libraries like Modernizr to make it trivial to detect whether something is available. Web developers don't bother though, and then they complain that "browsers broke their code".
Browser vendors do a lot to make it possible to write robust code that doesn't break in the future. Maybe they could do more, but if web devs are failing to leverage the features that are there already then why would they? A whole lot of the responsibility for the broken ass nature of the web is not due to browsers.
For instance Safari on iOS reports support for drag and drop events, but they aren't actually triggered. Another I encountered recently is the "accept" attribute on input file type. On iOS, you can't set specific file type, just mime type, but you have no way to detect that except by using the user agent. Then you have the buggy releases that make a feature seemingly supported, but is actually unusable in practice (looking at you IndexedDB on Safari).
This means using a library like Modernizr is almost mandatory. Also, what do you feature-test? Everything? Feature-testing something that has been available for 20 years sounds like a waste of time on the face of it, but the "alert" case has shown us that if you really want to do it correctly, you can't assume anything.
I am not saying it is not possible to do it properly, but it is not that simple. For anything non-critical, I understand waiting for things to break then fixing them instead, it's way less efforts.
The fact that all three examples you listed are iOS Safari is giving me flashbacks to a previous job where we had way more time spent coming up with ugly hacks to make iOS Safari like something behave closer to a decent browser than we spent on all other areas of new feature development. And we also supported IE11, which was way easier to manage specifically because it didn't straight-up lie to feature-detection like iOS Safari did (and does).
It's probably a bit biased because I develop on Firefox/Chrome (very rare to find difference between the 2) and have to wait for reports/borrow an iOS device to test/debug. There might be similar issues with the aforementioned browsers, but the pain is less visible because it happens during development and I don't remember it. Also most of our users are using iOS devices, so reports for them are more likely. On the other my gut feeling is that iOS is more painful to develop for.
I'd argue it's very much on the browser vendors, because they create the strong expectation that everyone is supposed to always be using the latest version. They do this by bundling together feature updates and security updates. Web devs do the pragmatic thing and ignore feature detection, because they know users are constantly being told to update their browsers to keep themselves safe.
This reminds me of Spolsky's blog post about Fire and Motion. [0] He gives the example of Microsoft creating an endless stream of new technologies which kept their competition busy (eg: ODBC, RDO, DAO, ADO, OLEDB, ADO.NET, ...). Get the competition to spend their resources keeping up rather than competing.
I agree with you, and I think it can be done today, by taking matters into your own hands.
I've done it by testing with historic browsers alongside modern, and challenging myself to make it work with all of them, JS and noJS, without errors, reliably.
In the process, I found a set of "lowest common denominator tags which work across almost anything. I use these to build the "base" HTML. Then, I add JS with feature-checks to allow older browsers with JS enabled to still run it, though it doesn't do much at the moment.
I think it's a worthwhile exercise to learn where the roots of the web are, and how it evolved, and allows you to write much more resilient code in general. The reason for this is that the longer a technique or syntax has been in use, the longer it's likely to continue to be used.
Most of the older browsers are covered by three VMs: Windows 95, Windows ME, and Windows NT 4.0.
Most Windows Netscape can run in Wine, so I can use symlinked .wine directories to switch versions.
I also do occasional testing at Best Buy or Walmart (many thanks to those places) at a cross-section of their available devices -- a couple of desktops, a couple of phones and tablets of each flavor, etc.
I also often ask people if I can test out my website with their device (or if they want to participate in a 5-minute user study)
For difficult things like Mac IE, I just have a couple of devices e.g. G4 Macs and iOS 7 iPad.
Of course, there are text-mode browsers, which I usually install with apt or whatever.
I also use online emulator services like BrowserStack, they have a pretty good slice in their free tier, and a couple of minutes is enough for smoke testing.
Also, I sometimes come across public devices, such as desktops in survival center, library, hotel, or public community space, and I test on those.
With my own devices, I test across various public wifi locations, so that I can provide workarounds for e.g. content blockers or inadequate proxying.
I use Charles Proxy locally to simulate low-bandwidth connections and other common issues.
I have also asked rare use-case users, such as visually impaired, to test using a script, usually through topical Facebook groups.
That's about all I can think of for now, there's probably more.
I was hacked by IE (viruses on Windows), Firefox, and Chrome.
Few years ago, at revolution, Chrome told us about MITM attack and refused to connect to Google servers, while Firefox noticed nothing.
Few years later, attackers used my Chromium, which I used for work, to spy on my Firefox window, which I use for private browsing, by capturing of whole screen when Chromium sit unused. (I have it recorded on video).
All the problems with security seem to come from JavaScript exploits intrinsic to the engine, not any of the new features (misty because the new features are strictly typed and have the power of hindsight with modern design principles), so it’s not like new features are strictly an antigen to security.
> All the problems with security seem to come from JavaScript exploits intrinsic to the engine
Yes the classic memory-related bugs come from the engine, but the comment explicitely mentioned leaks and I don't think that was about the memory ones. Many of the new "features" turned out to leak sensitive or at least identification-enabling information. Imo having remote code execution without a big red warning that this is stupid and you should not do it that users can't click away without being forced to think about it just isn't a good idea, even if it is sandboxed. At the very least we should have a permission-based system where users need to authorize every single Javascript API, for every single connection/file/database/whatever and be unable to ignore it without disabling the APIs. That would imo be the best compromise since web-devs would be forced to think about what they are doing to users computers¹ while still allowing applications to be built.
¹ My hope being that they wouldn't include [bullshit fontend framework] except when absolutely necessary
I think you underestimate the number of users who would either blanket-approve everything or switch to a browser that doesn't nag so much. Most people care very little about their privacy online.
As long as it doesn’t break or give up backwards compatibility, I don’t want the web to stop improving. It’s one of the most important platforms in history. I thought we can’t teach the old web new tricks because of backwards compatibility?
"Start teaching new tricks to the old ones" on the web usually means shipping a bunch of extra JavaScript. Which is fine when a new pattern or paradigm is being felt out, but once everybody is using this one library to do this thing the exact same way, you reach a point where it makes more sense to enshrine it in a native API.
See jQuery (both Ajax and selection), Moment/Temporal, etc
The recurring calls for a "faster web" or a "safer web" are responses to problems for users that web developers, "tech" companies and their advertiser customers have themselves created. Users did not create these problems and yet, unless I am mistaken, these marketing campaigns for "pushing the web forward" are directed at users. As a user, I want those problems fixed but I am under no illusions about where they come from. It stands to reason that a user-controlled web would be much faster and much safer.
I think it's OK for Google to make Chrome into an OS and cram whatever they want into it as fast as they can.
Regular web browsers don't necessarily need to be on the same feature treadmill/death march (assuming they could keep up.)
We seem to be trying really hard to reinvent the applet systems of the 1990s, but in a way that brings systems with 10-100x the memory and CPU resources to their knees and requires huge armies of programmers to implement. I guess JavaScript/webasm is better than Java in some ways.
It certainly is an insane amount of feature churn.
But the right perspective might be to look at the impact on end users.
The issue for end users seems to be that they occasionally encounter "web sites" (really web apps) that only work properly with Chrome. This is sort of a bummer for iOS users, but for the most part they seem to get by just fine. Perhaps there will be a tipping point where the "web" becomes unusable from iOS, but it hasn't happened yet.
I consider this a comparable problem to encountering web sites that only worked with Internet Explorer, or Flash, or Silverlight, or Java. Certainly annoying, but not really catastrophic.
This to refer to my annoyance of browser makers leaving incomplete implementations stagnant for years.
As an example, the <dialog> element, a browser-native standardized spec as promising replacement for alert. Except that it doesn't work, it's inaccessible at its core.
And nobody fixes it, it's just left in this broken state forever.
<section>, the element that was supposed to cut up an HTML document into multiple outlines, hence making componentized SEO-optimized headings easy and better, do nothing at all.
CSS columns, a simple and easy way to distribute text, were unusable for 8 years because Mozilla refused to fix their own small bug. Which pales compared to the extraordinary amount of Webkit bugs that are absolutely never ever fixed.
Form controls, since the very invention of them, are terrible. It has cost the world billions, as worldwide every single developer and project has to reinvent some of them, often breaking basic accessibility in the process.
I could go on, but I'll sum it up as the failure to address extremely common real world problems, and to just let broken buggy solutions linger. When you accept a standard and implement it, bloody finish the implementation. Fix bugs. Otherwise, what is the point?
I'd call this hardening the web. There's no reason I can see why you can't harden it whilst also making progress on new features.
> <section>, the element that was supposed to cut up an HTML document into multiple outlines, hence making componentized SEO-optimized headings easy and better, do nothing at all
They do a lot for Reader view and I’m fairly certain they help with screen readers where heading hierarchies might otherwise be ambiguous.
- - -
Overall, I share your concerns but feel they’re overstated. Mostly because I remember the bad old days of NS4, IE4-6, etc. The web as a set of reliable standards isn’t perfect but it’s worlds better than I ever anticipated.
Just as a matter of perspective: when I started web dev, I learned and used by rote dozens upon dozens of hacky incompatibility workarounds. I moved more backend in recent years, but have had more web work over the last year. I can count on one hand the number of browser compatibility issues I’ve had to address (yes, all Safari). And not because build tools are helping. If anything build tools are the biggest source of frustration for me now.
I'm not sure about Reader view, but <section> does nothing for screen readers as it comes to headings. It doesn't start a new nesting level. You can label a section and this way mark it as a landmark to a screen reader, but that's something you can do on any element.
Meanwhile, developers trying to keep up incidentally may use <section> in an effort to produce more semantic value over a <div>, but they all use it incorrectly. Perhaps because just understanding how to use it correctly seems impossible. Or, better said, it has no function at all:
https://www.scottohara.me/blog/2021/07/16/section.html
Overstated in comparison to darker times? Very much. I started web development in 1996, so I know what you mean.
But it doesn't lessen my annoyance. How can you deliver a 90% implementation, and then let it rot for a decade? Effectively delivering 0%, because it's unusable. It just doesn't make sense to me.
> Form controls, since the very invention of them, are terrible. It has cost the world billions, as worldwide every single developer and project has to reinvent some of them, often breaking basic accessibility in the process.
We're close to being down to two browser engines that matter, one of them with well over half total market share, and they still don't bother to fix forms. You're right about the costs, they're immense. Billions isn't an overestimate for ball-parking the figure, I'd say.
Shit, Firefox, you want to do something to stay relevant, be the first to do that right. Go nuts with some (well-considered) non-standard extensions, behaviors, and tags, worst case no-one uses them and no other browsers adopt them, best case you achieve arguably the greatest thing your project ever has (which is saying something—early FF, especially, was awesome). It may be too late (like every other idea I can come up with to save FF, they should have started at least a decade ago) but it's worth a try.
> Firefox can't do anything regarding relevance. It's not an engineering problem, they can't push their browser, they have no reach.
I don't think that's true, considering they became popular originally though features and overall program quality. I wasn't using it and recommending it to (and/or installing it for) everyone I knew back in the Phoenix/Firebird/FF1.x days because of advertising or whatever, but because it was excellent and solved a lot of problems for people, and that exact mechanism is how they gained a foothold to begin with—every power-user and nerd was doing exactly what I was, and pushing everyone who'd listen to switch to Firefox.
There are other ways to gain relevance, obviously (say, promoting your browser prominently on your search engine) but simply being better than alternatives definitely can work. The proof is that it already did, for Firefox in particular, once.
Firefox has no meaningful presence on mobile, whilst both Google and Apple can push their own browser to billions of users. Google in particular also pushes it from services having billions of users, like Youtube or Gmail.
Mozilla has no such thing, it can't push anything. It has no platform.
Your historical reading is correct. The lack of progress in IE created a temporary vacuum for a better browser to jump in. That doesn't mean the situation is repeatable, as this vacuum doesn't exist right now. Instead, Chrome is speeding away from Mozilla's budget-cut team.
I agree that they're probably screwed, but disagree that it's not an engineering problem. Way I see it, their only somewhat-realistic hope is to approach it as one. They certainly aren't going to advertise or "message" their way out of this, and their leverage is basically nil. Innovation is their only (admittedly remote) hope.
Make native HTML UI elements much better, and add behavior and new tags that should have been added to the spec 10-15 years ago. Bake ad-blocking in (though Brave stole their thunder for that, a bit). Build in federated social networking to the browser itself, to give people a reason to install FF (would it work? I don't know—but it might). Do something more than "we pointlessly redesigned the UI again, and we've almost caught up to 2nd-best on battery life and performance!" each release. They may as well give up, if that's all they're going to do.
Flat design is not just ,,timely'', but it makes it harder to understand how you can interact with the screen. I preferred Windows until Windows 7, but with Microsoft's hard to use design (and M1 hardware coming out) I switched to Mac, which I wouldn't have done before.
I was just talking with someone today about how Fetch API is now 10 years old and still isn't a complete replacement for XmlHTTPRequest (or is it XMLHttpRequest? I can never remember) because it can't do file upload progress tracking. It's been a decade of "the spec doesn't support that yet". Yet? Will it ever? At what point do you admit you're just not going to do it?
Indeed another fine example, forcing developers into massive packages like axios.
Since we're in a salty mood, let's keep it going. jQuery, the much despised jQuery. Inspired by jQuery, browsers now have native DOM APIs that are somewhat equivalent, reducing the need for jQuery.
Except that their syntax is terrible, and chaining isn't possible on most methods. So an elegant chained one-liner in jQuery becomes a blob of ugly syntax spanning many lines using native methods.
Can you elaborate on <dialog>? It is currently implemented behind a feature flag in Firefox, and not implemented at all in Safari. So the answer with caniuse is maybe with a polyfill. How exactly is it inaccessible at the core? As far as I know a <dialog> is required to have at least one focusable element inside it (I usually have a close button in the dialog’s <header>), and then the user agent is supposed to trap focus inside it.
Is it not usable for users with assistive technology? Is it a bad UX for them? Is it broken or buggy? Does the polyfill not workk? etc.
To sum it up, <dialog> is a specced standard of which the first implementation appeared 8 years ago. It is a perfect example to illustrate my original rant.
It is a feature in high demand, almost every web application needs it. Hence it makes sense to have a native control and for each browser to implement it, eventually.
No such thing happened. A broken implementation is delivered, and more importantly, never fixed. It doesn't work cross browser and in the browser where it works, it actually doesn't. And now, nothing happens, they just gave up on it.
Which indeed leaves us with custom implementations, but my point is that we shouldn't need those. It was specced for a reason, it's high on the list of developers needs.
> tldr; I’m just going to say right now that the dialog element and its polyfill are not suitable for use in production. And it’s been that way since the dialog’s earliest implementation in Chrome, six-ish years ago.
With the announced intent to get rid of window.alert/confirm (discussed elsewhere in this HN post comments), it would be nice if dialog got some attention as a replacement... I'm not sure what we're going to do when it goes away; everyone has to roll their own replacement? Doh.
Fixing bugs vs adding new features doesn't bring in new users, so it doesn't get prioritized. And if as you say these bugs are in features that nobody uses, why bother? Nevermind nobody might be using them because of the bugs, but the PR buz over those features has already been had, so on to the next.
The features we're talking about here are in the developer space, not the end-user space. When a browser maker implements a brand new web standard, I don't think the correlation with new end-users is that strong. It takes forever before any new standard is popularized and widely used.
Check release notes of browsers, almost all features no user will ever directly experience.
Turns out it was removed temporarily because of internal architecture changes, and never reintroduced because of lack of adoption. Of course the biggest barrier of adoption is Safari not supporting them, so talk about a self fulfilling prophecy.
> This feature was originally removed temporarily during multiprocess bring-up, and actual usage on the web has been pretty low. We're willing to reconsider if there is significant demand.
IIRC, it was only even available through WebKit1 (i.e., the single-process WebKit API) and never through WebKit2, so it will have gone from Safari when Safari moved to WebKit2, even though the implementation lived on in WebKit for longer.
It was only 4+ years after it was dropped from Safari that anyone started to ask about Safari support for it again, so it had kinda fallen to the wayside due to lack of interest.
> Why do people think that the universality of decay can be stopped?
Theory: A lot of those people tend to survive by jumping from metaphorical ship to ship (API or software or whatever). So to them, the reality is that the ship you're currently on pretty much always feels like it's sinking, and you're always looking out for signs. You write articles lamenting sinking ships, because that's your reality.
These people also may feel like the universality of decay can be stopped in the current context, by moving away from a decaying ship/system. It's more of a question of where the decay isn't as bad, or as seemingly needless.
Example Pro: After a while you can get really good at evaluating ships. Con: It feels useless to build your own ship; you're afraid you'd have to jump from your own ship and wouldn't that feel awful.
Other people survive by building ships. They're cool with decay, because building new stuff that works better is interesting. Their job is to support their stuff, and to a lesser degree to patch others' stuff, like maybe their supply ship, or a friend's ship. To people like this, the reality is that holes just happen. So you learn to deal. Maybe you even learn to love patching holes, and you get so good at building ships that your ship's holes are downright fascinating anyway.
These people aren't usually as worried about decay. But they may have a problem of eventually going down with their ship, or finding that their ship is no longer just a ship but also a lot like a baroque form of floating junk pile.
Example Pro: Obvs, you can build ships. Con: People will try to jump on your ship, and they'll probably tell you they think it's sinking, and expect you to do something about it.
Perhaps there is an expectation there, that we should be able to build something that would function without constant churn and effort on our part to prevent the code from rotting.
For a second, ignoring safety concerns, what should change in how we serve some HTML, JS, CSS and some images in 20 years? Sure, there are plenty optimizations and new technologies to utilize for sites that need high performance or to use certain hardware functionality, but when you just want to display some simple content, none of that is really relevant. Why couldn't i build my personal website with some mostly static content and have it work for many years, while i'm not tied down with constantly maintaining it?
Even now, that's not the case. I decided to build my own site in Ruby on Rails, since it feels mostly stable - however i need the exact same version of Ruby both on my local machine and the server for it to work (using containers for development isn't always a pleasant experience, even though using them for packaged software is great). I also need to rely on dozens if not hundreds of packages, as well as bunches of native extensions, for example, to connect with a SQLite database to serve some simple dynamic content. Of course, i also need to update the OS (thankfully Debian unattended upgrades are pretty stable, except for the one time when they broke GRUB entirely and the server couldn't boot), as well as the web server and there's no guarantee that the SSL/TLS certificate provisioning from Let's Encrypt also won't change in the future.
To that end, the above goal is impossible - i can't just keep building new things, since i have to spend time maintaining what i've already built, even if nothing changes about what i need from these projects functionally, just because sooner or later a rug will be pulled out from under my feet.
> Ruby on Rails, since it feels mostly stable - however i need the exact same version of Ruby both on my local machine and the server for it to work
Doesn't sound so stable to me…
> Why couldn't i build my personal website with some mostly static content and have it work for many years, while i'm not tied down with constantly maintaining it?
You can, HTTP still works and even oldschool HTML mostly works¹.
If you only need sqlite as a db you could easily compile a static binary that will run forever (as in foreseeable future) and serve content via unencrypted HTTP. If you then use a reverse proxy that can be automated with certbot you will have a system where all the maintenance work is done by the EFF, the reverse proxy developers and your distro's packaging team.
I can understand why they'd complain about version mismatches when installing dependencies, since in those circumstances failing fast prevents me from running into deprecated functions down the road, as would happen with PHP. However, the fact that different versions of Ruby/Rails are available in different OS distros and such basically mandates that i use containers OR that i just change the contents of my Gemfile to reflect the version that i will be using during build, which carries the aforementioned risks.
That said, Ruby and Rails are both far more stable than the current npm or pip ecosystems, given that the development has slowed down in Rails somewhat and isn't broken every week due to some package introducing breaking changes. That's not to say that it's better in most conceivable ways (for example, in regards to scalability), but as far as batteries included solutions go, it's pretty okay.
> If you only need sqlite as a db you could easily compile a static binary that will run forever (as in foreseeable future) and serve content via unencrypted HTTP.
Actually, static binaries are perhaps one of the better ways to ship software, especially with static linking, as long as you're ready to take certain security risks in the name of long term stability, though that doesn't prevent you from building new versions in an automated fashion either, at least before something breaks down the line and hopefully your tests alert you about needing manual intervention.
It feels like Java sort of tried to be this, as did .NET, but there is too much functionality that depends on reflection and standard library classes out there, that many projects are stuck on JDK 8, and the whole .NET/Mono --> .NET Core --> .NET cycle is as promising as it is also problematic to deal with. As for actually workable options nowadays, i'm not too sure - most ways to encapsulate scripts in static binaries fail miserably (containers allowing to mitigate this, but don't address the root issue) and otherwise there aren't too many technologies that are good for this out there.
If i wanted to go down that route, i'd probably go with Go, since it doesn't have the problem of needing JDK (and GraalVM is still brittle, for example with Spring Boot, an issue that Go doesn't have). Any other options that you can think of? I really like the idea behind Lazarus/FreePascal, though their web server offerings are really lacking, which is sad.
As for HTTP, i largely agree - read only sites don't necessarily have to be encrypted, even if that can hurt SEO.
> If you then use a reverse proxy that can be automated with certbot you will have a system where all the maintenance work is done by the EFF, the reverse proxy developers and your distro's packaging team.
I am already doing this, but as the Caddy v1 --> v2 migration showed, even web servers and their integrations are subject to churn and change. I'd say that it's only a question of time until Apache/Nginx/Traefik + Certbot run into similar issues, either with new methods for getting certificates being needed, or something changing elsewhere in the supply chain. And even then, your OSes root CA might need to change, which may or may not cause problems. Old Android phones have essentially been cut off from internet for this very reason - the fact that i can't (easily) install Linux on those devices and use them as small monitoring nodes for my homelab disappoints me greatly, especially since custom ROMs brick hardware devices due to lacking driver support.
So sadly if i get hit by a bus tomorrow, it's only a matter of time until my homepage stops functioning and the memory of me disappears forever. Of course, that's just a silly thought experiment, since i recall another article on Hacker News which pondered how someone could keep code running for centuries. It didn't look too doable.
> It feels like Java sort of tried to be this, as did .NET
I meant compile your whole logic and libraries into one (big) binary so you won't depend on any runtime that might ever change except for your operating systems syscalls.
> most ways to encapsulate scripts in static binaries fail miserably [...] and otherwise there aren't too many technologies that are good for this out there.
LUA is about as stable as it gets, (minimal) WASM runtimes will also probably live forever. (Or are, most likely, interchangeable if not) For both of them you'll need to build the interface yourself, so any breaking change will at least be your own fault.
> Any other options that you can think of?
Rust, or if you are a bit masochistic C or even C++. Rocket 0.5 (Rust) looks really nice (as in ergonomic) as a webserver and iirc you can statically link with musl instead of glibc.
> I'd say that it's only a question of time until Apache/Nginx/Traefik + Certbot run into similar issues
But then youll at least have http as a fallback
> So sadly if i get hit by a bus tomorrow, it's only a matter of time until my homepage stops functioning and the memory of me disappears forever.
Is one of these examples showing why people think the universality of decay can be stopped? I was confused about that, because it seems to me like neither of them think that?
> Why do people think that the universality of decay can be stopped?
Because information can be perfectly copied? If you replace the components as they wear out, you can still have a computer from the 1980's running fine. The OS and software still work exactly the same. Whatever data will still exist as a perfect copy.
(In fact, rumors are that George RR Martin does exactly that, and sends whatever he writes to his publisher on 3.5" floppies)
I share you opinion. I'm a little bit horrified by anybody who is alright with digitally-represented information somehow "decaying". Why is that an acceptable thing? We should be working to create new less-volatile and longer-lived storage media, and to be documenting the specifications for the machines that process our data so that gate-level simulations can be made in the future.
Nothing we store digitally need ever be lost so long as some basic stewardship is performed. For now that means moving data to newer storage formats, making redundant copies, using error-correcting codes, etc. Maybe eventually we'll get the mythical "store all your data in a diamond" 3D / 5D holographic storage that always seems to be a few years off.
Exactly. And this is, in fact, the very reason digital won over analog: digital data does not decay. The medium carrying it does, but data itself can be perfectly read and copied ad infinitum.
Somehow, we've managed to take that natural feature away.
Because humans are the constraint, not the bits. Humans (in a group, societal sense) need to context switch over time, and cannot perfectly retain equal, active understanding of how to use all systems or frameworks ever invented, no matter how perfectly the bits are preserved.
That being said, in an archival sense, it would be a shame and seems unnecessary to lose anything, since perfect preservation is achievable. But archival preservation, is different from staying in active use with a healthy community of practitioners perpetually ad infinitum.
That’s a really good point, there can exist a distinction where the goal should be to make it always accessible (archives, emulation, documentation, etc) but not necessarily always accessible in widely deployed web browsers.
So even if you have good reasons to remove an API or feature, you should also provide means or resources to those who wish to preserve and archive the data. And this is something that could be factored into the original design without committing the project to the technical overhead of supporting it forever.
Additionally reducing the problem to humans just chasing shiny new things is simply not true. There’s no denying that some implementations are just bad or dangerous security wise or the world has completely changed in some way.
Not letting things decay could risk the whole platform dying as a result, not just the feature. It could even get to the point where adding anything new is way too risky because of long term support obligations, so decay could be made worse because of efforts to prevent decay!
Obviously we can still make sure great consideration is made both before adding something new and before removing it.
There’s no getting away from the balancing act between change and conservation.
There's the physical degradation of mechanisms and data storage substrates themselves. That's ... not insignificant, but a minor part of the whole situation.
The short-term strength and long-term technical debt of digital is dependencies. Sure, you can spin up some bare-metal or virtualised instance of a system from last month, or five years ago, or twenty years, ago, or fifty. Odds are that the emulation will run faster than the original.[1]
But with time and complexity, dependencies started to expand.
One of the underheralded changes of the 1990s wasn't so much Free Software as what it wrought: an ever expanding and accelerating increase in the number and specificity of dependencies. Tarball distribution gave way to packages, with dependency-resolution, some better (APT), some worse (RPM). Crucially, dependencies didn't simply have to be resolved at build time, once in the lifecycle of an executable, but at install time, once per installation.
The explosion of Web apps and frameworks triggered another violent expansion of the situation with both even more dependencies, more deeply nested ones, but runtime dependencies where prerequisites are identified and fetched from remote hosts.
At runtime.
Which makes the current appified-web immensely flexible and convenient, but also fantastically brittle.
(Of course, the old-school type scan extend this story back to interpreted vs. compiled languages, JIT, hardware-specific variations, high-level vs. machine langauge, binary, and toggling in programmes. It's been a long process.)
But as bits of that infrastructure fall apart, you'll find that digital does in fact decay.
________________________________
Notes:
1. At a gig some years back, a cow-orker told of a uni prof they'd studied under, who did work on the the B and BCPL programming languages. Those are precursors to C. Back in the day when auto manufacturers were looking at automated systems controls, he convinced them that C was far too complex and high-level, and that they should use the more performant BCPL. Which they did. And still do (or did as of a decade or two back), running under several generations of emulation. Faster than the initial hardware implementation. Mind I'm taking them at their word....
> If you replace the components as they wear out, you can still have a computer from the 1980's running fine. The OS and software still work exactly the same. Whatever data will still exist as a perfect copy.
Sadly, this is no longer the case, since nowadays OSes rely far too much on the Internet. For example, your Docker and VS Code repositories eventually will deprecate and remove certain versions of software that you might have been using. Furthermore, npm and pip packages will also decay in a similar manner and eventually Maven repositories will drop off the Internet one by one.
Installing software from DVDs or flash memory is no longer the normal for all of the OS and the rise of the private package repositories without having the tooling in place to ensure that we can download .deb or similar files with all of their dependencies into an installable collection that can be persisted in such a manner is an utter failing of the modern age.
They're not tools that have had a lot of consideration and attention given to them, prioritizing their development and testing. They're scripts that are exceedingly hacky, patched atop unsuitable methods of managing packages.
>> If you replace the components as they wear out, you can still have a computer from the 1980's running fine. The OS and software still work exactly the same. Whatever data will still exist as a perfect copy.
>Sadly, this is no longer the case, since nowadays OSes rely far too much on the Internet.
That seems like an issue with current work, not with past work. And yes, it's an issue. Figuring out how to archive tools and buildchains is important.
Although, do modern OSes rely too much on the Internet, or does the modern development ecosystem?
> Although, do modern OSes rely too much on the Internet, or does the modern development ecosystem?
I'd say both.
Operating systems should be developed with offline first in mind, instead of giving into the prevalence of downloading things from the Internet. For example, Debian has apt-cdrom which allows updating /etc/apt/sources.list and adding packages from DVDs or CDs. That is good, the next logical progression of which would be doing the same for any storage medium - flash memory, HDDs, SSDs etc., just a set of tools to easily create package mirrors on these storage devices and to read them from the OS to make airgapped environments even easier.
Instead, as things currently stand, downloading a package with all of its dependencies is perhaps needlessly hard if you don't want a full mirror, but only need something like gcc with everything it depends on in one gcc-with-all-dependencies.deb file. And the situation isn't necessarily much better with the way how Flatpak and Snap packages want to handle updates, while there are definitely valid arguments to be made about automatically updating packages over the internet, as Debian unattended upgrades already does, relying on it too much makes software brittle.
It took Flatpak until 2020 to address this, i'm not even sure what the situation is with snap packages and using them in air gapped environments, since that's also only in beta: https://docs.ubuntu.com/snap-store-proxy/en/airgap
I apologize if the above sounds a bit like rambling, but the bottom line is that if developers truly cared about airgapped environments, then using and managing them would be as easy as the alternatives, not less so. Be it in regards to tools, to how packages are managed, or even just the day to day experience while using them.
And that trend extends deeply both into the OS itself, as well as the software that's used by it (especially in cases of non-standard update mechanisms, like some browsers like to do), as it does with the development ecosystems nowadays. It's surprisingly how little pushback something like snap got, instead of the community delaying its utilization until all of the concerns have been addressed.
I'm not saying that we shouldn't innovate in regards to package management, apt over apt-get showed that there definitely can be improvements in regards to usability, it's just that we as an industry should never be satisfied with using half baked solutions.
This is an excellent point. Consider the nature of decay - is it of the artifact itself? What about printed books, for example? Or language, or culture? Do those things decay in any sense?
Absolutely. However all these endless discussions have an implicit time frame, say 50-100 years backwards and forwards, during which time, old, well used stuff like HTML are expected to not suddenly remove stuff that's being used in the wild.
Because web pages and simple web scripting is often done by non-professionals, who cannot be expected to follow standards processes in perpetuity to keep their pages/scripts working. They often author a few pages and move on with other things in life, which is why browsers being ultra-conservative about breaking stuff is important for the robustness of the Web.
> Because web pages and simple web scripting is often done by non-professionals, who cannot be expected to follow standards processes in perpetuity to keep their pages/scripts working. They often author a few pages and move on with other things in life, which is why browsers being ultra-conservative about breaking stuff is important for the robustness of the Web.
I am a professional software engineer at my day job, and we strive to keep our software up to date etc as the world changes.
But I am also exactly this non-professional developer in my after-hours. I have written a number of little web apps that solve some small need, and I really have zero interest in maintaining them over time.
When I wear that hat, I really appreciate the conservatism of most web stuff.
> Because web pages and simple web scripting is often done by non-professionals, who cannot be expected to follow standards processes in perpetuity
Professionals can't keep up with standards processes either. Because Chrome employs people to work on them. Who's going to pay me to keep track of literally hundreds of standards currently in development?
Indeed, but then it becomes an argument about degree, not kind.
FWIW although I'm actually a fan of decay, I think its a terrible idea to deprecate `alert()`. I get it that it's abused, but it's also an important part of learning js -- it's the easiest way to make a side-effect. (No, `console.log()` isn't easy because you have to open dev tools, which is scary and hard. A simple modal dialog is far friendlier and immediate and visceral and gives a feeling of power.)
One of the great things about the web is the fact that I can expect anything I create today, to be relatively forwards compatible, and I can build things in a way so they're either backwards compatible or degrade gracefully.
The philosophies around entropy isn't really relevant here IMO. The web should continue to be evergreen.
Supporting legacy constructs forever can be hugely detrimental to progress though.
Something completely new would fasttrack innovation. It could leave out all the quirky workarounds and get advanced features built in or easily extensible. When adoption is high enough it could include a legacy box, to run good old HTML based content.
Have any attempts at this sort of thing ever been made?
I don't think this is really a good idea. HTTP and HTML aren't perfect, but they've been made into ubiquitous standards already used by everyone. In order to switch to a new standard, you'd need to have a pretty convincing way in which it was better. And I don't think you can ultimately outbalance what we have now. Not to mention that the only way this could probably actually happen would be through Google doing it, which would be disastrous for the open nature of the standards.
There's plenty of ways in which we could improve on the current setup. Everything could be so much easier, for one thing. Basic things like animation, drag & drop and responsive design all require libraries or extensive knowledge to get them right.
Something like websockets is not exactly accessible to a beginner, but there is a huge need for online content that supports live interaction.
You are right that it's not going to be easy to get everyone on board, but that should not be a reason to stop trying.
If you only use a super-basic subset of HTML tags, design carefully, and ignore "standards", you can write a website which works across 25 years of browsers, mainstream and obscure, with gated enhancements for browsers which support them.
I think that's pretty impressive as far as API age.
Browser vendors have long opposed making backwards incompatible changes. The problem is if any existing websites start breaking some users will switch browsers because of it. Browsers that don't implement the backwards incompatible change will in turn gain users. No browser wants to lose users, all browsers want to gain users, so no browser is willing to make any changes that cause old websites to break. Once it's a browser feature, it's always a browser feature (with very limited exceptions).
> Why do people think that the universality of decay can be stopped?
I'd rather say that the "universality of decay" is a U-shaped curve. Just have a look at old arcade and console games... they went out of fashion, the hardware (sometimes literally) rotted, but emulator technology is getting better and better all the time - the result is you can use any modern computer or many smartphones (!) to run all that stuff that is sometimes many decades old.
All that any kind of technology needs to survive into modern ages is one (single or group of) person that engineers an appropriate abstraction layer. Polyfills, virtual machines and other emulators, FPGA-based hybrids... the list is endless.
Does it, though? We still use some APIs from >50 years ago at this point (parts of C stdlib). I don't think the industry has been around long enough to make any definitive conclusions. FWIW, given how most software development is done these days, I think we'll just keep building layers upon layers, with lots of legacy CRUD baked inside, invisible but still necessary for the whole thing to work.
Since it looks like Chromium is set on removing alert() altogether[0], I don't see why this can't be handled in the same way browsers handle popup windows. If a website tries to open a pop-up, it gets blocked; but, on Firefox at least, I get a small notification in the toolbar, where I can choose to copy the popup window's URL, open the popup, or allow the website to open popups as much as it wants.
The problem is that alert() blocks JavaScript from executing. If a web page fires an alert, it expects to be blocked in that moment. If the browser were to delay the alert, the page would be blocked unexpectedly at some later time. This would probably cause bugs.
The problem is that people relied on a side effect of a function that isn't guaranteed to block execution all the time (browsers are allowed to ignore those prompts) and now they have to fix their code.
> The problem is that people relied on a side effect of a function that isn't guaranteed to block execution all the time
Yes, this is a problem when people code their websites against current iterations of a browser. It's not a problem regarding Chrome removing window.alert() but rather a problem that happened at development of the site, not at the iteration of browser (which is being discussed here)
> browsers are allowed to ignore those prompts
Unless previously marked as "Block future popups", is there any browser that currently (by default) doesn't block JS execution upon window.alert()? AFAIK, all browsers currently do.
> now they have to fix their code
Yeah, good luck maintaining the web with that mindset. There are countless of websites that will basically vanish (rather, stop working) if you change the execution model of browsers too much.
But large swaths of the web currently are just online because someone set it up well 20 years ago and has never touched it since. Maybe they can't even modify it at this point.
So any change needs to consider the historical impact the change can have. Hopefully the people working on browsers and standards have a bit better mindset than "now they have to fix their code", because otherwise we're utterly screwed.
At the time that change was proposed, the specification was saying that browsers could optionally return, with some examples, but those are never meant to be exhaustive lists.
If it's legal to do so, then your code needs to be ready for it. Relying on a browser's specific version behavior is brittle.
And no, not all browsers currently do, all the browsers you've used in some specific scenarios behaved the way you thought, but there were already ways for it to fail before.
As nice as it is, MDN and all the other websites are just paraphrasing what is in the specification, and sometimes omitting crucial information. Yes, Javascript and web technologies are accessible and can seem simple, but the reality is a lot more nuanced than it is portrayed in most places.
I understand the general principle you’re making, but for this specific case, how many websites would realistically break because the browser stopped pausing JS execution when alerts are fired?
From humble point of view HTML 4 was just fine for the purposes of the Web, and everything else should be done via native applications and network protocols.
Google, alongside all of those that push Chrome wrapped in whatever kind of package, have managed to turn the Web into ChromeOS.
I expect job adverts for HTML 6 to be about years of experience developing ChromeOS applications.
I disagree at least about the part about native applications. It really is better to have this universal VM for ephemeral apps and not have to worry about if the thing supports Linux or if it's actually spyware or how much hard drive space is this thing going to take up.
Recent things like Zoom native app being incredibly insecure but the same company's webapp being much better kind of proves the point.
They are not ephemeral. They are far more persistent than anything you could install locally, because all the data now resides on someone else's computer. The "ephemerality" paradigm of web apps has been a strong contributor to that trend.
How do you figure? Before everyone went web crazy and started bundling always-on network traffic into their calculator application, programs were a thing you could download and install and use without a network connection at all forever.
I think that’s a result of being connected to the web not a native application vs web app thing. Nothing is stopping a native app from sending telemetry to a server for every action you take.
If you can't self-host a web-based application you have no capability of ever using it without third-party tracking
It's at least possible (albeit potentially difficult) for a native application, should it have have such tracking, to have that tracking removed. Software "crackers" have shown, time and again, that so long as the code is present on a machine it can be made to run in whatever manner is desired.
> Again whatever native apps can do, web apps do all the time.
This isn't true. Yes, web apps have tons of telemetry, and every web request is logged server-side. But native apps do MORE:
- Native apps can look at what processes you're running. Web apps can't.
- Native apps can look at what software is installed. Web apps can't.
- Native apps can accurately determine exactly what operating system and browser you're using, while web apps either have to rely on a User-agent (which is trivially spoofed), or perform fingerprinting in order to come up with a guess.
- Native apps can see exactly what hardware you have. Web apps can't.
- Native apps have read/write access to every file on your system, subject to user-level permissions. Web apps require explicit selection from the user for file access. A native app can easily send your /etc/passwd file to a remote server, and can enumerate the local users.
--
Look, nobody is disputing that web apps have tons of telemetry, yet you keep responding as if that's what people are arguing with you about. What we're disputing is the exact statement I quoted. You implied that the telemetry of a native app is a subset or equal to the telemetry of a web app, and that's just plain false. It's very much the other way around. The telemetry of a web app is far less than a native app.
> - Native apps can accurately determine exactly what operating system and browser you're using, while web apps either have to rely on a User-agent (which is trivially spoofed), or perform fingerprinting in order to come up with a guess
A native app may know which browsers I have installed, but how would it know which of the umpteen ones I have I actually regularly use (if I don't do so while running the app)? The Web app, OTOH, is running in that browser, so yeah, of course it has a better chance of knowing that.
True, but to be fair, most users (Windows users, at least) don't have more than 2 browsers installed (Edge and either Firefox or Chrome, and it's likely a safe bet that if FF or Chrome are installed, that's their preferred browser). *nix users likely only have 1.
Your "umpteen" browsers is very much an edge case.
A native app running under your account can do anything you can do, so it can determine which browser you use by any number of methods, for example by checking the timestamps on the files in your various browser profiles (and of course read your browser history etc.).
Here's an example: Discord app reads all the processes running on the machine. Discord webapp can't. Telemetry is probably the same.
Another example: Microsoft Word can include a bug that makes opening a doc file run whatever command, including wiping the system. Google Docs can't do it.
It's much simpler to see telemetry in a web app - just open the Network tab. The fact that it's harder to do with a desktop app does not at all means it isn't there. Give wireshark a spin.
But web applications don't have all my data. I gave you an example just above - Discord web app can't see what other programs I have running. Discord Desktop can. Google docs can read all my data on Google Docs (shocking), but Microsoft Word could be stealing my cookies from my browser and accessing my Google Docs, my iCloud and anything else too.
You keep making these bombastic statements with no data behind. Not all web applications store every page interaction into a marketing engine. For example, I have a web application - as you navigate no additional network requests are sent (it's SPA!), and anyway I don't really have access to those the server logs because they're hosted by some Netlify-like service. See? Web application without you data that doesn't feed your interactions into a marketing engine.
Some web apps track, some desktop apps track. But clearly and without any doubt an executable running in your operating system can potential do much more than a web app you open with your up-to-date browser. An executable can even... open a web app!
You repeated this like 10+ times already in this thread, but never explained it why it's so evil. You just assume everybody is on the same page that tracking (logging actually) is bad, but it's far from obvious.
The fact that I can see access log in my web server is just a helpful tool for me as a developer to improve my services. I think the majority of sites use this in good faith and keep products healthy.
If your threat model involves secret services tracking your activity down based on downloading favicon.ico, then you might have more serious problems than architectural choices of the web platform.
Because 10+ times people keep not getting that while native apps can track you, all Web apps do track you and fed every single action into marketing engines, even if then don't public acknowledge doing so.
At my day job, we make a web application for health records that can be deployed inside an air-gapped intranet. Surely you don't think that's feeding a marketing engine?
That's a different question. All over this thread, you're repeatedly saying that 100% of web apps are feeding marketing machines. I have a counter-example.
It's a separate question of how a patient can be sure of that fact. There's actually not a really reliable way a patient could even become aware of the existence of this product, since they would never see it or be informed of it. Patients are not users of this product. Users could ask their IT department for a log of outgoing internet-bound requests from the servers. Or ask whether those servers even have the capability of contacting arbitrary third parties.
Sorry, but until you present conclusive proof that you don't, we better assume that you do. Unfair? Sure, possibly... But that's just the risk you took in choosing to use the same technology as all the personal info thieves.
I mean, one could also be running around in a supermarket in a balaclava without intending to rob the cashier -- but would you assume someone you saw doing that wasn't going to do exactly that?
You can look at the network tab of your browsers dev tools. You can see everything being exfiltrated that way.
In fact, that's pretty similar to the technique that you'd use to check on a local app too, except it's built into the browser.
I'm not particularly interested in convincing anyone that some app is or isn't leaking their data. If you don't want to use web stuff, don't use it. But I do take issue with assertions that 100% of all web apps must be doing that kind of stuff. It's obviously not true. You can develop your own web app from scratch that doesn't do it, which is sufficient to form a counter-example.
Sure I can. And you can. But to 99% of users, you're talking Greek -- ancient, not modern. And hey, BTW: Can we always? Where's the "Dev tools" menu on my phone browser?
And one counter-example does not a summer make. As long as 99% (typical Internet statistic, i.e. pulled from my mether regions) of web apps harvest your data for sale, that last percent won't get the benefit of the doubt: it's far too difficult and uncertain to find out which percent that would be.
It looks good, but it seems many applications still require filesystem=host to run (https://flatkill.org/2020/). Also, its sandbox solution isn't going to work on Windows, Mac and BSDs.
In which world do companies use rust and not over 20 years outdated c++ libraries to make your argument work?
I'm sorry, but the likeliness of zero days in a c++ program that was too stupid to handle char arrays or multithreading is way off the charts vs heap spraying bugs in a VM.
I'd argue that native applications therefore are far more vulnerable than web applications.
> Desktop applications can track, Web always tracks.
Desktop code cannot be verified. Web code can be verified. This argument goes both ways.
If we're talking about the web-equivalent of Desktop Apps: There's electron, which can do far more than HTTP requests and WebSockets - but that on the other hand is also too bloated, right?
Sometimes I wish people would just make up their mind, stop complaining, and start trying to fix it. We had servo, and we had a nice modular and privacy respecting future for everybody; and then we messed it up because apparently nobody really cares about it.
If it's in your browser, you can see the code it's running and the data it is transmitting. And you're only a single uBlock Origin (other other browser add-on) filter away from blocking it.
All web applications may be spyware, but using web technologies as a common format for specifying a UI had benefit, even if it's not through something as heavy as electron.
Having an interface I can just stand up on a port and access locally through multiple different browser options, or even expose to remote if the user wants, and it will be the same across every OS for zero additional shipped library cost, and works in every programming language, is an amazing thing.
The only one of those even remotely similar to what I'm talking about is X Window System protocol, and that's never been close to ubiquitous, which is something you can say about web browsers. HTTP+HTML is so ubiquitous that many (all of the most popular) operating systems ship built in components to handle it, and then people often have one or two additional clients to handle it.
For RDP, clients are easy to come by (but not ubiquitous), but the server side tech is limited, and generally OS based and not application provided.
For VNC, client and server tech is easily available as a library to all, but it's still an additional layer on top of your application which you need to layer on and then communicate as a separate step to any client that needs remote access.
I'm not familiar with views, but I'm not sure how it could be any easier to use than VNC without limiting where it can be easily deployed.
Opening a port and taking a few commands is simple. There are myriad libraries to help handling requests, and in some languages rolling your own is a matter of tens of lines. The client requires nothing that every person that would want to use it doesn't already have, and if you want to support remote access, you literally just change the interface you bind to from localhost to 0.0.0.0 or the actual IP address. All additional firewall config is something you would likely have to deal with in every other technology as well.
Now, don't get me wrong, I'm not saying this is the best UI paradigm to target. There are many things better about specific UI libs, but none of them can even come close to the cross platform capability and simplicity of just using HTTP+HTML. Do I want major applications delivered this way? No. Do I think it should be the ultimate choice for most programs that have time and resources to do otherwise? Probably not. Do I appreciate that I can write a Perl/Python/Rudy/JavaScript script and package it with its runtime or ship as a script (or just use a compiled language) and it will just work on basically any platform I'd want to run it on, and a client (browser) exists for everything someone would want to use to configure it? Hell yes.
Most of those SaaS have native mobile apps which track you, too. The runtime is not to blame. FOSS applications could be delivered with near-instant load times, native feel and excellent sandboxing, with one universal build target.
That is a remarkable ability.
Do not let the crimes of Web 3.0 blind you to this.
Tracking and disrespect for privacy are utterly orthogonal.
There are things like Minio which lots and lots of people use as an S3-compatible object store because it's so simple to set up. Most S3 alternatives are just a part of much larger filing system that's more demanding to set up. NextCloud is pretty big as well, though I don't know the exact numbers.
I think in the end, it doesn't matter as much. These are meant to be deployed for a cohesive user base that numbers between a single geek and an entire region of a country or small org.
They most often use libre data formats and protocols to store and communicate data. In such a situation, the network effect is less pronounced, and measuring market share isn't as important. As long as the service works reliably and meets user needs, I don't think people will clamour to replace them with proprietary solutions.
Some tracking will always be possible regardless of the platform but compared to native app the comparison is clearly in favor of web apps. Web apps make cross website tracking very difficult, web apps don't have private apis, web apps can be easily investigated to see what they do and even edited on the fly by the user if needed (adblocking), the sandboxing of web apps is very strong and exploits are getting rarer and rarer.
There's a reason everybody asks you to download their native app, tracking is much easier there.
You can only see the UI of Web apps, and tracking is super easy with marketing engines.
No one asks you to download native apps for desktop platforms, unless it is some Electron garbage for whatever reason, usually for stuff that is available to PWAs anyway.
All ask for native apps on mobile, because development just sucks less.
Whatever, it is great that people believe Web apps are so safe with their data, more fun when creating analytics rules.
I author a CSS 2.1 rasterizer, and a partial implementation of it is used in a game engine my company's open source organization publishes.
There's such a small number of people who have written their own pieces of visual web client technology, and an uncountable number who consume it.
I've entertained the idea of writing a partially compliant web browser and releasing that for fun. It's still totally possible to write your own web browser today.
You will of course need to put in effort than an exceptionally small number of people have, and even after you do that, you'll only have something partially compliant. But it will be valid!
Hell, you could build an HTML5 valid web browser that didn't even use CSS. Invent your own thing. Make JSON style sheets or something.
Anyway. We don't have enough people toying around with web tech. For years, I've only ever seen people toy around with the easy. Things like making little web clients to help you with API requests instead of turning to curl, or rehashing a CSS framework for the nth time.
And frankly it's sad to see because its so uninspired and boring.
Where are the people creating basic web browsers that use C# as a programming language instead of JavaScript? Or people inventing a new hypertext markup language as an alternative to HTML that still uses HTTP as a transport protocol?
SerenityOS probably has the most serious attempt I've seen at "Let's make our own web browser for the sake of it" (along with the rest of the OS). I think they are still working towards Acid 2 compliance but they also have a spattering of newer features supported as they hack at getting newer sites to work. Not a very whacky take though just a home grown one.
Apparently they are. How disappointing, I really like how useful they are for quickly getting something working and maintaining a consistent and expected experience for the user.
Where in that thread are they agreeing to deprecate it? This was someone random asking to deprecate, with the person in charge saying the usage is too high...
I also don't agree with deprecating this without a feasible alternative to ask the user of a page something with a simple line, that works well on desktop and mobile without any extra CSS needed to make it mobile friendly.
The original proposal of the author of that issue is to use NotificationAPI but that is not supported in IE. And a lot of web apps in B2B are extensively using alert and confirm.
I feel this is a solution for websites abusing this feature that will cause a lot of maintenance effort spent in a lot of legit applications.
Here is a better alternative (of course with a lot of drawbacks that I cannot think now in 5 minutes): make the dialog timeout after a period by default. When timing out the dialog disappears without any action/change happening in the rendered page.
That is a very broad statement. What specifically do you find terrible?
Here is a list of issues I often have with JS-based alternatives that do not exist with alert/confirm/onbeforeunload:
- the escape key does not close the modal
- tab focus is not restricted to the modal
- the modal is not properly announced by screen readers
- the positions of confirm and cancel buttons differ across sites, leading to misclicks
- the modal is not or very hard to use on mobile
Building good modal dialogs is hard and much easier done in the browser than on the page. Even <dialog> (if it ever becomes a reality) will not solve all of these issues reliably.
So in a way I agree with you: there might be more user friendly solutions. But the average alternative that people come up with will be worse, not better.
I use confirm() on occasion as a "are you sure you want to delete this?" type protection against misclicks that doesn't involve coding a modal or something.
How cares? I mean, sure if you want to do a shiny applications for consumers, you care. But 99% of the business software doesn't care and wants something that just works.
I use alert, confirm and prompt a lot because it's the simpler way to notify the user, ask for confirmation or ask some input that just works, in all browsers, with vanilla JavaScript, without having to code any CSS (that I hate), or including huge frameworks.
They are used extensively in all enterprise software, where you don't need to be fancy but need to produce something that works reliably.
Removing them to me is a terrible idea. More terrible if there are not alternatives to these, yes there is the dialog API that is supported only by Chrome, and it's not as simple as the good old alert, prompt or confirm functions. And we know that in the enterprise world we would have to wait years to have all the browsers compatible with new APIs, there are still a ton of people that uses Internet Explorer...
By the way this is a so big breaking change that to me would require a new version of HTML entirely. To the point where the browsers if they encounter a old HTML document they keep the old behavior. But they removed the DTD with HTML5 leaving just <!doctype html> that to me was a terrible idea.
Isn't the better solution for the browsers to collectively improve them in that case rather than ditch them & every site roll their own (with custom styles and the over-the-wire weight of the code to implement it)
In your opinion, what's terrible about these from a UX perspective? Is it just the styling or something else?
The alternative to a default confirm prompt is going to be someone including Bootbox in their site, which I'm not sure how that's much better
Ideally, all functions should be async-transparent. That is, it should be up to the caller to decide how to invoke it. This is usually done with some form of green threading.
It all works great, right up until the moment you have to interop with another language/runtime that doesn't understand your bespoke async. Callbacks (and layers over them such as tasks/promises) are uglier and necessitate opt-in async, but you can interop them to anything that speaks the C ABI.
Green threading is multithreading right? Isn't Javascript singlethreaded? I would assume adding multithreading would break tons of code that relies on it running singlethreaded.
It would break the same as sprinkling "await" all around your codebase. Asynchrony in general is not free - you have to redesign around it regardless, and deal with the issues it introduces.
Callbacks have been there, but most code wasn't written with that in mind. And you still need some synchronization in async code - even if it's all scheduled on a single thread - due to re-entrancy issues.
It's <plaintext> which basically means "stop parsing for rest of the page". There's no way to close the tag. It's super easy to implement which is probably why it's still around.
The other fun tag that similarly changes parsing is the <XMP> tag - it is similar to plaintext, but can be closed. I’m unsure if it is still supported because I haven’t used it for a decade and not near PC at moment.
appears to actually be flaky these days. I'll have to get back to it and figure it out. There's something subtle going on on mobile chrome. Things are being done differently. The image appears to get pre-fetched even though technically, according to the old-school <script> blocking rule, it shouldn't.
I'll have to check the blink source whenever I have some free time. There's probably a strange way around it (for instance, maybe convincing the browser it's a really old website and it reverts to the traditional policy for compatibility or perhaps maybe there's another strange old feature I can leverage, I dunno I'll have to check). And yes, I know this is just pure theater and it's completely useless, I still want to do it well!
> Forms with passwords marked Not Secure over HTTP
It requires a rather curious definition of “breaking change” to consider this one.
> A̶r̶r̶a̶y̶.̶p̶r̶o̶t̶o̶t̶y̶p̶e̶.̶f̶l̶a̶t̶t̶e̶n̶ ̶b̶r̶e̶a̶k̶s̶ ̶M̶o̶o̶T̶o̶o̶l̶s̶ renamed to Array.prototype.flat
That doesn’t belong in the list at all; it’s a prime example of the platform bending over backwards to avoid a breaking change, for better or for worse (it means that future users are stuck with an inferior name, see also contains which got renamed to includes because of, if I recall correctly, MooTools again).
If I'm interpreting the list right, I think they agree with you about flatten. I think the strikeout is supposed to indicate that the struck portion would have made the list, but they took corrective action. I spelunked through the commit history and the struck portion was indeed unstruck originally, and then when the situation was resolved they crossed it out and added the description afterwards.
Could you elaborate more? I’ve seen advice that it’s not recommended (and not been recommended for some years), but I’ve also seen questions in recent times by app developers who are bent on using it to “increase the security” (as it relates to where the apps want to connect to securely without any interception/modification).
8 points by buu700 on Aug 17, 2018 | parent | favorite | on: OpenPGPjs has passed an independent security audit
We (Cyph) have been pretty disappointed in the Chrome team's decision to kill HPKP.
Paraphrasing, but IIRC the reasoning pretty much boiled down to "it's a pain to maintain and Expect-CT is kind of similar anyway" — which I think is a really weak justification for harming end user security and breaking established APIs that people depend on in production. Fingers crossed that Firefox keeps it alive! [Narrator: They didn't.]
That said, it doesn't entirely break WebSign in Chrome, just weakens a bit further below strict TOFU. https://www.cyph.com/websign goes into detail, but WebSign has some client-side logic to validate its own hash against a signed whitelist. The major downsides to relying on this are:
1. It depends on a caching layer, not a security feature. This means that any guarantees are potentially out the window if a browser vendor decides to do something crazy for performance reasons or whatever.
2. It opens up an attack vector where it can be forcibly unpinned by filling up the user's disk and making the browser evict the cached WebSign instance.
All in all I think it's still basically fine, but shipping an optional browser extension for hardening WebSign is now a higher priority because of this.
Hmm, https://www.cyph.com/websign-architecture the hkpk suicide bit is a beautiful hack, but is so far removed from the motivating purpose of hpkp, that i dont think you can really blame web browsers for not caring.
Although i guess im kind of surprised that worked. I'd assume that service workers could fall out of cache before hkpk at random, and then your app would just be bricked (?) Seems like a bad failure case that could just happen without anything makicious going on, but maybe i just dont understand how service workers work well enough.
Ah yeah, 100% agreed. I think it was a cool concept, but if we're being fair we were practically exploiting a vulnerability in HPKP to produce unintended behavior. (On that note, one of the HPKP Suicide demos we presented at Black Hat and DEF CON was actually a ransomware concept.)
I'd assume that service workers could fall out of cache before hkpk at random, and then your app would just be bricked
Well... that did actually happen on occasion, although IIRC it was considered to be an edge case browser bug in the ServiceWorker and/or Persistent Storage implementations rather than expected behavior, since the locally installed worker shouldn't have been wiped before its replacement had been successfully fetched. We had to set up a support page with instructions to unpin the keys through about:config / chrome://net-internals, which wasn't really ideal. (Both browsers did end up actually fixing this, not that it ultimately did us much good.)
HPKP locks you into one public key forever, so you can't ever rotate private keys for your website. (You can rotate the cert, but this isn't the same.) Heartbleed was one time where your keys would be leaked and you'd have to rotate, but even normal business processes prefer key rotation (and heaven forfend you ever lose it!). Too much burden for too little gain.
No, HPKP didn't lock you into one public key forever. You could rotate keys. The HPKP header had an expiry date and let you specify multiple keys, so you could add a new key to the list and switch over when the previous key expired.
It makes sense to use HPKP to pin to a CA (maybe a CA's intermediate, I can't remember what they let you do) or better, multiple. Depending on your expiration, and what terrible thing happens in the PKI universe, you should probably be able to resolve an issue if you've got multiple independent CAs pinned.
Related: Stop Pushing the Web Forward (2015) https://news.ycombinator.com/item?id=9961613