Ars Technica has published a third post about the annoying user experience of Microsoft Edge in as many days. Today’s was about a notice that appears when the user tries to use Edge to download Chrome. These are notices that are displayed by the browser itself whenever the user opens up the Chrome download page.

Now, setting aside the fact that these notices shouldn’t be shown to the user at all, what got up my goat was the copy that appears in one of them:

‘I hate saving money,’ said no one ever. Microsoft Edge is the best browser for online shopping.

What is with this copy? Do they assume that all users do with their computers is buy stuff? That their only motivation with using a browser at all is to participate in rampant consumerism?

I’m not a Microsoft Edge user, so it’s probably not worth my time to comment on this. But what bothers me is that I’m seeing a trend suggesting that large software companies only think their users are just using their devices to consume stuff. This might be true in the majority — I really don’t know — but the problem is that this line of thinking starts to bleed into their product decisions, and reveals what lengths they will go to to extract more money from these users. I’m going on about Edge here but Apple does the same thing in their OSes: showing notifications for TV+ or Apple Music or whatever service they’re trying to flog onto their customers this month. At least with web companies like Google, Twitter and Meta (née Facebook 😒), we get to use the service for free.

I know software is expensive to build and maintain, etc, etc. But this mode of thinking is so sleazy it’s becoming insulting. It just makes the experience of using the product worse all around, like going to a “free” event when you know you’ll be pushed to buy something. This is how these software companies want their users to feel?

Over the weekend, I had the opportunity to spend some time with my parents who were staying in Mansfield, in regional Victoria. We were staying in a small cottage located on a hill, which meant some pretty stunning views, especially in the evening light.

We didn’t do a heap during our trip, although we did manage to do the The Paps trail on Saturday, which involved a 700 metre climb.

(Apologies for the photo, I had another one that was zoomed in a bit more but the photo turned out quite muddy. Might need to consider another phone or camera.)

It was a bit of a challenge — the trail was quite steep at times — and there were a few instances when we considered turning back. But we did eventually reached the summit, and got some spectacular views of Lake Eldon, which was quite full thanks to all the rainfall we got over the last few months.

This was followed by a pub lunch at the Bonni Doon Hotel. The place was chokers, probably with people eager to get out of the city at the end of lockdown (likewise for the cottage we stayed at, which has been booked solid for the next couple of months). But the food (and beer) was good and it was perfect weather to be dining outside, with the sun shining and temperature in the low 20’s Celsius.

All in all it was good to get out of the city, and out of my weekend routine, for a spell.

I really dislike the cookie disclosure popups that appear on websites. Ideally I shouldn’t be seeing them at all — I know that the EU requires it, but I’m not a citizen of the EU so the regulation should not apply to me. But I’m pragmatic enough to know that not every web developer can or will selectively show this disclosure popup based on the geographic region of the visitor.

That’s why I’m wondering if these disclosure popups would be better handled by the browser.

The way I see this working is that when a website tries to set a cookie, either through a response header or within JavaScript, and the user is located in a jurisdiction that requires them to be aware of this, the browser would be responsible for telling them. They could show it as a permission request popup, much like the ones you see already when the site wants to use your microphone or get your location. The user can then choose to “accept”, in which case the cookie would be saved; or they can choose to “deny”, in which case the cookie would be silently dropped or an error will be returned.

This has some major advantages over the system we have now:

• It would save the website dev from building the disclosure popup themselves. I’ve seen some real creative ways in which websites show this disclosure, but honestly it would just be simpler not to do it. It would also cover those web developers that forget (or “forget”) to disclose the presence of cookies when they need to.
• The website does not need to know where the user is browsing from. Privacy issues aside, it’s just a hassle to lookup the jurisdiction of the originator based on their IP address. Which is probably why no-one does it, and why even non-EU citizens see these disclosure popups. This is not a problem for the browser, which I’d imagine would have the necessary OS privileges to get the users’ current location. This would be especially true for browsers bundled with the OS like Safari and Edge.
• When the user chooses an option, their choice can be remembered. The irony of this whole thing is that I rarely see websites use cookies to save the my preferences for allowing cookies. These sites seem to just show the popup again the next time I visit. Of course for a user chooses to deny the use of cookies, it wouldn’t be possible for the site to use cookies to record this fact. If the browser is managing this preference, it can be saved alongside all the other site permissions like microphone access, thereby sitting outside what the site can make use of.
• Most important of all to me: those outside the jurisdiction don’t even need to see the disclosure popup. Websites that I visit could simply save cookies as they have been for 25 years now. This can be an option in the browser, so that users that prefer to see the disclosure prompt can do so. This option could come in handy for those EU citizens that prefer to just allow (or deny) cookies across the board, so they don’t have to see the disclosure popup either (I don’t know if this is possible in the regulation).

Of course the actual details of this would need to be ironed out, like how a website would know whether the user has denied cookie storage. That’s something for standards committee to work out. But it seems to me that this feature is a no-brainer.

The GitHub Universe 2021 conference started a few days ago and one of the features touted in the day one keynote was GitHub Codespaces. This is a development environment that is accessible from within your web browser. It’s based on VSCode, which is a popular and well-designed IDE that is already written in JavaScript¹, and also provides access to a Linux shell running in the cloud, allowing you to do various things like build and test your code.

After playing around with Codespaces during the beta, and seeing the feature develop into something that is available for everyone, I’d thought I’d say a few words on how I use it and what I think of it.

First, I should probably say that I’m not a heavy Codespaces user. The keynote seemed to be touting the features of Codespaces that makes it useful as a dev environment for collaborative coding. This is something I have no personal use for since it’s mainly just me working on repos I use with Codespaces, so I haven’t really explored these features myself.

The main use I have for Codespaces is making changes to repos on a machine that is not my own. There are times when I need to add a new feature or fix a bug on a tool I use, and for various reasons I cannot (or choose not to) setup a dev environment on the machine I’m working on to make the change. A case like this would have me look at one of the alternatives, or even make use of the GitHub web-editor. The web-editor works but doesn’t really offer much when it comes to building and testing your changes (I’ll talk more about the alternatives later).

I should say that this doesn’t happen very often. Most of my time I’m on my own machine, and I have no need for a web-based dev environment as I can just use the environment I have. But when that’s not possible, being able to spin up and make the change in Codespaces, complete with a Linux environment which you have sudo access to, is quite useful.

Codespaces is also pretty nice in terms of a coding environment. This is no real surprise since it’s based on VSCode, but compared to the alternatives, the little things like keystroke performance and doing things quickly in the editor make a huge difference. I’ve tried a bunch of alternatives in the past like Cloud9 and CodeAnywhere, and Codespaces is by far the most polished.

Another advantage Codespaces have over the comparison is that it seems suited to throw-away development environments. It might be possible to keep an environment around for an extended period of time, but I tend to spin up temporary workspace when I need them. The alternatives tend to prefer a more long-lived environment, which involves a lot setup for something that is kept around. This feels like splitting your dev environments in two, and I always feel the need to select one as the “definitive workspace” for that particular project going forward. I don’t feel that with Codespaces: I can quickly spin up a new environment, which has most of what I need already installed, and make the change I need with the full knowledge that once I no longer need it, it will be teared down (pro-tip: always push your changes to origin once you’re done making your changes in Codespaces). It helps that spinning up a new environment is quite fast.

So, that’s my impression of GitHub Codespaces. I’m not sure who has access to it: you may need to be on a paid plan, for example. But if it’s enable for your account, and you find yourself needing a temporary, cloud-based dev environment to do your work in, I’d suggest giving it a try.