6 ms·

> meaning outfits such as WhatsApp, Facebook Messenger or iMessage will have to open up and interoperate with smaller messaging platforms The way i read it, th

> meaning outfits such as WhatsApp, Facebook Messenger or iMessage will have to open up and interoperate with smaller messaging platforms The way i read it, they're calling for open standards, which can be a good thing. Sadly, open standards also slow down the development of new features, as everybody needs to be "on board" for new features to roll out. Take email (SMTP, IMAP, etc) as an example, where no major progress has been made in 25+ years, despite the platform being hopelessly insecure. There has been some unsuccesful attempts at security, like PGP and Protonmail/Tutanota, but as they're addons they haven't seen widespread adoption. Feel free to replace email for TCPv4/v6. The only successful open standard i can think of would be HTTP. Open standards, once they mature, usually mean "lowest common denominator".

kuboble 5y ago
Yes. That lowest common denominator will be probably being able to send text messages. Maybe a little more. 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.
- 8fingerlouie 5y ago
  > That lowest common denominator will be probably being able to send text messages. Maybe a little more. It was my understanding that we already have a (fairly old) standard that does just that, which also currently works as a lowest common denominator for texting between at least android and iOS.
  - andyferris 5y ago
    There’s a telecom protocol tied to your carrier and phone number that predates both android and iOS, but not a (free to use, free to implement) internet protocol. (EDIT: unless you are talking about email)
    - 8fingerlouie 5y ago
      Whatever communication method you select, there will always be ties to a carrier. In GSM it’s a IMEI ID / phone number, in TCP/IP it’s a MAC/IP address. Internet also requires a subscription, subscriber and more. And how would you implement a messaging service with “anonymous” endpoints ? Can’t send messages without a unique identifier for the recipient.
      - kilburn 5y ago
        SMSs are expensive in the EU. Typical mobile plans don't include them and they cost some cents per message (<255 bytes) which would add up quickly. Only some "2fa" and notification systems use them. Actual people don't.
pif 5y ago
> open standards also slow down the development of new features 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.
- pif 5y ago
  Would you like to go back to the dark times of IE6?
  - CJefferson 5y ago
    All the browsers since IE6 are built on open standards. It was stagnation and lack of openness (ActiveX) which caused IE6 to hang around so long.
    - mschuster91 5y ago
      ActiveX was relatively open-ish. Back in the days young me used a Visual Studio 6 off of eDonkey to develop applets in VB6. The problems were that: - unlike modern compiled code for the web - WASM and transpiled JavaScript - Java and ActiveX got executed with host privileges which made both an incredible entry point for malware such as "dialers" and early viruses. - many corporations and governments (e.g. Korea [1]) built their stuff in ActiveX or mandated its use in actual laws and regulations, while only MS Internet Explorer ever implemented ActiveX out of said security reasons. - many corporations and governments only ever coded and tested against IE6 which meant that their sites and products were dependent on IE6-specific quirks [1] https://www.forbes.com/sites/elaineramirez/2016/11/30/south-koreas-online-banking-system-is-stuck-in-1996/ https://www.forbes.com/sites/elaineramirez/2016/11/30/south-...
  - Narishma 5y ago
    Are you arguing with yourself?
- kmlx 5y ago
  > 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 the point is a degraded experience? how can that be the point?
DocTomoe 5y ago
Open Standards enable downward compatibility, they do not prevent innovation that builds on top of them. 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).
- 8fingerlouie 5y ago
  > maybe email is just the wrong format for you and something like encrypted messages over a network of Kafka-style message streams How long before the instant message formats of today becomes “the wrong format” ? Email is an open standard, and as such it should be easy to push out a new RFC that secures metadata, yet that hasn’t happened in 25+ years. I essentially agree that communication should be done over open, secure standards, but I’m not sure legislation is the right way of getting there. We will see how it all plays out.
