1
point
jstanley
Joined 22,094 karma
James Stanley
james@incoherency.co.uk
https://incoherency.co.uk/
- jstanleyWhere I live, the difference is almost six months!
- > Where are you getting this from?
I asked a friend who is knowledgeable about this stuff, but he hasn't provided a source, perhaps he is (and by implication I am) mistaken.
- The theory is that there was an older and more advanced civilisation that built them using more advanced techniques which are now lost.
And the Inca inherited pre-existing structures.
The Inca did do stonework of their own, but not close to the standard exhibited in this article.
- However many are left. In what circumstances do you care?
- I'm working on headless browser fingerprinting.
We're focusing on "anti-cloaking" for anti-phishing and other Internet security applications at the moment. Phishing sites can "cloak" themselves so that they present malicious content to ordinary users and benign content to bots, and thereby evade detection. Anti-cloaking is doing things to defeat cloaking.
The methodology is to operate a site that logs all requests, and collects information from the JavaScript environment, and looks for signals that a session is being operated by a bot instead of a human. We have 183 unique signals so far.
We've seen fake mobile phone APIs being injected into the DOM, and have been able to read out the source code implementing them. We've seen lots of people running the browser with TLS validation and same-origin policy disabled, which are both easy to probe for. And we've even seen people running services on localhost with CORS headers that allow cross-origin requests, allowing us to read out their server headers and page contents and which would allow us to send arbitrary requests to their local servers. We've seen people using proxies that don't support websockets. We've even seen surprisingly-big companies scanning us from netblocks that just straightforwardly name the company, which would be trivial to block just by IP address.
It turns out that every security vendor that scans VirusTotal submissions or domains from CT logs has major flaws in their headless browser setup which mean it's worryingly easy to cloak from them.
I don't know the best angle for monetisation. Currently we are selling "quick overviews" of what people are doing wrong, but it kind of feels like we're giving away too much value too cheaply. However it's difficult to convince people that there is value worth paying for without telling them what they're doing wrong upfront before they pay. Ideas include:
* automated quick overviews, where we give you a URL to point your bot at, find out all the signals you hit, and give you an automatically-generated report of what you are doing wrong
* or a manual "pentest" of your headless browser, where we do the same thing but spend a few days manually looking harder to see if there are new signals we're not yet spotting automatically
* or we could sell a report of the state of the industry as a whole
* or access to our tooling
* or something else
I have been told that if I say it's for anti-phishing then I have 12 customers max but if I say it's for AI browser agents then someone will give me a billion dollars. So possibly we need to explore other applications, like either telling AI scrapers why they are getting blocked, or else helping sites block AI scrapers (though I am personally opposed to building the apartheid web).
Open problems are:
* what's the best form to sell it?
* how do we satisfy people that if they pay for a test then they will get value from it?
* should we pivot away from anti-phishing?
* for bots that we notice have found us from VirusTotal or CT logs, how do we work out who is operating them so that we can sell to them? Sometimes attribution is easy but in the majority of cases it is not
- Not only is it pretty obvious why US independence day is not celebrated in the UK (although maybe that was tongue-in-cheek?), but we do have a fireworks night on a different date.
- After I finished my "industrial year" at university, we were all asked to give a short presentation on what we had done "in industry".
Returning to university after my industrial year, I took a very dim view of the academic environment and resented being asked to do this task that was worth no credit towards my degree.
So I didn't rehearse or even make any slides, I just stood up and talked about what I had been up to.
And although I was by any measure an extremely inexperienced speaker, it was the best talk I had ever given. It was the first time I stood in front of a room of people and felt present in the environment while giving my talk, rather than monotonously reciting the rehearsed material.
So obviously different people have different experiences, but I learnt that day that rehearsing your talk isn't always helpful.
It helped that I really enjoyed my industrial year and had loads of interesting stuff to talk about. So maybe the more important thing is to be interested in the topic.
- If a camera can see your eyes, why can't you?
- It's not confusing that this works in Go. (In my opinion).
A straightforward reading of the code suggests that it should do what it does.
The confusion here is a property of C, not of Go. It's a property of C that you need to care about the difference between the stack and the heap, it's not a general fact about programming. I don't think Go is doing anything confusing.
- You're more likely to get a ball-of-yarn if you try to separate things into unnatural layers than if you let it be a single layer.
- > At first, there were many people typing, then later [...]
There were more people typing than ever before? Look around you, we're all typing all day long.
- Centering text boxes in competent design software is easy because it has a tool to align things to the centre of other things.
For example, Inkscape has this and it is easy to use.
- It solves the rigging problem, it doesn't necessarily make claims as to whether that is the only problem that exists.
- If you're worried about someone exiting the protocol, you can use a smart contract to lock their funds so that if they simply exit then they lose all their money.
- Because you can rig the answer if it's just one person. But if two of you use the method from the post, and both commit to your answers before revealing them, then neither of you can rig it.
- That you don't understand something doesn't mean everyone else is wrong.
- > Users who go to http://mysite.example/ would be "redirected" to https://mysite.example/ but that redirection wasn't protected so instead the active bad guy ensures they're redirected to https://scam.example/mysite/ and look, it has the padlock symbol and it says mysite in the bar, what more do you want?
You can do better than this. You can have your mitm proxy follow the SSL redirect itself, but still present plain HTTP to the client. So the client still sees the true "mysite.example" domain in the URL bar (albeit on plain http), and the server has a good SSL session, but the attacker gets to see all of the traffic.
- That's an implementation detail of the bank.
You might just as well say that E2EE messaging is impossible because you are sending a message "to" Signal, and they need to read it in order to act on it.