I know of coworkers who are single and really looking back to get back to the office because they are sick of being alone in their small apartments for days at a time.
I also know of coworkers who are married with family and can't wait to get back to the office because they need to take breaks from their spouses/kids from time to time.
When I was in the same situation, I was very much enjoying working from a pub which was 20 minutes walk away from the "office". It was quiet, nice food and much socializing towards the evening. What's not to like?
To think how much money the company was wasting on the office... I still cringe today.
> It was quiet, nice food and much socializing towards the evening. What's not to like?
To me the smell of alcohol would be awful? Or maybe I don't like noisy strangers? Or maybe I can't bring my comfortable chair and twin 30" monitors to a pub with me every day?
I think you've fallen pretty deep in the trap of thinking your experience and preference applies to everyone.
I'm merely showing that there is life and work without an office, and better one much of the time.
Yes I prefer twin monitors, two black cats, zero interruptions and some ambient music most of the time. When I get in the other mood, I go sit at the pub. Or I take a walk and meditate on a problem. Or I take a 50 mile ride on a motorbike. Or I fire up the local equivalent of the Uber and give some rides to the people just for the talks. Or whatever else comes to mind.
Those are the choices I would never have had I made a mistake and got another job at the office.
> Due to the use of static keys, an authenticated attacker can trick the server into deserializing maliciously crafted ViewState data.
Many years ago I was shocked that ASP.net will deserialize arbitrary (potentially unsafe) objects from the client and relies on signatures to ensure that parameters sent by the client were in fact round-tripped via HTTP POST from the same server.
I assume the idea behind __VIEWSTATE is that you don't have to save anything on the server side, which makes the whole architecture easier (no need for storage layer, sharing the secret between machines allows for load balancing), and you can support as many clients as possible, since you don't have to worry about the storage size.
__VIEWSTATE should be as secure as JSON Web Tokens, unless you manage to leak the secret (or as in this case, you use a shared one for all customers.)
I don't know why exactly did they choose to (de)serialize executable code, instead of using an XML or similar format, but similar choices were made (and later changed) with frameworks/libraries for other languages, so they are not the only one.
There have been vulnerabilities in java and rails caused by deserializing arbitrary classes with given constructor parameters.
An attacker just has to find one that (e.g.) accepts a url and a filepath in its constructor and saves the file to that location, and you've (usually) got code execution (by eg overwriting something that gets run frequently).
I could have some of the specifics wrong here, especially since it's been forever...
But the problem is there are some things that needed to be serialized for things like .NET remoting or firing stuff across appdomains. Things like Delegates.
Now, I -think- the intent, back in the day that ASP.NET was created, to use Code Access Security/Security Transparent Code (CAS/STC) to safely put a system like this together. But CAS/STC is pretty easy to do 'wrong' and a lot of people, rather than setting up the correct LinkDemands for individual items like Database, File IO, ETC on the specific endpoints, would just toss 'AllowPartiallyTrustedCallersAttribute' on the assembly and call it a day. This renders it CAS/STC almost worthless, to the point Microsoft half-killed this concept in Net 4.0 and in Core it's just about gone.
Handling user input is tricky, and so is (de) serialization (I seem to recall most big frameworks from ruby, via php and python through Java - all doing some form of unsafe marshaling from both xml and json).
For encrypted and signed data on the client, you get to add "crypto is hard" on top.
You get things like clear signed data - that makes it easier to de-couple verifying signatures from marshaling contained data - perhaps without checking the signature...
You get encrypted data that isn't using a proper authenticated encryption construct - and again open the door for manipulated data.
Even with proper encryption, you get key revocation wrong (left out), and there's maybe no expiry on chiper texts either - so you happily accept data encrypted and signed by a compromised or expired key.
And there's key management, like in this case, re-using a key that should be sigle client/single session.
Oh,and re-play attacks due to missing serial numbers/nonce on transactions/messages...
But yeah, sure. Like another comment mentions - in theory encrypted data managed by the client is sound.. Unfortunately in practice theory isn't always right.
Hell no. Seaside captures the state server side, stores it under an id and sends that id to the client. The client sends the id of the state snapshot back to the server.
AFAICT there's nothing inherently insecure about server-encrypted data on the client. You have to secure that encryption, but fundamentally it Should Be Fine(TM).
Now, deserializing arbitrary objects which might contain code?... that's crazy town, but it was a different time.
This is an area where 'fine' rapidly becomes problematic.
Remember that the dataset is often going to be small, and frequently will contain known or easily guessed strings. Uncompressed, often at predicable locations.
There are whole classes of cryptographic vulnerabilities which might result from either not compressing (compression should in theory would normalize entropy over the stream) or using a compression algorithm that results in a predictable dictionary, length, or other value in the same location (if junk padding isn't used properly).
Also, sending the state from client to server might open replay attacks and all sorts of other horrid situations.
Security depends on doing everything correctly all the time; this context IMO just feels open to too many plausible and unknown (potentially introduced in the future) vulnerabilities.
> Remember that the dataset is often going to be small, and frequently will contain known or easily guessed strings.
This is why modern crypto is designed to be resistant to prefix attacks, rainbow attacks, why CBC is considered a good idea, etc. soo....
Yeah, you're being paranoid about the wrong things, I think.
EDIT: FWIW, I was being a bit cheeky with the Fine(TM) thing, but if you get the "process" bits about encrypting the thing you send to the browser (and will be returned to you) right, you should really be in a position about as good as if the encryption itself had been compromised.
I remember that JSF(java faces) used the same __VIEWSTATE approach to preserve the state, attaching the state to every request. It may also be a great source of security vulnerabilities.
Luckily neither .net WebForms, nor JSF are popular nowadays.
I'm suprised this attack is even possible. Disabling of the viewstate MAC validation is disallowed, since a while [1]. However, MAC validation is apparently circumvented because the ViewStateUserKey is known.
Well, if you're going to a 53 degree orbit, you're in luck. But if you have a specific polar orbit, well... You'll need a special transfer vehicle package (SpaceX is partnering with Momentus), which will increase the mass you need to launch and has its own costs, making it more comparable to RocketLab.
RocketLab will let you go to whichever orbit you choose.
Also, RocketLab is pursuing reusability as well, so that may allow RocketLab to compete more directly on cost. Also, RocketLab can launch smaller payloads (in bundles with other customers) for less than the $1 million minimum SpaceX has.
Still, I think SpaceX has a sizable advantage for a lot of launches.
IF you have a payload that needs a non-standard orbit you absolutely need it to make your project work at all. Problem is that there are 50+ small launchers trying to make it and with the big volume going SpaceX its hard to see how the economics works out for that.
The market size is growing, but not as fast as some people hopped.
> First day of first grade, I found out no one could competently read a sentence.
Isn't the standard expectation that children enter first-grade completely illiterate? I remember learning how to read and write letters one per lesson in first grade.
I'd guess that maybe 5% are taught to read by parents?
I think schools even discourage parents teaching their kids to read, even in wealthy suburban, college oriented districts. But some do anyway, and it could be more than 5% especially if you only count those that end up being strong readers.
A theory my parents had was that the limiting factor in teaching a child to read is not the mental capacity, but their eyesight - supposedly it's normal to start out relatively farsighted and unable to focus on small print close up. So they started me and my sister on words printed in very large letters and gradually reduced them.
For the places that have it, I think kindergarten is where you're expected to first learn. Mine was in the same building as 1st through 6th grade.
(I was taught by my parents before even that, and when I started school they didn't believe my parents' claim - had to prove it by reading a new book aloud to them)
> > SpaceX Is Lobbying Against Amazon’s Internet-Beaming Satellites
> Amazon is trying to get a waiver to FCC rules that companies like SpaceX and OneWeb had to follow.
Title is more than a little misleading. Space is a highly regulated business (for many good reasons) and forcing your competitors to comply with the rules is a very valid strategy.
If Amazon isn't willing to wait for the next round of licensing, and play the same rules, then I'd think that shows their intentions are to dominate the competition at whatever the cost.
This article, in general, renews my concerns over the space junk problem. It's depressing how much trash is already in orbit.
I don't see how satellites in very low orbit will contribute to the space junk problem. After a few years they fall down and burn up in the atmosphere. Even if they didn't burn up, it wouldn't stay in orbit, they aren't high enough to get stuck.
I for one am excited to see the day where the entire globe is connected finally. There's only so many places wires and towers will reach, lets fill that final (massive) gap.
> You can't force a shop owner to sell his products to you if he doesn't want to.
Yes you can, for example in cases of racial segregation.
But this refusal seems to be based on anti-trust regulation and it seems that Turkey won't be able to further penalize Google for this. People seem to be upset that a company can refuse to comply with the law and showing a sovereign government the finger.
But there is even a precedent for this: Google also refused to cooperate with Chinese search censorship and retreated from that market.