grishka 5y ago
> Sadly, open standards also slow down the development of new features, as everybody needs to be "on board" for new features to roll out. 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.
- 8fingerlouie 5y ago
  > It's perfectly fine to support some baseline feature set (one-to-one text messages) and build more optional features on top of it. So keep the status quo (SMS/MMS) and build more features on top of that ?
  - madsbuch 5y ago
    Those are not extensible enough as they are bound to the transport layer.
  - rolisz 5y ago
    In the EU (at least in Romania), MMS is not a thing, and even SMS is not the status quo. Everyone talks using WhatsApp mostly.
    - NotOscarWilde 5y ago
      SMS stopped to be status quo here (central Europe) because it still costs money to send each single text. It made sense when no other mobile communication option was available (early 2000s) but not anymore. WhatsApp or any other messaging platform is strictly better as long as your phone is connected to the internet.
  - grishka 5y ago
    > the status quo (SMS/MMS) There are countries that aren't the US. I honestly don't remember when was the last time I've actually sent an SMS. 99% of SMS messages I receive are notifications and 2fa codes. If anything, "status quo" over here is Telegram and VKontakte. Besides, the issue with SMS/MMS is that it's a closed system tightly controlled by carriers. The internet is an open system.
chockchocschoir 5y ago
> Sadly, open standards also slow down the development of new features, as everybody needs to be "on board" for new features to roll out. Take email (SMTP, IMAP, etc) as an example, where no major progress has been made in 25+ years, despite the platform being hopelessly insecure. 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.
- dtech 5y ago
  > Would you say that browser innovation has slowed down? For a long time it was, everyone was stuck on HTML4 while W3C was playing with XHTML. That only really changed when browser vendors came together and collectively decided to ignore start ignoring W3C and made WhatWG. Although IE6 was also a major factor here.
  - chockchocschoir 5y ago
    Entirely my point. It shifted from the flow of "Come up with standards > Software implements that" to "Software implements something > Standardize > Adjust software", the second flow works much better for innovation. Something we can do with chat apps too.
- skywal_l 5y ago
  The Personal Computer is also a successful standard in my opinion. We see constant innovation but with interoperability. It's a little messy sometimes but keeps prices low and innovation high.
- hackerfromthefu 5y ago
  Yeah sure, but messaging apps don't need new features - they need to simply send messages to each other. Walled gardens suck as a user experience for messaging apps.
hnlmorg 5y ago
Not always. One can use an open base but add proprietary extensions. This is exactly how the web has evolved from Netscape and IE having different tags in the 90s to the 00s CSS `ms-` / `o-`, prefixes. This is also how XMPP was designed: common base but support for extensions (open or otherwise). 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.
pooper 5y ago
> Feel free to replace email for TCPv4/v6. The only successful open standard i can think of would be HTTP. 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 https://news.ycombinator.com/item?id=12641880
- upofadown 5y ago
  Just secrecy I think. The complaint was that it would be harder to monitor TLS traffic in an organization by doing a man in the middle attack.
arlort 5y ago
I think in this case it's more about services allowing stuff like third party clients or providing APIs, not binding themselves to a specific standard 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.
freeone3000 5y ago
Yeah, but, I can send email to someone no matter what platform they're on. I can visit their website. I think this is "successful".
belorn 5y ago
Email is hard to replace in a similar way that BGP, IP, UDP and other old protocol is hard to replace. One need to have everyone switch everything, including hardware, at the same time in a coordinated fashion, and one also need to align incentives so that everyone agree that the money and time is worth the benefit of the new protocol. 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.
account42 5y ago
Email lacks development precisely because interopability is intentionally limited by existing stakeholders via opaque "spam" policies. We need regulation to require better interopability here as well so that we can have innovative mail providers that do no have to spend all their energy on being able to send mail at all.
cesarb 5y ago
> Sadly, open standards also slow down the development of new features, as everybody needs to be "on board" for new features to roll out. Take email (SMTP, IMAP, etc) as an example, where no major progress has been made in 25+ years, despite the platform being hopelessly insecure. 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.
viccuad 5y ago
> The way i read it, they're calling for open standards, which can be a good thing. > > Sadly, open standards also slow down the development of new features, 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.
- ensignavenger 5y ago
  Its not clear from the article what they are calling for- do you have a source? But lets say you are right, and all that the affected messaging services have to do is provide an API- will the regulators require them to document this API (and if so, what standards will the documentation have to follow?) Will they complain if the API changes too rapidly? Will the API have to support tall of the same features as the messaging service? As they say, the devils in the details, and right now I'm not seeing any details.
