EU negotiators agree new rules to rein in tech giants (opens in new tab)

Nice!

> Of course, some platforms ban you for using alternate clients.

Less nice... Doesn't seem like that list outlines which platforms will/could ban you either, which makes the entire list a no-go for me, and I'm sure others.

I am really loving this news, i was able to convince some of my old icq contacts back then to switch to jabber this way. And why wouldnt they if its all the same interface?

I don't think this is to be interpreted as "from now I need to be able to send messages from a Whatsapp client to a Signal client"

Of course any such app would be able to read all the messages in the clear and would be able to store them in the clear, leak them, sell them or whatever. As with any other case in which you choose to use a chat app you have to trust the chat app to read your messages if it wants to

I imagine if that's the case whatsapp or signal, when you do a first login from a different app, will flash a warning that you're using a third party client which might not be trustworthy

https://signal.org/docs/

And if they are deliberately breaking existing third-party apps for no reason, well I'm sure EU courts would like to have a word.

Actually I expect the usual outrage about limiting innovation or threats to leave the EU but consider that this interoperability is also a moat especially if they agree on some complicated protocol with no previous implementation.

I'm not sure what the current market cap for Signal is, but I'm fairly sure they don't have a turnover of 7+bn in the EU.

makes no sense. you can already pull all your data out of those services and import it into whatever other service you want.

https://wikiless.org/wiki/Fediverse?lang=en

No. They are asking for endpoints and public APIs. Nobody is forced to adopt a standard, that is a fallacy you have just built (and has powered a tangential thread of 20 messages and counting.. debating something that is not in the topic).

Services will be forced to provide public endpoints and public APIs. Nobody is forcing them to shape them in any way. Consumers can decide to interface with them, or not. The onus on implementing and interfacing with them lays on the consumers. You don't need an agreement between everybody.

A more successful example of open standards would be the various standards that browsers use. Would you say that browser innovation has slowed down? The model adopted there is less "Wait for everyone to adopt this new standard we wrote" and more "If you have a feature you found many people are using, suggest it as a standard and we'll get all browsers to implement it".

This model could be replicated to messaging solutions as well, without slowing down any innovation as companies can add new features, as long as they get standardized over time.

Capability negotiation is a thing. It's perfectly fine to support some baseline feature set (one-to-one text messages) and build more optional features on top of it. But, yes, it's important that the protocol is designed to be extensible in the first place.

It's a big thing. And it's a great thing.

Already in email you have some cool features that only work Gmail to Gmail but you can still send basic emails to people outside of Gmail.

Businesses will not need business accounts on 6 different platforms just so thay can have a simple chat with all their customers.

Nothing prevents people from releasing a new RFC describing their feature and how to implement it. See: EMail attachments (RFC 1521) which came after the original EMail definition (in RFC 822). And what you describe as "email insecurity" is just a common disagreement which encryption method to use in your MIME attachment (defined in RFC 989) - your argument sounds a bit like protesting that not everyone is using Word files when sending text attachments.

