Even the first announcement about this included BirdyChat and Haiket. Two completely unknown and yet unreleased closed source chat apps with a waitlist.
Can't help but think they are maintained by people close to Meta dev teams and were hand-picked for a malicious compliance, where they can just point to them as examples, and they make onboarding as complicated and expensive as possible for others.
Correct! This is just Meta doing malicious compliance by being "compatible" with companies with no actual product, three-months old waitlist, no actual users within the EU, and nobody to push back on WhatsApp's definition of interoperability. Then when some real product tries to actually become interoperable down-the-line, Meta's gonna be like "well these two did it just fine according to this backwards implementation, why can't you?"
They're both b2b products that are gonna try to find their first users by pitching the idea that you can use their products to spam WhatsApp users.
Haiket doesn't even try to hide its connection to Meta. All you have to do is to go to their website, click on press, and see in the only press release they've ever posted that its CEO holds patents in use by Meta. Here, let me save you a click: https://haiket.com/press/release-nov11.html
> Alex holds over 10 patents in voice and communication technologies, assigned to and used by Google and Facebook.
> Haiket doesn't even try to hide its connection to Meta. All you have to do is to go to their website, click on press, and see in the only press release they've ever posted that its CEO holds patents in use by Meta. […] Alex holds over 10 patents in voice and communication technologies, assigned to and used by Google and Facebook.
How does this imply he has any connection to Meta? Companies license patents all the time.
> Before Haiket, Alex founded a number of technology start-ups and helped develop innovative voice solutions for Facebook and Google.
At the very least, I think it's safe to say he has some connections within Meta that he utilised for this purpose. He's definitely not a complete outsider whose startup (with no actual product) just happened to be picked by Meta.
My bad. I searched for “Meta” instead of “Facebook.” Quite a few other red flags in that press release.
> Haiket is launching the Beta trial from today, with a pipeline of future innovation for early adopters, including a pioneering silencing technology that will allow users to speak privately in public, with voice communication that only your device can hear.
>> including a pioneering silencing technology that will allow users to speak privately in public, with voice communication that only your device can hear.
Does anyone else think this sounds beyond ridiculous?
> voice communication that only your device can hear.
This is fairly straightforward - you have the device spew out noise with similar characteristics to human speech (ie. random overlapping syllables in the speaker's voice). Take a recording then subtract the random syllables.
Only your device can do the subtraction, because only your device knows the waveform it transmitted.
Obviously in a room with lots of reverb this will be a bit harder, since you will also need to subtract the reflection of what was transmitted with a room profile and deal with the phone moving in the room, but it sounds far from impossible.
Countermeasure: set up four microphones some distance apart, use autocorrelation to pinpoint the sound sources, and then isolate them, recovering the "masked" speech. The countercountermeasure would be to fully surround your mouth and vocal tract with an active noise cancelling system and then produce noise (to push whatever little sound gets through far below the noise floor: the signal is unpredictable enough that you can't use averaging techniques to recover it). The countercountercountermeasure would be to use a camera in the radio band to look at the vocal tract directly, using the phone as a light source, and recover the phonemes that way. The countercountercountercountermeasure would be to construct an isolated box… at which point you're no longer having a voice call in public: you have a portable privacy booth.
Eh, there's no specific definition of interoperability written in the Digital Markets Act. It's decided on a case-by-case basis and I'm sure that the legislators in charge of this case will push back on this piss-poor implementation in like a year from now.
By the time this back-and-forth reaches its end, these two will find some shady b2b customers and are gonna be touted as "successful European startups".
- the default choice needs to be "strictly necessary cookies
- with other less prominent buttons for "allow all" and "deny all"
- a site is not allowed to force you to have the press a bunch of buttons or select a bunch of things to deny most/all cookies
The problem lies in enforcement. Unless you are a huge player, there is almost nil chance you're gonna get fined.
I think about the only thing missing is that they should have RFC'd a standard akin to Do Not Track, except this would have communicated to sites if your default is "strictly necessary", "allow all" or"deny all". With it being set to "strictly necessary" by default.
> The problem lies in enforcement. Unless you are a huge player, there is almost nil chance you're gonna get fined.
I am curious: why is that difficult? Define the fine as a percentage of the revenue of the company, have users report links, and pay someone to check the link and send the fine.
Sounds like easy money... I mean it's very profitable to pay people to check parking lots and fine drivers who don't follow the regulations. This should be even more profitable?
I don't know — why do businesses outside Europe care about GDPR compliance at all? They could just track Europeans all they want to, without any cookie banners.
Tbh most do. It makes sense only for big companies with a multinational presence.
But admitting you are subject to the laws of a country/entity is one thing, sending them your books (when your company is not based there) is kind of on a different level
If you don't care about GDPR at all, then you don't have a cookie banner. So if you have the abusive cookie banner, I think it's fair to say that you care about Europe.
Optimistic. They've got sideloading done, browser and search choice done, ad transparency done, more choice for payments done, many dark patterns banned.
The gears are turning slowly, but they're doing really useful work.
Would love to know how it is "obviously" against my interest to make a chat app and have 3.3 billion users adressable instantly. Bad for internet health to be still tied to Meta, sure, but the damage was done and this is a way to reverse it.
Why would you spend a lot of money to make a better app for whatsapp and let them keep all the revenue?
You won't get enough people to pay you money to use your app to make it profitable. If you think you will, then you have a business already; go build it!
Which revenue? Whatsapp is for free, those 3.3 billion people use it for free, the revenue is the reselling of user data and showing them ads. Which they would do less with a 3rd party client, and as such Meta fights it tooth and nail.
> You won't get enough people to pay you money to use your app
It might surprise you but people build apps just for fun, free and open source for others to use, just to make the world better. Which really would be in this case, that's also the intention of this law.
Why? I'd love to be an alternative whatsapp client with all kinds of new features that the official client doesn't have. Obviously you say you're building a compatible chat network, but the reality is users are just using your client to talk to whatsapp users.
Eg. one feature I'd love is some AI to automatically take any date and time someone mentions to me and put it as a draft event in my calendar. I miss so many events from big group chats I'm not paying proper attention to and suddenly everyone is saying "Whoa, you didn't come to Johns 50th birthday?!? Why not? We invited you months ago[in a group chat with 100 messages a day of mostly memes]"
As probably guessable, the state of author is in has not much to do with the Cracked Android Phone, but that I assume he tries to find remote positions (already a hard find) in US from an African country (assumption, doesn't write details). For that to happen, you need rockstar credentials. No business can accept the risk of fraud, scams, sanctioned origin country, or a dev disappearing overnight.
I was hiring devs for a number of years in EU, and we never ever looked at education - more specifically, any degree was good, as it was only an indicator that the person can learn. I would never assume practical software engineering knowledge based on a degree.
Anyone in the same situation, what the author did is a perfectly good way - build up knowledge, get mentors, build up a portfolio, work for well-known entities. But then judge your market value realistically, and possibly be in the same region/country. Even if it could technically possible, remote work with such distances has too much legal liability.
You're right that I'm looking for remote positions from Zambia, and that distance adds complexity. But I don't think the issue is legal liability or risk of fraud.
I worked remotely for Bellingcat for 8 months. They're an internationally recognised investigative journalism organisation. If they could verify me and manage the "legal liability," I don't see why tech companies can't.
The risk assesment you're describing assumes that being from Africa without a degree makes someone inherently risky. But I have verifiable work history, public code, and people who can vouch for me. That should count as verification.
I understand market realities. I'm not expecting to walk into a senior role at a FAANG company. But entry or mid-level positions shouldn't require "rockstar credentials" just because of geography. That's not about risk managment, it's about gatekeeping.
The advice to "be in the same region/country" isn't practical when there are very few tech opportunities locally that pay a living wage. Remote work was supposed to democratise access to these jobs. If it only works for people in certain countries, that's a problem worth pointing out.
Congrats to creating something you think is valuable. Do you see a risk that your business model is taking away income from an API provider that you 100% depend on - meaning the plug could be pulled at any minute while you have paying customers?
I see these posts left and right but no one mentions the _actual_ thing developers are hired for, responsibility. You could use whatever tools to aid coding already, even copy paste from StackOverflow or take whole boilerplate projects from Github already. No AI will take responsibility for code or fix a burning issue that arises because of it. The amount of "responsibility takers" also increases linearly with the size of the codebase / amount of projects.
That's quickly becoming the most important part of our jobs - we're the ones with agency and the ability to take responsibility for the work we are producing.
I'm fine with contributed AI-generated code if someone who's skills I respect is willing to stake their reputation on that code being good.
We still do that, it's just that realtime code review basically becomes the default mode. That's not to say it's not obvious there will not be a lot less of us in future. I vibed about 80% of a SaaS at the weekend with a very novel piece of hand-written code at the centre of it, just didn't want to bother with the rest. I think that ratio is about on target for now. If the models continue to improve (although that seems relatively unlikely with current architectures and input data sets), I expect that could easily keep climbing.
I just cutpasted a technical spec I wrote 22 years ago I spent months on for a language I never got around to building out, Opus zero-shotted a parser, complete with tests and examples in 3 minutes. I cutpasted the parser into a new session and asked it to write concept documentation and a language reference, and it did. The best part is after asking it to produce uses of the language, it's clear the aesthetics are total garbage in practice.
Told friends for years long in advance that we were coal miners, and I'll tell you the same thing. Embrace it and adapt
>the _actual_ thing developers are hired for, responsibility.
It is a well known fact that people advance their tech careers by building something new and leaving maintenance to others. Google is usually mentioned.
By which I mean, our industry does a piss poor job of rewarding responsibility and care.
You know how forums turned bad because people with good manners/communication skills can just go to a different discussion place so over time you consolidate with a toxic base of people with nowhere else to go?
Even if a company tries to get rid of the bad people, once you start doing random, the line must go up layoffs, the best people leave and then use their network within the company to poach the next down layers of good people. Current American 'layoff while spending the money on stock buybacks' is corporate suicide.
I wish there were some self-hosted setup that would replicate this based on either tags, bpm matching, or other similarity indicators snooped from online sites like lastfm.
I've been using https://www.beatunes.com/en/beatunes-matchlist.html (35€ for Mac or Windows) to create static playlists like this for years from my library of ~13K songs. I've created a few dozen such playlists with light curation (just kicking a song out here and there). I find myself listening to these playlists far more than the ones I created completely by hand.
I suppose you could do it often, or maybe even script it (e.g., with Keyboard Maestro on Mac) to get something a little more dynamic. But it's not something that just matches songs on the fly server side.
Can't help but think they are maintained by people close to Meta dev teams and were hand-picked for a malicious compliance, where they can just point to them as examples, and they make onboarding as complicated and expensive as possible for others.
reply