- 8fingerlouie 5y ago
  > They are asking for endpoints and public APIs How will they interface with the different APIs ? Or is it a single API defined by a standard ? The first one means that most clients will play “whack a mole” with 20 APIs, trying to keep up with features. The second will be the lowest common denominator, limiting what can be sent between different clients. It would be the new “green bubble”. Next, how do you identify people uniquely across different networks ? Phone number ? Email ? What happens if you’ve registered your Id in multiple places ? Or is it up to the sender to specify which network they wish to target ? Like someone@gmail.com@imessage ? The last one solves nothing. In case of multiple id registrations, should the network just keep trying round robin until it successfully delivers ? Or can I as a recipient register my preferred delivery network in case I never want Meta or Google to see my data ? Who maintains this central registry ? Will they do it for free ? Now that we’ve established how to pass messages between networks, how do we secure them ? Do we use the iMessage model and use a central key repository ? Or do we implement a protocol (potentially per API) on how to acquire encryption keys ? Or do we simply skip encryption because security is hard ? What about attachments ? Since most secure platforms use “per device” encryption, do we just send a 500GB attachment X times, one per device ? Do we limit the size of attachments ? iMessage solves this by encrypting it with a temporary key, and the attachment is then uploaded to Apples servers, and the temporary key is exchanged using normal messaging. Is that the way forward ? Will whoever handles it do it for free ? Do we trust them ? What about Memoji/whatever the kids use ? All of the above, and more, needs to be agreed on by all involved parties, which sets the lowest common denominator, either by a shared standard, or by reducing functionality for cross network messages. If it ends up complex enough to support all the features of modern instant messaging, it sets the bar rather high for new players. If it ends up simple, we have gained almost nothing over using SMS/MMS. Things are never as simple as just exposing an API.
varajelle 5y ago
But email evolved. You can now use a 8bit encoding, use formating with html content. Is encrypted with TLS. Send calendar events. PGP did take of for people who care. You can even revoke emails.
shafyy 5y ago
> Sadly, open standards also slow down the development of new features, as everybody needs to be "on board" for new features to roll out. 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.

kuboble 5y ago

Yes. That lowest common denominator will be probably being able to send text messages. Maybe a little more. 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.

8fingerlouie 5y ago
> That lowest common denominator will be probably being able to send text messages. Maybe a little more. It was my understanding that we already have a (fairly old) standard that does just that, which also currently works as a lowest common denominator for texting between at least android and iOS.
- andyferris 5y ago
  There’s a telecom protocol tied to your carrier and phone number that predates both android and iOS, but not a (free to use, free to implement) internet protocol. (EDIT: unless you are talking about email)
  - 8fingerlouie 5y ago
    Whatever communication method you select, there will always be ties to a carrier. In GSM it’s a IMEI ID / phone number, in TCP/IP it’s a MAC/IP address. Internet also requires a subscription, subscriber and more. And how would you implement a messaging service with “anonymous” endpoints ? Can’t send messages without a unique identifier for the recipient.
    - kilburn 5y ago
      SMSs are expensive in the EU. Typical mobile plans don't include them and they cost some cents per message (<255 bytes) which would add up quickly. Only some "2fa" and notification systems use them. Actual people don't.

pif 5y ago

> open standards also slow down the development of new features 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.

