Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

W3C Releases First Working Draft of Web Crypto API

Unknown Lamer posted about 2 years ago | from the who-do-you-trust dept.

Encryption 63

From David Dahl's weblog: "Good news! With a lot of hard work – I want to tip my hat to Ryan Sleevi at Google – the W3C Web Crypto API First Public Working Draft has been published. If you have an interest in cryptography or DOM APIs and especially an interest in crypto-in-the-DOM, please read the draft and forward any commentary to the comments mailing list: public-webcrypto-comments@w3.org" This should be helpful in implementing the Cryptocat vision. Features include a secure random number generator, key generation and management primitives, and cipher primitives. The use cases section suggests multi-factor auth, protected document exchange, and secure (from the) cloud storage: "When storing data with remote service providers, users may wish to protect the confidentiality of their documents and data prior to uploading them. The Web Cryptography API allows an application to have a user select a private or secret key, to either derive encryption keys from the selected key or to directly encrypt documents using this key, and then to upload the transformed/encrypted data to the service provider using existing APIs." Update: 09/19 00:01 GMT by U L : daviddahl commented: "I have built a working extension that provides 'window.mozCrypto', which does SHA2 hash, RSA keygen, public key crypto and RSA signature/verification, see: https://addons.mozilla.org/en-US/firefox/addon/domcrypt/ and source: https://github.com/daviddahl/domcrypt I plan on updating the extension once the Draft is more settled (after a first round of commentary & iteration)"

cancel ×

63 comments

Client/Server support? (1)

