Anyone else feels like this will be abused for phishing and/or malware distribution?
is there any hosting site that isn't? feels like a computing law at this point; if you build a hosting site, someone will try to use it for malicious purposes.
Can’t you just make the hosting site features only be for real purposes?
Like a link shortener which only forwards to a domain that matches the subdomain? Or only for watching videos and collecting metrics etc.
Any file upload can be used for unintended purposes, eg encoding files into static to upload to youtube and all other sorts of tomfoolery: https://github.com/boehs/awesome-cloud-storage-abuse
It will be. We had the same issue with Matrix attachments.
got fixed by https://github.com/matrix-org/matrix-spec-proposals/blob/mai... fwiw
I noticed^^
Tbh, I still haven't figured out how my IRC client is supposed to fetch avatars of bridged matrix users now.
Previously I was able to special case bridged matrix users and access their avatars through
/_matrix/client/r0/profile/{name}/avatar_url
/_matrix/media/r0/thumbnail/{server}/{id}/
/_matrix/media/r0/download/{server}/{id}I believe the bridges should host a proxy (per-bridge) to expose content: https://github.com/matrix-org/matrix-appservice-irc/pull/180...
But does that proxy actually expose avatars/profile pictures? From what I can tell they only proxy attachments.
avatars pictures /are/ just attachments tho?
The bridge only transforms images attached to events to new media proxy links.
If a bridged matrix user joins a channel, as IRC client I see the following information:
justJanne[m][email protected] (@justjanne:matrix.org)
mxc://matrix.org/uQMYcfRtSKFlYYBXLGhuIXzq
With authenticated media, I would need to get a URL with a signed JWT from the bridge's media proxy such as
https://matrix.org/snoonet/media/v1/media/download/ARahZwUoMu0BcC8Di6Q3N3lpPAejecpE6OyRcKnsvw3n7pjmP7XVSXG8hYT99knbOtESJ9ODlzqLcdLy8Y2mPs9CeTshGEPwAG1hdHJpeC5vcmcvdVFNWWNmUnRTS0ZsWVlCWExHaHVJWHpx
I'd expect to have an special endpoint such as /snoonet/avatar/{mxid} that'd redirect me to the /snoonet/media/v1/media/download URL.
It'll take about 5 mins for that to happen and then for *.bsky.network to start getting blocked by Google Safe Browsing, Palo Alto, Bluecoat etc.
I don't see how. This is a direct link to the author's bluesky server (PDS) so of course it is controlled by them.
The link in question (linked from the the sumbitted link) is `porcini.us-east.host.bsky.network`. That's hosted by bsky, isn't it?
Lack of moderation combined with an offical-sounding domain name.
This would have to get the user to follow a link or call a phone number or something though. These are plausible. It's too bad the content-security-policy can't prevent following links.
Bluesky seems to use a lot of totally different domain names for each part of their infrastructure, maybe for this reason. e.g. this one is bsky.network
While they're nowhere close on volume, they're certainly beating microsoft in terms of the rate they're adding similar looking official URLs.
> bsky.network
Shortening your brand to 4 letters when your chosen TLD is the same length as your full brand name is such a weird choice.
I think the linked blogpost is the first time I've seen that URL used anywhere user-facing. (other than the status page) bsky.<TLD> is already used for other user-facing URLs though.
I guess bsky.net and bluesky.net were taken. What’s weird is why ICANN allowed .network TLD at all when .net already existed, was shorter, and meant for that.
I can't be the only person who visited bluesky.com, assuming that was the thing everyone was talking about.
I mean, the way AT Proto is designed, moderation primarily happens on the app layer, not the protocol layer. So on an app like Bluesky, you can have a lot of moderation. But the protocol itself allows hosting arbitrary content in a distributed/decentralized way.
Phish could be this:
$inane_marketing_trope
...
Click here to Unsubscribe from Bluesky
https://porcini.us-east.host.bsky.network/xrpc/com.atproto.s...
...
Redirects to bad site.
As long as content is authored by the administrator of the server, I don't see where there is a security issue.
It's like if you point to your own Apache server in your own domain where you host a scam page and say there's a security issue with Apache because you could do that.
Or are you saying that you can make this person's server serve third-party content?
> Or are you saying that you can make this person's server serve third-party content?
Http: yes see OP
Email: not sure. Hopefully not. But spoofing happens.