@Edent@mastodon.social

Terence Eden

Mastodon enforces a "noreferrer" on all external links.

I have mixed feelings about that.

As a blogger, I want to see *where* visitors are coming from. I also like to see (and sometimes join in) with the conversations they're having.

But, I get that people want privacy and don't want to "leak" where they're visiting from.

Is it such a bad thing to tell a website "I was referred from this specific server"?

---

When you click on this link - https://www.bbc.co.uk/news - your browser says "Hey! BBC! Please can I have your /news page? BTW, I was referred here by shkspr.mobi. THANKS!" This is called the "Referer" and, yes, it is mispelt.

One the one hand, sending the referer is good; it lets the linked-to server know who is linking to it. That allows them to see where traffic is coming from. On the other hand, this could be bad for much the same reason.

If you run a server anarcho_terrorists.biz, you probably don't want the FBI knowing that your members are sharing links to their pages. If you run a small personal server, you may not want anyone knowing that you personally linked to them. If you run a server for a marginalised community, you may not want a hate-site to know your members are linking to you.

But if you're a large-ish, general purpose, non-private site - like Mastodon.social - where's the harm in allowing referer headers?

Anyway, for historic reasons, Mastodon blocked the referer header. This, I believe, was sensible for smaller servers but a miss-step for larger servers. As I pointed out last week:

@Edent@mastodon.social

Terence Eden

Two years later.

Want to know one of the major reasons Mastodon didn't catch on with journalists and large website owners?

It is *invisible* in referrer statistics.

Here's my blog from the last month.

BlueSky now sends me more traffic than Bing.

How much traffic does Mastodon send? It is impossible to know due to the "noreferrer" header in all links.

