Seems there have been cases of crims hijacking USB charging outlets in airports to connect special devices that can pwn your mobile device <https://www.nzherald.co.nz/travel/news/airport-passengers-warned-of-phone-charging-scams/RGBS35ORBVBUDJIVO466TIFNAQ/>.
When I was in Hong Kong Airport a few years ago, it was very hard for
me to find a mains outlet to charge my laptop. Just about all the
ports built into the public seating areas were USB ones, for
phones/tablets.
It is possible to get USB cables that only connect the power wires for charging, without enabling data transfer. Alternatively, here <https://github.com/robertfisk/USG/wiki> is a USB “firewall”-type
device that tries to protect you from malicious devices. If you don’t
want to build your own, there’s a link in the readme to buy NZ-made
ones.
Lawrence D'Oliveiro wrote:
It is possible to get USB cables that only connect the power wires for
charging, without enabling data transfer. Alternatively, here
<https://github.com/robertfisk/USG/wiki> is a USB "firewall"-type
device that tries to protect you from malicious devices.
See also "USB condom"
<https://www.usbcompany.co.uk/accessories/usb-condom>
Not so simple with type-C and PD
Scott Alfter wrote:
(Your newsreader is inserting CRs at the ends of lines, BTW...might want to >> fix that.)
I see CRLF at the ends of lines in Andy Burns' message. Both in the
raw message and in the base64-decoded text. I checked Andy's message
on two different news servers.
CRLF is the correct, standard on-the-wire format.
(Your newsreader is inserting CRs at the ends of lines, BTW...might want to fix that.)
Ralph Fox wrote:
CRLF is the correct, standard on-the-wire format.
Actually I think bare LF's are correct, no?
I think on this occasion it took objection to Lawrence's fancy
double quotes around the word 'firewall', unfortunately I've tried
various character encodings/charsets and nothing prevents the issue.
On Fri, 07 Jun 2024 14:12:23 GMT, Scott Alfter wrote:
(Your newsreader is inserting CRs at the ends of lines, BTW...might want to >> fix that.)
I see CRLF at the ends of lines in Andy Burns' message. Both in the
raw message and in the base64-decoded text. I checked Andy's message
on two different news servers.
CRLF is the correct, standard on-the-wire format.
Ralph Fox wrote:
Scott Alfter wrote:
(Your newsreader is inserting CRs at the ends of lines, BTW...might want to >>> fix that.)
I see CRLF at the ends of lines in Andy Burns' message. Both in the
raw message and in the base64-decoded text. I checked Andy's message
on two different news servers.
CRLF is the correct, standard on-the-wire format.
Actually I think bare LF's are correct, no?
Thunderbird does on occasion do the wrong thing, if it sees 8-bit
characters (often an whitespace character, or two spaces at the
end of a paragraph) it decides to base-64 encode where it doesn't need
to, I think on this occasion it took objection to Lawrence's fancy
double quotes around the word 'firewall', unfortunately I've tried
various character encodings/charsets and nothing prevents the issue.
Using the latest Thunderbird 115.11.1 on Windows...
* When I compose a reply to Lawrence's post with the 'curly' quotes
and put it in the Outbox, my reply is not base-64 encoded.
* I would like to try composing my reply with various character
encodings/charsets, but current Thunderbird 115.11.1 does not seem
to have that option any more.
to Lawrence is always UTF-8.
Using Thunderbird 115.11.0 on Linux Mint...
Same thing.
Seems there have been cases of crims hijacking USB charging outlets in airports to connect special devices that can pwn your mobile device <https://www.nzherald.co.nz/travel/news/airport-passengers-warned-of-phone-charging-scams/RGBS35ORBVBUDJIVO466TIFNAQ/>.
When I was in Hong Kong Airport a few years ago, it was very hard for
me to find a mains outlet to charge my laptop. Just about all the
ports built into the public seating areas were USB ones, for
phones/tablets.
It is possible to get USB cables that only connect the power wires for charging, without enabling data transfer. Alternatively, here <https://github.com/robertfisk/USG/wiki> is a USB “firewall”-type
device that tries to protect you from malicious devices. If you don’t
want to build your own, there’s a link in the readme to buy NZ-made
ones.
Lawrence D'Oliveiro wrote:
It is possible to get USB cables that only connect the power wires for
charging, without enabling data transfer.
Is this still an issue, at least as far as Android phones are concerned?
In article <5br66jp0u5gdvppc8nm9j2rmug0piq02uc@4ax.com>,
Ralph Fox <-rf-nz-@-.invalid> wrote:
On Fri, 07 Jun 2024 14:12:23 GMT, Scott Alfter wrote:
(Your newsreader is inserting CRs at the ends of lines, BTW...might want to >>> fix that.)
I see CRLF at the ends of lines in Andy Burns' message. Both in the
raw message and in the base64-decoded text. I checked Andy's message
on two different news servers.
CRLF is the correct, standard on-the-wire format.
Maybe they were extras in addition to whatever standard newline is present. When I replied to his post, there was an extra Ctrl-M at the end of every line. Right now, while I'm replying to your post, it's normal...no extra characters that need deleting.
Andy's message body is base-64 encoded. Mine is not.
When I run Andy's raw base-64 message body through a base-64 decoder,
the messageafter decoding also has CRLF and only CRLF at the ends
of lines. I tested this with a base-64 decoder outside of my newsreader,
to avoid any possibility that my newsreader might be modifying the line
ends after decoding.
On Sat, 08 Jun 2024 16:15:04 +1200
Ralph Fox <-rf-nz-@-.invalid> wrote:
On Fri, 7 Jun 2024 21:57:40 +0100, Andy Burns wrote:
Ralph Fox wrote:
Scott Alfter wrote:
(Your newsreader is inserting CRs at the ends of lines, BTW...might want to
fix that.)
I see CRLF at the ends of lines in Andy Burns' message. Both in the
raw message and in the base64-decoded text. I checked Andy's message
on two different news servers.
CRLF is the correct, standard on-the-wire format.
Actually I think bare LF's are correct, no?
The on-the-wire format for transmission is CRLF, *not* bare LF. See,
for example, RFC5537 "Netnews Architecture and Protocols" section 2
"Transport".
<https://www.rfc-editor.org/rfc/rfc5537#section-2>
| Transports for Netnews articles MUST treat news articles as
| uninterpreted sequences of octets, excluding the values %d00 (which
| may not occur in Netnews articles), %d13, and %d10 (which MUST only
| appear in Netnews articles as a pair in that order and which,
| together, denote a line separator). These octets are the US-ASCII
| [ASCII] characters NUL, CR, and LF respectively.
How a newsreader client or news server stores articles locally (CRLF
or bare LF) is up to that client or server. But when communicating
between client and server / server and client, the on-the-wire format
is CRLF.
I believe the RFC quote refers to articles before decoding (if there was an encoding step).
Here the complaint is that Andy's message had CR at the end
of every line even after decoding. I don't believe there is any standard for that and a newsreader should probably follow the customs of the underlying operating system.
Ralph Fox wrote:
Andy's message body is base-64 encoded. Mine is not.
When I run Andy's raw base-64 message body through a base-64 decoder,
the messageafter decoding also has CRLF and only CRLF at the ends
of lines. I tested this with a base-64 decoder outside of my newsreader,
to avoid any possibility that my newsreader might be modifying the line
ends after decoding.
I accept that TB is doing that (I think not just mine) several times
I've tried to stop it, but I fear I can't ... it's usually "lured" into
doing base64 by a particular sequence of messages, suggestions welcome ...
Ralph Fox wrote:
Using the latest Thunderbird 115.11.1 on Windows...
* When I compose a reply to Lawrence's post with the 'curly' quotes
and put it in the Outbox, my reply is not base-64 encoded.
Several times I've half-arsedly looked into what causes my TB to use
base64, after looking in a hex editor, it always seems to occur after a perfect storm combination of user-agents, content-types,
character-encodings etc
Maybe I have some ancient about:config setting that I can't remember?
I've never managed to get even close to being able to log a good
bugzilla ticket.
* I would like to try composing my reply with various character
encodings/charsets, but current Thunderbird 115.11.1 does not seem
to have that option any more.
Tools/Accounts/[ServerName]/ServerSettings/DefaultTextEncoding
Ralph Fox wrote:
At one time you could specify the character encoding for an outgoing
message from its Compose window menu "Options >> Character Encoding".
<http://kb.mozillazine.org/Font_settings_in_Thunderbird#Character_encoding>. >> Similar to how you still can in SeaMonkey. See this screen-shot from
SeaMonkey:
<http://img4.imagetitan.com/img.php?image=27_lchai5__text-encoding-menu-on-the-compose-window-in-seamonkey.png>
Have you looked at about:config, Tools-->Options-->Advanced-->Config Editor...
In my old Thunderbird I see mailnews.send_default_charset;UTF-8 I guess
you could change it to Windows-1252.
Or simply use SeaMonkey. With some
config editing, you could probably share your news directories, unless Thunderbird has changed something.
Dave
I suspect Andy's posts
are base64 encoded when they contain non-ASCII characters
(no matter
what the charset) because I suspect Andy's Thunderbird preference 'mail.strictly_mime' is set to true.
On Fri, 14 Jun 2024 16:15:33 -0700, Dave Yeo wrote:*SKIP* [ 5 lines 3 levels deep]
Ralph Fox wrote:
At one time you could specify the character encoding for an outgoing
message from its Compose window menu "Options >> Character Encoding".
<http://kb.mozillazine.org/Font_settings_in_Thunderbird#Character_encoding>.
Have you looked at about:config, Tools-->Options-->Advanced-->ConfigThat about:config preference is not in Thunderbird version 115.11.1
Editor...
In my old Thunderbird I see mailnews.send_default_charset;UTF-8 I guess
you could change it to Windows-1252.
(the current release).
Ralph Fox wrote:
I suspect Andy's posts are base64 encoded when they contain
non-ASCII characters
Yes, I did tests several months ago
(no matter what the charset) because I suspect Andy's
Thunderbird preference 'mail.strictly_mime' is set to true.
With various charsets, with/without the "strictly" setting, on
messages that were 7-bit clean or otherwise.
My conclusion was that everything annoys somebody,
but the least annoying overall is to embrace UTF-8
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 388 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 05:19:48 |
| Calls: | 8,220 |
| Calls today: | 18 |
| Files: | 13,122 |
| Messages: | 5,872,259 |
| Posted today: | 1 |
