" is now banning the popular Linux browsers named Konqueror, Falkon, and Qutebrowser from logging into Google services because they may not be secure." 🤦‍♂️

@Kevin gonna ban those but not IE9/IE10 over "security"


@quad @Kevin it's not secure if it neuters goolag's skynet!

@Kevin And I'm seeing more sites that push you to use only chrome for transactions on that site. Shades of Microsoft IE a decade or so back. Ugh.

@Kevin that's crappy.

@Kevin 🙄 and just the other day, I used to check Gmail with Lynx!

@Kevin Guess they are pushing for that browser monopoly bit by bit.

changing to 's seems to circumvent this for now according to the thread:

@Kevin ughh, the browser monopoly is such bad news for the internet

@Kevin Hmmm, they'll block browsers because "Don’t support JavaScript or have Javascript turned off."?

This is funny because I consider JS to be a security hole. (Yes there's a sandbox, no I don't trust it)

@Kevin Solution: don't use Google services. I never used Chrome anyway, very glad I never fell for it. It's pure evil, 100% malware. The web was more inclusive in IE6 days! Block Google to your sites! The Linux community is still way too friendly for Google/Android.

@Kevin That is dumb.
The best part is that you could just fake your browser info with a plugin an pass the check.


Google trying to call out others for not being secure. Funny. Luckily I don't use Google services so they can take their banning and shove it.

@Kevin NOOOO! my precious Falkon! They can't ban Falkon, I hate it slightly less than every other browser I've tried!

@Kevin "May not be secure", as opposed to Chrome that they made sure is not secure and will spy on you?

If you own a browser and you start to block other browsers you should get with an anti-trust lawsuit right in the face, at the bare minimum.

@alcinnz @Kevin if you're making a browser, make sure to support just a little JS

@jookia @Kevin Odysseus supports JavaScript, Rhapsode does not. I feel like I have no other choice.

Not that I like JavaScript, as I consider it a security threat that's vastly overcomplicating web browsers.

@alcinnz @Kevin will you offer an alternative for accessibility features like ARIA?

@jookia @Kevin Definitely!

Rhapsode is a voice browser, it is accessible to the blind (but not deaf), and you'll be able to deliver pretty much whatever verbal experience you want as a webdeveloper.

@Kevin google self-censoring and helping people migrate


Dear Gooooooogle,

Please don't ask for my user agent string. Some of my answers may make you feel insecure.

Inhale, exhale, it's just that I don't need you.


@alcinnz @Kevin So ... what about the deaf?

@alcinnz @jookia @Kevin Will it still support text though? Obviously not even people with good hearing can use a voice-only application in every situation.

@grainloom @jookia @Kevin The vision I want to illustrate with it is that we can create different browsers to present The Web in mediums. So if audio isn't the appropriate medium for you, use a different browser!

Though I will still support keyboard input on laptops/desktops.

@alcinnz @grainloom @Kevin Why do they need to be different browsers? Can't they share code and just have different frontends?

@jookia @alcinnz @Kevin I'm mostly worried about the content I guess. If the content can be browsed by anyone, then I think it's fine to create specialised browsers. But maybe give them warnings when the content wouldn't be accessible in the other ones or something.

@jookia @grainloom @Kevin They can absolutely share code!

There's plenty of XML (and to a lesser extent, HTML) parsers & HTTP clients already, and I made sure my CSS engine can be flexibly reused.

@grainloom @jookia @Kevin You'd *really* have to go out of your way to write content that can be heard in Rhapsode but not viewed in, say, Firefox! I'm not concerned.

The content's ordinary HTML5 you can style differently for different mediums.

@alcinnz @grainloom @Kevin Uh, re my original question: How will you support features like ARIA does? For instance, a dropdown menu.

@jookia @grainloom @Kevin I haven't implemented the input side yet, but you'd need to frame it in terms of hyperlinks. Those'll become commands the user can trigger either typing or speaking them aloud, as indicated by a preceding beep. Otherwise the page will be entirely static.

For the dropdown menu case you could link to a "" and tell it to only read the menu when it's the ":target". Or you could use <details> which'll do the exact same thing.

@jookia @grainloom @Kevin And before you ask, I do plan to implement webforms probably late next year.

@alcinnz @grainloom @Kevin I'm not gonna lie, it rubs me the wrong way that you're building software that's deliberately inaccessible

@jookia @grainloom @Kevin Great intuition!

@alcinnz @grainloom @Kevin I'm not saying it's the wrong approach? But I haven't seen such a thing done before in a good way.