3 ms·

The other component of the regulatory package, the DMA (Digital Markets Act), brings interoperability obligations. This aspect is arguably primarily related to

by cpa 3y ago

The other component of the regulatory package, the DMA (Digital Markets Act), brings interoperability obligations. This aspect is arguably primarily related to competition rather than content moderation, which is why it falls under the DMA rather than the DSA (Digital Services Act).

sylware 3y ago
Ok, DSA and DMA, but as far as I can remember, No DMA news on the actual technical interop grounds. What are the reasons of that? I wonder.
- di4na 3y ago
  What do you mean no news? The interop mandate is still in it?
- jeroenhd 3y ago
  The DMA requirements for interop has a longer lead time. They won't go into full force until 6 March 2024. With the IETF still working out MIMI and MLS, that's not necessarily a bad thing in my opinion.
  - sylware 3y ago
    What are those MIMI MLS? Why is it the first time I hear about this? What's extremely important is how modular is the technical interop, and above all modules (and not 748397498324 modules) must be reasonable to implement by one individual normal developers (well, for the crypto module, "normal" is not enough). Hope we don't get a remake of the "semantic web" which end up pushing forward the current abomination of web engines (including their SDK).
    - jeroenhd 3y ago
      MIMI is a system to allow different chat services to communicate with each other. It's intended to be the protocol between WhatsApp and Signal, for example. MLS is a standardised encryption standard for messages, including a protocol and an architecture, to ensure that MIMI can be implemented securely. MIMI and MLS are still being worked on by the IETF taskforce so you probably haven't heard of it because it's not even sure how it works exactly yet. The difference between these protocols and the semantic web is that people from actual chat apps actually got involved in its development rather than just being a good idea by a bunch of ideological people.
      - sylware 3y ago
        So MIMI is a server-server protocol... even worse than what I thought, it is a "interop" client-server protocol which should be worked on. Because signal or whatsapp, same same to me, I don't want them, but I would need to interact with some people there: namely create an account, and use a light open source client (not using any of those grotesquely and absurdely massive and complex web engines... and their SDK). I have a very bad feeling about this. EU regulators seems to miss the point: in this very case, it is the client protocol which should be open, stable in time and super ez to implement by even a normal individual dev (not the TLS part ofc). Then, there is the account creation or guest account, etc. A friend told me EU started to emit user specific certificates.
        jeroenhd 3y ago
        I don't see why we would specifically need an open client protocol, the goal is to prevent gatekeepers from locking users inside their networking effect. The EU does not state specifically how gatekeepers must open up their services. For all we know, iMessage will open up a web API that offers the same functionality rather than sticking to MIMI. The IETF called for a unified protocol and people from several projects started laying down their requirements and suggestions, that's it. In my personal opinion, an open server-to-server system would be better than an open client. An open client protocol would pretty much limit messengers in their functionality for the next ten years, because WhatsApp couldn't possibly alter their image upload API unless they're willing to risk an EU investigation. You'd also end up with ten different APIs, all in various states of feature support and implementation details, and if someone does manage to make a unified app, you'd end up with ten different contacts for the same person. You're never getting a simple client API with modern chat messengers. E2EE is practically a requirement these days, and E2EE is hard to accomplish. Requiring a simple client would actually make the situation worse, allowing the EU to basically force chat apps to break their E2EE properties because of "API compatibility" reasons. I don't think anyone but the worst politicians want that. I don't know anything about user specific certificates. There are some EU countries that permit authenticating to government services using a smart card, but that's got very little to do with this whole system. It's certainly not something we use to authenticate with chat services.
  - sylware 3y ago
    I had a look at MIMI and MLS: this is IRC with/without TLS. Is this really from the EU? What's need to be done is to clearly defines the various URIs to navigate between the various clients (with/without TLS): IRC client, voice/video conf client, email client. For the voice/video conf, it is still a slipery slope as I don't think there is an actually simple voice/video conf protocol yet: no, webrtc is not reasonable, I am talking about a brutally simple protocol namely direct TCP IPv[46]:port (signal, video stream, audio stream and the client will have to deal with UPNP IPv4) with optionaly a DNS name (like SMTP where the DNS is optional). and again, it is missing the web: noscript/basic (x)html, 2D semantic HTML documents.
  - extraduder_ire 3y ago
    I both love and hate the long lead-times that EU regulations tend to have. It's occasionally a surprise to me when it comes into effect after I forgot about the law.

