I don’t think you even need to be particularly cynical to see how that will screw things up.
It is totally anti-thetical to the internet/web as we know it to insist that a web browser behave exactly according to the website’s demands before it’s any meaningful responses will be served.
Amazing how Google has turned into exactly the evil they presumed claimed to not be when they started.
Perhaps it will become necessary for anyone who values freedom, open source, free software, etc to implement something like WEI for their own sites that will visibly and openly deny access to (or at least gate keep) people using major, mainstream browsers.
I guess the only question is when consumers will notice this and just refuse to participate in stuff that only works via chromium, safari etc.
I’ve got nothing against digitalization as such, for example the idea to have tickets as well defined tokens in an application on my device designed for such tokens is great, the idea of beeing forced to download software from ‘trustworthy’ companies like my local transportation provider (who just recently got hacked) to use their tickets is insaane.
It’ll be interesting if we manage to move away from the web as a platform as a whole
Perhaps it’s not quite as evil as we first believed:
We had proposed a hold-back to prevent lock-in at the platform level. Essentially, some percentage of the time, say 5% or 10%, the WEI attestation would intentionally be omitted, and would look the same as if the user opted-out of WEI or the device is not supported.
This is designed to prevent WEI from becoming “DRM for the web”. Any sites that attempted to restrict browser access based on WEI signals alone would have also restricted access to a significant enough proportion of attestable devices to disincentivize this behavior.
This sort of concession is nothing more than an attempt to gain the support of those with valid concerns, such as Mozilla. The danger in this sort of proposal is that it is a ‘foot in the door’, so to speak. The big risk is that once they have this implemented, they can then drop the infrequent token omitting, thereby achieving vendor lock-in with far less friction than they would have initially faced if they had done it all at once. Even if the people writing this spec have the best of intentions, you are trusting them to continue omitting attestations on an ongoing basis. If those people are then replaced (as they could be, since this is a corporate Google initiative), they could simply turn on the attestation all of the time. It is dangerous to give a single company this power, especially given how much influence they have over the web already.
Their goal is to fight against robots, because they want to guarantee that the ads on the web (Google main source of income) are viewed by real humans.
They currently do this with captchas, and they already have some cases where Chrome won’t show the captcha, but other browsers will. This will make sure that every non-certified browser gets the captcha every single time, while certified ones (Google Chrome) only get it 10% of the time.
The effect will be, of course, that more and rore people will use Chrome and the other browsers will get single-digit percentage of tne market, which will not be worth supporting by any company doing websites.
I’m sure that makes up a significant part of their goal, but it doesn’t change the fact that trying to enforce it the way they are (coming at you from both ends – via both the browser and by coercing web servers/web site owners to comply) is very anti-user and maybe anti-human.
Perfect example of how large tech companies and their customers are the completely and totally unwilling to actually engage with users about what is acceptable. Just shows that we still very much need laws to compel them to behave responsibly.
Even if it didn’t cause the kind of problems we are discussing here, it’s still very much against the whole premise of an “open internet”. That is precisely because it forces us to accept their advertisements as a fundamental reality in exchange for using their browser (minimum) or even just trying to use the internet/web (maximum).
The simple reality here is that it is very much necessary for the “Haiku project” to do their work using software and platforms that are accessible and usable for most people.
That doesn’t exactly favor ancient systems and approaches that might be more accessible from technology that is increasingly old (plain truth), potentially outdated (semi-subjective, but also just how things are), or simply a result of niche interest and limited development/support.
I’ve gotta say I agree with Null here, discuss and gerrit work terrible in webpositive, and really any webkit browser. They aren’t ment to be good websites but rather an “application on the web platform”
Gerrit keeps breaking on updates requiring us to “fix” webkit by updating it or enabling random apis, this isn’t really what I want to spend my time on for webkit : /
They effectively don’t trust the browser
to do anything, gerrit and discuss both don’t use just the normal text input but heavily modified ones that break normal input as a result: gerrits text views cant be selected half of the time on ios safari, their ligitaures font crap doesn’t use “just” normal chars, emoji input in discuss is completely broken, the text cursor can’t be used properly etc.
All of this would be much easier and better if the website software would “simply” trust the browser to do the right thing : /
Edit: I really like gerrits workflow, just not the software, I do hear a lot of cursing from the admin side aswell, I do wonder if this could not be done much better with a native application (even if we were to continue using the same api, and thus backend)
I think the term you are searching for is “not made by google”
Haiku isn’t old at all as far as iperatibg systems go, and our webkit port is usually even ahead of safari. It’s easy to claim it’s old because we don’t ship a flat theme but that just isn’t the case.
I’d like to point out yet again that this is all by design to force the users to use certain technologies. Luckily Googles latest move makes this so much easier to see.
I remember a website that implemented a fully working desktop with applications, and it was around the year 1999-2000. 20+ years later and we are forced to update to the latest software several times per year in order to visit pages that are trivial in comparison. You need to understand that they use compatibility in order to force us into using technologies.
The solution by the Haiku project is to simply decide that all their services should be fully functional on a certain set of software. 10+ year old hardware and software should be supported. There is no technical reason not to.
Our software is supported on an up to date version of Haiku and our web software on the latest version of HaikuWebKit. I don’t see why we should be forced to live 10 years in the past.
There are many downsides to the modern web, but there are a few good ideas as well.
There is gertty that implements a curses based interface so you can do all Gerrit things from the Terminal. I should test it again now that we have the new login page, because previously I couldn’t get it to connect to our Gerrit server.
On the contrary, I am not “searching” for any term at all here.
My point is not Haiku specific and WebPositive itself isn’t particularly relevant. The point is simply that the rest of the world proceeds forward whether you do or do not. It can be problematic to rely upon tools that nearly everyone else no longer uses.
That basic principle applies to everything from operating systems, CLI tools, and compilers to everyday stuff like web browsers and office productivity software.
The solution by the Haiku project is to simply decide that all their services should be fully functional on a certain set of software. 10+ year old hardware and software should be supported. There is no technical reason not to.
There are two entirely different ideas there, the first is reasonable and the second is somewhat silly.
Sorry about that: I was going to write more, but someone came barging into the office and wanted help with something ASAP so I just saved what I had. Possibly not the best decision!
So, in summary: Google’s plan to “validate” browsers has been officially cancelled. It’s possible that they’ll try again at some point in the future, but we’re in the clear for now.
Well, it looks like they decided to implement it in a different way: Youtube is now complaining about ad blockers. They will probably continue deploying this and maybe start rejecting non-chrome browsers. And they have enough market share (on both websites and browsers) that they can do whatever they want here.
So, I wouldn’t go as far as saying we’re “in the clear”, as far as Google owned websites are concerned, at least. But, this may help with the development of non-Google websites, so, let’s see what happens next.
