Can someone explain how they can detect if you are in incognito mode? I didn't understand the article's explanation. From what I understand, it checks if you can store cookies. But doesn't incognito store cookies until you close the window? When I just opened YouTube in incognito, I get generic recommendations. But after watching several videos, I get recommendations based on what I watched, which I presume, are stored as cookies.
Some web APIs are disabled in incognito mode, yet are almost universally present on modern browsers. By attempting to use these APIs, a web page can detect if you are in Incognito. If the API is blocked, they can reasonably assume you are.
Sounds like the reasonable thing to do would be to shim those APIs to make them look like they're functional (in fact, it sounds like Chrome Canary is doing exactly that with the filesystem API).
I wonder how far you'd need to shim before you can stamp out detection. I.e. does it really matter if you shim the Filesystem API? A program can just write some data and try to read it back. If the shims just no-oped those API calls, it'd be pretty easy to detect, no?
Chrome Canary's workaround is to store blobs in memory, which one can argue is akin to actually implementing the API and not disabling it.
I mean, if the point of the API is to access the filesystem, and you instead redirect those calls to a different in-memory scratch filesystem local to that incognito session and/or tab, then I'd call that shimming to at least some extent; it'd just be an especially thick shim.
It's a shame that thinkpads are becoming less and less modular and functional. Some of my favorite functionalities are:
* Red nub. I use it exclusively, the track pad is disabled and serves me no purpose
* Hot swappable battery. I have a spare battery and it effectively doubles how long I can use my laptop without without charging.
* 7 layered keyboard. It's great to not have to use so many keyboard shortcuts, but rather have a dedicated button.
* Hardware switch for WiFi. If only it had one for the camera, microphone and sound.
* Durable and modular. I installed a hard drive using nothing more than a screwdriver and a 5 minute YouTube tutorial.
* Linux support (or at least not hindrance)
Some things that I do not like about the leaked Thinkpads.
* Envelope widthed laptops. I'm planning on using the Ethernet port before I plan on mailing my laptop in an envelope.
* 1 gram lighter than earlier models. I'm not so strong, but I have no problem sticking my laptop in my backpack and walking around with it. If I really wanted to I could remove 1 gram from my backpack without having to make the compromises that Lenovo is.
* Soldered memory. WTF
Does anyone have a recommendation for a laptop that is still being built that have most of the features that I am looking for. Assuming that it is good quality, money is not so much of an issue.
I still use X220s for all my portable computing needs as it was the last model before Lenovo ruined the keyboards. As they invariably die off or just get too slow (or architecturally different - can hardly profile code on them nowadays) I have no idea what to do. Every single modern laptop, irrespective of price, looks like a huge downgrade in every aspect I care about other than the CPU.
Are there any options out there at all for laptops that have at least usable keyboards, hot swappable batteries, proper Ethernet ports, basic maintainability and solid build quality instead of the insane thinness fetish?
Oh wow. I have an X62 and T70, but skipped the X210 because of the display. If I knew you could get it with a 3:2 display I'd have been really tempted to get one. Do you do the mod yourself or purchase it pre-installed?
I didn't know that. I figured the webcam was removed since the 2nd batch X210s had them.[1] It looks like the 2nd batch chassis is the X201, not the X201s.
If you want to see (most) of the many "TYPE xxxx-xxx" variants of a given older ThinkPad model number, and don't mind doing some detective work, you can Google for "PSREF" PDF files.
The PSREFs were/are catalogs of the variants available for sale and their specs, issued periodically. There were also PSREFs for withdrawn variants, covering year ranges.
(I got well-acquainted with these when stockpiling X200 units for Coreboot, a large-screen workstation model I like, and an older model that has better build-quality keyboards that can be swapped into certain newer models.)
Various Lenovo Web site lookups of specs have come and gone, and TYPEs seem to disappear from them sometimes, but the PSREF PDFs are forever.
Sorry I don't seem to have PSREFs covering X210S, but I suspect they're out there.
> It seems that Lenovo prioritized sleeker designs over flexibility with the newest T ThinkPads, as the manufacturer is making some rather drastic changes to the internals and ports of the new models. Features like the SD card slot (replaced with MicroSD) or full-size RJ45-Ethernet on the T490s are getting the axe, the same is true for the 2.5 inch storage bay on the T490 and T590. Also, Lenovo is relying more on soldered RAM than before. The ThinkPad T490s has a maximum of 32 GB of soldered RAM, while the T490 and the T590 both have up to 16 GB of soldered RAM plus a single DDR4 RAM slot (up to 48 GB RAM in total). All of those changes will likely result in some fierce discussions among the ThinkPad fans.
I think the silver T490 is a little telling. Anecdotally, people are abandoning MacBooks for Thinkpads due to a drop in the quality and utility of the former, and Lenovo is trying to grab that share by... making Thinkpads more like Macbooks?
Sadly, those of us who value features only found on older Thinkpads are probably in the minority. My X220 is slowly aging out of usefulness and I'm not sure what will replace it.
What's interesting is that even aside from build quality, that little red eraser wad basically pushes Thinkpads outside the normal comparison shopping market.
If you don't like touchpads, your choices are basically "buy a Thinkpad direct from Lenovo" or "try to find the weird corners of the world where they actually mention, let alone sell HP Elitebooks and certain Dell Latitudes, and then find they're mind-blowingly expensive because they basically only compete with the high-end ThinkPad series."
I ordered a new laptop recently, and the ThinkPad option (an E585 plus adding my own RAM and SSD upgrades) clocked in about 40% cheaper than buying the comparable Elitebook. Even if the bottom were epoxied on, and you had to pay heir absurd prices for RAM and storage, I'd probably have ended up there.
Check out the P52. It's still got the Ethernet port and upgradeable memory. I've got a p51 and I just dropped 64 GB of RAM into it. I'll probably replace the SATA SSD with an NVMe drive or two as they drop in price in the next couple of years.
The T-line of laptops has suffered from the same kind of design mistakes for several years now, but as long as Lenovo keeps making the P-series with replaceable parts I'll keep buying them.
Go for the T440p. It should fit most of your needs and you can also replace the trackpad with the T450 version's in case you want clickable buttons. Unfortunately you dont get the 7 rows keyboard.
I'd really like a USB-C-Thunderbolt-based UltraBay. That would let you do literally everything UltraBays have ever been used for and more. Can you imagine sliding the 10GbE into your laptop...
So then what was the point of the heavily publicized hq2 search? If, in the end, Amazon chose a deal that was available to everyone, then what did they negotiate?
It's quite subjective, but my view is Matrix is what XMPP would like if it was written today.
The main advantages are it is using JSON instead of XML, and HTTP instead of custom protocols so it can work directly from browsers and with lightweight mobile clients. It also has a lot built into the core protocol, where as to get XMPP to do anything useful you will need to use a lot of extensions (and ensure the server and all clients support them).
The only con is it's still a relatively young project. I'm not sure I would want to rely on it as my main form of communication in a company just yet, but for personal usage it is fine.
Also, what custom protocol are you talking about? XMPP works on top of TCP/TLS (or Websocket). Those are the IETF standards. In fact XMPP doesn't require an additional layer of HTTP at all.
> with lightweight mobile clients
Where are they? Anything even remotely comparable battery-wise with Conversations (an XMPP client)?
Not to mention that Matrix has a terrible server implementation which requires several GB of RAM just to join matrix.org room.
> It also has a lot built into the core protocol, where as to get XMPP to do anything useful you will need to use a lot of extensions (and ensure the server and all clients support them).
I fail to see how having a monolith core versus splitted specs has to do anything with code written to support that. Of course, initially every implementation will strive to implement full core (that was in XMPP in 2000s), but when the core evolves you have absolutely no guarantee that every developer will implement all new parts of the core. How is that addressed in Matrix?
Well that's quite easy, since hosting a server is a resource hog, most people are still on matrix.org, which gives it a special status in the ecosystem (even more special than jabber.org has been in the early 2000s fox XMPP). This allows them to "move fast and break stuff" on short notice (a few months), to bring the protocol forward and force people to upgrade. In the federated XMPP ecosystem, they essentially have to come to a community consensus between developers, servers operators and all other relevant actors to write a manifesto or a new spec that says "stop using $thing at $date".
In my opinion matrix, while being open-source, federated and easy to write clients for, is still a half-locked platform because essentially the matrix.org server is "too big to fail", and the matrix team is the only one who can e.g. offer consultancy over the protocol because nobody else can have a long-term view of its future evolutions (of course the matrix people are nice, and you can discuss with them, but that is still not a standards body).
> is still a half-locked platform... but that is still not a standards body
Exactly. That's why I always stress the importance of the IETF. The whole point of the IETF is that you cooperate with people, deal with opposite opinions, accept criticism, come to agreement, develop a compromise and produce a high quality absurdly documented standard. In Matrix bubble (and any others, see cryptocurrency or p2p community for example) they are the only one who makes the decision. They don't care on other opinions. If you disagree with them you're asked to stop "fighting", "focus on interaction", "understand their goals" and other meaningless stuff like "let the best standard wins" (when in reality the whole point of the standard is to cooperate). Formally speaking they try to substitute a "standard document" with an "open document" and people kinda swallow this because they don't see the difference.
> In Matrix bubble (and any others, see cryptocurrency or p2p community for example) they are the only one who makes the decision. They don't care on other opinions.
> You can see our governance model at https://github.com/matrix-org/matrix-doc/blob/matthew/msc177.... and see that we do everything we can to ensure that the wider community can contribute to the spec and steer it in the right direction... And fwiw, we'd be perfectly happy to contribute the spec to IETF or W3C or whoever once it's relatively stable, just like XMPP did.
I'm not a lawyer to read such documents. Just "contribute" your core to the IETF, prove me wrong.
I might be mistaken, but from what I read the main addition is that all peers replicate the full state.
If you have a dominant xmpp server (like gmail was) that removes xmpp support, its users have the start using other clients to connect to it or start a new social structure from scratch. In essence this makes the xmpp server a dominant player with leverage.
If gmail had used matrix when it pulled the plug all interactions (who knows who, how to route traffic, chat history) would have been replicated at the peers so it would just have removed google’s servers from the equation. The people who had been using it would continue uninterrupted.
In both cases, if users have an account on gmail and are using it, and gmail pulls the plug, then they can't use it anymore and can't migrate. The history is still there in the case of matrix, but they can't reuse the same account.
However if another user is homed on another server, they would still keep the knowledge and history on their side: gmail did pull the plug on xmpp, yet people are still using it. Their server still know who their contacts are, what room they're usually in, etc...
Matrix does have the advantage that the chat history is fully replicated on all homeservers so it makes history retrieval much saner, but that's it. Matrix doesn't route traffic (messages go from sender's homeserver to recipients' homeservers, that's it) and doesn't share client's information with the whole world.
> The people who had been using it would continue uninterrupted.
I'm not sure about that. If the main matrix server disappeared today that'd be problematic. Yes, you'd have history locally but the same can be said for any native client that stores history locally.
As far as I know there is no way to migrate matrix history now. Is there? (genuinely curious)
> I'm not sure about that. If the main matrix server disappeared today that'd be problematic
This ^^
Currently a large amount of users (I'm told around a half, but I'm not sure) have matrix.org as their home server. So Matrix is effectively building a power-law network with all its drawbacks: when the "power node" of the network goes down the whole network falls apart.
To be fair, this is somewhat inevitable in the initial stages, before a reasonable spec is released. Many people, like me, are just "sitting on the fence" and test-driving Matrix via their matrix.org server, until there are reasonable assurances that deploying our own Matrix server will come without too much hassle.
After Synapse 1.0 is released (sometimes next month, IIRC), I'm definitely deploying my own homeserver, and federating it with the rest of the world.
FWIW, I've been running Synapse since 0.20 or so (for at least 2 years now), and there has never been a breaking change in the protocol as far as I'm aware. I had to read release notes at some points to get the upgrade to work, but it was mostly Python-library-related stuff IIRC.
Well they are making one big instance nothing else. Also unfortunately it means that you can't possibly federate with matrix.org. I've been running small otherwise perfectly functioning instance for few years for my circle/work as slack alternative on small vps. One time i did the amazing mistake of turning on federation with matrix.org. It immediately killed my servers performance especially when i joined some popular channel. The channels probably have more messages than my whole server combined. And it works the other way too - matrix.org is like sponge sucking other instances.
I guess this is the real problem for me - i would love to federate but i can't possibly police or enforce what servers/channels are small enough that my users can join them.
This isn’t anything to do with the size of the matrix.org server; just that synapse needs to be more resource efficient and we need to limit the sizes of rooms small servers try to join. we are doing both.
I can't see any advantage in using JSON and HTTP for a protocol. JSON shines for ad-hoc, untyped, structured message payloads rather than the strongly-typed semistructured text payloads possible with XML/SGML, and HTTP wasn't designed for federated protocols. It seems more like a fashion thing to me.
I kind of agree with you, but I'll add that XMPP usage of XML is weird enough that it makes it hard it use a normal XML parser / producer. Honestly I really wanted to like XMPP. I read all the specs at the time, even started to write some code, but all I can say is that it really sucks. I haven't looked at matrix yet, I hope it's better
Indeed! I was in the same boat - also started writing a client, but wasted too much time on the stupid XML stream idea.
Basically, chatting is message oriented, but the XMPP inventors thought it would be neat to start the connection with a tag like <beginconversation> which would then be dangling for the whole connection, preventing the use of a simple DOM XML parser (remember this is many years ago) for each message.
Can it handle plaintext XML suddenly becoming TLS encrypted? Because that's also what happens on any XMPP connection. If it can, then great but I guess it's more an exception than the rule
You don't have to implement all the modules :p
There is some basic ones that you need (see XEP-0412: XMPP Compliance Suites 2019 - https://xmpp.org/extensions/xep-0412.html) and you have already an up to date client and server. The rest if for specific use cases.
I dislike JSON, but it's a step in the right direction from XML. XML is an inelegant, verbose, over-specified mess, a relic of 90s thinking. JSON is definitely an improvement.
HTPP's fine, I guess. It's certainly available everywhere, and saves one from writing a bunch of tiresome parsing code. But that's really an indictment of the current state of our technology. Popular languages should make it easy to read structured data out of a socket (with some sort of max length to prevent DDoSes) & write structured data to a socket. Since they don't, HTTP is an okay compromise. It's a bit heavyweight, but it gets the job done.
Well, technically both are valid approaches which get messages from one user to another in a federated way. Besides that, XMPP is an IETF standard which has proven it can adapt to changing requirements. Matrix, on the other hand, is a young project with more momentum and more consistent software landscape.
That said, I have quite a biased view on the topic, as I kinda blame the Matrix devs for splitting the federated communication community. XMPP is quite capable of delivering what everyone expects it to do. But lately, developers seem to be more interested in the new Matrix protocol (just because it is new). At the same time, many XMPP clients do not implement all of the latest features the standard has to offer and I wonder what the world would look like if the Matrix devs would have spent their energy on improving existing XMPP clients instead of inventing another protocol.
we really don’t, fwiw. we have zero money assigned to marketing and nobody working on it, unless you count me chatting on HN and twitter, or our designer or the guy who updates the matrix.org/blog?
It is possible to consider them different categories of things. XMPP solves the IM problem but conferences with lots of users are a bit awkward if you use a XMPP MUC server. Conferencing is to some extent a bag on the side of XMPP. You would probably be better off just using IRC.
Matrix is primarily about dealing with the issues of conferences with lots of users... I see it as more of an improved IRC than a replacement for XMPP.
I guess you'll have to be in such a situation to find out. I have an ancestor who moved to America as an Orthodox Jew in the early 1900s. He would find work on Monday, and work until Friday. If the employer wouldn't let him take Saturday off, then he would quit and look for a new job. This cycle eventually stopped when he got hired by a seventh day Adventist.
The problem is that the taxes are zero for specific businesses. If I want to open a business in New York, I'd get nowhere near as much of a tax break that Amazon got. I agree that business taxes should be low, but they should also be consistent.
Snopes claims that a meme (showing a picture of people, many of whom have red x over their faces, writing that everyone with a red x has been voted out of office) is true even though they admit
> Although memes are frequently grossly inaccurate, this one got the general idea and numbers correct (even if the persons actually pictured in the accompanying photograph are difficult or impossible to identify).
Some of the people with an x were not elected people and some did not get voted out. This meme is clearly false, yet Snopes calls it true.
> Is the information on the snopes page false or incorrect? No, it isn't.
It is both false and incorrect. Saying that "every one with an x has since been voted out of congress" When not every one with an x has since been voted out of congress is false. I mean even the article quotes a tweet listing 10 people who were incorrectly marked. You should see what Snopes does every time a right wing person says something not 100% correct.
> "snopes occasionally makes editorial decisions I disagree with" is not the same as "snopes is fake and unreliable".
Again, the Snopes article is blatantly false.
> Sorry, I must have missed it the first time, tell me again why you continue to rely on an overtly racist blog to be your arbiter of "ethics"?
Sorry, I missed why you think that I continue to rely on a racist blog to be my arbiter of ethics.
> Christy, who is a frequent critic of EPA regulations, said he will use his position on the 45-member board to question the results of climate models.
So do what scientists do? Question models and improve them.