pif 5y ago
Would you like to go back to the dark times of IE6?
- CJefferson 5y ago
  All the browsers since IE6 are built on open standards. It was stagnation and lack of openness (ActiveX) which caused IE6 to hang around so long.
  - mschuster91 5y ago
    ActiveX was relatively open-ish. Back in the days young me used a Visual Studio 6 off of eDonkey to develop applets in VB6. The problems were that: - unlike modern compiled code for the web - WASM and transpiled JavaScript - Java and ActiveX got executed with host privileges which made both an incredible entry point for malware such as "dialers" and early viruses. - many corporations and governments (e.g. Korea [1]) built their stuff in ActiveX or mandated its use in actual laws and regulations, while only MS Internet Explorer ever implemented ActiveX out of said security reasons. - many corporations and governments only ever coded and tested against IE6 which meant that their sites and products were dependent on IE6-specific quirks [1] https://www.forbes.com/sites/elaineramirez/2016/11/30/south-koreas-online-banking-system-is-stuck-in-1996/ https://www.forbes.com/sites/elaineramirez/2016/11/30/south-...
- Narishma 5y ago
  Are you arguing with yourself?
kmlx 5y ago
> 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 the point is a degraded experience? how can that be the point?

DocTomoe 5y ago

Open Standards enable downward compatibility, they do not prevent innovation that builds on top of them. 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).

8fingerlouie 5y ago
> maybe email is just the wrong format for you and something like encrypted messages over a network of Kafka-style message streams How long before the instant message formats of today becomes “the wrong format” ? Email is an open standard, and as such it should be easy to push out a new RFC that secures metadata, yet that hasn’t happened in 25+ years. I essentially agree that communication should be done over open, secure standards, but I’m not sure legislation is the right way of getting there. We will see how it all plays out.

grishka 5y ago

> Sadly, open standards also slow down the development of new features, as everybody needs to be "on board" for new features to roll out. 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.

8fingerlouie 5y ago
> It's perfectly fine to support some baseline feature set (one-to-one text messages) and build more optional features on top of it. So keep the status quo (SMS/MMS) and build more features on top of that ?
- madsbuch 5y ago
  Those are not extensible enough as they are bound to the transport layer.
- rolisz 5y ago
  In the EU (at least in Romania), MMS is not a thing, and even SMS is not the status quo. Everyone talks using WhatsApp mostly.
  - NotOscarWilde 5y ago
    SMS stopped to be status quo here (central Europe) because it still costs money to send each single text. It made sense when no other mobile communication option was available (early 2000s) but not anymore. WhatsApp or any other messaging platform is strictly better as long as your phone is connected to the internet.
- grishka 5y ago
  > the status quo (SMS/MMS) There are countries that aren't the US. I honestly don't remember when was the last time I've actually sent an SMS. 99% of SMS messages I receive are notifications and 2fa codes. If anything, "status quo" over here is Telegram and VKontakte. Besides, the issue with SMS/MMS is that it's a closed system tightly controlled by carriers. The internet is an open system.

chockchocschoir 5y ago

dtech 5y ago
> Would you say that browser innovation has slowed down? For a long time it was, everyone was stuck on HTML4 while W3C was playing with XHTML. That only really changed when browser vendors came together and collectively decided to ignore start ignoring W3C and made WhatWG. Although IE6 was also a major factor here.
- chockchocschoir 5y ago
  Entirely my point. It shifted from the flow of "Come up with standards > Software implements that" to "Software implements something > Standardize > Adjust software", the second flow works much better for innovation. Something we can do with chat apps too.
skywal_l 5y ago
The Personal Computer is also a successful standard in my opinion. We see constant innovation but with interoperability. It's a little messy sometimes but keeps prices low and innovation high.
hackerfromthefu 5y ago
Yeah sure, but messaging apps don't need new features - they need to simply send messages to each other. Walled gardens suck as a user experience for messaging apps.

hnlmorg 5y ago

Not always. One can use an open base but add proprietary extensions. This is exactly how the web has evolved from Netscape and IE having different tags in the 90s to the 00s CSS `ms-` / `o-`, prefixes. This is also how XMPP was designed: common base but support for extensions (open or otherwise). 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.

