Correct. IRC was intended for installable native clients. But as I understand it, IRC also originated in a time when most computers connected to the Internet had a compiler already installed, or at least allowed execution of unsigned binaries added by a user, as opposed to being cryptographically locked down to those apps hand-picked by the computer's manufacturer. That makes installable native clients slightly more practical than in a 2018 scenario where one wouldn't want to launch without iOS support.
1. The demo and registered version can share assets (non-executable data), not code, through the content provider mechanism. 2. It works only if the assets are downloaded separately, not if they are downloaded as part of the APK. This breaks downloading the game and running it for the first time while offline. 3. As the user migrates the campaign and first episode's assets to the registered version, the assets still occupy duplicate space on the device until the content provider finishes transferring the first episode's assets from the demo version to the registered version.
What keeps the evil maid from entering the admin interface and uploading her own public key? I guess that's why a Chromebook write-protects its firmware with a physical screw.
Many ISPs' networks are structured in such a way that "port forward 113 & open a range" is not enough. See the post by Bert64 that I linked above and "Carrier-grade NAT" on Wikipedia for background. And even on those ISPs that do allow forwarding a port, a customer may not understand how to do so.
to trying to freak the user out about 'this totally static site that doesn't use HTTPS must be insecure even though you can't submit info to it because it's totally static'
The sentiment that Chrome is trying to get across in that case is "Chrome cannot guarantee that your Internet service provider has refrained from injecting malicious JavaScript code into the static site that you are viewing." Xfinity by Comcast, for example, has been caught doing this. What would be a better way to express this in a manner short enough to fit in the location bar?
That has a few drawbacks. First, it does nothing to protect the data from fire, flood, or another disaster that renders electronics in your home inoperable. Second, many home ISPs ban running a server at home or block incoming connections or both, as do their direct competitors in the same geographic market (if any even exist). Third, if your dynamic DNS provider isn't on the Public Suffix List or doesn't support TXT records, you still have to buy a domain and keep it renewed in order to qualify for a Let's Encrypt certificate for your home server.
USB flash drives come in gigantic capacities these days. So do SSDs.
Colocation facilities in which to store and access USB flash drives and SSDs offsite aren't quite as cheap.
Many routers, printers, and network attached storage (NAS) boxes for home use offer a web-based configuration interface. If someone buys one of these devices, where should he or she obtain a TLS certificate to use with said device in order to suppress "Not Secure" messages in web browsers?
Let's Encrypt and other publicly trusted CAs won't issue a certificate for a private IP or a name in a made-up TLD, such as.internal or.test. It has to be a real domain. Nor do all dynamic DNS providers offer enough features to pass an ACME dns-01 challenge, namely being on the Public Suffix List and supporting TXT records.
Or should it be the device manufacturer's responsibility to issue a name under the manufacturer's domain and resell a certificate from a known CA, the way Plex does? If so, watch the manufacturer set the certificate's expiry the same as that of the warranty on the device, so that the user has to re-buy hardware in order to renew the certificate. Nor do I see how that would apply to a home-built server made out of a Raspberry Pi or Intel NUC.
it's been a LONG TIME since 1994-2001 when I was on IRC
Back when IRC was still popular, most Internet-connected households had only one PC connected to the Internet at a time, and there weren't enough Internet users in IPv4 address-poor countries to make CGNAT a necessity. Nowadays, those are no longer the case quite as often.
What brought NAT up ? Was it in your conversations earlier with others??
I don't see how the law would differ between logged chat and a message board. For example, would Slashdot be required, and would Slashdot be able, to handle an erasure request from a user?
Is there an IRC server distribution that supports all this?
if you look around you may even find plugins for current servers that add those enhancements
Hence why I asked "distribution".
The benefit of Skype, Slack, Discord, and HipChat is that someone without experience in looking around doesn't need to learn how to look around for a combination of server and plug-ins. To many organizers of communities of people on the Internet, the benefit of everything already being there outweighs these chat platforms' proprietary character. If someone were to come up with a solid answer for "Which server and which plug-ins?" to which I could refer people, there wouldn't be quite so much of a need for Skype, Slack, Discord, and HipChat.
Why is it that on Slashdot, so many people think that just because something is not 100% perfect in 100% of the possible cases they can imagine, it must be useless?
It may be a counterreaction to a delusion commonly observed among marketing departments that if something is 100% perfect in one case, it must be perfect for all cases. I personally was trying to help characterize the limits of end-to-ends encryption so that people considering it could see under which conditions it is practical.
I already keep things synced across multiple devices. [The keypair for end-to-end encryption] is simply another file in the mix.
Does this work for both web-based and non-web-based chat clients? I thought web applications, such as clients for chat services, couldn't read arbitrary "files" from your device for security reasons, and you didn't want to upload your private key to the server in order to prevent the server from compromising your encryption. Once you have synced the file containing a keypair, how do you get it into the JavaScript-based chat client's local storage? Or is it generally better to drop a web-based client in favor of an installable native client, provided one even exists for a given pair of chat protocol and client platform?
Say I wanted to set up an IRC server that supports logging of messages and attachments, plus a server-side metadata bot so that posting a link in a channel doesn't cause a couple hundred users' metadata fetching scripts to all fetch metadata at the same time, thereby hammering the site with requests. Is there an IRC server distribution that supports all this?
Skype, Slack, Discord, and other proprietary web-based chat platforms allow uploading attachments even if your device is behind network address translation (NAT).
DCC requires the sender to be able to receive incoming connections, which is not true of a device behind NAT. UPnP is supposed to let applications configure a router to punch a hole in the NAT, but it's often disabled for security reasons, and it doesn't work anyway across a NAT operated by your ISP (called a carrier-grade network address translation or CGNAT).
Or are you referring to use of a reverse DCC SEND to let a sender behind a NAT send a file to some proxy, from which a recipient behind a different NAT retrieves the file with a normal DCC SEND? If so, which if any IRC networks make such a proxy available to their users?
Until you get to a channel with 200 or 500 people in it, and the size in bytes of the set of asymmetrically encrypted copies of the symmetric key for each message greatly exceeds the size in bytes of the message. I've seen channels that big in both IRC and Discord.
And if a new user joins and a channel's moderator accepts the new user's request to be read in on the channel's history, how does the new user's symmetric key get added to all the existing messages? By decrypting the symmetric key of each message using the moderator's private key and reencrypting it using the new user's public key? That could take a while.
Furthermore, how does the user keep his key synchronized across two desktop computers, a laptop, and a tablet?
I agree that in theory, chat with server-side history is functionally to a message board. Some communities prefer chat with history because history allows users in less populous (and often less economically privileged) time zones to catch up. They prefer chat with history over a message board primarily for two user experience reasons:
Lighter chrome per message
User interface elements are smaller than those of phpBB, Slash/Rehash, and other popular message board software. Slash and Rehash, for instance, add two lines (subject and byline) above each comment and one line ("Reply to This | Parent | Share") below. Chat collapses these by default, except for the author's name and an optional timestamp. This encourages shorter messages that aren't quite as monolithic, encouraging a more conversational style as opposed to the more formal style of monolithic multi-paragraph message board posts.
Real-time updates
All users looking at a channel receive new messages instantly through a WebSocket without having to refresh the page.
However the core protocol needs end to end encryption. Not encryption where a multinational manages your private key "for" you, but true, E2E encryption.
Some chat services support end-to-end (E2E) encryption for one-to-one chat but not group chat. The point of the latter is to broadcast a message to all other users of a channel. How would end-to-ends (plural) encryption work?
It needs some more modern features like presence.
IRC protocol already has presence support, which many clients expose as the /away command. Though this doesn't include "offline" status at the protocol level, an IRC server could in theory implement "offline" as a subset of away status by providing a bouncer for all users of the server to use.
But wasn't one of the main selling points of ChromeOS the fact that it's seamlessly self-updating?
Chrome OS seamlessly updates its userland. For comparison, Android has been working toward this since version 8 "knOckoff of Hydrox". Just as Android 4.x largely separated Google Play Services from AOSP to update the former faster, Android 8 introduced a frozen kernel and device driver ABI called Project Treble to separate AOSP from the hardware support to update the former faster.
Why does that not include the kernel? [...] I guess the OEM's would have to get involved to do a kernel upgrade
Bingo.
The following applies to both Chrome OS and post-Treble Android: Because hardware manufacturers customize the kernel with custom device drivers, kernel upgrades require more cooperation from each hardware manufacturer than userland upgrades. Manufacturers would prefer to sell a new device. And in markets where cellular ISPs use different mutually incompatible cellular air interfaces, such as CDMA2000 vs. GSM/UMTS in the United States, kernel upgrades on devices with a cellular radio additionally require cooperation from each cellular ISP. Cellular ISPs would prefer to sell a new device with a new 24-month service commitment.
If anyone knows how to share executable code and data between Android applications from the same publisher without including redundant copies on the user's device's storage, please feel free to share the citation to Google's documentation of this feature.
For some use cases, tne big advantage of Skype, Slack, HipChat, Discord, and other web-based functional clones of IRC over IRC itself is that they store chat history on the server side. This lets a user see messages that were sent to a channel while the user was offline. It's as if an IRC server had built-in functionality equivalent to that of a bouncer, except that each user doesn't have to lease a VPS on which to run ZNC. The major IRC networks couid offer a built-in bouncer to compete with proprietary web-based chat, but they don't.
Another is that web-based chat allows uploading attachments. IRC has traditionally used pastebins and filedrops for this. The major IRC networks couid operate pastebin and filedrop services for their users to use, but they don't.
Say someone wants to carry a computing device but wants that device to prevent an evil maid with physical access from installing a boot-time rootkit. How would that protection measure work while keeping the owner's control?
"unofficial" kernel? Does not that imply, there is also an "official" kernel? What is that
The official kernel for a device is the one that stock firmware loads without having to be put into developer mode.
and just how "open source" is that very concept?
It's the phenomenon that Free Software Foundation has referred to as Tivoization: the user has the legal right to modify a computer program, but the hardware it's shipped on has technical measures to block use of a modified version. A Chromebook's stock firmware is partially Tivoized in the sense that though the blocking can be disabled, disabling it puts the user at risk of accidental data loss every time the machine starts.
When you install a.NET application, it would mount all of those things, as well as a.NET runtime for the app.
Would this.NET runtime allow use of mixed assemblies (which contain both native and CIL code) or other unsafe CIL? If not, read on:
You can get a Python and Java VM running on.NET, which may allow extending this to other types of native applications using the same runtime.
I read years back about something called C++/CLI, which extends ISO C++ with.NET-specific syntax for pointers and references in verifiably type-safe code. ISO C++ uses * to declare pointers and & to declare references, but C++/CLI uses those to mean unsafe pointers and references. Use of these causes verification of type safety at load time to fail. To declare pointers and references to managed objects, C++/CLI instead uses ^ for a pointer and % for a reference. (Source: "Component Extensions for Runtime Platforms")
Can ISO C or ISO C++ be compiled to verifiably type-safe.NET bytecode? Or is there a useful subset that can be automatically translated both to ISO C++ and to verifiably type-safe subset of C++/CLI? I don't think so given Microsoft's attitude in the following document: "If your code needs to be safe or verifiable, then we recommend that you port it to C#." (Source: "Pure and verifiable code (C++/CLI)")
Slashdot Mirror
Even a DMZ doesn't work if your ISP blocks incoming connections before they even get to your modem.
Correct. IRC was intended for installable native clients. But as I understand it, IRC also originated in a time when most computers connected to the Internet had a compiler already installed, or at least allowed execution of unsigned binaries added by a user, as opposed to being cryptographically locked down to those apps hand-picked by the computer's manufacturer. That makes installable native clients slightly more practical than in a 2018 scenario where one wouldn't want to launch without iOS support.
That solution is somewhat limited:
1. The demo and registered version can share assets (non-executable data), not code, through the content provider mechanism.
2. It works only if the assets are downloaded separately, not if they are downloaded as part of the APK. This breaks downloading the game and running it for the first time while offline.
3. As the user migrates the campaign and first episode's assets to the registered version, the assets still occupy duplicate space on the device until the content provider finishes transferring the first episode's assets from the demo version to the registered version.
What keeps the evil maid from entering the admin interface and uploading her own public key? I guess that's why a Chromebook write-protects its firmware with a physical screw.
Many ISPs' networks are structured in such a way that "port forward 113 & open a range" is not enough. See the post by Bert64 that I linked above and "Carrier-grade NAT" on Wikipedia for background. And even on those ISPs that do allow forwarding a port, a customer may not understand how to do so.
to trying to freak the user out about 'this totally static site that doesn't use HTTPS must be insecure even though you can't submit info to it because it's totally static'
The sentiment that Chrome is trying to get across in that case is "Chrome cannot guarantee that your Internet service provider has refrained from injecting malicious JavaScript code into the static site that you are viewing." Xfinity by Comcast, for example, has been caught doing this. What would be a better way to express this in a manner short enough to fit in the location bar?
Store your data at home on your own hardware.
That has a few drawbacks. First, it does nothing to protect the data from fire, flood, or another disaster that renders electronics in your home inoperable. Second, many home ISPs ban running a server at home or block incoming connections or both, as do their direct competitors in the same geographic market (if any even exist). Third, if your dynamic DNS provider isn't on the Public Suffix List or doesn't support TXT records, you still have to buy a domain and keep it renewed in order to qualify for a Let's Encrypt certificate for your home server.
USB flash drives come in gigantic capacities these days. So do SSDs.
Colocation facilities in which to store and access USB flash drives and SSDs offsite aren't quite as cheap.
Many routers, printers, and network attached storage (NAS) boxes for home use offer a web-based configuration interface. If someone buys one of these devices, where should he or she obtain a TLS certificate to use with said device in order to suppress "Not Secure" messages in web browsers?
Let's Encrypt and other publicly trusted CAs won't issue a certificate for a private IP or a name in a made-up TLD, such as .internal or .test. It has to be a real domain. Nor do all dynamic DNS providers offer enough features to pass an ACME dns-01 challenge, namely being on the Public Suffix List and supporting TXT records.
Or should it be the device manufacturer's responsibility to issue a name under the manufacturer's domain and resell a certificate from a known CA, the way Plex does? If so, watch the manufacturer set the certificate's expiry the same as that of the warranty on the device, so that the user has to re-buy hardware in order to renew the certificate. Nor do I see how that would apply to a home-built server made out of a Raspberry Pi or Intel NUC.
If they did their code-injection correctly there wouldn't be as much issue.
Is there even a "correctly" in Chrome's extension API?
it's been a LONG TIME since 1994-2001 when I was on IRC
Back when IRC was still popular, most Internet-connected households had only one PC connected to the Internet at a time, and there weren't enough Internet users in IPv4 address-poor countries to make CGNAT a necessity. Nowadays, those are no longer the case quite as often.
What brought NAT up ? Was it in your conversations earlier with others??
Yes. For example, Bert64 reports that all home ISPs in Myanmar use CGNAT.
I don't see how the law would differ between logged chat and a message board. For example, would Slashdot be required, and would Slashdot be able, to handle an erasure request from a user?
Is there an IRC server distribution that supports all this?
if you look around you may even find plugins for current servers that add those enhancements
Hence why I asked "distribution".
The benefit of Skype, Slack, Discord, and HipChat is that someone without experience in looking around doesn't need to learn how to look around for a combination of server and plug-ins. To many organizers of communities of people on the Internet, the benefit of everything already being there outweighs these chat platforms' proprietary character. If someone were to come up with a solid answer for "Which server and which plug-ins?" to which I could refer people, there wouldn't be quite so much of a need for Skype, Slack, Discord, and HipChat.
Why is it that on Slashdot, so many people think that just because something is not 100% perfect in 100% of the possible cases they can imagine, it must be useless?
It may be a counterreaction to a delusion commonly observed among marketing departments that if something is 100% perfect in one case, it must be perfect for all cases. I personally was trying to help characterize the limits of end-to-ends encryption so that people considering it could see under which conditions it is practical.
I already keep things synced across multiple devices. [The keypair for end-to-end encryption] is simply another file in the mix.
Does this work for both web-based and non-web-based chat clients? I thought web applications, such as clients for chat services, couldn't read arbitrary "files" from your device for security reasons, and you didn't want to upload your private key to the server in order to prevent the server from compromising your encryption. Once you have synced the file containing a keypair, how do you get it into the JavaScript-based chat client's local storage? Or is it generally better to drop a web-based client in favor of an installable native client, provided one even exists for a given pair of chat protocol and client platform?
Say I wanted to set up an IRC server that supports logging of messages and attachments, plus a server-side metadata bot so that posting a link in a channel doesn't cause a couple hundred users' metadata fetching scripts to all fetch metadata at the same time, thereby hammering the site with requests. Is there an IRC server distribution that supports all this?
Skype, Slack, Discord, and other proprietary web-based chat platforms allow uploading attachments even if your device is behind network address translation (NAT).
DCC requires the sender to be able to receive incoming connections, which is not true of a device behind NAT. UPnP is supposed to let applications configure a router to punch a hole in the NAT, but it's often disabled for security reasons, and it doesn't work anyway across a NAT operated by your ISP (called a carrier-grade network address translation or CGNAT).
Or are you referring to use of a reverse DCC SEND to let a sender behind a NAT send a file to some proxy, from which a recipient behind a different NAT retrieves the file with a normal DCC SEND? If so, which if any IRC networks make such a proxy available to their users?
Until you get to a channel with 200 or 500 people in it, and the size in bytes of the set of asymmetrically encrypted copies of the symmetric key for each message greatly exceeds the size in bytes of the message. I've seen channels that big in both IRC and Discord.
And if a new user joins and a channel's moderator accepts the new user's request to be read in on the channel's history, how does the new user's symmetric key get added to all the existing messages? By decrypting the symmetric key of each message using the moderator's private key and reencrypting it using the new user's public key? That could take a while.
Furthermore, how does the user keep his key synchronized across two desktop computers, a laptop, and a tablet?
I agree that in theory, chat with server-side history is functionally to a message board. Some communities prefer chat with history because history allows users in less populous (and often less economically privileged) time zones to catch up. They prefer chat with history over a message board primarily for two user experience reasons:
Lighter chrome per message User interface elements are smaller than those of phpBB, Slash/Rehash, and other popular message board software. Slash and Rehash, for instance, add two lines (subject and byline) above each comment and one line ("Reply to This | Parent | Share") below. Chat collapses these by default, except for the author's name and an optional timestamp. This encourages shorter messages that aren't quite as monolithic, encouraging a more conversational style as opposed to the more formal style of monolithic multi-paragraph message board posts. Real-time updates All users looking at a channel receive new messages instantly through a WebSocket without having to refresh the page.However the core protocol needs end to end encryption. Not encryption where a multinational manages your private key "for" you, but true, E2E encryption.
Some chat services support end-to-end (E2E) encryption for one-to-one chat but not group chat. The point of the latter is to broadcast a message to all other users of a channel. How would end-to-ends (plural) encryption work?
It needs some more modern features like presence.
IRC protocol already has presence support, which many clients expose as the /away command. Though this doesn't include "offline" status at the protocol level, an IRC server could in theory implement "offline" as a subset of away status by providing a bouncer for all users of the server to use.
But wasn't one of the main selling points of ChromeOS the fact that it's seamlessly self-updating?
Chrome OS seamlessly updates its userland. For comparison, Android has been working toward this since version 8 "knOckoff of Hydrox". Just as Android 4.x largely separated Google Play Services from AOSP to update the former faster, Android 8 introduced a frozen kernel and device driver ABI called Project Treble to separate AOSP from the hardware support to update the former faster.
Why does that not include the kernel? [...] I guess the OEM's would have to get involved to do a kernel upgrade
Bingo.
The following applies to both Chrome OS and post-Treble Android: Because hardware manufacturers customize the kernel with custom device drivers, kernel upgrades require more cooperation from each hardware manufacturer than userland upgrades. Manufacturers would prefer to sell a new device. And in markets where cellular ISPs use different mutually incompatible cellular air interfaces, such as CDMA2000 vs. GSM/UMTS in the United States, kernel upgrades on devices with a cellular radio additionally require cooperation from each cellular ISP. Cellular ISPs would prefer to sell a new device with a new 24-month service commitment.
If anyone knows how to share executable code and data between Android applications from the same publisher without including redundant copies on the user's device's storage, please feel free to share the citation to Google's documentation of this feature.
For some use cases, tne big advantage of Skype, Slack, HipChat, Discord, and other web-based functional clones of IRC over IRC itself is that they store chat history on the server side. This lets a user see messages that were sent to a channel while the user was offline. It's as if an IRC server had built-in functionality equivalent to that of a bouncer, except that each user doesn't have to lease a VPS on which to run ZNC. The major IRC networks couid offer a built-in bouncer to compete with proprietary web-based chat, but they don't.
Another is that web-based chat allows uploading attachments. IRC has traditionally used pastebins and filedrops for this. The major IRC networks couid operate pastebin and filedrop services for their users to use, but they don't.
It probably depends on how you define "based on". In any case, Slack isn't compatible with IRC at present, as the summary links to a story about Slack having shut down access to its service through IRC protocol.
Say someone wants to carry a computing device but wants that device to prevent an evil maid with physical access from installing a boot-time rootkit. How would that protection measure work while keeping the owner's control?
"unofficial" kernel? Does not that imply, there is also an "official" kernel? What is that
The official kernel for a device is the one that stock firmware loads without having to be put into developer mode.
and just how "open source" is that very concept?
It's the phenomenon that Free Software Foundation has referred to as Tivoization: the user has the legal right to modify a computer program, but the hardware it's shipped on has technical measures to block use of a modified version. A Chromebook's stock firmware is partially Tivoized in the sense that though the blocking can be disabled, disabling it puts the user at risk of accidental data loss every time the machine starts.
When you install a .NET application, it would mount all of those things, as well as a .NET runtime for the app.
Would this .NET runtime allow use of mixed assemblies (which contain both native and CIL code) or other unsafe CIL? If not, read on:
You can get a Python and Java VM running on .NET, which may allow extending this to other types of native applications using the same runtime.
I read years back about something called C++/CLI, which extends ISO C++ with .NET-specific syntax for pointers and references in verifiably type-safe code. ISO C++ uses * to declare pointers and & to declare references, but C++/CLI uses those to mean unsafe pointers and references. Use of these causes verification of type safety at load time to fail. To declare pointers and references to managed objects, C++/CLI instead uses ^ for a pointer and % for a reference. (Source: "Component Extensions for Runtime Platforms")
Can ISO C or ISO C++ be compiled to verifiably type-safe .NET bytecode? Or is there a useful subset that can be automatically translated both to ISO C++ and to verifiably type-safe subset of C++/CLI? I don't think so given Microsoft's attitude in the following document: "If your code needs to be safe or verifiable, then we recommend that you port it to C#." (Source: "Pure and verifiable code (C++/CLI)")