HN user
[ my public key: https://keybase.io/romeovs; my proof: https://keybase.io/romeovs/sigs/LRjdZcyZ1KAWisoL4pJem7zwUAGZ3VlGlG6Xulk-8Gk ]
tesla.sexy contains the following text, which is slightly concerning:
love your fate
become your own ubermensch
you are the master of your soul
be kind
there is so much to love, so much to live for
follow your heart, ok?Finally we can set up verifiably fair betting!
$10 that the NIST beacon at 1727710980000 will have more than 15 A's in it!
Why do you “have to oppose induction” now?
This might be off topic but has anyone else noticed the sloppiness in Apples' websites lately?
On both Safari and Firefox on my machine the titles on this page appear without the correct fonts (falling back to Times).
On apple.com a lot of buttons (eg. the buy button on https://www.apple.com/mac/) lead to 404 pages.
Trying to report these issues seems impossible, of course.
Obligatory "Why Philosophers Should Care About Computational Complexity" by Scott Aaronson[1], one of the best reads I've ever had from a paper. It debunks the kind of arguments this blog article makes quite deftly.
For instance the argument about the hot iron reminds me of section 6 in the paper "Computationalism and Waterfalls". For someone to ascribe consciousness to a piece of hot iron (or a waterfall, or any other random or psuedorandom process), we need to create a mapping of its states onto consciousness, or in this case, as a proxy, the program called consiousness.exe. Aaronson argues if the mapping we create is too complex, it might be doing all of the work of being consious, not the original underlying piece of hot iron. The article does not go into amount this detail, but it seems like the process of creating this mapping is: make enough mappings at random until one works. It would probably take waaay more mappings than atoms in the universe to try before we hit on one that works (something that's also discussed in Aaronsons' paper in section 4), so I'm not sure if the argument is even relevant.
Give the paper a read, it's one of my favourite pieces of text of all time and Aaronson is better at writing down his ideas than I am.
[1 (pdf)]: https://eccc.weizmann.ac.il/report/2011/108/revision/2/downl...
YouTube themselves haven't done this, but a lot of content creators have started integrating their own ads and sponsorship deals into their content.
This is often done in fun ways where the ad is integrated into the content of the video, so it doesn't annoy me too much and can actually be a fun break from the content of the video.
But for the videos where it _does_ annoy me, I use SponsorBlock [0]. It's an browser extension that lets its users mark certain sections of a video as "ad", "sponsor deal", "self-promotion", etc. to effectively build a crowd-sourced database of ad sections in YouTube videos.
The database is shared and used by the extension to skip the marked sections on most videos I've encountered.
Nice! A welcome addition!
Too bad they're not using KaTeX [0] instead.
It renders the maths server-side, so there's no runtime needed.
An additional bonus is that the resulting math is copy-pasteable, which in the case of disply math might not be that useful (since most equations are to complex to be meaningfully copy-pasted with unicode), but it helps from inline math dissappearing when copy pasting texts.
But, that being said, I'm sure they had their reasons to do so. For one, MathJax seems more well-known by quite a bit so maybe it's the safer option.
My hunch is that it’s not explicitly provided to the website by the browser, but there are ways to measure what the zoom level is using JavaScript on the page.
One could use element.getBoundingClientRect and similar APIs to measure what size certain elements are rendered at and compare that with their default size for instance.
The resulting zoom level can then be used as a signal for fingerprinting.
But nothing is stopping the US customs service (or any other service) to store the unencrypted data for later reference right?
I don’t find it farfetched that some big players would have a database that holds basically a huge lookup table that goes from encrypted data to the unencrypted data.
This wouldn’t work on your first visits, but return visitors could have their rfid read like that.
Or do the rfid chips hold some kind of randomness in them so they can do a type of handshake (that is unique every time) where that machine readable password is needed?
Oh man, there was a post of a (new?/in preview?) productivity/project planning app on HN recently that I've been looking for in a while since I lost the link.
Hoping that shows up here again. I don't remember the name but the website left an impact. It looked really highly polished (a la Stripe).
Some of the features I remember:
- email integration
- tags and folder for organising projects
- richt text editing
That would be more effective! But that's not something Apple is trying to solve here (or could ever solve).
They are trying to prevent CSAM images from being stored and distributed using Apple products. If that goal is easily circumvented, the whole motivation for this (anti-)feature becomes invalid.
I a way, this architecture could potentially even make Apple products more attractive for CSAM distributors, since they now have a known way to fly under the radar (something that is arguably harder/riskier on other image sharing platforms, where the matching happens server-side).
One reasonable strategy Apple could have against that is through constantly finetuning the NeuralHash algorithm to hopefully catch more and more offenders. If that works reasonably well, it might deter criminals from their platform because an image that flies under the radar now might not fly under the radar in the future.
NB. I'm not trying to say Apple is doing the right thing here, especially since the above arguments put the efficacy of this architecture under scrutiny.
A lot has been said about using this as an attack vector by possibly poisoning a victims iPhone with an image that matches a CSAM hash.
But could this not also be used to circumvent the CSAM scanning by converting images that are in the CSAM database to visually similar images that won't match the hash anymore? That would effectively defeat the CSAM scanning Apple and others are trying to put into place completely and render the system moot.
One could argue that these spoofed images could also be added to the CSAM database, but what if you spoof them to have hashes of extremely common images (like common memes)? Adding memes to the database would render the whole scheme unmanageable, no?
Or am I missing something here?
So we'd end up with a system that: 1. Can't be reliably used to track actual criminal offenders (they'd just be able to hide) without rendering the whole database useless. 2. Can be used to attack anyone by making it look like they have criminal content on their iPhones.
This is pretty cool!
It reminds me of a similar project that’s been around called drawille [0] which is pretty nifty.
Yep! I build this font in FontForge. Such a simple pice of software.
Hi everyone, quite unexpected to see this on the frontpage of Hacker News!
I made this so many years ago but I'm not using it myself anymore and I haven't been maintaining it.
I was (and am) also very inexperienced making fonts so the result was "good enough for my own limited use case" but too broken for general use, so it's good to see other people taking it and running with it, fixing my oversights and improving things.
Questions or suggestions are more than welcome.
This concept is really neat!
I do have one question: how would something like this work when your webpages are being cached or when you're behind a CDN? As far as I can see none of this can work unless all requests hit your web server.
Does anyone know of any solutions that work similarly, but would allow for CDN's and caching? I'm aware that these will probably need JS, but I'm fine with that.
It is to my understanding that Apple and its lawyers aren't claiming that the code they create is "speech".
They are claiming that forcing Apple to digitally sign the codebase (which would be necessary to make it installable on the iPhone) would be a violation of freedom of speech.
I think this is a much more reasonable claim (but I'm not a law professor, so don't look at me).
You could do this (although it is likely to be impractical): avoid writing java code altogether. Use a language with better abstraction features like Scala or Clojure. Those two compile to JVM bytecode so you could still use them in your java project.
great read!
http://alternativeto.net/ kind off does this. Although it is not for programming only so I don't know if this is what you're looking for.