(Note: EMail metadata is deeply "insecure" and can theoretically be used to glean information about communication - but if that's your concern, maybe email is just the wrong format for you and something like encrypted messages over a network of Kafka-style message streams, ideally with lots of noise in it, would be better suited).

Email is a totally different problem because it's a suite of a multitude of different standards used across countless different platforms. At least with proprietary messaging services Facebook et al will still be the implementation standard that most people will use (given that habit has already been well established) but lesser used 3rd party clients wont have to worry as much about Facebook breaking the protocol to intentionally break support for 3rd party clients. However I'd wager you will still see new proprietary features added that will not function in 3rd party clients if just to convince users that the 1st party app is the better client.

Btw, does anyone here remember off hand what happened to the "concern" the banking industry had with TLS 1.3?

My understanding is someone just came in at the last moment and basically wanted to change the entire design of TLS 1.3 because their workflow would no longer work because of forward secrecy.

https://news.ycombinator.com/item?id=12641880

On one hand, that is not right: open standards mean no walled garden, rather than each garden equally ugly.

On the other hand, that is exactly the point: no new feature can be used to buy the users' freedom to interact with customers of other services.

So if I'm whatsapp I have to allow third party clients, but I can also change my API as needs change, as long as I don't lock it.

Close standards is not inherently different (people who work in telecom can likely attest to that), but closed standards has a higher probability to be owned by a single entity. A single entity has a much easier time to coordinated a switch with themselves, or align their own incentives with their own incentives. If you are alone or don't need to work with others, cooperation is trivial. Obviously, having everything owned by the same entity also has its drawback. If you don't like the new price, features, tracking and forced advertisements, well tough luck. While spam is an issue with email, I am not forced to wait 3 seconds and click "skip add" every time I read an email. I also don't need to pay per email, in contrast to sms. Email could had been much worse if it was a closed standard owned by a single entity.

The usual answer for avoiding the need for everybody being "on board" with the changes is capability negotiation. Unfortunately, that doesn't work for email since it's a unidirectional, store-and-forward protocol: the sender has no way to negotiate capabilities with the recipient (or recipients, in case of a mailing list). If for instance I invent a new rich-text format for email, I have to include a fallback format on every message, since I cannot know whether the recipient can read my new format.

> Feel free to replace email for TCPv4/v6.

With TCP, there's another issue: middleboxes. While TCP does have working capability negotiation, unrelated third parties (which were not part of the negotiation) interfere with things they don't understand. If for instance I introduce a new TCP option which when negotiated changes the meaning of the sequence number field, a stateful firewall would drop the data packets even though they're valid for both endpoints. Due to the large amount of middleboxes in the wild, the design of TCP has been effectively "frozen", in that any enhancement will break unexpectedly for a large subset of users.

> The only successful open standard i can think of would be HTTP.

What saved HTTP was SSL/TLS. By making it hard for middleboxes to interfere without actually acting as an endpoint (with negotiation), it allowed the protocol to evolve. The best example is HTTP2: while there is a cleartext version of HTTP2, nobody uses it because it would get broken by middleboxes.

Stop repeating this talking point of big tech. This is FUD. Sure, developing the standard further requires more work and is slower if just one person alone developed it, but the upsides clearly overweigh.

Furthemore, everonye is free to build their own features in their own app that are not part of an open protocol (good examples are snooze or send later features in email).

PS: As a sister comment pointed out, open standard is not even in the scope of this new EU act. It's only about opening up their APIs. They are not foced to use an open protocol.

“at least” would be serious

But that would require for politicians to actually want to do something to benefit the people, not just themselves and their bribers/lobbyists.

Masterful communication on top of solid analysis. I’m going to keep a copy just to review when I’m writing my own reports to stakeholders.

I very much want this to happen now. However I would not have wanted this 15 years ago when the platform was a baby and little was known on how to move it forward. Last thing you wanted at that time was layers of regulation and laws that would hinder the speed of development.

15 years is probably too long and this could have happened 5-10 years ago.

If you really want some nasty stuff on your phone for some reason you can always write it yourself or find something open source and install it with Xcode. You are free to do this; the idea that you are not is a myth regurgitated by haters who don’t think for themselves. Just good luck doing it on someone else’s iPhone without their permission.

> DUKE Apple charging 30% App Store tax

Note that Income tax is in reality earnings tax (as expenditures are generally subtracted), while Apple/Google fee is based on just income.

The right thing here would be making a standard, modern way of communication that supersedes SMS/MMS with a push for global adoption that has all the necessary features of sending videos/images/links/locations etc. with E2EE that is part of GSM technology suite which is either super cheap or free, to offer a sensible alternative to free but closed down services offered by giant companies. That would be much more fair play for a free market.

If there is an inconsistency introduced (e.g. I can send something to one user but can't to another) it will just confuse the users more.

About malicious compliance, yup, it will probably happen. If I were a company with my platform and someone comes to me and says that I have to open up my own private platform, I probably would implement the bare minimums to not get fined, and cripple that part in every conceivable way, while still "complying" with the law. I'm a private company and want people on my platform, simple as that.

Not saying that it couldn't happen in other setting, but innovation definitely did happen in the current fragmentation of silos.

The DMA is a Regulation, not a Directive. It doesn't need to be transposed in to national law in member states.

Regulations become law across the whole EU (and usually the EEA as well) as soon as they are published in the Official Journal.

The DMA is a regulation, not a directive btw.

That's why I'm asking these questions.

I still don't quite understand on which stage this initiative is at the moment and how long until it is enforced.

I'm running my own mail server. The problem with regards to spam is not that it's hard for me not to be inundated by spam: I'm just running spamassassin and qpsmtpd with mostly standard configuration and my account on my own server is rather better at catching spam and not ham than my Gmail account. The problem I've always been fighting with (it's better lately) is that Google (and to a lesser degree Yahoo and Microsoft) tends to put my mails into the recipients' spam folders.

It's understandable that a minimal level of centralisation is necessary with email so as to build up server reputation. I think that level is already satisfied with just a few dozen or maybe hundreds of emails sent per day. If there are many installations of that size, companies like Google are forced to accept mails from them, and there's no need for further centralisation.

> Google along with the rest of the industry has essentially killed email spam through the many additions to classical email standards. From reputation based delivery, to spam databases, crypto signatures and more.

I don't see Google having had an exceptional role in "killing" email spam that way. Spam databases (both server reputation as well as content fingerprints) existed before Gmail started, DomainKeys was designed by Yahoo[1], the DKIM (the current way to add cryptographic signatures) RFC[2] does not list anyone from Google as its authors, bayesian learning was published by PG[3] in 2002. Gmail launched 2004[4]. Giving reputation much weight was something easy for them to do and it does tend to come at the cost of small legit servers.

They had a solid implementation early on (both the spam filter and, for the time, a top notch HTML UI), had of course a good name, and were free, so they were a default choice for anyone who was with an email provider that didn't do well (like many (most?) ISPs). There are reasons for people to flock to a strong, large company, that's not different here, but I contest that spam necessitated this.

That said, any new protocol would do well to take the problem of handling spam seriously and learn from and improve upon the past.

TL,DR: my argument is that spam is (somewhat) easier to handle in a centralised way, just like most problems are, but handling spam doesn't inherently require centralisation.

[1] https://en.wikipedia.org/wiki/DomainKeys [2] https://www.rfc-editor.org/rfc/rfc6376.txt [3] http://paulgraham.com/spam.html [4] https://en.wikipedia.org/wiki/Gmail

Zoom illegally sold users' personal data [1] and Teams unsurprisingly turned out yo have all the security features we'd expect from Microsoft [2]. Jit.si comes out looking pretty good.

It's hard to hold up as paragons of good tech products that required a global pandemic to do their marketing and still couldn't deliver the goods without getting caught with their hands in the cookie jar.

[1] https://www.cbsnews.com/news/zoom-app-personal-data-selling-...

[2] https://www.forbes.com/sites/thomasbrewster/2020/04/27/your-...

Please attack my arguments, don't make aspersions as to my disposition.

> the problem is that we moved away as an industry

Please don't try to define the narrative from a parochial viewpoint. No. we didn't. Some of us did. And those few have arguably done a great deal of damage to "the industry".

> widely used standards take decades to change just slightly, or never (see SMS, email)

It's arguable that they _should_ take a long time to adapt, because stability is also a value. That doesn't preclude the emergence of new and better standards which have a fair chance of adoption in the market for protocols. Interoperability would be a key factor in their success of course.

> interoperability means either lowest common denominator

I see no justification for this statement. There are many factors that portend lowest-common outcomes, like efficiency, reckless engineering in pursuit of fast time to market... but interoperability isn't one of them.

> or a huge cost to keep things interoperable

This is what you're really shooting at isn't it? Less profit for people who want to "move fast and break things" and get out when they're done extracting. I prefer to build lasting things and treat technology as a part of long-term culture. It's just a personality type thing.

> horrible for innovation

Advancing dichotomy between standards and innovation is simply disingenuous. The entire existence of the internet is a counterexample.

> killer for funding, both pull money away from other things.

Money.

> all for giving "jit.si" or your "home grown WebRTC solution" a reason to exist.

No. Everything else you've said is about differences of value and philosophy. Fair enough. But on this point you are missing some fundamental understanding of technology.

It is not "all for" my choice. Choice is a means not an ends. Choice is what underpins the drive for innovation, but ultimately there is telos (purpose) in technology beyond making profit. Those ends include resilience, opportunity, reliability, hybrid vigor of hetrogenous systems to name a few. Naivety is having a partial or immature understanding of a bigger picture, though I would not accuse you of that of course.

respects

A moral question would be "how much should governments control voluntary interactions between customers, platforms and products?" The immoral answer might well be "As much as it will help them gain short-term votes", not the moral one.

* The EU

* Tech sector

The legislation, at least the one coming from Brussels, is nearly always reasonable in scope, extent, impacts, penalties, and tends to strike a fair balance between specificity and vagueness as to allow the courts for some wiggle room for interpretation

As an example, with interoperability, the final legislation might stipulate something similar to this:

* once a software service reaches sufficient market size

* the core functionality of the service must be exposed for interoperability

* any breaking changes to core functionality must allow for sufficient period of backwards-compatibility and deprecation warnings. Exceptions for security breaches or other emergencies

So, for Youtube, this would mean logging in, viewing videos and history. It doesn't mean that every single feature of every single web site must be publicly exposed and be backwards-compatible for eternity

It is a similar death spiral to how we deal with the housing problem. People have a hard time finding affordable apartments in the city centers? Create more laws that limit rents! Does this create more apartments? No. It just send the local housing market further down the drain.

Intellectual property protection is opt-in. It requires the individual to enforce his rights before a court in the relevant jurisdiction. The government only facilitates registration and adjudication. Courts don't force individuals into global protection schemes against claimant's own will.

Whatever the expected merits were, GDPR's existence as a policy has been of little more use than a protectionist beating stick in service of the EU. It gave the EU the power to dictate how websites are to be designed. Non-Europeans with business interests inside the EU had no say or representation in the matter. Governments shouldn't claim universal jurisdiction over the Internet, whatever their reasoning for such claims might be.

The general pro-vs-anti regulation dimension of the argument over tech policy seems to lack the necessary nuance if it doesn't ask about antitrust. The lack of antitrust regulation in the US has meant that the SV pipeline which fifteen years ago supported a diverse tech landscape is at risk of degenerating into one that only aims to produce targets for monopolists to buyout. It's a possible future of your "1st model" I'd rather we were more worried about.

Also, cookie banners are mostly bad faith restriction implementation. You can have functional cookies with no banner. What you cant have are those tracking cookies which is what the whole thing is about.

That depends on the religion. For a bit more context (read the full history in [1]): As part of the 1800s separation between state and church, the major ones (Catholic and Evangelic-Lutheran) got the right to a percentage of employed people's wages as a sort of "membership fee". This gets deducted by the employer out of your paycheck and collected by the tax office, then distributed to the church you're a member of. Over the years, the right to collect these taxes expanded by quite a number, although currently only the Roman Catholic, Old Catholic, Evangelic-Lutheran, Free Protestant and Jewish synagogues use that right.

In real life, no one but HR at onboarding cares which religion you specify.

Also note, this is not exclusive to Germany. Italy, Sweden, Austria, Finland, Denmark and Switzerland all have a similar system.

[1] https://de.wikipedia.org/wiki/Kirchensteuer_(Deutschland)

A perfect counter-example to people rambling about EU legislation - Wikipedia.

Consistently in the top 10 sites in the world for 15 years, yet there's no cookie banner, no GDPR consent screen, no personal data hoarding, no dark patterns, etc.

> To determine whether a natural person is identifiable account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly.

https://arxiv.org/pdf/1904.06009.pdf

Turns out writing vague laws lets you turn entities you don't like into cash cows.

Many of the most powerful web tools are not compatible with the GDPR. Google Analytics. Ad marketplaces. Free CDNs. And its all a moving target. I see small companies struggling for years now with these problems. And they will keep struggling for the forseeable future.

I also have experience from two start-up scale-ups that many clients are saying we won't work with you if you use a US Big Cloud. The EU alternatives are much worse and this causes lots of developer waste now ensuring the platform runs as well on the Big Cloud as it does with really terrible EU-cloud.

Look at where we are communicating here. On a US website built by a single person.