(I'm not saying your privacy isn't important. But you can't grow a community if no-one knows you exist.)

---

I'm not the only one to make this point - it has been a popular complaint for some time.

A few days ago, Mastodon changed to allow this to be configurable.

This is excellent news. Website owners will be able to (somewhat) accurately see how much traffic Mastodon sends them. That way they can determine if there is a suitably large audience to engage with on the Fediverse.

It is, of course, slightly more complicated than that!

• Instance owners can opt-in to allowing Referer headers (it is off by default).
• The policy means that only the domain name is sent; not the full page.
• Mastodon is federated and there are thousands of sites. Even if they all opted-in, their statistics will be fragmented.
• Apps can set their own Referer header - leading to more fragmentation.
• Even if they do opt-in, users can set their browsers not to send Referer headers.

Nevertheless, I'm delighted with this change. Hopefully it will allow the Fediverse to grow and attract more users.

HTTP Message Signatures are hard⁰. There are lots of complex parts and getting any aspect wrong means certain death¹.

In a previous post, I wrote A simple(ish) guide to verifying HTTP Message Signatures in PHP. It turns out that it was too simple. And far too trusting.

An HTTP Message Signature is a header which is separate to the message it signs. You might receive a JSON message like this:

{
   "actor":   "https://example.com/user/Alice",
   "message": "We strike at dawn!"
}

How do you know that really came from Alice? You look at the header of the message. It will be something like:

Signature: 
   keyId="https://example.org/user/Alice#main-key",
   algorithm="rsa-sha256",
   headers="(request-target) host date digest",
   signature="/AJ4Dv/wSL3XE1dLjFHCYVc7AF4f3+Q10G/r8+6cPsooiUh2K3YX3z++Nclo4qKHYr61yu+T4OMqUry1T6ZHmZqmNkg1RpVg=="

We want to check that Alice signed this message with her private key. So we grab her public key given by the keyId. From there, we do some fancy maths using RSA-SHA256 and conclude that, when you put together the (request-target) host date digest content-type and compare them to the public key, they can only have be signed by the private key. Hurrah!

Did you spot the mistake I made? It wasn't in the maths, or the complex ordering of the data, or the algorithm choice, or some weird Unicode problem.

I made an error in trust.

Take a look at the Signature again.

The keyId is from example.org. But the actor is from example.com.

This message is signed correctly. It is cryptographically valid. But it wasn't signed by the actor in the message!

In this case, the fix is simple. Get the public key from keyId. Then independently get the named actor's public key. If they match, all is well. If not, skulduggery is afoot.

I'm almost tempted to say that you should ignore the provided keyId entirely; the source of truth is the actor's key - and the best way to get that is directly from the actor's profile.

Please explain why I'm wrong in the comments.

This is a quick example to show how to verify these signatures using PHP. I don't claim that it covers every use-case, and it is no-doubt missing some weird edge cases. But it successfully verifies messages sent by multiple Fediverse servers.

Let's step through it with an example of a message sent from Mastodon to my server.

Headers

The HTTP request starts with these headers:

User-Agent:  http.rb/5.1.1 (Mastodon/4.3.0-nightly.2024-02-23; +https://mastodon.social/)
Host:  example.com
Date:  Sun, 25 Feb 2024 10:48:22 GMT
Accept-Encoding:  gzip
Digest:  SHA-256=Hqu/6MR2imi8DTzbNp5PNEAFSyk0poN7+x5F+Z4vZMg=
Content-Type:  application/activity+json
Signature:  keyId="https://mastodon.social/users/Edent#main-key",algorithm="rsa-sha256",headers="(request-target) host date digest content-type",signature="P07V5I2zflR8FRsDMHshHmhgOwSkjWevujEbOyKMwjycrdVXjTD0ACiLuc5lTqDEXZ/...4eg=="
Connection:  Keep-Alive
Content-Length:  2857

Some of those you may be familiar with, some not. The first thing we'll do is a sanity check; was this message sent recently? Because clocks drift in and out of synchronisation, we'll check if the message was within ±30 seconds.

$headers = getallheaders();
if ( !isset( $headers["Date"] ) ) { return null; }  //  No date set
$dateHeader = $headers["Date"];
$headerDatetime  = DateTime::createFromFormat('D, d M Y H:i:s T', $dateHeader);
$currentDatetime = new DateTime();

// Calculate the time difference in seconds
$timeDifference = abs( $currentDatetime->getTimestamp() - $headerDatetime->getTimestamp() );
return ( $timeDifference < 30 );

That was easy! On to the next bit.

Digest

A message posted to the server usually has a body. In this case it is a long string of JSON data. To ensure the message hasn't been altered in transit, one of the headers is:

Digest:  SHA-256=Hqu/6MR2imi8DTzbNp5PNEAFSyk0poN7+x5F+Z4vZMg=

That says, if you do a SHA-256 hash of the JSON you received, and convert that hash to Base64, it should match the digest in the header.

$digestString = $headers["Digest"];
//  Usually in the form `SHA-256=Hqu/6MR2imi8DTzbNp5PNEAFSyk0poN7+x5F+Z4vZMg=`
//  The Base64 encoding may have multiple `=` at the end. So split this at the first `=`
$digestData = explode( "=", $digestString, 2 );
$digestAlgorithm = $digestData[0];
$digestHash = $digestData[1];

//  There might be many different hashing algorithms
//  TODO: Find a way to transform these automatically
if ( "SHA-256" == $digestAlgorithm ) {
    $digestAlgorithm = "sha256";
} else if ( "SHA-512" == $digestAlgorithm ) {
    $digestAlgorithm = "sha512";
}

$json = file_get_contents( "php://input" );

//  Manually calculate the digest based on the data sent
$digestCalculated = base64_encode( hash( $digestAlgorithm, $json, true ) );

return ( $digestCalculated == $digestHash );

But, of course, if someone has manipulated the JSON, they may also have manipulated the digest. So it is time to look at the signature.

The Signature

Let's take a look at the signature header:

Signature:
  keyId="https://mastodon.social/users/Edent#main-key",
  algorithm="rsa-sha256",
  headers="(request-target) host date digest content-type",
  signature="P07V5I2zflR8FRsDMHshHmhgOwSkjWevujEbOyKMwjycrdVXjTD0ACiLuc5lTqDEXZ/...4eg=="

This contains 4 pieces of information.

1. keyID - a link to the user's public key.
2. algorithm - the algorithm used by this signature.
3. headers - the headers which make up the string to be signed.
4. signature - the signature string.

Let's split them up so they can be used:

//  Examine the signature
$signatureHeader = $headers["Signature"];

// Extract key information from the Signature header
$signatureParts = [];
//  Converts 'a=b,c=d e f' into ["a"=>"b", "c"=>"d e f"]
               // word="text"
preg_match_all('/(\w+)="([^"]+)"/', $signatureHeader, $matches);
foreach ($matches[1] as $index => $key) {
    $signatureParts[$key] = $matches[2][$index];
}

Let's tackle each part in order.

Get the user's public key

You might think you can just get https://mastodon.social/users/Edent#main-key - but you would be wrong.

Firstly, you need to tell the key server that you want the JSON representation of the URl - otherwise you'll end up with HTML.

$publicKeyURL = $signatureParts["keyId"];
$context   = stream_context_create(
    [ "http" => [ "header" => "Accept: application/activity+json" ] ] 
);
$userJSON  = file_get_contents( $publicKeyURL, false, $context );

That gets you the JSON representation of the user. On Mastodon, the key can be found at:

I don't know how to automatically find the key, so I've hard-coded its location.

$userData  = json_decode( $userJSON, true );
$publicKey = $userData["publicKey"]["publicKeyPem"];

Get the algorithm

This is rather straightforward. It's just the text in the signature header:

$algorithm = $signatureParts["algorithm"];

Reconstruct the signing header

Let's take a look at the third piece of the puzzle:

headers="(request-target) host date digest content-type"

This says "The signature is based on the following parts in order". So we only care about the headers which make up the request, the host, the date, the digest, and the content type. Other servers may require different parts of the headers.

Again, let's tackle them in order.

(request-target)

This means the method of the request and the target it was sent to. In our example, this is a POST sent to the path /inbox.

host

This is the HTTP host the message was sent to. This should be retrieved from the server, not taken from the sent headers.

date digest content-type

These are the values from the headers which were sent with the request.

Putting it all together

Annoyingly, the HTTP headers are written in Title-Case whereas the headers in the Signature are in lower-case. So some conversion is necessary:

//  Manually reconstruct the header string
$signatureHeaders = explode(" ", $signatureParts["headers"] );
$signatureString = "";
foreach ($signatureHeaders as $signatureHeader) {
    if ( "(request-target)" == $signatureHeader ) {
        $method = strtolower( $_SERVER["REQUEST_METHOD"] );
        $target = strtolower( $_SERVER["REQUEST_URI"] );
        $signatureString .= "(request-target): {$method} {$target}\n";
    } else if ( "host" == $signatureHeader ) {
        $host = strtolower( $_SERVER["HTTP_HOST"] );    
        $signatureString .= "host: {$host}\n";
    } else {
        //  In the HTTP header, the keys use Title Case
        $signatureString .= "{$signatureHeader}: " . $headers[ ucwords( $signatureHeader, "-" ) ] . "\n";
    }
}

//  Remove trailing newline
$signatureString = trim( $signatureString );

This results in a string like this:

(request-target): post /inbox
host: example.com
date: Sun, 25 Feb 2024 10:48:22 GMT
digest: SHA-256=Hqu/6MR2imi8DTzbNp5PNEAFSyk0poN7+x5F+Z4vZMg=
content-type: application/activity+json

Get the signature

The signature that we are sent is in Base64.

signature="P07V5I2zflR8FRsDMHshHmhgOwSkjWevujEbOyKMwjycrdVXjTD0ACiLuc5lTqDEXZ/...4eg=="

It needs to be decoded before we can use it.

$signature = base64_decode( $signatureParts["signature"] );

Verify the signature

We're nearly there! Luckily, we don't have to do any crazy cryptography by hand. We use PHP's openssl_verify():

//  Finally! Calculate whether the signature is valid
$verified = openssl_verify(
    $signatureString, 
    $signature, 
    $publicKey, 
    $algorithm
);

That takes the reconstructed string based on the headers, the signature which was sent, the public key we retrieved, and the algorithm.

If it all matches, it will return true. If not... time for some debugging!

But what about...?

This is not a complete solution. My code almost certainly contains bugs, unforeseen edge-cases, memory leaks, black holes, and poisonous frogs. This is intended to step you through the practical process of verifying an HTTP Message Signature.

Then you should get a properly tested and validated library and use that instead.

Conceptually, they're relatively straightforward.

You send me a normal HTTP request. For example, you want to POST something to https://example.com/data

You send me these headers:

POST /data
Host: example.com
Date: Sat, 24 Feb 2024 14:43:48 GMT
Accept-Encoding: gzip
Digest: SHA-256=aaC57TDzM0Wq+50We2TkCsdMDvdqON92edg7KI+Hk8M=
Content-Type: application/activity+json
Signature: keyId="https://your_website.biz/publicKey",algorithm="rsa-sha256",headers="(request-target) host date digest content-type",signature="JGQ53kEoIiMWRp9By9jajVGCOCu4n7XBeiA1uY5xLcnAxL2Y1GIgU/...=="
Connection: Keep-Alive
Content-Length: 751

In order to verify the contents of the message, I need to do three things:

1. Check the SHA-256 hash of the message matches the content of the "Digest" header.
2. Check the timestamp is somewhat fresh.
3. Check the signature matches.

The first is simple: base64_encode( hash( "sha256", $request_body, true ) ).

The second is a matter of opinion. I might be happy to receive messages from the distant past or far in the future. For the sake of a little clock drift, let's allow 60 seconds either way.

The third gets complicated.

First, I need to get the public key published at keyId="https://your_website.biz/publicKey".

Next, I need to know which algorithm is being used to sign the headers: algorithm="rsa-sha256"

Then, I need to know which headers - and in what order - are being signed: headers="(request-target) host date digest content-type"

So I create a string using the received details which matches those headers in that specific order:

(request-target) POST /data
Host: example.com
Date: Sat, 24 Feb 2024 14:43:48 GMT
Digest: SHA-256=aaC57TDzM0Wq+50We2TkCsdMDvdqON92edg7KI+Hk8M=
Content-Type: application/activity+json

I can verify if the signature - signature="JGQ53kEoIiMWRp9By9jajVGCOCu4n7XBeiA1uY5xLcnAxL2Y1GIgU/...==" matches by:

openssl_verify(
    $headersString, 
    $signature, 
    $publicKey, 
    $algorithm
);

If that's TRUE then all is well.

But can you spot the implicit problem?

How do I get your server's public key?

I just GET https://your_website.biz/publicKey - but if your server uses something like Authorised Fetch then I have to sign my request to you.

Which means your server will need to validate my signature by obtaining my public key. Which it will get by signing a request and sending it to me. Which, before I return my public key, I will need to validate your signature by obtaining your public key. Which I will get by signing a request... and so on.

This deadlock loop is documented. The usual way around it is either for the sending server to use an instance-specific signature which can be retrieved by an unsigned request, or to allow any unsigned request to access a user's public key.

I get why things happen this way - I just wish it were easier to implement!

For years, HTTP content has been served with gzip compression (gz). It's basically the same sort of compression algorithm you get in a .zip file. It's pretty good!

But there's a new(er) compression algorithm called Brotli (br). It's Better, Faster, Stronger, Harder than gzip. Mostly.

Looking through my browser's request logs, I noticed everything was being transferred with Brotli compression except for one specific text file was being served as gz.

What's going on?

Well, let's take a look at the file's size.

curl -s "https://openbenches.org/api/benches.tsv" | wc -c

That downloads the file, counts the number of bytes, then formats it for readability. It's 2,727,104 bytes.

Now let's request it as a gzipped file:

curl -s -H'Accept-Encoding: gzip' "https://openbenches.org/api/benches.tsv" | wc -c It's 1,085,372 bytes.

Finally, requesting a Brotli compressed transfer: curl -s -H'Accept-Encoding: br' "https://openbenches.org/api/benches.tsv" | wc -c

That's 1,098,151 bytes. A whole 12,779 bytes larger!

My server was correct in using gzipped rather than Brotli for this specific file.

But, that's not the entire case here! I manually compressed the full file using different compression levels. Here's a quick graph showing the filesize at different compression strengths:

So, in this case, Brotli ≤ 3 is worse than gzip ≥ 5.

I suspect my host's server is configured to prioritise faster compression over absolutely smallest file size. That's probably a reasonable trade-off. I couldn't see a way to tell it to use a higher strength Brotli algorithm all the time - but I would probably be chasing marginal gains.

So, there you go. Don't be surprised if you occasionally see gzip where you expect to see Brotli.

Generally speaking¹, clients (like browsers) talk to servers using a set number of HTTP "verbs". This tells the server what sort of thing the client is trying to do.

The two most popular² verbs are probably POST - which lets you send data to a server - and GET - which lets you get data back from a server.

There are other HTTP verbs like DELETE to delete data, and PATCH to change data. But it is a fairly limited set of actions.

What would be some interesting or useful verbs to add to HTTP's vocabulary?

Payments

I think the most obvious one would be BUY.

A client sends a GET request to a server. The server responds with HTTP Status 402 Payment Required which includes payment details. The client sends BUY along with confirmation that they've sent the payment³. The server responds with the content.

Mistakes

What about if you make a mistake using POST, PUT, or DELETE? Wouldn't you like to use HTTP UNDO?

Terence Eden is on Mastodon

@edent

Your deepest wish comes true and you get to add one more HTTP Verb to the specification.

Which one do you choose?

---

Buy: (6)
6
Forgive: (10)
10
Prevaricate: (20)
20
Something else - what?: (12)
12

---

ཀ།༨ཇ ་།་འ།སབཇའ

@chthonicionic

Replying to @edent@edent Possibly it’s forgive, but … UNDO

---

Let's not get in to a discussion about idempotency⁴

Halt And Catch Fire

Some CPUs have peculiar instructions which can be (ab)used to make them self-destruct. So why not extend that to HTTP⸮

<https://twitter.com/whalecoiner/status/1562878271960002560>

Remember that scene in every Star Trek movie where the captain shouts "Computer! Initiate self-destruct sequence. Confirmation code Heliotrope Banana Daguerreotype." Let's extend that so that clients can request that a (virtual?) machine shuts down.

Won't you please please help me?

APIs - and other services - are sometimes difficult to use. In the Linux⁵ world we just type -h or --help after every command and get some more-or-less useful help text.

So what about HTTP HELP? Return a machine- or human-readable document explaining what commands the server responds to. Pretty sure that'd be useful.

Who are you? Who? Who?

Cookies have gotten out of hand. And, frankly, they're a security disaster. Why should a server send a client a token to store? Let's reverse that with HTTP REMEMBER.

The client sends the server a suitably complex string and a validity period. The server is then compelled to remember the client's authorisation. Perfect⁶!

And when you want to log out, an HTTP FORGET is easier than clearing your cookies. Imagine that, a log-out button in your browser which worked everywhere...!

Over to you

So, if you were made God-Emperor-For-Life of the IETF, which new HTTP verbs would you add?

But Twitter seems to think so.

When I share a link to Twitter on Facebook, this (sometimes) happens.

And sometimes, I get this delightfully mangled Unicode atrocity!

So, what's going on?

When Facebook wants to display a link, its servers send a quick web request to the URL that the user has typed into the box. When Twitter receives that request, it looks at where it has come from and tries to localise its content.

If you're a German, you probably want the Twitter website to be in German. That's fairly sensible. But when you receive a request from one country on behalf of another, what should you do?

Here are the headers which Facebook sends with every request.

User-Agent: facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)
Accept: */*
Accept-Encoding: deflate, gzip
Range: bytes=0-524287
Host: example.com
Connection: keep-alive
IP: 31.13.110.120

That IP address, according to most geolocation databases, is from Ireland - however some list it as being Swedish.

Twitter is, arguably, doing the right thing here. They're seeing an IP from Sweden, and serving it up a Swedish page.

Yes, their IP database is out of date, but even if it wasn't I'm not sure everyone on Facebook want to be reading in Gaeilge or English.

Facebook knows what language the user speaks. It really ought to be including the HTTP "Accept-Language" header in its requests.

It's really easy! All that HTTP request needs is:

Accept-Language: en-gb;q=0.8, en;q=0.7

That means "I want British English, but I'll accept any other form of English".

Hey presto! Twitter will see a request from Sweden / Ireland and rather than dumbly looking at the IP will make an intelligent choice based on the user's language preferences as determined by Facebook.

I spoke to someone informally at Facebook about this. They claimed that this is a user privacy measure. Facebook sending your language preferences to a third party could be an unwanted invasion of privacy. Personally, I think that's a load of rubbish. Could an attacker send you a specially crafted link and find out that you secretly read Facebook in Pashto? Perhaps. But because this doesn't happen all the time, I suspect it's just a piece of sloppy engineering.

As we say in Sweden, "Ibland användbarhet innebär att arbeta lite hårdare för att se till misstag i andra företags datorer påverkar inte dina användare negativt!"

One would think that, in these capitalist times, ISPs would compete over who could provide the fastest speed, the best service, and the lowest price. Sadly, in the UK, our ISPs seem to compete on who can be slightly less awful than each other.

Last night, I did what many people normally do with their Internet connection. I made an HTTP request to open a website. Rather than receiving the site I had requested, I received this monstrosity from Virgin Media - my ISP.

I really was baffled. At first, I thought the site I was trying to reach had been blocked by the infallible British justice system. This is what Virgin customers see when they try to access a site blocked by the Great Firewall of Cameron:

I'd made several web requests during that session but, crucially, this was the first one that I had made over HTTP. The rest had all been secured via HTTPS. It wasn't even a salacious site I was visiting - unless cultural criticism of Barbie is too hot to handle nowadays.

Here's the thing though. I've a number of devices in my house, all of which make HTTP requests. My solar panels, my tablet, my TV, my radio, all chattering across the 'net on Port 80. Any one of them could have had their session hijacked. Perhaps they would have failed gracefully - perhaps not?

Perhaps some cheap piece of kit is sending usernames and passwords in plain text - now all that information has been redirected to my ISP.

I wasn't able to catch the exact exchange, nor the HTTP status code that redirected my session. All I do know is that my ISP broke the trust that it has with me. I pay Virgin to send and receive bits. Nothing more, nothing less. I don't want it interfering with my traffic outside the bounds of normal operations.

What next?

• Sorry to interrupt you ordering from Pizza Hut - we'd really like you to try a slice from Dominos?
• Sorry to interrupt you listening via Pandora - we've done a deal with Spotify, so try that instead!
• Sorry to interrupt you placing an order with a new ISP - please give us another chance!

Virgin send me an email with my bill. They also post me endless leaflets asking me to upgrade to their TV service. If they wanted to contact me about their new "Web Safe" system, they have ample opportunities to do so without monkeying around with the service that I'm actually paying for!

This sort of session hijacking is... I struggle to adequately describe it. Disgraceful is probably the word that comes closest. It is a Man In The Middle (MITM) attack. It impairs the operation of my computer. It's just rude!

And, the icing on the cake, Web Safe isn't very good.

There's a plaintive thread on Virgin Media's community forums asking for help with Web Safe:

is there a way to block only on-line betting/gambling sites i.e. make it impossible for anyone in the house to gamble away real money ?

I don't see any obvious solution on the f-secure or the web safe pages.

I don't want to filter my connection - but I appreciate that some people want to place limits in order to protect themselves. Web Safe can't do that. You can only opt out of sex, drugs, and rock'n'roll crime.

Why is Virgin Media doing this?

As part of our commitment to the UK government's initiative to improve child safety online, we're giving all our customers the chance to decide if they want to switch on Web Safe, our suite of parental controls.

From October until December, you will occasionally be redirected to a branded Virgin Media web page when you're browsing the web.

Please watch out for any other pages claiming to encourage you to switch on parental controls during this period, as these will not be from us, and may put your online security at risk.

From Virgin Web Safe FAQs.

Yup, Call-Me-Dave and Theresa May-Not have decided that we aren't sufficiently puritanical in our online browsing. Despite their hectoring and scaremongering, fewer than 15% of households have switched on the censorship software.

Even the language of it leaves me crawling with horror. "There are some things online that you might not want your family to see" is reminiscent of the Lady Chatterly trial's infamous "Is it a book that you would even wish your wife or your servants to read?"

Let me briefly enumerate some of the many ways that Web Safe is a bad idea.

• It only works on your domestic connection. If you - or your wife - wants to get around it, switch off WiFi and use mobile data instead.
• As mentioned above, it's now an extra vector for web criminals to phish for your details.
• The risk of false positives - Virgin Media has a page where you can tell them that they've over-zealously blocked an innocent page - such as a church.
• The risk of false negatives - if you believe that Virgin Media are doing their job, you may believe that you are surfing encased in a cyber-condom and are completely free from the risks of infection.
• It fundamentally alters the relationship between the subscriber and the ISP. It allows them to pro-actively censor material that you request.
• By demonstrating their ability to hijack your browsing sessions - because the Government asked them nicely - it shows that they take no interest in standing up for the rights of their customers.
• It equates the free expression of sexuality with violence, hate, and criminal activity. If your house contains a person who is confused about their sexuality - cutting off their chance to understand what's happening to them is barbaric.
• It's likely that these filters will also block sexual health charities. That's probably a bad thing, right?

Web Safe is a rotten product which is being foisted upon users in a manner which is unbecoming of a decent ISP.

If you want to stop the government pushing more censorship and control onto the Internet, please join the Open Rights Group.

Terence Eden is on Mastodon

@edent

Dear @virginmedia, don't hijack my HTTP sessions. It is incredibly rude, potentially dangerous, & an abuse of trust. pic.x.com/ak0sr7mxvw

---

Most of the app's communication with the Path servers is over SSL. This means that no-one can see the data you're sending and receiving. If there are snoops on your network, they will only be able to see the encrypted data flowing back and forth. In general, this is a good thing.

Apart from images. If your friends are posting images, they are sent over http. No security. Anyone monitoring your network connection will be able to see all the images you're viewing.

Now, that's bad enough - but it turns out that all the images you send are visible to the the world even if you've set your post to private.

The images are sent over SSL, but as soon as you return to your "Path", a thumbnail is shown of what you've just posted!

Here's a picture of the logs, so you can see what's happening.

So, every image you post or see - including the avatars of your friends - are visible to all. A rather serious security and privacy problem.

Oh, does anyone know what the unencrypted call to "sendgrid.net" is all about?