The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,406 other followers

Archive for the ‘Algorithms’ Category

Automated “take-down” algorithm simulation: thread by @AlecMuffett: “Regards Article13, I wrote up a little command-line false-positive emulator; it tests 10 million events with a test (for copyrighted material […]” #Article13

Posted by jpluimers on 2018/07/08

Via [WayBack] Artikel 13 (Uploadfilter) vs. Math – Math wins – Kristian Köhntopp – Google+:

Simulation of the proposed law effects are easy: [WayBackThread by @AlecMuffett: “Regards Article13, I wrote up a little command-line false-positive emulator; it tests 10 million events with a test (for copyrighted material) […]” #Article13

What it shows that an automated test for content-originality only succeeds when there are a truckload of copyrighted-material uploads than original-content uploads:

about 1 in 67 postings have to be “bad” in order to break even

So if you have less than 1% false uploads, even with a 98.5% accuracy (which is very very good for a take-down algorithm!), you will piss off far more good items wrongly marked as false positive, than bad items correctly marked bad.

When the accuracy gets less, you piss-off far more original-content uploads, but also catch less copyrighted-material uploads..

This is called the a far less “sexy” term False positive paradox – Wikipedia, which is a specialisation of the far mor dull sounding Base rate fallacy – Wikipedia

Source code: [WayBack] random-code-samples/ at master · alecmuffett/random-code-samples · GitHub

Original thread:

[WayBack] Alec Muffett on Twitterさん: “Regards #Article13, I wrote up a little command-line false-positive emulator; it tests 10 million events with a test (for copyrighted material, abusive material, whatever) that is 99.5% accurate, with a rate of 1-in-10,000 items actually being bad.…”


[WayBack] next_ghost on Twitter: “And for the nerds who want to learn more, this is called a “False positive paradox”.… “



Posted in Algorithms, Development, Software Development | 1 Comment »

Client-Side Password Hashing – DelphiTools

Posted by jpluimers on 2018/05/03

Interesting thought on client-side password hashing: [Archive.isClient-Side Password Hashing – DelphiTools.

I’ve ambivalent feelings on it, especially since it will expose salt and other settings to the client.

On the other hand it tremendously helps when there are transparent proxies in between. Read the article for full details; here is just one quote below.

Maybe dual hashing would be in place: once at the client to prevent plain-text to go over MITM channels, and a second hash server side with different settings like salt to prevent brute force attacks.

I need to give this more thought.

The quote:

If you are using a regular Windows and a regular browser, access to HTTPS will go through the regular certificate chain, using regular certificate authority. You also benefit from extra security layers like Public Key Pinning.

But when a custom Root CA is installed, all that goes through the window: the custom Root CA allows the corporate proxies to issue “valid” certificates for any website (even and the rest), and the public key pinning features are disabled:

How does key pinning interact with local proxies and filters?

Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. 

A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.

All the major browsers have a similar behavior… because it is required to allow transparent proxies. And transparent proxies are the means through which the legal logging requirements are fulfilled.

So besides introducing a major MITM opportunity, this also means that there are legally-required corporate logs somewhere of all that went through HTTPS… including plain text passwords, if you did not hash them on the client-side.

These logs will have varying degrees of security when in the corporate domain… and next to none if they are ever requested by the legal system for an investigation.



Posted in Algorithms, Design Patterns, Development, Hashing, Power User, Security, Software Development | Leave a Comment »

Pathfinder, a fast GPU-based font rasterizer in Rust – pcwalton

Posted by jpluimers on 2018/04/25

When you thought font rendering was a done thing, read [WayBackPathfinder, a fast GPU-based font rasterizer in Rust – pcwalton

via: [WayBack] Text display is so critical, great speed is a MUST – David Berneda – Google+



Posted in Algorithms, Development, Software Development | Leave a Comment »

Interactive additive and subtractive colour mixing

Posted by jpluimers on 2018/03/30

Cool interactive colour mixing:

The site has way more interesting pages around colour spaces, colour press techniques (like colour separation, rasterising, etc). Worth visiting!



Posted in Algorithms, Development, Power User, Software Development | Leave a Comment »

Scalable spinlocks 1: array-based | The Infinite Loop

Posted by jpluimers on 2017/12/12

Cool: [WayBackScalable spinlocks 1: array-based | The Infinite Loop

Last time we saw that spinlock implementations which only use a single synchronization variable (Test-And-Set Lock, Ticket Lock) don’t scale with growing numbers of threads. Today, I want to talk about two spinlock variants that scale. Namely the Graunke and Thakkar Lock1 (1989) and the Anderson Lock2 (1990). Their underlying key idea is to use one synchronization variable per thread instead of one for all threads, to reduce the amount of cache line invalidations when acquiring/releasing the lock. Both spinlock variants store the synchronization variables in an array. This means that there’s an upper bound on the maximum number of thread’s that can compete for the lock concurrently, which must be known a priori. In upcoming blog posts I’m going to show spinlock variants (the MCS Lock and the CLH Lock) that improve upon array-based spinlocks by removing this hard upper limit.


via: [WayBack] Scalable spinlocks 1: array-based | The Infinite Loop – David Berneda – Google+

Posted in Algorithms, Development, Software Development | Leave a Comment »

%d bloggers like this: