I've also been like this. But if as the article suggests trivial options like HTML entities or elements with display:none will keep my email out of >90% of harvesters I'm reconsidering as they seem to have no downside other than an extra couple of bytes on the wire.
No browsers support streaming parsing of XHTML so you are slowing down pageloads. Especially for longer pages.
Also the ecosystem is really not there for XHTML, it never really took off. In practice it is close enough to HTML that it probably mostly works, but you are going to have problems.
The advantage is also very small, your emitter is simpler (you don't have to special case void elements and whatnot) and if you need to consume your own pages the parser is simpler. But that isn't worth much for most people.
It does make me sad, because parsing and even emitting HTML is a nightmare. But it won, so at the end of the day I find it easier to just accept that.
There's an old SF short where one of the people who won't gets forced to. Battery of psychological tests followed by "you're one of the rulers now, and you're going to hate every minute of it, but we enslave you so the rest of us have a peaceful, prosperous planet."
Certificate pinning can be useful, especially in particularly sensitive areas. But I wouldn't expect it as a standard security practice. If anything I appreciate that it isn't done so that reverse engineers can thoroughly study the traffic on their own devices. I agree that it was odd that the article mentioned it more than a quick note, let along made a big deal out of it.
Random idea: If you have a known sentinel value for empty could you avoid the reader needing to read the writer's index? Just try to read, if it is empty the queue is empty, otherwise take the item and put an empty value there. Similarly for writing you can check the value, if it isn't empty the queue is full.
It seems that in this case as you get contention the faster end will slow down (as it is consuming what the other end just read) and this will naturally create a small buffer and run at good speeds.
The hard part is probably that sentinel and ensuring that it can be set/cleared atomically. On Rust you can do `Option<T>` to get a sentinel for any type (and it very often doesn't take any space) but I don't think there is an API to atomically set/clear that flag. (Technically I think this is always possible because the sentinel that Option picks will always be small even if the T is very large, but I don't think there is an API for this.)
Yeah, or you could put a generation number in each slot adjacent to T and a read will only be valid if the slot's generation number == the last one observed + 1, for example. But ultimately the reader and writer still need to coordinate here, so we're just shifting the coordination cache line from the writer's index to the slot.
I think the key difference is that they only need to coordinate when the reader and writer are close together. If that slows one end down they naturally spread apart. So you don't lose throughput, only a little latency in the contested case.
That's a good point. They are very similar. I guess the sentinel design in theory doesn't need to synchronize at all as long as there is a decent buffer between them. But the cached design synchronizes less commonly the more space there is which sounds like it would be very similar in practice. The sentinel design might also have a few thrashing issues when the reader and writer are on the same page which would probably be a bit less of an issue with the cached index design.
Programming in assembly isn't really "hard" it mostly takes lots of discipline. Consistency and patterns are key. The language also provides very little implicit documentation, so always document which arguments are passed how and where, what registers are caller and callee saved. Of course it is also very tedious.
Now writing very optimized assembly is very hard. Because you need to break your consistency and conventions to squeeze out all the possible performance. The larger "kernel" you optimize the more pattern breaking code you need to keep in your head at a time.
This makes sense and it's really that last step. It's one thing to do pattern matching or bit flipping routines. It's a whole different ballgame to build a game engine. Maybe if I knew gamedev better I wouldn't be as intimidated by it, but it really does seem like a herculean task.
I think it'd be cool to do assembler on a Pi Pico or something, that seems like it would be a fun exercise.
But it is about code syntax. Languages like Haskell make it part of the language by only supporting single-argument functions. So currying is the default behaviour for programmers.
I think you are focusing on the theoretical aspect of partial application and missing the actual argument of the article which having it be the default, implicit way of defining and calling functions isn't a good programming interface.
It's still not very useful to hide the length. If you don't know the length and just start guessing with passwords of length 0 it only adds about 1/N extra guesses where N is the alphabet size compared to guessing strictly the right length. So it is a very small savings to know the password length.
It might matter a bit more for dictionary-based attacks (you don't have to bother hashing dictionary permutations that don't match the expected length) but I still suspect it doesn't save you much.
For opportunistic attacks, this could help you identify those with short passwords and only attack them. This is a factor of N speedup where N is the pool of people you are interested in attacking.
I think the more important aspect is that people will have 24h to slow down, think, and realize that they are being scammed. Urgency and pressure is one of the top tactics used by scammers.
Scammers will definitely call back the next day to continue. But it is quite possible that by then the victim has realized, or talked to someone who helped them realize that they are being scammed.
There's been some reporting recently where I live about a case of some woman being scammed.
She went to a bank to transfer the scammer money. They told her no. She came back the next day. The police got involved and explained everything to her. Then she came back the next day. After that, she apparently found another location which let her transfer the money.
There's basically zero chance a 24 hour (or any amount of a) cool off period will help these people.
It's not one example. The scammers purposefully target people like these. That's their business.
Like, I'm sure there's a small amount of people who normally wouldn't get scammed but fall for it in a panic. But, is that really such a big concern for Google that they absolutely must continue stripping user freedoms from us? Is the current 30s popup which needs 3 confirmations not enough? Will the new one really work?
> helping some people is great even if it doesn't help everyone
It's kind of funny, but I very much agree with this. It's just in this case, it's hurting everyone (in ways most don't even realize) so that you can help a few people.
It's like putting everyone in prison, because some people might commit a crime and this would save some victims. A bit of an overreaction, no?
Regardless one of the conditions surely is giving them permissions to sell this to starlink as and everyone else. So whether the information is the same is probably irrelevant, how they are using it is.
Probably, because you are now associating your internet browsing with your personal information. (I don't know if they have the sophistication to actually do this, but it is very possible.)
reply