pooper 5y ago

> Feel free to replace email for TCPv4/v6. The only successful open standard i can think of would be HTTP. 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 https://news.ycombinator.com/item?id=12641880

upofadown 5y ago
Just secrecy I think. The complaint was that it would be harder to monitor TLS traffic in an organization by doing a man in the middle attack.

arlort 5y ago

I think in this case it's more about services allowing stuff like third party clients or providing APIs, not binding themselves to a specific standard 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.

freeone3000 5y ago

Yeah, but, I can send email to someone no matter what platform they're on. I can visit their website. I think this is "successful".

belorn 5y ago

Email is hard to replace in a similar way that BGP, IP, UDP and other old protocol is hard to replace. One need to have everyone switch everything, including hardware, at the same time in a coordinated fashion, and one also need to align incentives so that everyone agree that the money and time is worth the benefit of the new protocol. 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.

account42 5y ago

Email lacks development precisely because interopability is intentionally limited by existing stakeholders via opaque "spam" policies. We need regulation to require better interopability here as well so that we can have innovative mail providers that do no have to spend all their energy on being able to send mail at all.

cesarb 5y ago

> Sadly, open standards also slow down the development of new features, as everybody needs to be "on board" for new features to roll out. Take email (SMTP, IMAP, etc) as an example, where no major progress has been made in 25+ years, despite the platform being hopelessly insecure. 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.

viccuad 5y ago

> The way i read it, they're calling for open standards, which can be a good thing. > > Sadly, open standards also slow down the development of new features, 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.

ensignavenger 5y ago
Its not clear from the article what they are calling for- do you have a source? But lets say you are right, and all that the affected messaging services have to do is provide an API- will the regulators require them to document this API (and if so, what standards will the documentation have to follow?) Will they complain if the API changes too rapidly? Will the API have to support tall of the same features as the messaging service? As they say, the devils in the details, and right now I'm not seeing any details.
8fingerlouie 5y ago
> They are asking for endpoints and public APIs How will they interface with the different APIs ? Or is it a single API defined by a standard ? The first one means that most clients will play “whack a mole” with 20 APIs, trying to keep up with features. The second will be the lowest common denominator, limiting what can be sent between different clients. It would be the new “green bubble”. Next, how do you identify people uniquely across different networks ? Phone number ? Email ? What happens if you’ve registered your Id in multiple places ? Or is it up to the sender to specify which network they wish to target ? Like someone@gmail.com@imessage ? The last one solves nothing. In case of multiple id registrations, should the network just keep trying round robin until it successfully delivers ? Or can I as a recipient register my preferred delivery network in case I never want Meta or Google to see my data ? Who maintains this central registry ? Will they do it for free ? Now that we’ve established how to pass messages between networks, how do we secure them ? Do we use the iMessage model and use a central key repository ? Or do we implement a protocol (potentially per API) on how to acquire encryption keys ? Or do we simply skip encryption because security is hard ? What about attachments ? Since most secure platforms use “per device” encryption, do we just send a 500GB attachment X times, one per device ? Do we limit the size of attachments ? iMessage solves this by encrypting it with a temporary key, and the attachment is then uploaded to Apples servers, and the temporary key is exchanged using normal messaging. Is that the way forward ? Will whoever handles it do it for free ? Do we trust them ? What about Memoji/whatever the kids use ? All of the above, and more, needs to be agreed on by all involved parties, which sets the lowest common denominator, either by a shared standard, or by reducing functionality for cross network messages. If it ends up complex enough to support all the features of modern instant messaging, it sets the bar rather high for new players. If it ends up simple, we have gained almost nothing over using SMS/MMS. Things are never as simple as just exposing an API.

varajelle 5y ago

But email evolved. You can now use a 8bit encoding, use formating with html content. Is encrypted with TLS. Send calendar events. PGP did take of for people who care. You can even revoke emails.

shafyy 5y ago

> Sadly, open standards also slow down the development of new features, as everybody needs to be "on board" for new features to roll out. 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.