Just finished a large write up on a security flaw I found and disclosed in an exam spyware vendor's "zero knowledge encryption" - derived keys that were generated from incrementing integers, discussion on obfuscation and more.

It was a hell of a time writing this up; not sure if linking my personal blog here would be bad practice, but here it is: https://proctor.ninja/wave-rake-pro...

It's been something else, but hopefully I can keep fighting against tech like this on school campuses.

Just reported a minor tracking bug I found on WebKit to the WebKit bugzilla, and I have a few thoughts:

1. Apple product security can be kind of vague sometimes - they generally don't comment on bugs as they're fixing them, from the looks of it, and I'm not sure why that is policy.

2. Tracking bugs *are* security bugs in WebKit, which is quite neat in a way. What amazes me is how Firefox has had a way to detect private browsing for years that they are still working on addressing (indexedDB doesn't work in private browsing), and chrome occasionally has a thing or two that works, with Safari, Apple consistently plays whack-a-mole with these bugs - news sites that attempt to detect private browsing generally have a more difficult time with Safari/WebKit than with other browsers.

I guess a part of that could be bragging rights - since tracking bugs (and private browsing detection bugs, I think) count as security bugs, people like yours truly are more incentivised to report them to Apple because then you get to say "I found a security bug", and internal prioritisation is also higher for them.

This image. I almost feel bad for poor old Satya.

0. *gets on podium* All people being able to work together without yelling at somebody. For just a day if that's too hard.
*hops off*

1. A job in computer science without having to study all of physics and chem till 12th grade, It's a requirement here that you need to study all three sciences if you want to pursue just one, and I wish I could escape from it, it's stressful.

2. Not Dev related, but hugs.

Hello, devRant.

In high school, 11th grade right now. Looking to apply for a webdev internship. Not really for the pay, more for the experience and having something to put on a résumé I guess.

I have done "webdesign" before, but that's only a static blog (for the curious, Jekyll, https://oxylibrium.me/ until July 30 when the domain expires)

They list... "Integrate front-end services with Bootstrap and jQuery" and similar, and they list skills required as "Website Designing".

Do I apply and see how it turns out? Any last words before your (hopefully friendly) neighbourhood python backend dev leaps to unknown waters?

(First post in a while; age++ happened a while ago but was really busy patching life up to post)

Thanks for your time,
Oxy :)

So... GDPR.
And the deadline.
And I have no idea what to do.

What does it mean for one-man indie projects? Data protection officers? Companies? Controllers? Processors? EU employees? Argh.

Look, please, EU. Not everyone can afford to hire an entire team for this, when their current team is literally one person.

Yes, the GDPR is probably a step in the right direction, but I think I'll just stop collecting the data altogether.

(All data I collect is just user settings stored in a database, nothing more.)

Can someone point me in the right direction?

!rant

Ever find something that's just faster than something else, but when you try to break it down and analyze it, you can't find out why?

PyPy.
I decided I'd test it with a typical discord bot-style workload (decoding a JSON theoretically from an API, checking if it contains stuff, format and then returning it). It was... 1.73x the speed of python.

(Though, granted, this code is more network dependent than anything else.)

Mean +- std dev: [kitsu-python] 62.4 us +- 2.7 us -> [kitsu-pypy] 36.1 us +- 9.2 us: 1.73x faster (-42%)

Me: Whoa, how?!
So, I proceed to write microbenches for every step. Except the JSON decoding, (1.7x faster was at least twice as slow (in one case, one hundred times slower) when tested individually.
The combination of them was faster. Huh.

By this point, I was all "sign me up!", but... asyncpg (the only sane PostgreSQL driver for python IMO, using prepared statements by default and such) has some of it's functionality written in C, for performance reasons. Not Cython, actual C that links to CPython. That means no PyPy support.

Okay then.

Porting over code to python3 from python2 be like:
(Cakechat, in this case)

Day 0 of n of python 3 compatibility work:
This should be _easy_, just use six and do magic!

Day 1 of n:
Oh, true division is default instead of integer division, so I need to replace `/` with `//` in a few places.

Day 2 of n:
Oh, map in python2 behaves differently than map in python3, one returns a list, other an iterator. Time to replace it with `list(map())` then.

Day 3 of n:
Argh, lambdas don't evaluate automatically, time to fix that too.

Day 4 of n:
Why did I bother trying to port this code in the first place? It's been so long and I DON'T EVEN KNOW WHAT IS BROKEN BECAUSE THE STUFF RUNS WHEN I BREAKPOINT AND STEP THROUGH BUT NOT WHEN I RUN IT DIRECTLY?!

Day ??? of n:
[predicted]
*gives up*
I've had enough.

My biggest personal challenge as a dev? The one friend that keeps yelling at me to learn vim when I'm doing just fine with VSCode.

Cakechat.
Not going to deny Lukalabs' credit where it's due, it's an actually good NN chatbot. Works pretty decently even on my poor old Haswell i3.

But... the things you do, Lukalabs.
First off... PYTHON 2?!?! IN ${CURRENT_YEAR}?

Jokes aside, there's a lot of things that could've been done better, or in a more compatible way, or both. Such as:

tokenized_dialog_context = imap(get_tokens_sequence, dialog_context)
tokenized_dialog_contexts = [tokenized_dialog_context]

1. imap doesn't exist in python3, but whatever, doesn't make a big difference.
2. why wrap it in another array?
3. *two* variables, and the first one just used to create the second?

I will admit, Cakechat works well, but it's one of those things where if you try to run it on anything other than the recommended settings, it's not very fun.

Right now, I'm porting it to python3 with six, and making small refactor adjustments in random places to clean up the code.

(Official live demo at https://cakechat.replika.ai/, if you want to try it out.)

It'd be pretty nice if I could learn how microservices work. Probably read a book or two on them in summer break. One can hope, right?

Also, probably learn how to use vim, finally. :^)

!dev

I've got so much overdue winter break work that I have to skip celebrating New Year to do math and finish my biology sketches.
Argh.
Hope you guys have a better 2018. Happy New Year, I guess?

So, I sign up for devrant and read all about the school devops fuckery everyone seems to have.

The only problem is, computers at my school's lab has no internet access and only a pirated copy of.... Visual Studio *6*. Hell, that's 5 years older than I am.

No python, no git, nothing. The best part, you ask? They use VS6 just for teaching 9th graders Visual Basic, and for C and C++, they use TurboC++ in DOSBox. 25-year old software. They teach us Pre-ANSI C++.

No fucking wonder people from here re-learn everything on the job. I jumped the gun and started messing with basic C++ in 7th grade, and then had to go back and remember that 25 years ago, they used <iostream.h> instead of just <iostream>.

Everyone just saves their code in the TC/BIN folder in DOS too, making it more of a chaotic mess than anything ever imaginable.

Bringing your own device? Too bad that's against the school rules.

The fact that they went out of their damn way to make me use TurboC in DOSBox on Windows 7 instead of giving me a sane Linux install with an editor and GCC is just... ugh.

My classmates all think I work magic, while all I really do is simple logic. Schools here in India are almost universally terrible.

Well, it's a good thing I started learning it on my own, because if I thought programming was in any way similar to how they try to teach it to us, I would've given up a long time ago.