mozumder (178398) | about 2 years ago | (#41375147)

Anyone know which browsers & httpd's are planning support for this soon? Webkit?

Re:Client/Server support? (5, Insightful)

InvisibleClergy (1430277) | about 2 years ago | (#41375451)

Chrome will probably put in an update which contains this when nobody's looking. Firefox will update two weeks after Chrome. And IE will take another two years, and their interface for it will be completely broken. Opera will have already had it implemented a month before everybody else, but nobody cares because nobody uses Opera.

Re:Client/Server support? (2)

Archenoth (2592069) | about 2 years ago | (#41375645)

I love how hilariously likely that comment is, but it also makes me kinda sad since I use Opera. :(

Re:Client/Server support? (-1, Flamebait)

InvisibleClergy (1430277) | about 2 years ago | (#41376033)

I love how it was upmodded as insightful, but it's really just dumb humor.

Re:Client/Server support? (1)

mr_goodwin (220609) | about 2 years ago | (#41377717)

You'll notice that this is from David Dahl (at Mozilla)... with a Googler as co-author. Maybe Firefox will get there first.

Re:Client/Server support? (2)

NevarMore (248971) | about 2 years ago | (#41375523)

Safari, Chrome, Firefox, and IE will all support this...in slightly different ways.

Re:Client/Server support? (4, Insightful)

daviddahl (553513) | about 2 years ago | (#41375611)

We have Microsoft, Google and Mozilla all deeply involved in the Working Group. I expect this will be a "webkit" patch, and hopefully land in all webkit browsers. Some initial experimentation has been done by me in Gecko in bug 649154: https://bugzilla.mozilla.org/show_bug.cgi?id=649154 [mozilla.org]

obvious question (-1)

smallfries (601545) | about 2 years ago | (#41375149)

(that I'm too lazy to read the article for) is does this mean an end to passwords, and the beginning of proper identity management in the browser. I would love to authenticate myself once to the browser, and then have it negotiate identities with each website.

Re:obvious question (3, Interesting)

PmanAce (1679902) | about 2 years ago | (#41375253)

Just wondering how would you authenticate yourself with your browser? A username password authentication? If not, what would happen if someone else used your browser and had access to everything of yours?

Re:obvious question (2)

daviddahl (553513) | about 2 years ago | (#41375757)

You will create keypairs and exchange public keys via a web app. Via the API, you will be able to create digital signatures to help with user verification. This API is not being promoted as a silver bullet for security and privacy, however, when used in conjunction with other browser features like CSP ( http://www.w3.org/TR/CSP/ [w3.org] ) - and I imagine new browser features we still need to figure out (perhaps secure input and reading widgets), we hope to enable more secure web applications. I want to underscore that this API is just the first piece of the pie. Taming and being able to trust the DOM is not going to be easy.

Re:obvious question (1)

OdinOdin_ (266277) | about 2 years ago | (#41427695)

How you secure your keyring is upto you.

Most users will like the convienence of a single password model, but this time that password never leaves the device you are using. Still at risk to keyloggers just like before.

You could if you wanted secure your own secret keyring using a mixture of methods, such as a combined smartcard, password and biometrics. The biometric code unlocks data on a smartcard, the smartcard provides part of the data to the browser and the password entered into the computer completes all the necessary information needed to gain access to the keyring (that maybe stored on smartcard or on computers).

But the point is you get to decide how secure you want to make your keyring, you no longer have to hope the website you are using is understands how to do things securely. Also each website by default will have their own unique key and it is infeasable to brutre force the authentication.

Re:obvious question (4, Informative)

FilmedInNoir (1392323) | about 2 years ago | (#41375287)

No, The Cryptocat Vision statement explains it a lot better.
Basically it's for when your so paranoid that you fear even your cloud service app provider.
For example, you go and use Cloud Doc Editor and write some docs and save them locally...
But what about the remote server? What's it doing with that data? Is it making copies?
Could it know you write erotic fan-fic about Captain Picard having sex with Rainbow Dash?

Re:obvious question (0)

Anonymous Coward | about 2 years ago | (#41376149)

I'd read that if it had a decent plot.

Re:obvious question (1)

firewrought (36952) | about 2 years ago | (#41376183)

Basically it's for when your so paranoid that you fear even your cloud service app provider.

Maybe. The W3C draft lists "Cloud Storage" as one of its use cases [w3.org] , but remember that the app provider is also delivering the JavaScript that runs the decryption and loads up the DOM, so it could intercept the plaintext or decryption key if it wished. It doesn't protect against a malicious cloud service app provider, but it does make it easier for them to secure against data breeches (if their backups were stolen, for instance) and/or rely on 3rd party storage providers.

This has really interesting implications for online privacy, but the more practical/mundane benefits will be in reducing server CPU and making backend storage more secure.

Re:obvious question (0)

Anonymous Coward | about 2 years ago | (#41376965)

Finally, my stories about blue horsebird will be secured from the prying eyes of Google. This is truly a redletter day. /me uploads redletterday.md to the cloud

Re:obvious question (1)

DragonWriter (970822) | about 2 years ago | (#41375335)

does this mean an end to passwords, and the beginning of proper identity management in the browser.

Probably not. Encryption-in-the-DOM doesn't really do much for that (and, anyway, SSL client certificates for authentication do more for that, but almost no one uses them.)

Re:obvious question (1)

InvisibleClergy (1430277) | about 2 years ago | (#41375425)

No it doesn't. It's just for crypto between server and client.

Re:obvious question (0)

Anonymous Coward | about 2 years ago | (#41375679)

It's for a lot more than that. This API is specifying a full suite of cryptography tools. There's symmetric encryption, asymmetric encryption, signing, hashing, key generation, message authentication, secure random number generation...the works. You could use this API for anything you would want to use encryption for, showing what you want only to who you want and hiding it from everyone else. Even hiding it from the server if you want.

And yes, you could even implement something that would let you never type a password again.

Re:obvious question (2)

jamiesan (715069) | about 2 years ago | (#41375855)

boiled encryption, baked encryption, encription scampi, fried encryption, grilled encryption..encryption cocktails.

Re:obvious question (1)

GuldKalle (1065310) | about 2 years ago | (#41380859)

Well, there's encryption egg sausage and encryption, that's not got much encryption in it.

Re:obvious question (-1)

Anonymous Coward | about 2 years ago | (#41375765)

I don't want my "identity" managed using a spec developed by a consortium of interests who want to implement universal identification and tracking.

Passwords may be broken for those too stupid to choose proper passwords and not re-use them, but they work fine for those of us who don't want FB or G+ intruding into our private lives.

Mark my words: if "identity" functionality gets any support from big industry, it will be because it is in their interests, not ours.

So, Why? (1)

FilmedInNoir (1392323) | about 2 years ago | (#41375181)

Eventually at some point I would hope there's a backend server the app is talking to.
Why can't the server do it? Thin Client Fat Client... Why are you making my client fat Sir?

Re:So, Why? (4, Informative)

DragonWriter (970822) | about 2 years ago | (#41375445)

Why can't the server do it?

If the server does the encryption, then the server has to see the unencrypted content.

If the client does the encryption, the server doesn't have to see the unencrypted content.

Also, if the server does the work and you have a million clients, then the server has to do a million units of work rather than the clients each doing one unit of work. This can make the server more impacted by traffic spikes and provide a less-consistent and sometimes lower-quality user experience than just offloading that work to the client.

Alternatively, its more expensive (more CPU = more $$) for the server operator, who often owns the app. So there's an incentive to build apps in a way that the work is offloaded.

Re:So, Why? (1)

InvisibleClergy (1430277) | about 2 years ago | (#41375481)

The server can't decrypt the page for you. That would eliminate the entire point of encrypting the page in the first place. The server encrypts the page and gives it to you, then your browser decrypts it using this interface specified by the W3C. Are you actually dumb, or is that just a hobby?

Re:So, Why? (1)

icebraining (1313345) | about 2 years ago | (#41375825)

That's SSL and has been here for 17 years. This API is useful for other stuff, like data that never leaves the client unencrypted.

Re:So, Why? (1)

Lennie (16154) | about 2 years ago | (#41376397)

This is more about encrypting your data in the client and storing data encrypted on the server. So when a server compromise happends your data can't be easily stolen.

I remember thinking about implementing this... (3, Interesting)

InvisibleClergy (1430277) | about 2 years ago | (#41375379)

It was because NearlyFreeSpeech doesn't support HTTPS, and I wanted to implement some sort of encryption. So, I figured that my server could encrypt pagelets and send them, and then the client could use a previously-established key to decrypt the pagelets, attaching them to the DOM structure in a logical way. The problem is, since JavaScript explicitly disallows XSS, I couldn't figure out a way to contact a separate key authority server. This meant that however I did it, I'd be (more) vulnerable to a man-in-the-middle attack.

Looking this over, it looks like this specification doesn't solve that issue. I know that key authorities can be compromised, but it's better to require two points of failure rather than one.

JavaScript and XSS (2)

DragonWriter (970822) | about 2 years ago | (#41375643)

The problem is, since JavaScript explicitly disallows XSS, I couldn't figure out a way to contact a separate key authority server.

JavaScript doesn't "explicitly disallow XSS". Most browsers (through implementations of the still-in-draft Content Security Policy, and, for IE, additionally through its own "XSS filter") include means of restricting XSS, but those browsers also allow pages to control whether and how those XSS-limiting features are applied.

Re:JavaScript and XSS (2)

spottedkangaroo (451692) | about 2 years ago | (#41375719)

There are also xss allow headers you can send in the http headers, called "http access control" and you can also get around it with things like JSONP.

Re:JavaScript and XSS (2)

jedwidz (1399015) | about 2 years ago | (#41383811)

Expanding on that JSONP mention to hopefully save someone a googling...

XMLHTTPRequest calls are subject to single-origin policy, so can't be used for XSS. However, SCRIPT tags don't have this restriction, even for tags that are dynamically created using JavaScript. JSONP is a trick that leverages this to implement XSS.

The main limitation is that JSONP can't be used to call non-JSONP web services. So changes to the third-party service may be needed in order to support JSONP.

As an aside, dynamically loading images cross-domain is also permitted. Not useful for the current discussion though.

Re:JavaScript and XSS (1)

InvisibleClergy (1430277) | about 2 years ago | (#41376065)

Oh, derp. I don't know what I was thinking, then.

Re:I remember thinking about implementing this... (2)

dgatwood (11270) | about 2 years ago | (#41376007)

Uh... JavaScript has allowed cross-site XHR for going on four years now. It does, however, require appropriate configuration on the server you're contacting. The bigger problem with that design is that if your web hosting server doesn't support HTTPS, how will the third-party server handing out authentication tokens set the token on the server side?

No, this is better handled through a DH key exchange. Then both sides have a shared symmetric key, and both sides can store it locally (with client-side storage, *not* cookies—you don't want it getting sent in cleartext over the wire). This is actually what the website I'm developing now does. With that solution, sniffing is prevented (or, in my case, injection of unauthenticated non-replay queries to the server; I'm not encrypting the requests, just signing them).

Of course, none of that prevents active tampering (modifying the JavaScript code to send a copy to a MITM server, for example), which is why HTTPS is still a good idea if at all possible. It would be helpful if more browsers supported SSL with SNI, or if browsers supported SSL with domain keys when working with DNS servers that support DNSSEC, or both.

Re:I remember thinking about implementing this... (2)

InvisibleClergy (1430277) | about 2 years ago | (#41376271)

I was thinking about this originally in January of 2011, and I think I remember finding people mentioning XHR but not finding anything beyond scant mentions. No good "what is this and how do I do" documentation. I was originally thinking a DH key exchange, but that requires you to store it each session, which means each session is vulnerable to MitM, or to use HTML5 things that were not widespread two years ago.

Re:I remember thinking about implementing this... (2)

dgatwood (11270) | about 2 years ago | (#41379475)

Right. HTML5 local storage is a fairly recent addition. You might also have been able to use a cookie with the "secure" flag set, which means the cookie is sent only over HTTPS connections, but AFAIK can be accessed in JavaScript code locally. I'm not certain whether such cookies are accessible through JavaScript that arrived over unencrypted HTTP, though, so that might not work.

Regarding cross-origin XHR, it's pretty straightforward. It works just like regular XHR. The only difference is that the server has to send out an Access-Control-Allow-Origin [w3.org] header to indicate that the browser should be allowed to make the request. And the browser makes two requests—a HEAD request to check the ACAO header and an actual request for the URL. As a small caveat, unless they have fixed it recently, Internet Explorer requires you to use a different object, XDomainRequest [microsoft.com] .

Re:I remember thinking about implementing this... (1)

dkf (304284) | about 2 years ago | (#41384591)

Right. HTML5 local storage is a fairly recent addition. You might also have been able to use a cookie with the "secure" flag set, which means the cookie is sent only over HTTPS connections, but AFAIK can be accessed in JavaScript code locally. I'm not certain whether such cookies are accessible through JavaScript that arrived over unencrypted HTTP, though, so that might not work.

You're supposed to be able to mark a cookie as being unavailable to Javascript (well, as being only for use with HTTP connections; secure transport of the cookie is an orthogonal attribute) but that's both something I wouldn't rely on working and also easy to disrupt from JS; there's nothing to stop any cookie from being overwritten with something else. Cookies aren't designed for deep security.

Re:I remember thinking about implementing this... (1)

Riskable (19437) | about 2 years ago | (#41385225)

Tip: WebSockets don't have any cross-origin limitations. You can connect to anything from anywhere.

So there you go. Now you can make that key authority server :D

In other news... (1)

Dishwasha (125561) | about 2 years ago | (#41375473)

Microsoft releases less secure copy of W3C Web Crypto API already implemented in Internet Explorer 10 called SecureXaml while citing the changes as "features".

Re:In other news... (1)

SolitaryMan (538416) | about 2 years ago | (#41375783)

Well, it's not just Microsoft nowadays. After XHTML fiasco nobody takes W3C seriously any more.

Why do I even read news anymore? (1)

Anonymous Coward | about 2 years ago | (#41375773)

They are never, ever good. Just more stupid crap that stresses me out and makes me tired.

Secure JavaScript crypto environment? (0)

hydrofix (1253498) | about 2 years ago | (#41375969)

Douglas Crockford tends to disagree [crockford.com] . And he's not alone [matasano.com] .

How do they mitigate these inherent security problems of the JavaScript platform in the API draft? With XSS, I can always overwrite the browser's crypto API object, replacing it with a rogue implementation.

My understanding has been that JavaScript in its present form is not a viable platform for cryptography.

Re:Secure JavaScript crypto environment? (0)

Anonymous Coward | about 2 years ago | (#41376307)

You would think a "modern" browser implementing Javascript crypto would first opt to implement ECMA5 improvements like Object.seal [mozilla.org] in an effort to pre-empt those kinds of attacks.

Re:Secure JavaScript crypto environment? (0)

Anonymous Coward | about 2 years ago | (#41376319)

If the crypto code is built in to the browser, it will be very, very easy to thwart the type of attack you describe.

Re:Secure JavaScript crypto environment? (1)

Lennie (16154) | about 2 years ago | (#41376359)

I believe both Firefox and Chrome have support for:

http://www.w3.org/TR/CSP/ [w3.org]

Which allows for more control on where code should be loaded from.

Actually I think having crypto as part of the browser is a bigger chance of success then just implementing the crypto in Javascript as some people clearly have already done. You don't want to implement a cryptographically secure pseudorandom number generator in Javascript it will never be secure.

Re:Secure JavaScript crypto environment? (1)

daviddahl (553513) | about 2 years ago | (#41376845)

CSP will be a huge help in reducing attack vectors. Another thing is the key material being unavailable in the DOM. Current JS libraries do not have the option of making all key references opaque and truly hiding the private and secret key material from the DOM. This spec allows the browser to only ever reference key IDs instead of the actual key material.

Re:Secure JavaScript crypto environment? (1)

cbhacking (979169) | about 2 years ago | (#41376525)

This. Providing proper crypto primitives in the JS standard library is a good thing, I suppose, but it doesn't solve any (and I do mean any) of the underlying problems with things like CryptoCat. CC actually had quite good crypto primitives (implemented from scrach in JS, but apparently implemented well).

The problem was that every time a user wanted to use CC, they had to download the page (and its JS) from the CC server... and there are so many ways to attack that. An obvious one is to insert a backdoor in the code sent from the server (like what Hushmail did). Crypto primitives in the script library won't help here. Another obvious one is to use SSLStrip to MitM the connection, and inject your own backdoor script along with the server response. Finally, there's attacks against the SSL itself, including things like CRIME.

Essentially, the degree to which you can trust something like CryptoCat is entirely based on the degree to which you trust the server and the connection. It's still host-based security, even though it pretends not to be. No amount of making it easier to implement CryptoCat (which is what you'll get out of this change) is going to make it any more secure.

Re:Secure JavaScript crypto environment? (1)

cryptizard (2629853) | about 2 years ago | (#41376831)

Thats the point of this API I imagine. If it is included in the browser then there is nothing to intercept and replace. Also it can have some priveledged status where methods can't be overwritten by other scripts.

Re:Secure JavaScript crypto environment? (1)

cbhacking (979169) | about 2 years ago | (#41377459)

Um... no. No part of any of the attacks I described requires any interception or replacement of the crypto code (I thought I made that clear). You're still going to have to serve a webpage though. In fact, in order to use these new crypto functions, you're going to have to serve script as well.

I (the attacker, whether via MitM or server control or some other mechanism) can modify that to my heart's content. I don't even have to modify the existing scripts; just inject my own that captures every keystroke sent to the web page and sends them to a server I control (for example). All the crypto in the world won't protect you against that, no matter where it's implemented or what protections it has.

Re:Secure JavaScript crypto environment? (0)

Anonymous Coward | about 2 years ago | (#41377635)

The draft doesn't address any of the more important points at all. Some are TBD, others not even mentioned.
The basic problem (in my opinion) is one of trust, and that's always the thing crypto revolves around. You want to send something from A to B despite not trusting some other party E. Suppose you trust the server... well then you can use SSL and trust the server on getting the crypto right. Suppose you don't... well, then how are you going to know that the JavaScript the server gives you will operate the crypto API in a secure fashion? You don't, because you don't trust it.
The only way we could, possibly, make this work is if the JS + DOM of the unencrypted content were to execute completely isolated from the web or anything else and JS or other software that submits the data to the server can only get its hands on the encrypted content. But I think that at this point you're probably better off using a native application.

Re:Secure JavaScript crypto environment? (0)

Anonymous Coward | about 2 years ago | (#41383917)

All client-side encryption and decryption should take place in a sandbox that is visually unique. A crypto-tab with unique, unspoofable chrome. This crypto-tab should not be allowed to interact with the web (AJAX, deferred loading of scripts, images...) or with any other part of the browser (cookies, plugins...). The only allowed interactions with the web are initial loading of the crypto-tab and encrypted data, and final submission of an encrypted form. Of course keylogging and DOM access for the input/output fields are also blocked.

The problem with native applications is to get people to trust them and install them, and to not trust or install their evil twins. If a standardized crypto API is deployed across browsers, that's a trusted platform a site can use without depending on other insecure user actions.

MashSSL (2)

flankenstein (2663903) | about 2 years ago | (#41375979)

Why not use MashSSL? That seems like a simpler and better solution.

Why PKCS#1v1.5? (3, Interesting)

cryptizard (2629853) | about 2 years ago | (#41376093)

The API has two padding modes for RSA, PKCS#1v1.5 and OAEP. OAEP is provably secure. That is, if the underlying scheme (RSA) is a secure public key cipher, then RSA combined with OAEP is a semantically secure encryption scheme that is resistant to chosen-plaintext attacks. On the other hand, not only is PKCS#1v1.5 not provably secure, it has been known [jhu.edu] for years [cryptograp...eering.com] to be vulnerable to real world attacks.

Most of the time when you see people using it today it is for backwards compatibility, but in this case they are designing a brand new API. Why not go with the one which we know to be secure instead of encouraging the use of a dangerously vulnerable scheme?

Re:Why PKCS#1v1.5? (1)

B-Con (782416) | about 2 years ago | (#41378933)

In theory the Web Crypto API might interact with data encrypted with non-Web Crypto API applications. They may want to preserve compatibility with other APIs.

Re:Why PKCS#1v1.5? (1)

cryptizard (2629853) | about 2 years ago | (#41379165)

Well in that case they should be a note in big red letters that says "not recommended for use, backwards compatibility only" or something to that effect.

It's not a working draft... (0)

arglebargle_xiv (2212710) | about 2 years ago | (#41376117)

... it's a bunch of random thoughts. Most of the current "draft" consists of "TBD" or "here are some ideas that need to be fleshed out". This looks like it's years from reality, at which point it'll have turned into another CDSA-sized monstrosity containing the union of every feature requested by every vendor ever.

Re:It's not a working draft... (2)

daviddahl (553513) | about 2 years ago | (#41379703)

I have built a working extension that provides 'window.mozCrypto', which does SHA2 hash, RSA keygen, public key crypto and RSA signature/verification, see: https://addons.mozilla.org/en-US/firefox/addon/domcrypt/ [mozilla.org] and source: https://github.com/daviddahl/domcrypt [github.com] I plan on updating the extension once the Draft is more settled (after a first round of commentary & iteration)

Re:It's not a working draft... (1)

arglebargle_xiv (2212710) | about 2 years ago | (#41384003)

I have built a working extension that provides 'window.mozCrypto', which does SHA2 hash, RSA keygen, public key crypto and RSA signature/verification,

No offence, but that's about a hundredth of what SSLeay (the thing that came before OpenSSL) was doing 15 years ago. That's a long, long way to go before you have a general-purpose crypto API usable by web developers.

The OS (0)

Anonymous Coward | about 2 years ago | (#41376309)

Every time I read a story like this, I feel like we're getting closer and closer to the web browser implementing every feature of the OS.
Soon they will decide that they need a better way to manage tabs and build in a primitive tab manager, vaguely reminiscent of a window manager.
At some point there will be a page where you can enable and disable different extensions.
Some extensions will then open their own tab that will be handled by the tab manager.
Eventually we will decide that html is too restrictive, and someone will make an extension that translates some other markup language into html.
And so on, and so forth.

Re:The OS (1)

cbhacking (979169) | about 2 years ago | (#41377515)

Off-topic, but you can actually already run an entire Linux OS in the browser. Of course, first you have to emulate an x86-based computer to run it on.

You think I'm joking... [bellard.org]

With your powers combined... (1)

trev.norris (2010080) | about 2 years ago | (#41381123)

I'm interested to see how this would work with the WebRTC API, to allow for browser-based encrypted P2P communications.

Missing information (0)

Anonymous Coward | about 2 years ago | (#41381543)

Couldn't see in the draft anything about crypto exportation restrictions. Would it be safe to use a browser supporting this in Iran?

RSA is NOT secure (0)

Anonymous Coward | about 2 years ago | (#41382119)

sorry if you cant use aes then forget it....

Ryan Sleevi (0)

Anonymous Coward | about 2 years ago | (#41386047)

Mandy Moore regrets every day of her life for discounting his prom request.

Re:Ryan Sleevi (0)

Anonymous Coward | about 2 years ago | (#41386383)

Mandy Moore regrets every day of her life for discounting his prom request.

There should be a sandwich named after him.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...