The specs are public from 3gpp2 (https://www.3gpp2.org/). I didn't have to reverse engineer but in the initial RF bringup, even with the specs, it took me a while and had to pick up some old CDMA test equipment to capture actual BTS signals to help me understand it better.
Yeah maybe at some point -- I'd need to learn about all the formal stuff though first, it's new to me. For now it's cocotb test benches and also I run it through the Klaus test (https://github.com/Klaus2m5/6502_65C02_functional_tests) which is pretty comprehensive. There are definitely edge cases though that I found when actually running it on physical hardware that my tests didn't find (i.e ran into some IRQ servicing issues), so not easy to be 100%.
InAuth | Santa Monica, CA or Remote | Site Reliability Engineer
InAuth is looking for SREs to help operate and scale our real-time mobile and browser security platform. We use a variety of technologies and are looking for people with experience in:
The role has a lot of opportunity for growth as the SRE team is new. We have an office in Santa Monica, CA but we also are willing to have someone remote (if they are the right fit).
If you are interested or have questions email Chris Moos at: moos [at] inauth.com
One of the main differences is this one uses lookup tables for faster decoding of Huffman compressed data as opposed to using a tree (which is what the stdlib one uses). It also offers some additional encoding options for users that want more control of header field indexing.
It would be possible but not that straightforward, you can change how log4j loads/finds properties file, for example, so it would be hard to enforce that.
Its pretty easy to unpack an APK, change log4j stuff to DEBUG, repack, and run vs. unpacking APK, disassemble class files, go through files, find how key is stored, routine for deobfuscation, etc,.
I've reverse engineered plenty of Android apps before and yeah, unpacking it and seeing .class files is pretty straightforward. More sophisticated than modifying a text file, but still pretty easy.
Extracting the private key though is not that easy if it is obfuscated well. The key isn't just stored as a static variable and used as-is. I think the overall thing I'm trying to explain is:
* There are different classes of attackers
* Everything can be broken, but we want to stop as much people as we can
* Layering security is a good thing
* Is it really necessary to have the library log the information, as opposed to letting applications decide?
My issue is with the application running somewhere like an Android app where an attacker could easily change logging and see the sensitive information, as opposed to having to do a more sophisticated attack to get to the decrypted data (through finding out the key, patching class files, etc,.)
It probably has something to do with NUMA. Java 7 has a NUMA supported allocator that makes it more likely for threads to access memory from their local node. I'd be interested to see the golang test running with multiple processes, with each one running on an individual NUMA node.
1) How much do the founders need you? This will be helpful in negotiations.
2) How will your role in the company effect its success?
3) How important is salary to you?
All the above will give you an idea of how much equity you can get (or are worth). Use the answers to these questions to help you negotiate.
If salary is really important to you then expect less equity. If you really believe in the company and are willing to work to make it successful then maybe you should go towards more equity and take less salary. This will pay off (much more) in the long run.
I would recommend that you let them make you an offer first. This will give you a baseline on what their expectations are. They might say.. 60K/year and 20,000 options. You need to ask them about the options:
1) What percentage of the company is the employee options pool? This might be 10 or 20%.
2) How many shares are in the option pool, or...what percentage of the option pool is 20,000 options. This will help you determine what actual percentage of the company you may be entitled to.
3) What is the vesting schedule?
Remember one thing when negotiating: You need to ask or you will not receive :).
An in-app browser isn't the only way to provide OAuth, on most platforms you can invoke a URL and the browser application will open on the phone.
For example, on iPhone you can invoke an HTTP(s) URL, your app will exit, mobile safari opens, and you can then login and know that what you are typing is as secure as the OS/app sandboxing is....take a look at how the Facebook iPhone SDK flow works, its actually quite nice and very easy for users.
In reality, if you want to know that you aren't giving your username/password to a malicious third party, as an end user, you have to deal with a little inconvenience...being redirected in your browser to an SSL page that you trust, for example.
I called today and escalated it. The woman I spoke with pretty much said that she has guidelines to follow, regardless of the law.
They just follow what the legal department for Maricopa tells them to do.
She told me that I should file a request for the district committee to review the case. This is probably what I will do, as I do believe the law is in line with our situation and will be in our favor.
Honestly, the first thing I did was add indexes. On device_id, user_id, and date_added.
I'm using Linode and I kept getting these I/O notifications...and the site would load extremely slow at times.
After looking at the log of my Rails app, I saw that some requests were taking > 20 seconds. I determined that this was some kind of blocking at the database.
I connected to MySQL and ran something simple...
select count(*) from location;
It took a long time...I turned profiling on and saw that it was taking a really long time in "table lock".
I assumed (which probably wasn't a good idea) that it was going through and counting all the rows.
I didn't really know what to make of this..because I didn't think that getting the count would take so long.
I embarked on reading about partitioning, which may have been a solution for a problem that didn't actually exist (based on the feedback here). I attempted to partition (on what I put in the article), and everything seemed much snappier after that. If the indexes should have solved the problem (given that they were correct), I don't know why the location queries were taking so long.
Anyway, I still have lots to learn on the database front, and maybe the fact that my VM had 7MB free of memory was causing weird things to happen, I'm not sure.
Thanks for all the feedback and I have definitely learned a lot in this thread.
kogir:
I'm using MyISAM (which, in retrospect, seems stupid), so I don't even have foreign key constraints (InnoDB only, I believe).