by cpa 3y ago

sylware 3y ago

Ok, DSA and DMA, but as far as I can remember, No DMA news on the actual technical interop grounds. What are the reasons of that? I wonder.

di4na 3y ago
What do you mean no news? The interop mandate is still in it?
jeroenhd 3y ago
The DMA requirements for interop has a longer lead time. They won't go into full force until 6 March 2024. With the IETF still working out MIMI and MLS, that's not necessarily a bad thing in my opinion.
- sylware 3y ago
  What are those MIMI MLS? Why is it the first time I hear about this? What's extremely important is how modular is the technical interop, and above all modules (and not 748397498324 modules) must be reasonable to implement by one individual normal developers (well, for the crypto module, "normal" is not enough). Hope we don't get a remake of the "semantic web" which end up pushing forward the current abomination of web engines (including their SDK).
  - jeroenhd 3y ago
    MIMI is a system to allow different chat services to communicate with each other. It's intended to be the protocol between WhatsApp and Signal, for example. MLS is a standardised encryption standard for messages, including a protocol and an architecture, to ensure that MIMI can be implemented securely. MIMI and MLS are still being worked on by the IETF taskforce so you probably haven't heard of it because it's not even sure how it works exactly yet. The difference between these protocols and the semantic web is that people from actual chat apps actually got involved in its development rather than just being a good idea by a bunch of ideological people.
    - sylware 3y ago
      So MIMI is a server-server protocol... even worse than what I thought, it is a "interop" client-server protocol which should be worked on. Because signal or whatsapp, same same to me, I don't want them, but I would need to interact with some people there: namely create an account, and use a light open source client (not using any of those grotesquely and absurdely massive and complex web engines... and their SDK). I have a very bad feeling about this. EU regulators seems to miss the point: in this very case, it is the client protocol which should be open, stable in time and super ez to implement by even a normal individual dev (not the TLS part ofc). Then, there is the account creation or guest account, etc. A friend told me EU started to emit user specific certificates.
      - jeroenhd 3y ago
        I don't see why we would specifically need an open client protocol, the goal is to prevent gatekeepers from locking users inside their networking effect. The EU does not state specifically how gatekeepers must open up their services. For all we know, iMessage will open up a web API that offers the same functionality rather than sticking to MIMI. The IETF called for a unified protocol and people from several projects started laying down their requirements and suggestions, that's it. In my personal opinion, an open server-to-server system would be better than an open client. An open client protocol would pretty much limit messengers in their functionality for the next ten years, because WhatsApp couldn't possibly alter their image upload API unless they're willing to risk an EU investigation. You'd also end up with ten different APIs, all in various states of feature support and implementation details, and if someone does manage to make a unified app, you'd end up with ten different contacts for the same person. You're never getting a simple client API with modern chat messengers. E2EE is practically a requirement these days, and E2EE is hard to accomplish. Requiring a simple client would actually make the situation worse, allowing the EU to basically force chat apps to break their E2EE properties because of "API compatibility" reasons. I don't think anyone but the worst politicians want that. I don't know anything about user specific certificates. There are some EU countries that permit authenticating to government services using a smart card, but that's got very little to do with this whole system. It's certainly not something we use to authenticate with chat services.
- sylware 3y ago
  I had a look at MIMI and MLS: this is IRC with/without TLS. Is this really from the EU? What's need to be done is to clearly defines the various URIs to navigate between the various clients (with/without TLS): IRC client, voice/video conf client, email client. For the voice/video conf, it is still a slipery slope as I don't think there is an actually simple voice/video conf protocol yet: no, webrtc is not reasonable, I am talking about a brutally simple protocol namely direct TCP IPv[46]:port (signal, video stream, audio stream and the client will have to deal with UPNP IPv4) with optionaly a DNS name (like SMTP where the DNS is optional). and again, it is missing the web: noscript/basic (x)html, 2D semantic HTML documents.
- extraduder_ire 3y ago
  I both love and hate the long lead-times that EU regulations tend to have. It's occasionally a surprise to me when it comes into effect after I forgot about the law.